This customer is not buying a complex platform or a one-off delivery, but a sustainable, predictable, cost-controlled Token supply outcome. The plan should first define annual demand, monthly peaks, SLA boundaries, and cost bandwidth, then decide how underlying resources will carry it.

Based on current demand, we recommend splitting the 1.8 billion Tokens into a base supply package + peak elasticity package + high-priority guarantee package, giving the customer stable supply without building a heavy foundation, while keeping capacity and cost risk on the supply side.

Resources are not the business itself. The key is not "having GPU" but whether resources have been organized into a closed loop that can be supplied, metered, settled, and operated on a rolling basis. Without stable demand, a metering basis, a settlement counterparty, and operational ownership, the project remains at the "resources without a model" stage.

A more reasonable structure at this stage is: an upfront setup fee covering project build-out, a mid-term maintenance fee covering ongoing hosting, and later Token supply and business-result sharing, allowing the project to both land and retain long-term operational headroom.

The current gross margin decline is not a single-metric regression but three compounding factors: first, the share of high-cost DeepSeek-R1 paths rose; second, research-lab tenant traffic crowded out high-priority inference capacity; and third, KV Cache hit rate dropped from 78% to 72%, further amplifying per-Token cost.

Effective throughput has risen to 18.4M Tokens/min, but this increase came more from the high-cost model service mix than from a better capacity structure. In other words, the system got "busier" without converting that into a better 34.7% gross margin.

If traffic rises 30% tonight, pool-a100-prod will be the first to hit a bottleneck. It is already running at 86% utilization, and over the last 24 hours it has been serving high-value DeepSeek-R1 and MiniMax-M1 requests; once traffic continues to climb, sellable capacity is expected to sustain only 2.4 more hours.

The recommended order is not to scale up directly but first reroute, then apply rate limits or shift low-value requests to lower-cost model pools, and only then evaluate supplementing pool-a100-prod. This avoids protecting system metrics at the expense of ROI.

Root-cause summary: the 19:42 to 20:05 anomaly was jointly triggered by KV Cache reuse decline + pool-a100-prod queue backlog + research-lab peak traffic surge, which raised TTFT, pushed queue depth up to 184, and amplified SLA jitter on the DeepSeek-R1 latency-priority path.

Mitigation recommendation: first shift low-business-value traffic to the GLM-4.5 balanced route, enable the cache protection policy, then rate limit the high-priority route. For structural policy changes, go to the admin backend to execute explicitly.

1. Overall SLA today held at 99.93%, but peak windows had a slight jitter, concentrated on the high-cost DeepSeek-R1 path.

2. Effective throughput has reached 18.4M Tokens/min; system capacity has not dropped, but the share of high-cost models rose and pulled gross margin down to 34.7%.

3. The research-lab tenant is occupying an outsized share of high-priority inference capacity without proportional revenue contribution, and is already eroding sellable capacity.

4. Cache hit rate dropped to 72%, directly raising TTFT and queue depth. Performance is closely tied to cache reuse decline.

5. Recommend comparing DeepSeek-R1 and GLM-4.5 routing combinations first, generate the business analysis report, and then have the platform team execute explicit policy changes in the admin backend.

Desktop should not just be a magnified mobile digest; it should use the wide screen to keep recent chats, the main analysis process, pinned summaries, and the action area on a single workspace, reducing tab-switching and context loss.

A more suitable layout is: left rail for continuous context, center for deep analysis, right rail for pinned business & capacity summaries, letting duty operators judge and act on the next step without hunting for information across pages.

The rise is not mainly because DeepSeek-R1's "model price" itself changed, but because it has been placed in the latency-priority service template + pool-a100-prod high-cost combination, while cache hits declined, causing it to hit the expensive path more often.

Yes, it is the same capability set. The digital human is a different interaction carrier, while the underlying Copilot still shares the same context understanding, analysis capability, recommendation output, and artifact generation. It is especially suited to reception, presentation, exhibition, or training scenarios, where business summaries, SLA risks, and capacity recommendations can be communicated more naturally.

We recommend starting with partial traffic shift, not a one-shot full switchover. For low-business-value or non-real-time requests, the GLM-4.5 / balanced route can significantly lower per-Token cost; SLA-sensitive traffic such as Risk Control should stay on the stable DeepSeek-R1 path.

The most notable right now is research-lab. It occupies the largest share of high-priority inference capacity, but its revenue and business value growth do not match that share, so it is indirectly eroding the SLA guarantee headroom of high-value GPU pools for key tenants.