目录

Alibaba Execs Hold Emergency Meeting, Jack Ma Talks AI: The LLM Race Enters Its “Mid-Game”

“The head of the Qwen model steps down,” “executives hold an emergency meeting to answer questions,” “Jack Ma and the core management discuss AI”—when these three headlines appeared on the same day, any engineer who has slogged through the AI track could smell something unusual in the air.

Background: Why Should Engineers Care About These Headlines?

As someone who works in tech, I scan industry news every day, but today’s batch from 36Kr made me set down my coffee. On the surface, these are a few unrelated corporate stories: a personnel change in Alibaba’s LLM division, a capital acquisition of a coffee brand, Jack Ma showing up at a school. But if you look at them against the backdrop of China’s LLM race entering deep waters, a clear signal emerges: the first phase of the AI arms race—“staking out territory”—is over, and the second phase—“intensive cultivation”—has officially begun.

As one of the domestic leaders in LLMs, Alibaba Cloud’s Tongyi Qianwen really did run fast over the past year. But “fast” is a double-edged sword—technical debt, team friction, and commercialization pressure snowball over time. Lin Junyang’s departure and the executives’ emergency meeting are, at bottom, the organization adjusting the tempo of its technological development. And Jack Ma talking about AI in public for the first time in years is an even stronger signal: Alibaba’s emphasis on AI has been elevated to the highest strategic level.

It reminds me of the cloud-computing wars around 2015, when everyone expanded madly and then entered a period of adjustment. Today’s LLM track is replaying that script.

Technical Breakdown: The “Impossible Triangle” of LLM Teams and Architectural Evolution

Anyone who has built enterprise-grade systems knows that every technical team faces an “impossible triangle”: development speed, system stability, and technical foresight—you can rarely have all three at once. LLM teams especially.

1. The Evolution Path of Tongyi Qianwen’s Architecture

Based on public information and our technical observations, Tongyi Qianwen’s architectural evolution has roughly gone through three stages:

Stage 1 (2022–early 2023): Catch-up
Architecture traits:
- Transformer-based dense model
- Parameter scale: hundreds of billions
- Training framework: in-house + open source combined
- Core goal: match GPT-3.5, achieve 0 to 1

Stage 2 (mid-2023–early 2024): Differentiation
Architecture traits:
- MoE (mixture of experts) architecture introduced
- Multimodal capability integration (text, images, code)
- Inference optimization and cost control
- Core goal: find commercialization scenarios

Stage 3 (2024–now): Deep waters
Architecture traits (speculation):
- Model family (different sizes for different scenarios)
- Extreme optimization of inference performance
- Deep integration with existing enterprise systems
- Core goal: profit at scale

2. Why Are We Now Entering “Deep Waters”?

From an engineering standpoint, LLM development has moved from the “alchemy” stage into the “engineering” stage. Early on the focus was “get the model built”; now it’s “get the model used, and used well.”

There’s a key technical turning point here: once model parameters exceed a certain scale, performance gains are no longer linear but subject to diminishing marginal returns. At that point, brute force alone (“throw more compute at it”) is no longer enough; you need finer-grained architectural design.

# A simplified model performance evaluation function
def model_performance(params_size, architecture_score, data_quality, engineering_maturity):
    """
    A simplified model of LLM performance
    params_size: parameter count (hundreds of billions)
    architecture_score: architecture design score (0-1)
    data_quality: data quality score (0-1)
    engineering_maturity: engineering maturity (0-1)
    """
    # Early: parameter count dominates
    if params_size < 500:  # 500 billion parameters
        return params_size * 0.7 + architecture_score * 0.3
    
    # Middle: architecture and data start to matter
    elif params_size < 1000:
        return params_size * 0.4 + architecture_score * 0.3 + data_quality * 0.3
    
    # Deep waters: engineering and refinement dominate
    else:
        return params_size * 0.2 + architecture_score * 0.25 + data_quality * 0.25 + engineering_maturity * 0.3

This simple model illustrates one point: once parameter count reaches a certain scale, piling on more parameters yields steadily worse returns, while the importance of architecture design, data quality, and engineering maturity rises sharply.

3. How Should Organizational Structure Match Technical Architecture?

Technical architecture determines organizational structure. In the early days of LLMs, you needed a strongly tech-driven “special forces” unit to break through quickly. But once the technology enters deep waters, you need a more stable “regular army” to fight a protracted war.

Early team structure (special forces model):
Tech lead → Algorithm group → Engineering group → Data group
Traits: flat, fast decision-making, tech-oriented

Deep-water team structure (regular army model):
Product committee → Architecture group → Algorithm engineering dept → Application engineering dept → Quality & Ops dept
              ↓
          Platform middle-office group
Traits: matrix-style, standardized process, business-oriented

Lin Junyang’s departure most likely means Alibaba’s LLM team is transitioning from “special forces” to “regular army.” Such a transition necessarily comes with growing pains, which is why executives needed an emergency meeting to steady the troops.

My Cool-Headed Take: Three “Technical Debt” Traps of LLMs

As someone who has lived through multiple technology cycles, I want to share a few sober thoughts:

1. The Technical Debt of “Leaderboard Culture”

Domestic LLMs have a rather amusing phenomenon: everyone is extremely keen on climbing every kind of evaluation leaderboard. But anyone who has built enterprise-grade systems knows there’s often a gulf between leaderboard scores and the real user experience.

I’ve seen far too many teams pour a disproportionate amount of R&D resources into gaining 0.1 point on some leaderboard, when users can’t perceive those gains at all in real scenarios. This is textbook “technical debt”—sacrificing long-term maintainability for short-term metrics.

2. The Integration Trap of “Multimodality”

Every LLM now talks about multimodality, but multimodality isn’t simply “text + image + audio” glued together. True multimodality requires a reconstruction of the underlying architecture.

# Wrong multimodal implementation (naive concatenation)
class NaiveMultimodalModel:
    def __init__(self):
        self.text_model = load_text_model()
        self.image_model = load_image_model()
        self.audio_model = load_audio_model()
    
    def process(self, input):
        # Each modality processed independently, then simply fused
        text_result = self.text_model.process(input.text)
        image_result = self.image_model.process(input.image)
        return combine_results(text_result, image_result)

# Correct multimodal implementation (unified representation)
class UnifiedMultimodalModel:
    def __init__(self):
        # Unified encoder and decoder
        self.unified_encoder = UnifiedEncoder()
        self.unified_decoder = UnifiedDecoder()
    
    def process(self, input):
        # All modalities encoded into the same space
        unified_representation = self.unified_encoder.encode(input)
        # Unified decoding
        return self.unified_decoder.decode(unified_representation)

Many teams, in order to ship multimodal features fast, choose the first, naive-concatenation approach, which creates enormous integration costs later.

3. Technical Compromise Under Commercialization Pressure

This is the most realistic problem. When investors need to see returns, technical teams are often forced into compromises:

• Skipping necessary security reviews to ship fast
• Using lower-quality data to cut costs
• Building custom work that breaks architectural consistency to satisfy client demands

Jack Ma showing up to talk about AI is very likely about balancing “technical ideals” against “commercial reality.” After all, technology without commercial returns can’t be sustained.

Lessons for Product Builders: From Tech-Driven to Scenario-Driven

Based on the analysis above, here are a few suggestions for teams building LLM-related products:

1. Find Your “10x Advantage Scenario”

LLMs are now a red ocean, and the window for general-purpose models has closed. But vertical scenarios still hold plenty of opportunity. Don’t think “build a general model better than GPT”—think “in some specific scenario, my model can be 10x better than GPT.”

For example:

• Legal documents: precise understanding of legal clauses
• Medical diagnosis: professional analysis of medical imaging
• Software development: deep support for a specific tech stack

2. Build a Data Flywheel with a Closed Loop

Competition in LLMs ultimately comes down to data. But data isn’t static—it’s dynamic.

Users use product → generate interaction data → clean & label data → iterate & train model → improve product experience
      ↑                                                          ↓
      └──────────────────────────────────────────────────────────┘

Design a data flywheel like this: the more users use it, the better the model; the better the model, the more users use it.

3. Pay Attention to Engineering Optimization of “Edge Cases”

Many teams only focus on the model’s “average performance,” but the actual user experience is often decided by the “worst case.”

# Wrong optimization direction: only optimize average performance
def evaluate_model(model):
    scores = []
    for test_case in test_cases:
        scores.append(model.performance(test_case))
    return np.mean(scores)  # only focus on the mean

# Correct optimization direction: also watch the worst case
def evaluate_model_professionally(model):
    scores = []
    for test_case in test_cases:
        scores.append(model.performance(test_case))
    
    return {
        'mean': np.mean(scores),  # average performance
        'p95': np.percentile(scores, 95),  # 95th percentile performance
        'p5': np.percentile(scores, 5),  # the worst 5% of cases
        'variance': np.var(scores)  # performance stability
    }

In a real product, that worst 5% often determines whether users are willing to keep using your product.

4. Build a “Explainability” Trust Mechanism

LLMs are a black box, but a product can’t be one. Especially in B2B scenarios, clients need to know “why the model gave this answer.”

This isn’t just a technical problem—it’s a product-design problem. For example:

• Provide confidence scores
• Show the reasoning process (where possible)
• Offer similar case references
• Allow human intervention and correction

Conclusion: The Second Half of AI Is “Intensive Cultivation”

Back to the news at the start: Alibaba’s series of moves is really a microcosm of China’s AI industry entering its second half. The first half was “staking out territory”—the contest was who ran faster; the second half is “intensive cultivation”—the contest is who lives longer.

As someone who has run marathons for over a decade, I know well the difference between sprinting and long-distance running. Sprints rely on explosive power; long runs rely on rhythm and endurance. This LLM race now looks much more like a marathon.

When Jack Ma talked about AI at Yungu School, he said: “AI is not about replacing people, but about making people stronger.” That line carries a lot of meaning. Technology must ultimately return to human value—solving real problems, creating real benefits.

For every engineer on this track, my advice is: forget the flashy buzzwords, return to the most basic engineering principles, and solve the most practical user problems. LLMs are not the goal but the means. The real value isn’t in the model itself but in what problem you use it to solve.

Just like Blue Bottle Coffee being acquired—coffee is fundamentally a beverage, not a capital game. AI is fundamentally a tool, not a technical show-off. Whoever grasps this essence better will go further in the second half of AI.

After all, tech waves come and go, but users’ pursuit of “it just works” never changes.

中英对照

文章作者：阿文

文章链接： https://www.awen.me/post/926515bc.html

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