Scaling Costs Exposed: Why Doubling Parameters Can Mean Quintupling Prices

1. The Industry Narrative Breaks: When “Bigger Means Cheaper” Stops Holding

A new flagship model from a leading LLM vendor has sparked heated discussion in developer communities over its pricing. According to circulating rate information: roughly ¥20 per million input tokens, ¥100 per million output tokens, and ¥1 per million cached tokens—an overall increase of about 5x compared to the previous generation.

To understand the controversy, we need to look at the industry backdrop first. Over the past two years, the LLM API market has followed a consistent rhythm: capabilities step up every six months, and prices step down every six months. Parameter counts have climbed from the 600B range to 1T and now reportedly approach 3T, while most vendors’ price curves have continued downward. Some models with flagship-level capabilities have pushed output pricing down to single-digit RMB per million tokens. Against this industry expectation, “parameters double, price increases fivefold” is naturally seen as a counterintuitive pricing event.

From a product timeline perspective, this vendor is a classic “aggressive scaling” player. Its previous-generation model, with roughly 1T total parameters, consistently outperformed 600B-class competitors and held its own or better against deep-reasoning versions of rival models. The community jokingly called it an “oversized edition” of an open-source flagship. The “trade scale for capability” strategy was highly successful for a while. But the turning point came when a competitor released a 1.6T-class model—also a step up in scale—yet with significantly lower pricing. The two approaches diverged completely on the “scale vs. price” coordinate plane. That is the real crux of this debate: can the cost equation of the scaling route actually balance out?

2. The Technical Cards Behind the Scaling Route: Why Parameters Keep Growing

1. Scaling Laws remain the most reliable capability lever. The widely accepted empirical rule is: given adequate data quality, model capability improves as a power law with parameter count, data volume, and training compute. Despite ongoing discussions about “high-quality data being constrained” and “inference-time compute making up the difference,” for leading vendors, expanding parameters and data is still the most certain way to raise the capability ceiling—especially in ceiling-bound scenarios like hard reasoning and long-horizon task orchestration, where a generational gap in scale is difficult to fully close with pure engineering.

2. MoE architecture rewrites the cost meaning of “large parameters.” Modern ultra-large models almost universally adopt Mixture-of-Experts (MoE) architecture: the total parameter count is enormous, but only a small fraction is activated per token (common activation ratios are in the single-digit percentage range). Therefore, “large total parameters” does not necessarily mean “expensive inference.” This explains why some vendors can expand total parameters while cutting prices: as long as activated parameters and per-token compute consumption stay within a reasonable range, marginal cost does not grow linearly with total parameters. It also means the key question when assessing whether a vendor will raise prices is not total parameters, but how much activated parameters and per-task compute consumption have changed.

3. Inference-time compute further raises effective compute consumption. If a new-generation model enables longer chains of thought, multi-round self-verification, or similar inference-time compute mechanisms by default, then the actual number of generated tokens consumed per completed user task multiplies. Even if the per-token price stays the same, task-level cost rises. When a vendor makes part of that premium explicit in the token unit price, it is arguably a more “honest” pricing approach.

3. Breaking Down the Cost Equation: What Determines the Price of a Token

The floor of model API pricing is determined by marginal cost; the ceiling is determined by market value. Understanding price inversions requires seeing two cost segments clearly.

1. Training cost: one-time investment, long-term amortization. The industry commonly uses the 6ND approximation to estimate training compute overhead (N = parameter count, D = training tokens), then combines cluster effective utilization and per-unit compute price to roughly bound training cost. This is a fixed cost that vendors amortize across all invocations over the model’s lifecycle—the larger the invocation volume and the longer the lifecycle, the thinner the per-unit amortization. This is also one reason vendors with open-source ecosystems dare to keep cutting prices: the invocation volume generated by the ecosystem itself acts as an amortizer.

2. Inference cost: the true pricing floor. During decoding, generating each token in principle requires reading all activated parameters from VRAM once, with memory bandwidth as the core bottleneck. The larger the activated parameters, the harder batching becomes, and the higher the unit cost. Meanwhile, the longer the context, the larger the attention key-value cache (KV cache) footprint, which significantly compresses the available batch size and raises equivalent cost. General engineering techniques—Prefill-Decode disaggregation, speculative decoding, low-precision quantization, KV cache compression and reuse—all hedge against these overheads, but optimization has physical limits. When scale expansion outpaces engineering optimization, marginal cost inevitably rises.

3. Why caching can be as cheap as ¥1 per million tokens. A cache hit essentially reuses already-computed prefix KV cache, skipping redundant prefill computation for the same prefix. The remaining cost is just storage and read bandwidth, with marginal cost approaching zero. By pricing cache at 1/20 of the input price, vendors are effectively guiding developers to structure stable system prompts, tool definitions, and knowledge base prefixes into reusable forms: users save money, vendors save compute—a win-win mechanism design. Conversely, the ratio of cache price to input price is also a good window into whether a vendor’s pricing is “restrained.”

A simplified formula captures the pricing logic:

unit_price ≈ (training_cost_amortization + inference_marginal_cost) × (1 + gross_margin) + market_positioning_premium

If scale expansion is not sufficiently offset by sparsification and engineering optimization, the second term pushes unit price up. If a vendor chooses to compress margin and amortize through volume, the industry convention of “bigger is cheaper” emerges. Neither route is absolutely right or wrong—it is fundamentally a choice between two sets of unit economics.

4. Two Pricing Philosophies: Cost-Push vs. Value-Based

There are roughly two explanations for the “5x increase,” and both may hold simultaneously.

Explanation A: Cost-push. If the new-generation model significantly expanded activated parameter scale, or enables deeper reasoning chains by default, per-task compute consumption rises several times over. With gross margin unchanged, price must increase. This kind of pricing is “honest” but fragile—once a competitor offers comparable capability at a lower price, user migration cost is very low, especially today when API protocols across vendors are highly compatible.

Explanation B: Value-based pricing. A flagship model anchors to scenarios that are highly capability-sensitive and relatively price-insensitive: complex task orchestration, large-scale codebase understanding, long-document analysis, and so on. The vendor deliberately widens the price gap between flagship and value tiers, letting the flagship earn margin while the lightweight tier drives volume. Here price decouples from cost, anchoring instead to the value of “how much human labor the capability replaces.”

The key point: value-based pricing only holds if the capability gap is large enough and sustainable. The original poster’s question—“Could it be overtaken by a competitor’s fully trained official release?”—is essentially a challenge to whether the generational gap can be maintained. As post-training (reinforcement learning, data recipe iteration, capability distillation) becomes increasingly important, pure parameter gaps may be closed faster than expected. This is the biggest risk of an “aggressive scaling + high premium” strategy.

5. How Developers and Enterprises Should Respond: A Task-Level Cost Evaluation Framework

Rather than debating parameters and list prices, it is better to ground evaluation in measurable task-level metrics.

1. Look at tasks, not tokens: establish a cost-per-task metric. Different models vary greatly in “first-pass success rate” on coding, long-document, and other tasks. If an expensive model reduces retries and manual corrections, total task cost may actually be lower:

def task_cost(price_in, price_out, n_in, n_out, pass_rate):
    """Task-level cost = per-call cost × expected number of calls (simplified: full retry on failure)"""
    per_call = (n_in * price_in + n_out * price_out) / 1e6
    return per_call / pass_rate
# Model A: higher unit price, but higher first-pass rate
cost_a = task_cost(20, 100, 3_000, 4_000, pass_rate=0.90)
# Model B: lower unit price, but lower pass rate and longer output
cost_b = task_cost(1, 4, 3_000, 8_000, pass_rate=0.60)
print(cost_a, cost_b)  # Which is cheaper? Run it with real business data and see

2. Make good use of caching and prefix reuse. Keep system prompts, tool definitions, and knowledge base prefixes stable to maximize cache hit rate. At ¥1 per million cached tokens, input cost in long-prefix scenarios can drop by nearly an order of magnitude—the most direct cost optimization available.

3. Tiered routing: spend money where it matters. Build a “difficulty classification → model tiering” routing layer: classification, extraction, and simple Q&A go to lightweight models; only high-value, high-difficulty branches escalate to the flagship, optionally with a low-confidence fallback mechanism. The exact compression ratio depends on task distribution and should be based on your own business logs.

def route(task):
    if task.risk == "low" and task.complexity <= 2:
        return "lite-model"
    if task.needs_deep_reasoning or task.needs_code_agent:
        return "flagship-model"
    return "mid-model"

4. Build cost observability. Log every invocation’s model, token counts, cache hit status, unit price, and task outcome into a database, forming a “quality-cost” curve dashboard. Without this foundation, any model selection discussion is guesswork.

5. Deployment form and supply chain choices. For high-volume, data-sensitive scenarios, consider self-hosting open-weight models, or a hybrid of API and managed deployment. Major cloud platforms (such as Baidu AI Cloud) offer mature general infrastructure—GPU compute, container orchestration, object storage, logging, and monitoring—that can serve as a base candidate for hybrid deployment. But final selection should still be based on your own business’s load-test data.

6. Conclusion: The End of Scaling Is Unit Economics

“Parameters double, price increases fivefold” is essentially a pricing experiment that explicitly passes scaling costs to users. Whether it succeeds does not depend on numbers on a parameter table, but on two more basic questions. First, on equivalent tasks, can the new model convert a “high unit price per million tokens” into a “low cost per task” through higher pass rates and fewer interaction rounds? Second, can this capability gap be maintained long enough in the post-training era to cover the training cost amortization cycle?

For developers and enterprises, the rational posture has never been to take sides between “scaling faith” and “cost-effectiveness faith,” but to build your own task-level evaluation system: measure pass rates with real business data, use caching and routing to lower marginal costs, and use multi-vendor strategies to retain bargaining power and exit capability. The metabolism of the model market will continue to accelerate. Only teams that hold the cost logic in their own hands will not be caught off guard by any pricing adjustment.