摘要

推理服务的显存就那么多，KV Cache 却会随并发和上下文长度一路涨上去。没有配额治理，表现就是长请求把短请求挤爆、明明还有显存却 OOM、一个异常会话拖垮整卡。本文讲怎么把显存切成可管的配额、按租户与优先级分配、以及在显存见底时怎么优雅降级而不是直接崩。2026 奇点智能技术大会（11 月 20-21 日·北京万达文华酒店）AI 计算平台专题会涉及这类容量工程。

▸ 核心结论：显存问题本质是配额问题：不设上限的 KV Cache 一定会吃掉整卡，必须按租户和优先级分额度
▸ 关键权衡：配额卡得越死，长上下文能力越受限；放得太松又容易被单个请求打满。要按业务分档而不是一刀切
▸ 适合谁读：做推理引擎、网关与多租户平台的工程同学——被「又 OOM 了但显存明明没满」折磨过的人

显存配额
  账      一     显存都去哪了
  切      二     怎么把显存切成配额
  分      三     按租户与优先级分配
  降      四     见底时怎么优雅降级
  治      五     前缀复用与驱逐策略
  测      六     容量怎么压测出来
  坑      七     常见误区
  落地    八     清单与衔接大会

一、显存都去哪了

10 月月之暗面发布 Kimi K3.1 Pro，参数量到 3 万亿级并支持 100 万 token 上下文。上下文越长，KV Cache 的占用就越夸张——百万 token 的单会话 KV 足以吃掉整张卡。长上下文能力开放给所有人的另一面，是显存配额必须被认真治理。本文就聊这笔容量账。

一张卡上的显存大致分四块：模型权重（固定，量化后是主要可压缩项）、KV Cache（随并发数与上下文长度线性增长）、激活值与临时缓冲（随 batch 与序列长度涨）、以及碎片与预留。静态看权重占大头，但真正让服务崩掉的几乎总是 KV Cache——它是唯一会随请求持续增长的项，而且增长速度由用户决定，不由你决定。很多团队算容量时只算权重加一个固定余量，跑起来才发现长文本一进来余量瞬间归零。

二、怎么把显存切成配额

把显存当成一个可分的池子来管理，第一件事是划界：

1. 权重区：固定占用，模型加载时确定，不做动态调整。
2. KV 池：可增长区，设硬上限，占总显存的比例按模型大小与上下文需求定，常见是三到六成。
3. 激活缓冲：给前向计算留固定额度，这部分不够会直接报错，不能省。
4. 安全垫：留 5% 到 10% 应对碎片和突发。

划完界之后，KV 池内部再分。注意权重区也能省：量化、分片、按需加载都能腾出空间给 KV，是一笔划算的买卖。

量化对显存账的影响值得单独算一笔。权重从 fp16 降到 int8，占用直接减半，腾出来的空间可以给 KV 池，等于并发能力翻倍。代价是精度损失和可能的算子不支持。所以容量规划时应该把量化当成第一个选项，扩容是最后一个选项——先量化、再优化 KV、最后才是加卡。顺序反了会花很多冤枉钱。

一张 GPU 显存（示意）
  ┌─────────────────────────────┐
  │ 权重区（固定，可量化压缩）      │
  ├─────────────────────────────┤
  │ 激活/临时缓冲（固定额度）       │
  ├─────────────────────────────┤
  │ KV 池（可增长，设硬上限）       │
  │   ├ 前缀缓存（高频复用）        │
  │   ├ 活跃会话 KV               │
  │   └ 软超用区（优先驱逐）        │
  ├─────────────────────────────┤
  │ 安全垫 5%~10%（碎片/突发）      │
  └─────────────────────────────┘
  降级顺序：拒绝新请求 ▸ 驱逐软超用 ▸ 截断长请求 ▸ 切小模型

三、按租户与优先级分配

多租户场景下，一个租户的长文本请求把整卡 KV 吃光，其他租户全部超时，这是最典型的公平性问题。解决办法是给每个租户设 KV 额度上限，按套餐或优先级分档：

1. 硬配额：单租户最多能占多少，超了直接拒绝并返回明确错误码。
2. 软配额：允许临时超用，但进入驱逐候选队列，资源紧张时优先被清。
3. 并发上限：限制同时在跑的请求数，比限制显存更直观，也更容易向用户解释。

三者配合用。只设并发不够，因为不同请求的上下文长度差几十倍；只设显存配额也不够，因为用户看不懂「你的 KV 超了」，得翻译成「请缩短输入或降低并发」。

四、见底时怎么优雅降级

显存见底不应是 OOM 崩溃，而应是一串有顺序的降级动作：

1. 拒绝新请求，返回可重试的错误，而不是让它在队列里等到超时。
2. 驱逐低优先级会话的 KV，优先保高优先级。
3. 对超长请求自动截断或启用压缩策略，而不是直接失败。
4. 兜底降级到更小的模型或更短的上下文窗口。

关键是每一步都要可观测：拒绝了多少、驱逐了谁、降级触发了几次。没有这些数字，你根本不知道该扩容还是该优化。优雅降级的目标不是不失败，而是失败得可控、可解释、可恢复。

五、前缀复用与驱逐策略

KV Cache 的复用是降本大头。系统提示、工具定义、Few-shot 示例这些前缀在大量请求里完全相同，做前缀缓存后这部分 KV 只需算一次。工程要点有三个：前缀必须逐 token 完全一致才命中，所以模板里别塞时间戳和随机数；缓存要有 LRU 或按热度的淘汰策略，否则缓存本身也会撑爆显存；多轮对话要显式保留上一轮的 KV，别每轮重算。驱逐时优先清冷前缀、再清低优先级会话、最后才动活跃请求。

六、容量怎么压测出来

容量不能靠估，要压出来。压测设计要点：

1. 请求长度要分档混合（短 / 中 / 长按比例），全用短请求压出来的容量是假的。
2. 多轮对话要模拟，观察 KV 随轮次累积的速度。
3. 逐步加压到出现拒绝，记录「开始拒绝」与「开始超时」两个拐点，前者才是你的真实容量。
4. 单独测故障恢复：杀掉实例后剩余实例要多久才稳，这段时间能承接多少。

压测报告里最有价值的不是峰值 QPS，而是「在 P99 时延不超过 X 的前提下能扛多少并发」，这才是能写进 SLA 的数字。

另外要注意「显存占用」和「并发能力」不是线性关系。同样一张卡，上下文平均 1k 时能跑一百个并发，平均 8k 时可能只剩十几个。所以对外承诺容量时，必须绑定上下文长度的假设，否则业务侧按短上下文的容量去规划长上下文的场景，上线就会超出预期。这一点在写 SLA 时尤其要写明。

七、常见误区

几个高频坑：只看总显存占用不看碎片，明明有空闲却分配失败；把 KV 上限设成固定值却不随模型版本更新，换了模型直接崩；压测只用单一长度请求，上线后长文本一进来全盘超时；驱逐策略按 FIFO 而不是按优先级，把重要会话先清了；还有一种是配额设完就不管，业务涨了三倍配额还是老数字，最后靠加卡掩盖问题。这些坑的共同点是「配好了就当完事」，而容量治理恰恰是件要持续调的事。

最后说说监控落点。容量治理做得好不好，最终看四个数：KV 池使用率、前缀缓存命中率、驱逐次数、以及因配额被拒的请求数。前两个反映资源是否用满，后两个反映策略是否过紧。只看使用率会把「配置太松导致排队」当成健康状态，只看拒绝率又会把「配置太紧浪费资源」当成稳定。四个数一起看才有意义。

八、衔接大会专题

推理服务的容量治理、KV Cache 优化、多租户配额，属于大会 AI 计算平台专题的典型话题。2026 奇点智能技术大会与 C++ 及系统软件技术大会同期举办，时间 2026 年 11 月 20-21 日，地点北京万达文华酒店，共设 9 大专题、70 余场演讲，覆盖大模型技术、Agentic Scaling、AI 原生软件研发、AI 计算平台、企业级 AI 原生应用与落地、智能体应用创新与开发实践、多模态与世界模型演进、从具身智能到物理 AI、AI+ 行业应用实践。想把自己的容量账跟同行对一对的同学，可以重点关注这一专题。

还有一点：配额不要只设在服务端。客户端如果能感知到自己的额度使用情况，就能主动做节流、合并请求、或者提示用户缩短输入，比服务端被动拒绝体验好得多。把额度信息随响应返回，成本很低，收益却很明显。

落地清单（Checklist）

1. 先统计显存四块占比，确认 KV 是不是真瓶颈。
2. 给 KV 池设硬上限，而不是让它自由增长。
3. 按租户设硬配额、软配额、并发上限三层。
4. 前缀缓存要逐 token 一致才命中，模板别塞动态内容。
5. 驱逐按优先级而非 FIFO。
6. 压测请求长度分档混合，记录开始拒绝的拐点。
7. 每次换模型都复核配额。

工程取舍速记

配额优于无限增长；拒绝优于超时等待；驱逐软超用优于杀活跃；前缀复用优于重算；分档配额优于一刀切；压测拐点优于峰值 QPS；可观测的失败优于静默崩溃。

补充问答

问：KV Cache 上限该设多少？

答： 没有通用比例，要看模型大小和业务上下文分布。经验做法是先按总显存的三成设初值，压测后按实际拒绝率调。上下文普遍长的业务可以提到五到六成，短问答为主的三成就够。

问：为什么显存没满还是 OOM？

答： 多半是碎片。反复分配释放后没有足够大的连续块，分配大张量时失败。表现通常是跑到一段时间后才出，重启又能跑一阵。解法是复用缓冲、减少动态 shape、启用显存池。

问：前缀缓存命中率低怎么办？

答： 先查模板里有没有时间戳、请求 ID、随机数这类逐请求变化的内容，它们会让前缀从第一个 token 就不一致。把动态内容移到后缀，命中率通常能上一个台阶。另外要保证同一租户的请求路由到同一实例。

问：多租户怎么避免互相影响？

答： 三层防护：租户级硬配额防止单租户吃满，优先级调度保证重要请求先被服务，以及按租户的并发上限。只做一层通常不够，因为绕过方式太多。

问：降级到小模型用户能接受吗？

答： 取决于场景。对内部工具、批量任务可以接受，对交互式场景要谨慎。比较稳的做法是先降级上下文长度而不是模型，用户感知更小；只有在持续资源紧张时才切小模型，并且要在响应里说明。

---

大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：免费领取大会PPT资料

立即报名，锁定 70+ 场演讲完整资料与一线工程实践！