服务器专题 | 第12期：存力只在关键路径上才算数

服务器 · 2026-10-25 · 九羲科技

九羲内部对"存力"有个很窄的定义，只写公开口径：只有进了算力关键路径的存储，才叫存力。视频按 TB 卖的容量，不算；备份仓库，不算。这个定义听起来像咬文嚼字，落到大模型推理上，却是一道很实在的算术题：数据如果不在算力等它的地方，存多少都只是仓库。

先看推理的两段。预填充（Prefill）一次处理整个提示词，算力吃得饱，是算力受限。解码（Decode）一次只吐一个字，算力几乎闲着，时间全花在搬数据上，是内存带宽受限³。解码的算术可以写出来：70B 模型 FP16 权重约 140 GB，H100 的 HBM 带宽 3.35 TB/s，读一遍权重要约 41 毫秒，而真正算一次只要约 0.14 毫秒³。等数据的时间，是算数据时间的近 300 倍。GPU 不是算不动，是等不起。

KV 缓存的账：每多一个字，账就厚一分

KV 缓存是解码的另一笔大账。生成第 100 个字时，前 99 个字的 Key、Value 不用重算，存下来复用，这就是 KV 缓存³。省了算力，花了内存：每个 token 的 KV 大小约等于 2 乘层数乘注意力头数乘头维度乘 2 字节。以 Llama-3 70B 级别估算，单个 token 约 320 KB⁴；1 万上下文就是 3.2 GB，批量 32 路并发，KV 缓存就超过 100 GB⁴。上下文越长、并发越高，这笔账越厚，厚到 HBM 装不下，就得往外溢出。

溢出到哪里，决定了它是存力还是仓库。溢出到显存之外的慢速层，每吐一个字都要跨层取数，输出速度直接被取数速度钉住；溢出到离线归档，生成结束后再写，生成速度完全不受影响。同一个 KV 缓存，放的位置不同，身份就不同。判断标准不在介质叫什么，而在它是不是每步必经。

KV 缓存随上下文与并发线性膨胀：单路 1 万上下文约 3.2 GB，32 路并发超过 100 GB（量级估算，来源：Llama-3 70B 级别公开测算整理⁴；示意图为程序绘制）

向量检索的账：索引快了，原文慢了也白搭

向量检索是另一条关键路径。问答系统先拿问题向量去向量索引里找最像的几段，再把原文取回来喂给模型。这里藏着两段等待：一段是索引检索，一段是原文读取。索引放在内存里跑得飞快，原文躺在慢盘上，答案照样要等原文。检索链路的速度，取决于最慢的那一段，不是最快的那一段。

反过来想也很清楚：如果检索是离线批量做的，索引建好、结果缓存好，在线问答不再碰存储，那存储再大也只是仓库。只有当"每一次问答都实时取原文、每一次生成都实时读 KV"时，存储才站到了算力前面。这就是"关键路径"四个字的全部含义：不是数据重要不重要，而是算力在不在等它。

所以，什么才叫存力：三道判据

给存力立三道判据，买存储的时候可以直接拿着问：

第一道，每请求必经吗？生成每一步、问答每一次都要过这层存储，还是偶尔才碰一次？

第二道，卡住输出速度吗？这层慢下来， token 速度、首字延迟是不是跟着慢？

第三道，省掉重算吗？这层存的东西，是不是替算力省下了本来要重算的活？KV 缓存、前缀缓存、向量索引加原文直取，过的是这三道；冷备份、离线归档、按 TB 计价的容量池，过不了。

解码每一步的真实分工：权重与 KV 缓存重读一遍，计算只占一小部分，输出速度被搬运速度钉住（机制示意，来源：公开推理优化资料整理³；示意图为程序绘制）

以小见大的一层判断：存力不是"存储加 AI"四个字的组合，而是一句取舍——把算力正在等的数据，放到离算力最近、最快、最不会被别人抢走的地方。容量生意比的是每 TB 多少钱，存力生意比的是每一次等待值多少钱。两本账的算法不一样，报价单的写法也不一样：前者写容量，后者要写清"这层存储站在哪一步、卡住谁的速度"。

没完全想通、留下一个问题：KV 缓存溢出到 CXL 内存层（见第 11 期）到底划不划算？CXL 比 HBM 慢一个量级，比 SSD 快得多，刚好卡在"能忍"与"不能忍"之间。这笔账，需要拿真实的解码延迟分布来算，单点带宽数字算不出来。

· · ·