China's Open-Source Large Models: The Technical Logic of Going from 'Full-Throttle Sprint' to 'Deep Squat'

目录

“Why isn’t it out yet? Llama 3.1 next door is already open-sourced — what is DeepSeek V4 waiting for?” — this is a common sentiment in China’s AI developer community lately.

As someone in tech, I understand this expectation very well. At this time last year, China’s open-source large models were on a “one release a week” cadence, with headlines like “world’s first” and “China’s strongest” everywhere. But now, as Meta’s and Google’s open-source models iterate faster and faster, we’ve instead slowed down. What exactly happened behind this? A technical bottleneck, or a strategic adjustment?

1. Why Has “Slowing Down” Become a Problem?

To understand this, we first need to see how we “sped up.”

2023 was China’s large-model “year of the full-throttle sprint.” From ChatGPT igniting the market to domestic vendors rapidly following, the open-source community saw a new model almost every month. The rhythm back then was: first a 7-billion-parameter version, then quickly iterating to 13 billion, 34 billion, even 70 billion. Developers were busy “alchemy-ing,” and the community brimmed with excitement over “topping SOTA again.”

But in 2024, things started to change. As foreign open-source models kept breaking through on parameter scale, multimodal capability, and inference efficiency, the domestic open-source rhythm slowed markedly. DeepSeek V3 has been out for a while, yet V4 shows no sign of appearing. Vendors like Zhipu and Baichuan are also adjusting their open-source cadence.

Why has this “slowing down” become a problem?

1. The developer ecosystem needs continuous stimulation: the activity of an open-source community depends heavily on the stimulus of new technology
2. Commercialization pressure is growing: the upfront investment is huge, and a path to returns needs to be seen
3. The technical gap may widen: if the iteration speed can’t keep up, we may fall behind on key technologies

But is it really “slow”? Or was our earlier understanding of “fast” too shallow?

2. Technical Breakdown: The “Triple Gate” of Large-Model Iteration

From an engineering standpoint, large-model iteration is far more than “adding parameters.” Anyone who has built enterprise systems knows that once system complexity reaches a certain point, linear scaling hits a bottleneck. Large-model development is even more so.

1. The data bottleneck: the shift from “quantity” to “quality”

In early model training, data scale was the main bottleneck. But as high-quality Chinese data got consumed quickly, the problem changed:

# Early: quantity of data first
def early_stage_data_collection():
    data_sources = ["Chinese web crawl", "public papers", "encyclopedia data"]
    # used directly after simple cleaning
    return process_data(quantity_first=True)

# Now: quality of data first
def current_stage_data_collection():
    data_sources = [
        "high-quality textbooks", 
        "specialized-domain literature",
        "human-annotated dialogue data",
        "synthetic data (quality must be verified)"
    ]
    # requires complex quality filtering and balancing
    return process_data_with_quality_control()

Key changes:

• Low-quality data went from “useful” to “harmful” — it pollutes the model
• Data diversity requirements are higher — not just general text
• Data copyright and compliance issues have come to the fore — you can’t just use anything

2. The architecture bottleneck: MoE is not a panacea

The Mixture of Experts (MoE) architecture lets model parameters break through the trillion mark, but at what cost?

Traditional dense model architecture:
[input] → [Transformer layer ×N] → [output]
Pros: stable training, consistent inference
Cons: low parameter efficiency

MoE architecture:
[input] → [router] → [expert1|expert2|...|expertN] → [aggregate] → [output]
Pros: large parameter scale, high computational efficiency
Cons: unstable training, expert imbalance, fluctuating inference latency

The MoE architecture has already been applied in DeepSeek V3, but for V4 to break through further, it needs to solve:

• The expert-specialization problem: how do you make different experts truly learn knowledge from different domains?
• The routing-optimization problem: how do you ensure inputs are assigned to the most suitable expert?
• Training stability: MoE’s training curve is “bumpier” than a dense model’s

3. The inference-efficiency bottleneck: parameter growth ≠ capability growth

This is the most easily overlooked point. As model parameters grow from a hundred billion to a trillion, inference cost may increase 10x while capability may improve only 20%.

# Inference cost model
def inference_cost_model(params, seq_length):
    # memory footprint ≈ 2 * params * dtype_size
    memory = 2 * params * 2  # assume FP16
    
    # compute ≈ 2 * params * seq_length
    flops = 2 * params * seq_length
    
    # actual latency is also limited by memory bandwidth
    latency = max(flops / compute_capacity, 
                  memory / memory_bandwidth)
    
    return {
        "memory_gb": memory / 1e9,
        "flops": flops,
        "estimated_latency_ms": latency * 1000
    }

# hundred-billion params vs trillion params
print("100B model:", inference_cost_model(100e9, 1024))
print("1T model:", inference_cost_model(1e12, 1024))

The output shows that a trillion-parameter model’s inference cost doesn’t grow linearly but exponentially. This means:

• Ordinary developers simply can’t afford it
• Commercial adoption is difficult
• Ecosystem-building is blocked

3. Cool-Headed Thinking: Do We Really Need a “Bigger” Model?

As a tech veteran with over a decade of experience, I’ve seen far too many cooling-off periods after tech frenzies. The current large-model field may be at just such a turning point.

1. The trap of “leaderboard culture”

China’s AI community has a trait: it especially values leaderboard scores. But the problem is:

• Many leaderboards test “knowledge” rather than “intelligence”
• Models may overfit to the test set
• Leaderboard scores are disconnected from actual application results

I’ve seen far too many models that shine on leaderboards but “crash” in real business scenarios. Why? Because real-world problems have no standard answers; what’s needed is reasoning ability, generalization ability, and the ability to handle uncertainty.

2. Open source ≠ free lunch

Many people have a misconception: open-source models are a “free lunch.” But the reality is:

• Training cost: training a trillion-parameter model once may cost millions of dollars
• Inference cost: even if open-sourced, ordinary people can’t run it
• Maintenance cost: bug fixes and security updates after release all require sustained investment

Companies like DeepSeek need to find a balance between “open-source influence” and “commercial sustainability.” Burning money on open source indefinitely is not a long-term plan.

3. Rethinking the technical path

Perhaps V4’s delay is because the team is rethinking the technical path:

Traditional path: bigger → stronger → more general
Problem: diminishing marginal returns, sharply rising costs

New path thinking:
1. Specialization: don't build a general giant model, build vertical-domain experts
2. Efficiency first: under equal capability, fewer parameters, faster inference
3. Multimodal fusion: not simple splicing, but deep fusion
4. Reasoning breakthrough: from memorization to true reasoning

4. Implications for Product Builders: From Technology-Driven to Value-Driven

Based on the above analysis, I want to offer teams building AI products a few suggestions:

1. Redefine “competitiveness”

Don’t let parameter scale throw off your rhythm. Real competitiveness should be:

• Performance per unit cost: how many tokens can each yuan of inference cost process?
• Real-scenario results: how does it perform in real business?
• Usability and ecosystem: are developers willing to use it, and is it easy to use?

2. Build a “technology-product-business” closed loop

My experience building an enterprise RPA system from scratch tells me: however advanced the technology, if it can’t solve a real problem, it’s a castle in the air.

Healthy tech-product cycle:
tech breakthrough → product validation → commercial monetization → feeds back into R&D

Common death spiral:
tech showmanship → divorced from scenarios → can't monetize → R&D runs out of money

3. Embrace the “small but beautiful” opportunity

While big companies fight over parameter scale, small and mid-sized teams can focus on:

• Optimization in specific domains: vertical fields like law, healthcare, and finance
• Inference-efficiency gains: model compression, quantization, distillation techniques
• Edge deployment: letting AI run on phones and IoT devices

4. Value the data-flywheel effect

Models can be open-sourced, but data is the moat. Build your own data loop:

Users use it → behavior data collected → high-quality data annotated → model improved → better user experience

Once this flywheel spins, even if your model parameters aren’t the biggest, you can build an advantage in a specific domain.

5. Conclusion: Slow Is Fast, Less Is More

Writing here, I think of my marathon experience. My half-marathon personal best is 2 hours 2 minutes — a result I didn’t have from the start. At first I chased speed too, and ended up crashing in the first 5 kilometers. Later I learned to pace myself, to “slow down” at the right moments to adjust my breathing and refuel, and my results actually improved.

The development of large models may also have arrived at the point of needing “pacing.”

DeepSeek V4’s “lateness” may not be a lack of technical ability but a sign of technical maturity. When the industry moves from frenzy to rationality, from chasing parameter scale to chasing real value, this kind of “slowness” is actually a good thing.

As developers, we can also adjust our mindset:

• Don’t chase every newly released model
• Deeply understand the capability boundaries of existing models
• Create real value at the application layer

The future of China’s open-source large models doesn’t depend on whether we can release the “world’s biggest” model, but on whether we can build a healthy, sustainable ecosystem. When our developers can use these models to solve real problems and create commercial value, that’s the real “return of the king.”

The essence of technology is to solve problems, not create them. Sometimes, slowing down to think is more important than blindly sprinting.

中英对照

文章作者：阿文

文章链接： https://www.awen.me/post/78bc7c1b.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！