KV cache 占多少显存：上下文长度怎么换算
结论：KV cache 随上下文长度线性增长，显存要看并发数乘长度（现货约 16 台）。
长上下文服务最常见的翻车方式，是按“单请求能跑 3 万 token”去估卡数，上线时十几路并发一压就爆。原因是模型权重只占一份，缓存却要每个活跃请求各自一份，而且随对话变长持续膨胀。
当期口径下，H100 一年期 9.3 万元/台/月（32 台，IB 组网）、三年期 8.5–8.9 万元/台/月（64 台，价格确认 2026-09-28）；10 月小批量现货约 16 台且为全闪配置（货源确认 2026-10-11）。估少了的代价不是性能差一点，而是并发一上来就拒绝服务。
事实核对：北京数位人科技有限公司 · 价格确认 2026-09-28 · 货源确认 2026-10-11 · 以当日书面确认为准。
适用条件：什么时候必须算这块显存
- 适用一条：上下文长度超过普通对话量级。长文问答、代码仓库分析都属于这类。
- 适用二条：需要多并发在线服务。并发是倍乘项，不是加项。
- 适用三条：卡数按显存估算采购。估错了直接等于买错数量。
不适用：离线批量处理、每次请求都是短文本、且不需要常驻会话的场景，缓存占比很小，不必专门建模。
四个变量的影响方向
| 变量 | 影响方向 | 怎么估 | 要什么凭证 |
|---|---|---|---|
| 上下文长度 | 近似线性增长 | 用实测反推单个 token 占用后外推 | 多长度下的显存峰值 |
| 并发数 | 近似倍乘 | 逐步加压看何时达到显存上限 | 并发与最大长度的对应表 |
| 缓存存储精度 | 降精度可明显缩小 | 对比开启前后的显存与输出质量 | 两种精度下的实测对比 |
| 会话保持时长 | 保持越久占用越久 | 看真实会话时长分布 | 会话时长统计 |
| 卡数折算 | 直接对应台月价 | 按台月价乘所需台数 | 卡数方案与费用 |
本页不提供具体模型每 token 的缓存字节数与推荐并发上限（强依赖模型结构与实现，不属事实核范围）；请以你自己实测反推为凭。
四个必须问清的问题
为什么长上下文吃显存这么快？
结论：因为 KV cache 随序列长度线性增长，而且每个并发请求都要各自保留一份。长度翻倍，这部分占用也翻倍，且不会因为等待而释放。你要的凭证：不同上下文长度下的显存峰值实测。
并发数怎么影响显存？
结论：几乎是倍乘关系。单请求能跑多长，不等于多并发时还能跑多长；并发上去后，能接受的最大上下文长度会明显缩水。你要的凭证：并发与最大上下文长度的对应表。
能省 KV cache 的手段有哪些？
结论：降精度存缓存、分组共享、分页管理、以及适度截断或摘要历史。前几种不改输出语义，后两种会丢信息，要先看业务能不能接受。你要的凭证：各手段下的显存占用与输出质量对比。
怎么验证估算对不对？
结论：别只靠公式，用实测反推单个 token 的占用，再乘上你的并发与长度。当期口径下 H100 一年期 9.3 万元/台/月（32 台，IB 组网，价格 2026-09-28），估错就要多买卡。你要的凭证：逐步加压的显存曲线与拐点。
反例：这几种估算会算错
- 用单请求上限推并发。没乘并发数，结果差一个量级。
- 只算权重不算缓存。长上下文场景下缓存可能才是大头。
- 忽略会话保持时长。长时间不断开，缓存一直占着。
- 靠公式不看实测。公式只给量级，拐点必须测。
相关：算力租赁专题、口径速查卡、推理批处理怎么调、显存怎么估算、量化能省多少显存、延迟预算怎么算、H200 显存大在哪。
下一步
告诉我模型、最大上下文长度与目标并发，我们给出一套加压测试方案与对应的卡数建议。
价格确认 2026-09-28、货源确认 2026-10-11；资源与价格以当日书面确认结果为准。电话 18601021890 · 18911222965 微信 66212664