Dual-Track LLM Pricing: Peak/Off-Peak Tiering and Subscription Premiums

As large language model (LLM) inference services move into large-scale production, pricing is no longer just a numbers game about “how much per thousand tokens.” It has become a composite signal that reflects compute cost structures, channel relationships, and market positioning. Two very different pricing approaches now coexist in the market: one attracts developers with off-peak “value” rates, while the other anchors scarce compute at premium subscription prices. They look contradictory, but each maps to a different cost model and a different position in the value chain. This article starts from the billing structures, breaks down the business logic behind both strategies, and outlines a cost evaluation and governance playbook that developers can actually use.

1. Start with the Price Sheet: How the Two Billing Structures Differ

A typical usage-based billing model distinguishes three dimensions: input (cache miss), cached input, and output. For one class of high-end inference services, the price structure looks roughly like this (illustrative figures, CNY per million tokens):

Billing item	Peak hours	Off-peak hours
Input (cache miss)	9	4.5
Cached input	0.3	0.15
Output	27	13.5

A lightweight inference service, meanwhile, can go as low as input at 1, cached input at 0.02, and output at 4 during off-peak windows. Closed-source services sold on subscription, by contrast, often quote much higher unit prices — for example, input around 20 and output around 100, with cached input around 1.3 and output around 68.

Two key details stand out from this sheet.

First, “value pricing” is conditional. Low-cost services often launch with discounted rates to acquire users, then gradually turn the discount into the standing price, and later introduce peak/off-peak tiering: fixed windows on weekdays (for example, 9:00–12:00 and 14:00–18:00) count as peak, priced at twice the off-peak rate. “Cheap” is therefore not unconditional — it requires the caller to schedule around the peaks. Only by shifting offline batch processing, evaluation runs, data cleaning, and other non-real-time workloads into off-peak windows can you actually realize the low rate.

Second, a high-priced subscription does not mean nobody is buying. Some closed-source services raised output unit prices several-fold over the previous generation, yet subscription slots remained oversubscribed — to the point of temporarily closing new sign-ups because their compute clusters were near capacity. Their annual recurring revenue (ARR) jumped from the hundreds-of-millions-of-dollars range to the billion-dollar range within a few months, with an even higher year-end target. In a window where compute is scarce and model capability leads the market, price elasticity does not follow traditional SaaS intuition.

2. Closed-Source vs. Open Weights: Who Holds the Pricing Power

To understand the pricing divergence, start by separating the two ways models are sold.

Closed-source models have a relatively simple pricing logic: only the original vendor can sell them. The price is a two-sided relationship between the user and the vendor, with no third party taking a cut or marking it up. The vendor is therefore free to run a “low-price acquisition, gradual increases, peak/off-peak tiering” sequence — or to go straight to the premium subscription route. Pricing power is highly concentrated.

Open-weight models are a completely different story. Once the weights are public, cloud providers can deploy the model themselves, and third-party inference providers can do the same, each setting its own price. Users are buying “the same model,” but the money may end up with different parties. The vendor behind an open-weight model must therefore answer one core question: when others make money with my model, can I capture any of it — and if so, how?

That question is the root of the split between the two pricing tracks. Vendors on the “value” track tend to push official prices extremely low, using the price advantage to grow call volume and win developer mindshare, then monetizing through the vendor-operated compute channel. Vendors on the “premium subscription” track lean into the scarcity of the model’s capability itself, locking in high-value users with subscriptions and converting cluster capacity directly into pricing power.

3. The Cloud Provider’s Dilemma: Why Self-Deployment Rarely Undercuts the Original Vendor

One phenomenon deserves attention: for the same open-weight model, cloud providers often list two versions side by side:

• Vendor-hosted version: priced exactly at the original vendor’s official rates, with the same peak/off-peak windows — essentially a resale of the vendor’s compute.
• Self-deployed version: deployed by the cloud provider itself, where the input unit price can run to more than double the vendor’s off-peak rate, and no peak/off-peak distinction is offered at all.

Why would self-deployment cost more? The answer lies in cost structure. The original vendor amortizes GPU costs across very large clusters and lifts utilization through prompt caching, batch scheduling, and peak shaving. A cloud provider deploying the same weights on its own must independently absorb GPU purchase or rental costs, utilization volatility, operations staffing, and the sunk cost of idle capacity. Once the official price has already been pushed very low, self-deployment can hardly win on price.

The end result is that cloud providers on these models drift toward “selling the original vendor’s compute” — some even state in their announcements that peak/off-peak pricing is “adjusted in sync with the original vendor.” This points to an easily overlooked fact: open weights do not automatically produce price competition; they can instead concentrate pricing power in the original vendor, the one player with the scale effects to sustain it.

4. The Developer’s View: How to Evaluate and Govern Inference Cost

For developers and enterprise users, the pricing split is not an abstract business topic — it is an engineering problem that directly shapes budgets and architecture decisions. An evaluation framework can be built along the following dimensions.

1. Separate real-time from non-real-time workloads. Peak/off-peak billing means a large share of the cost-optimization headroom comes from scheduling, not model selection. Queuing embedding generation, batch evaluation, log-archive analysis, and similar tasks into off-peak windows is the precondition for actually getting the low rate. Illustrative scheduling pseudocode:

def schedule_inference(task, now):
    if task.is_realtime:
        return submit_now(task)          # Real-time tasks go through immediately
    if is_peak_hour(now):
        return enqueue_deferred(task)    # Non-real-time tasks wait for off-peak hours
    return submit_now(task)

2. Watch the cache hit rate. As the price sheet shows, cached input is often an order of magnitude cheaper than uncached input. Reuse the cache wherever possible — repeated system prompts, fixed knowledge-base prefixes, stable context across multi-turn conversations — and push down the share of cache-miss input.

3. Anchor budgets to output tokens, not input tokens. Output unit prices are usually several times — sometimes more than ten times — the input price, so long-form generation and chain-of-thought workloads are dominated by the output side. Controlling generation length, setting sensible max tokens, and using shorter answer templates on non-critical paths is usually more effective than optimizing the input side.

4. Compare channel costs, not headline prices. The same model may be available through the vendor-hosted and self-deployed channels at different prices, with different peak/off-peak rules. When choosing, plug your call-volume distribution, time-of-day distribution, and cache hit rate into a realistic bill model instead of comparing the numbers on the pricing page.

5. Leave room for price changes. The progression from promotional discount to standing price to peak/off-peak tiering shows that per-token inference prices are dynamic. Architecturally, abstract model calls behind a replaceable service layer and avoid coupling business logic to any specific billing scheme.

5. Conclusion

The divergence between the two pricing strategies is, at its core, a divergence between two business logics. One holds that economies of scale and off-peak scheduling can push marginal costs extremely low, trading price for market share. The other holds that capability scarcity is itself a form of pricing power, using subscriptions to lock in high-value demand. For developers, the task is not to decide which track is “more correct,” but to understand the cost structure and constraints behind each price — and to fold off-peak scheduling, cache reuse, output control, and channel comparison into day-to-day cost governance, so that technical choices line up with budget reality. That is what keeps both your architecture and your costs elastic in a market where pricing keeps evolving.