70% of Usage, 30% of Revenue: Breaking the LLM Commercialization Deadlock

In recent months, LLMs have maintained a rapid pace of iteration. New flagship models, lightweight inference models, and multimodal models are released consecutively, constantly pushing the boundaries of capabilities while driving down inference costs. Industry statistics indicate that models from emerging markets now account for nearly 70% of global token consumption; however, their corresponding share of revenue hovers around only 20% to 30%. This “scissor gap” between usage volume and revenue forces the entire industry to confront the same question: once models become fast and cheap, where does the true commercial value come from?

1. The Core Problem: Why Usage Volume Does Not Equal Revenue

Usage volume measures “consumption,” while revenue measures “willingness and ability to pay.” The misalignment between the two is typically caused by a combination of three factors:

1. Continuous price decline. As model capabilities converge, API services rapidly commoditize. Pricing becomes dictated by marginal cost rather than value, making “volume compensating for price” the industry norm.
2. Structural loss risks. Inference costs scale linearly with API calls. Once a price war drives unit prices below inference costs, higher usage volumes lead to greater losses. Scaling usage ironically becomes a burden.
3. Weak value chain positioning. Selling tokens is equivalent to selling “raw materials.” High-value-add processes, such as business workflow transformation, data governance, and outcome accountability, are captured by the application layer and system integrators.

In other words, the “70% usage, 30% revenue” phenomenon is not a model capability issue, but a value chain positioning issue. The solution lies not merely in “building stronger models,” but in a combined upgrade of business models and engineering systems.

2. The Three Dilemmas of Token-Based Pricing

2.1 Commoditization: Converging Capabilities Make Price the Only Variable

When the performance gap between flagship models on general benchmarks narrows to single-digit percentages, and the cost for customers to switch providers (primarily migrating prompts and data formats) becomes far lower than the price difference, tokens effectively become a commodity. In commoditized markets, pricing power is inevitably lost, and price wars become almost inevitable.

2.2 Cost Rigidity: Compute is a Hard Constraint

The bulk of LLM costs lies in compute: training amortization plus inference overhead. Inference overhead scales linearly with usage, and the compute cost for output tokens is significantly higher than for input tokens (as autoregressive generation produces tokens sequentially). This means vendors cannot indefinitely dilute costs through “thin margins, high volumes.” Volume growth does not automatically translate to profit growth.

2.3 Unit Misalignment: Tokens Are Not the Unit Customers Care About

Customers care about “the accuracy of a customer service quality inspection,” “the time taken to review a contract,” or “the pass rate of a coding task”—not “how many tokens were consumed.” The misalignment between pricing units and value units is the fundamental ceiling of the token-based business model.

A simplified cost model illustrates the leverage of unit pricing and engineering optimizations (the following code is illustrative and does not represent any specific vendor’s actual pricing):

def estimate_monthly_cost(
    requests_per_day: int,
    avg_input_tokens: int,
    avg_output_tokens: int,
    input_price_per_1k: float,    # Price per 1K input tokens
    output_price_per_1k: float,   # Price per 1K output tokens
    cache_hit_rate: float = 0.0,  # Context cache hit rate
    cache_discount: float = 0.5,  # Discount applied to cache hits
) -> float:
    """Monthly cost estimation based on token pricing (illustrative)"""
    input_cost = requests_per_day * avg_input_tokens / 1000 * input_price_per_1k
    output_cost = requests_per_day * avg_output_tokens / 1000 * output_price_per_1k
    cache_saving = input_cost * cache_hit_rate * cache_discount
    return (input_cost + output_cost - cache_saving) * 30
# Scenario: 1 million daily requests, 3000 input tokens, 500 output tokens
# A high cache hit rate can drastically reduce input costs, directly altering the gross margin structure
print(estimate_monthly_cost(1_000_000, 3000, 500, 0.002, 0.006, 0.6, 0.75))

This code reveals two key insights: First, at constant unit prices, costs scale linearly with usage; “driving volume” does not naturally equate to “driving revenue.” Second, engineering optimizations like cache hits and batch processing have a massive impact on actual costs—this is the core focus of the following sections.

3. Pathway 1: From Selling Tokens to Selling Solutions

The first transformation pathway is upgrading the deliverable from a “model API” to a “scenario-oriented solution.” This involves three key aspects:

• Industry Specialization: Deeply integrating general models with industry knowledge, compliance requirements, and business workflows. Examples include document element extraction in finance, process knowledge Q&A in manufacturing, and policy consultation in government. The evaluation criteria for these scenarios are business metrics (accuracy, recall, compliance) rather than public benchmark scores, naturally providing differentiation and pricing power.
• Engineering Delivery: Supporting private or hybrid deployments, paired with vector retrieval, knowledge base management, permission auditing, and log monitoring. This packages “model capabilities” into a business system that customers can directly operate, rather than just an API call they have to stitch together themselves.
• Service Operations: Shifting from “delivery as the end” to continuous operations—creating a closed loop of data feedback, performance evaluation, and model iteration. This establishes the foundation for annual subscription and performance-based revenue-sharing business models.

Platform providers like Baidu AI Cloud are strategically expanding into this layer: integrating LLM services with general engineering capabilities on the cloud, such as compute scheduling, object storage, container platforms, and log monitoring. Enterprises can deploy industry solutions without building the entire infrastructure from scratch. This indicates that the competitive focus of MaaS (Model as a Service) is shifting from a “model catalog” to a combined capability of “model + toolchain + industry templates.”

4. Pathway 2: AI Agents and the Application Layer: Upgrading “Calls” to “Tasks”

The second pathway is capturing value higher up the application stack. AI Agents are currently the most practical lever: they orchestrate multiple model calls, tool executions, and result verifications into a complete task. The customer’s perception and payment anchor shifts from “token usage” to “task completion.”

class ToolAgent:
    """Illustration: An agent orchestrates multiple model calls into a 'task'.
    The pricing and evaluation anchor shifts from token usage to task completion quality."""
    def __init__(self, tools: dict, max_steps: int = 10):
        self.tools = tools
        self.max_steps = max_steps
    def run(self, goal: str, verify) -> str:
        context = [{"role": "system", "content": goal}]
        for _ in range(self.max_steps):
            plan = self.plan(context)                    # Model plans the next action
            if plan.action == "finish":
                return plan.answer
            result = self.tools[plan.tool](**plan.args)  # Execute external tool
            if not verify(result):                       # Verify result; retry if failed
                context.append({"role": "user", "content": f"Verification failed: {result}"})
                continue
            context.append({"role": "tool", "content": str(result)})
        raise RuntimeError("Exceeded maximum steps, task incomplete")

This layer brings a crucial change in business semantics:

• Task-Based Pricing: “Pricing a resume screening report at $0.50” is far easier for business stakeholders to understand and accept than “pricing 8,000 tokens at $0.02.” It provides a clear anchor for budget approval.
• Outcome-Based Pricing: For example, “billing based on the number of successfully resolved support tickets.” This binds the revenue of the model, tools, and workflow to the business outcome, aligning the vendor’s interests with the customer’s.
• Value Evidence Chain: Task-level success rates, latency, and cost logs form operational data that continuously proves value to the customer, supporting long-term partnerships rather than one-off purchases.

Naturally, outcome-based pricing demands higher system stability and result verifiability, which circles back to the main theme of engineering capability.

5. Pathway 3: Inference Engineering: The “Invisible Battlefield” Determining Pricing Space

Regardless of the pathway chosen, unit inference cost remains the underlying variable of the business model. Standard industry optimization techniques form the current “cost-reduction toolkit”:

1. Model-Side: Weight quantization (e.g., INT8/INT4), distilling smaller models to handle long-tail tasks, and speculative decoding to accelerate autoregressive generation.
2. Service-Side: Context caching to reuse repeated prefixes (highly effective for long system prompts), dynamic batching to improve GPU utilization, and tiered routing—directing simple requests to small models and complex requests to large models.
3. Architecture-Side: Decoupling inference from storage, multi-model co-location, and elastic scaling based on load to maximize resource utilization.

When these methods are combined, unit costs can potentially drop by an order of magnitude. The commercial significance of this is twofold: vendors can either maintain healthy margins at current competitive prices, or they can possess a downward pricing capability that competitors lack. In other words, engineering capability is becoming the true moat and source of pricing power for LLM providers.

6. Selection Advice for Enterprises and Developers

In a market where “usage does not equal revenue,” the logic for selecting LLMs and platforms should be upgraded accordingly:

1. From Benchmarks to TCO: Factor input/output token distribution, cache hit rates, peak concurrency, and retry rates into a Total Cost of Ownership model, rather than just looking at benchmark scores and sticker prices.
2. From Point Solutions to Systems: Evaluate whether a platform has accompanying capabilities like vector retrieval, workflow orchestration, monitoring/alerting, and security auditing. These determine the actual distance from a demo to production.
3. Assess Switching Costs: The higher the migrability of prompts, data formats, and business workflows, the better you can avoid vendor lock-in and retain leverage during contract renewals.
4. Prioritize Small Closed-Loop Scenarios: First establish a “model + tool + verification” closed loop in a specific workflow with quantifiable business metrics (e.g., document extraction, ticket classification). Validate the ROI before scaling horizontally.

7. Conclusion: From Selling Resources to Selling Outcomes

The sentiment that “LLM providers no longer want to just sell tokens” reflects a repositioning within the value chain. The model itself is evolving from a “product” to a “component,” and the primary battlegrounds for competition are shifting to three layers: scenario understanding, AI agent orchestration, and inference engineering. The scissor gap between 70% usage and 30% revenue will not disappear on its own; it will only reward the players who率先 complete three transformations—turning tokens into tasks, tasks into results, and results into operable services. For developers and enterprises, understanding this value migration path means understanding the strategic direction and selection criteria for the LLM industry over the next two to three years.