Peak/Off-Peak Pricing and Sold-Out Subscriptions: The Business Logic Behind LLM Pricing

I. Pricing Divergence: Two Strategies in One Market

Over the past year, the pricing strategies for LLM inference services have seen an intriguing divergence. One category of service providers focuses on extreme cost-effectiveness: attracting developers with token unit prices far below the industry average, initially penetrating the market with deep discounts, and then solidifying these discount prices as long-term rates. However, “cheap” is becoming conditional—with the introduction of peak/off-peak time-based pricing where high-peak hours cost about twice as much as off-peak hours. To get the lowest price, users must shift their usage to off-peak times.

Conversely, other providers are doing the exact opposite. The output prices of their new-generation models have increased several-fold compared to previous generations, subscription services have sold out, and some have even temporarily stopped accepting new subscriptions because their compute clusters are nearing maximum capacity. Despite this, their Annual Recurring Revenue (ARR) has multiplied within months.

On the surface, this is a conflict between “cheap” and “expensive.” Fundamentally, it is a projection of two different resource endowments, cost structures, and growth stages onto pricing. To understand this divergence, we must first examine the cost foundation of the LLM inference business.

II. The Cost Foundation of Inference Services: Why Pricing is So Sensitive

1. Compute is a rigid supply. The primary costs of inference services come from purchasing accelerated GPU clusters, data center power, and operations and maintenance (O&M). This supply is highly inelastic: from placing an order to bringing a cluster online often takes months, while demand can double in a matter of weeks. The short-term supply curve is nearly vertical, making prices naturally prone to severe fluctuations.

2. Output is more expensive than input for physical reasons. The pre-fill phase can process an entire input segment in parallel, making it compute-intensive. The decoding phase, however, generates tokens autoregressively one by one. Generating each token requires reading the full model weights and KV Cache, making it memory-intensive and impossible to amortize through parallelization. This is why the unit price for output tokens across the industry is generally several times that of input tokens.

3. Workloads are highly unbalanced over time. Office hours and evenings are peak usage times, while late night and early morning hours see vast amounts of idle compute. Once accelerator cards are purchased, they become sunk costs. During idle periods, “serving one more request is almost pure incremental revenue.” Peak/off-peak pricing targets exactly this phenomenon.

III. Peak/Off-Peak Pricing: Bringing Electricity Market Wisdom to Inference Services

1. The Mechanism. The day is divided into peak and off-peak periods, with peak prices roughly double those of off-peak. This is logically isomorphic to peak/off-peak electricity pricing: the commodity cannot be stored, supply is rigid, demand fluctuates over time, and price becomes a lever to regulate demand.

2. Value to Providers. The peak/off-peak price spread systematically pushes price-sensitive but time-insensitive workloads—such as offline batch processing, corpus cleaning, batch document summarization, and benchmark evaluation—into off-peak valleys. This “peak shaving and valley filling” improves the overall utilization rate of the cluster. Once utilization goes up, fixed costs are amortized, making low prices sustainable. In other words, today’s “cost-effectiveness” is conditional: willing to shift off-peak gets you a low price; requiring real-time responses means paying a peak premium.

3. Significance for Users. Price signals have become “schedulable” for the first time. This is similar to demand-side response in electricity markets: enterprises can migrate delay-tolerant inference tasks to off-peak periods, trading time for cost. A minimal off-peak scheduling example is as follows:

import datetime
def is_off_peak(now: datetime.datetime) -> bool:
    # Example assumption: Workdays 9-12, 14-18 are peak, rest are off-peak
    # Actual time divisions depend on the provider's billing documentation
    if now.weekday() >= 5:
        return True
    h = now.hour
    return not (9 <= h < 12 or 14 <= h < 18)
def route_task(task) -> str:
    if task.latency_sensitive:
        return "realtime_channel"      # Online requests: accept peak pricing
    if is_off_peak(datetime.datetime.now()):
        return "batch_channel_now"     # Off-peak: execute batch tasks immediately
    return "delayed_queue"             # Peak: queue and wait for off-peak execution

This scheduling logic is not complex and can be implemented using message queues and cron jobs, often yielding significant cost reductions for delay-tolerant batch tasks.

IV. Sold-Out Subscriptions and Price Hikes: The Other Side of Scarcity Pricing

1. Why Subscriptions Sell Out. A subscription is essentially “selling an uncertain volume of service at a fixed price.” When model capabilities are significantly leading and user growth is rapid, heavy users derive actual compute value far exceeding the subscription fee, shifting the overall demand curve outward. Since compute supply cannot be expanded in the short term, providers can only “stop accepting new subscriptions” to protect the experience of existing users. This is essentially a quantity control under supply rigidity—pricing mechanisms temporarily yield to queuing mechanisms.

2. Why They Dare to Raise Prices.
First, capability premium: after a generational leap in model capabilities, output prices can be raised several-fold while still retaining a large user base, proving that pricing power stems from the capability gap rather than cost-plus markup.
Second, customer filtering: high prices naturally filter for high-value scenarios—complex reasoning, code generation, long-horizon Agent tasks—where users are price-insensitive but extremely capability-sensitive.
Third, revenue validation: ARR multiplying within months shows that high pricing did not suppress revenue; instead, it accompanied an exponential revenue increase, which is typical pricing during a “capability scarcity period.”

3. The Lifecycle of the Two Routes. The cost-effectiveness route profits from scale and ecosystem: low prices attract developer density, and growing API call volumes amortize costs, betting on the dividends of continuously declining inference costs (quantization, speculative decoding, KV Cache optimization, MoE sparsification). The high-price route profits from scarcity dividends: harvesting the most valuable scenarios through generational capability gaps. However, scarcity periods eventually pass—when competitors catch up in capability and inference costs continue to drop, high-price strategies must either pivot to scale or rely on sustained capability leadership to survive.

V. Three Business Logics Behind Pricing Divergence

Putting the two routes together, we can extract three principles:

1. Pricing Power = Supply Rigidity × Capability Scarcity. The more rigid the supply and the scarcer the capability, the higher the price you can set. With abundant supply and homogeneous capabilities, you can only compete on cost-effectiveness. Price divergence is essentially a declaration of current capability and capacity.
2. Time-Based Pricing = Liberating Idle Compute via Price. Peak/off-peak pricing is not a disguised price hike; it is yield management of non-storable compute along the time dimension. The aviation, hotel, and electricity industries have long validated this logic; inference services are simply the latest application.
3. Dual-Track Subscriptions and APIs = Tiered Customer Management. Subscriptions capture stable, moderate-to-heavy individual and team users; pay-as-you-go APIs capture elastic enterprise demand. When capacity is insufficient, prioritizing existing users and pausing increments balances revenue certainty with user experience.

VI. How Enterprise Users Should Respond: Turning Price Signals into Architecture Decisions

For users, pricing divergence is not noise, but a clear optimization signal.

1. Build a Token Cost Model First. Figuring out the cost structure of a single API call is the prerequisite for all optimizations:

def estimate_cost(in_tokens: int, out_tokens: int,
                  in_price: float, out_price: float) -> float:
    """Example: price unit is USD per million tokens"""
    return in_tokens / 1e6 * in_price + out_tokens / 1e6 * out_price

Since the output unit price is usually several times that of the input, “making the model say less nonsense” is the most direct cost-reduction method: compress system prompts, limit maximum output length, and require structured, concise outputs.

2. Load Classification + Off-Peak Scheduling. Classify requests by latency sensitivity: online chats go through the real-time channel; batch summarization, vector construction, and evaluation enter a delay queue to be uniformly executed during off-peak hours.

3. Tiered Routing and Degradation. Route simple tasks to lightweight models; only use flagship models for complex tasks. Automatically degrade to a cost-effective tier during peak hours and fall back during off-peak hours to balance experience and cost.

4. Leverage Caching and Batch Processing. Reuse context caching for identical prefixes (like long system prompts); switch non-real-time tasks to batch processing modes, usually trading longer latency for a lower unit price.

5. Comprehensively Evaluate Platform Capabilities. When selecting a provider, do not just look at the unit price. Consider service stability, rate limiting and quota strategies, context caching capabilities, and billing and monitoring transparency. Taking platforms that provide LLM service capabilities, such as Baidu AI Cloud, as an example, invocation governance, observability, and security suites significantly impact the true total cost. Simply comparing token unit prices can be misleading.

VII. Conclusion

Peak/off-peak pricing and sold-out subscriptions seem like two extremes, but they are actually two solutions derived from the same compute economics under different supply and capability conditions. Pricing is strategy: low pricing is a weapon for scale, time-based pricing is a lever for utilization, and high pricing is the pricing power of scarcity. For enterprise technical teams, what truly matters is not judging who is expensive or cheap, but reading the supply and demand structure behind the price signals, and translating it into concrete architectural decisions like off-peak scheduling, tiered routing, and cache reuse—to find your own optimal solution between cost and experience.