Why LLM Inference Costs Are Surging: Is Scaling Law Breaking Down at Trillion-Parameter Scale?

    As large language models scale from hundreds of billions to trillions of parameters, inference prices are climbing instead of falling — some new-generation models now charge roughly five times more per output token than their predecessors. This article explains the technical mechanisms driving up inference costs, including growing active parameter counts, quadratic attention overhead from long-context workloads, and utilization losses caused by always-on availability requirements. It walks through the shifting unit economics with a concrete pricing example, examines when premium models justify their cost and when they do not, and offers practical guidance for developers: building internal cost baselines, optimizing prompt caching, routing requests across model tiers, and making inference cost a standing item in architecture reviews. It closes with a look at the next phase of Scaling Law — balancing capability gains against marginal cost.

    From the Parameter Race to the Cost Race

    Over the past two years, one of the defining storylines in the large model industry has been the steady expansion of parameter scale. From dense models at the hundred-billion level to sparse and mixture-of-experts (MoE) architectures with hundreds of billions or even trillions of parameters, the jump in capability has genuinely delivered more complex reasoning, stronger code generation, and more stable long-context understanding.

    At the same time, however, an issue long obscured by the “capability first” narrative is surfacing: inference costs have not fallen linearly as engineering matures — on some ultra-large models, they have risen significantly.

    A typical pricing shift has recently appeared in the industry: a new-generation large model charges roughly RMB 20 per million input tokens, about RMB 100 per million output tokens, and around RMB 1 per million cached tokens, with output prices up roughly 5x compared with its predecessor. This is not an isolated case. It reflects a broader trend: as parameter counts keep climbing, the unit economics of inference are being redefined.

    This raises a fundamental question: with Scaling Law still widely debated, does a larger model necessarily translate into proportionally greater overall returns? Or have we entered a new stage where marginal capability gains coexist with surging marginal costs?


    Why Trillion-Parameter Inference Costs More Than “a Few Extra Parameters”

    Many developers’ first instinct is: more parameters means more compute, so prices go up. The reality is far more complicated. Ultra-large models face at least the following cost-amplification mechanisms during inference.

    In a dense model, every inference typically activates all parameters, so compute grows roughly linearly as a model scales from 100 billion to several hundred billion parameters. In a mixture-of-experts architecture, only a fraction of the total parameters is activated per token — but the key problem is that the absolute number of active parameters is still growing. A model with 2.8 trillion total parameters, even if it activates only 5%–10% per token, may still push hundreds of billions of parameters through the forward pass. Compared with a previous-generation 1-trillion-parameter model, per-token compute is still substantially higher.

    This means that even with sparse designs, inference-side memory footprint, memory bandwidth pressure, latency, and hardware utilization will not stay low simply because the model is “sparse.”

    Long Contexts Bring Quadratic Attention Overhead

    New-generation models heavily promote ultra-long context windows — from 128K to 256K and beyond — and the impact on inference cost is often underestimated.

    The compute and memory overhead of standard self-attention scales roughly with the square of sequence length. Even with efficient attention implementations, KV cache management, chunked inference, and positional encoding handling for long contexts still significantly increase per-request resource consumption.

    So when output prices jump, “the model got bigger” is only part of the story: context lengths in real user requests are growing at the same time, and the two combined create a multiplier effect on per-inference cost.

    Availability Requirements Drag Down Utilization

    Serving ultra-large models is different from serving ordinary ones. To guarantee low latency and high concurrency, providers must reserve substantial inference capacity, while real traffic fluctuates between peaks and valleys. If capacity is planned for peak load, GPU and accelerator clusters sit noticeably idle during off-peak hours.

    This “paying for availability” model is ultimately passed on to users through pricing. When model weights are huge, single-instance startup is slow, and elastic scaling is expensive, providers tend to set higher unit prices to cover the cost of redundancy.


    Behind the 5x Price Hike: How Unit Economics Change

    Consider a simplified scenario in which a business consumes 100 million output tokens per day on average:

    Metric Previous generation New generation
    Output price (RMB per million tokens) 20 100
    Average daily output cost (RMB) 2,000 10,000
    Average monthly output cost (RMB) 60,000 300,000

    And that covers output only. Factoring in input tokens, cache hits, and the extra resources consumed by long contexts, the real gap can be even wider.

    Cached tokens are usually priced far below regular input tokens. The reason: if a request prefix is already cached on the server, subsequent requests can reuse earlier attention computations, reducing the amount of work required. But caching is not a silver bullet:

    • Hit rates are high only when request prefixes are highly similar;
    • For personalized conversations, complex multi-turn tasks, and dynamic contexts, the benefits drop sharply;
    • Caches require additional storage and index management, so providers use low prices to nudge users toward optimizing how they call the API.

    When evaluating model costs, therefore, do not stop at nominal unit prices. Build a cost model around actual cache hit rates, request context distributions, output lengths, and call frequency.


    Do Capability Gains Cover the Cost Increases?

    Judging from published benchmarks, ultra-large models do outperform their predecessors on complex reasoning, code generation, and multi-step planning. Whether those gains are cost-effective, however, depends on the use case.

    High-Value Tasks Can Absorb High Costs

    For scenarios such as financial analysis, drug discovery support, complex system troubleshooting, and deep code audits, even if the cost of a single inference rises from a few RMB to a few dozen, overall ROI stays positive as long as output quality improves meaningfully. In these cases, developers care more about output reliability, reasoning depth, and verifiability than about token prices.

    Standardized Tasks Cannot Sustain High Costs

    For summarization, routine Q&A, format conversion, and basic code completion, the new generation may offer only marginal improvements while costing several times more. Migrating such workloads blindly inflates per-task costs without a matching business return.

    This is why enterprises should adopt a “tiered routing” mindset: assign requests to different model sizes based on task complexity, value density, and latency requirements.


    Practical Recommendations for Model Selection

    Build an Internal Inference Cost Baseline

    Before switching to or introducing a new model, build an evaluation set from real business samples. Beyond capability metrics such as accuracy, recall, and code pass rate, record:

    • Average input tokens
    • Average output tokens
    • Average context length
    • Cache hit ratio
    • End-to-end latency
    • Failure and retry rates

    Only by putting capability and cost metrics side by side in the same table can you tell whether an “upgrade” is actually worth it.

    Invest in Cache Design and Prompt Structure

    For conversational and document-analysis applications, place stable context up front — system instructions, knowledge base snippets, summaries of past conversations — to raise prefix cache hit rates and qualify for lower cached pricing.

    Also avoid frequently editing the shared prefix. A change of even one character can invalidate the entire cached prefix.

    Adopt a Multi-Model Tiering Strategy

    Do not send every request to the most expensive model. Place a task classifier or rule engine at the entry layer:

    1. if task is simple extraction:
    2. use a lightweight model
    3. elif task requires moderate reasoning:
    4. use the previous-generation large model
    5. else:
    6. use the new-generation frontier model

    This pattern is becoming mainstream across the industry. The point is not to avoid advanced models, but to spend the advanced model’s budget where it is genuinely needed.

    Make Inference Cost a Standing Item in Architecture Reviews

    Architecture reviews used to focus on availability, scalability, data consistency, and security. Today, the inference cost of an LLM application is large enough to deserve a fixed place in that process.

    For example, in an agent workflow, every tool call, reflection step, and planning round triggers additional model calls. If an agent needs eight model interactions on average to complete one task, a 5x output price increase gets amplified further. In that case, redesign the workflow to cut unnecessary intermediate calls, or run intermediate steps on a low-cost model.


    The Next Phase of Scaling Law: From Scale Worship to Efficiency Balance

    The tension between growing parameter counts and rising inference costs does not mean Scaling Law has failed. More precisely, it may be entering a new phase: capability can still be gained through scale, but the marginal cost per unit of capability is no longer falling — and may even be rising.

    The core challenge of this phase is finding a new balance between model capability, inference efficiency, unit cost, and application value. Possible directions include:

    • More efficient sparse activation, to reduce the number of parameters activated per token;
    • Adaptive computation at inference time, spending less compute on easy tokens or easy layers;
    • Finer-grained cache reuse mechanisms;
    • Distillation and capability transfer: using ultra-large models to generate data for training mid-sized models that are cheaper to deploy;
    • Co-optimization of inference hardware and model architecture.

    A breakthrough in any of these areas could bend the current cost curve. Until then, developers and enterprises need to accept one reality: stronger models will mean more expensive inference for some time to come.

    As a result, technology selection will increasingly shift from “which model is strongest” to “which model delivers the most reliable return for a given task and a given budget.” That is not merely a cost question — it is a measure of engineering maturity.