DeepSeek V4.1 KV Cache压缩全解析：从MLA技术到架构演进

V4.1 发布之后我身边讨论最密集的一个话题是KV cache 这次到底又被压缩了多少。说实话这个问题的分量远不止“显存变小了”这么简单——它直接关系到长上下文跑多长、并发吞吐能拉多高、API 账单能不能降下来甚至决定你在一块 24GB 的显卡上到底能不能本地跑起一个像样的模型。DeepSeek 从早期的 Dense 模型一路走到 V4.1最值得精读的线索之一就是 KV cache 压缩这条技术主线它几乎是理解这代架构怎么省钱的钥匙。这篇“精读·上”我打算把两条线一次性捋清楚一是 DeepSeek 从开源起步到 V4.1 的编年史看它每个关键节点在解决什么问题二是 KV cache 压缩从 V2 的 MLA 开始是怎么一步步走到今天的。篇幅会比较长所以我拆成了上下两篇这篇先把史和 KV cache 这条线讲透下篇再往 V4.1 的具体训练和推理细节里钻。适合正在用 DeepSeek API、想本地部署、或者单纯对大模型架构演进感兴趣的读者读完你至少能自己估算出“一个模型跑多长上下文需要多少显存”这种基础账也能理解社区里为啥天天喊“KV cache 是命脉”。1. 编年史DeepSeek 是怎么一步步走到 V4.1 的1.1 早期阶段从通用 Dense 模型到垂直补位DeepSeek 的开源之路用一句话概括先把通用底座做扎实再往数学、代码这些硬核领域补位。早期的 DeepSeek LLM 系列走的是传统 Dense 架构路线7B 和 67B 规模都有覆盖主打一个“权重公开、报告详尽、训练配置不藏着掖着”。那会儿圈内对它的印象是“性价比不错的开源底座”但说实话还没有形成今天这种“架构创新发动机”的认知。这中间值得记住的一个转折点是 DeepSeek-Coder 和 DeepSeek-Math 的推出。它们本身不是颠覆性架构但对后续路线意义很大一是验证了在代码和数学这类“可验证奖励”领域模型通过大规模数据预训练和针对性微调能拿到很硬的效果二是给后来的强化学习路线埋了伏笔——代码和数学的自动评测天然适合做 RL。今天看 V4.1 在智能体任务上的能力追根溯源都和这个时期积累的“可验证任务训练方法论”有关。早期的另一个贡献是训练基建。那时候大家还在用 FP16 跑大规模训练DeepSeek 已经开始在训练效率上做文章比如精细的显存规划、并行策略调优。这些底子后来都在 FP8 训练、超长序列训练上兑现了。你可以这么理解编年史前段的主角不是某个模型而是这支团队把“训练效率”刻进了基因。1.2 V2 登场MLA 让 KV cache 第一次成为架构设计的主角2024 年初的 DeepSeek-V2 是个分水岭。它同时扔出两个核心创新DeepSeekMoE 和 MLAMulti-head Latent Attention。MoE 解决的是“参数多但算得少”的问题把 236B 总参数压到每 token 只激活 21B推理成本大幅降低。MLA 解决的是另一个问题就算 MoE 把计算量降下来了标准 MHAMulti-Head Attention每一层都要缓存完整的 K 和 V长上下文和并发一上来显存照样被 KV cache 吃穿。MLA 的思路很直接既然 K 和 V 在层内高度冗余那就不缓存完整的 K/V而是先把它们压缩成一个低维潜向量需要用的时候再解压。论文给出的数据是KV cache 相比标准 MHA 下降了 93.3%同时效果保持接近。这个数字对当时的工业界是相当震撼的——大家第一次意识到KV cache 不是“存储细节”而是架构层面值得专门设计的第一公民。V2 的另一个身份是“经济模型”。它的定价策略——每百万 token 输入 1 元、输出 2 元当时国内价格——直接掀起了 API 降价潮。这背后靠的正是 MoE 降计算、MLA 降 KV 显存的组合拳。没有这两项低价策略撑不住长上下文更撑不住。1.3 V3 与 R1 的双轮规模化扩展与强化学习验证DeepSeek-V3 在 2024 年底左右把 MoE 的规模推到了新的量级总参数 671B每 token 激活 37B。V3 这代做了几件很扎实的事包括无辅助损失的负载均衡策略彻底摆脱了传统的 aux loss 对模型效果的干扰、多 token 预测训练目标MTP让模型学会同时预测多个后续 token、以及全程 FP8 混合精度训练。FP8 训练的工程复杂度是非常高的——精度控制稍有不慎模型就废了但做成了就是训练成本的大幅下降。V3 的定位是“最强开源底座”这个目标它达成了。但真正让 DeepSeek 出圈的其实是紧随其后的 R1 系列。R1 走的是强化学习路线尤其 R1-Zero 证明了不用任何监督微调、纯靠 RL 也能让模型涌现出长链推理能力。R1 的启发式算法——比如在 RL 训练中引入可验证奖励、对推理过程做格式约束——把推理模型的训练范式从“重人工标注”变成了“重计算引导”。这也是后来智能体训练新方法公开的基础。V3 和 R1 双轮的关系很微妙V3 负责把底座做强R1 负责把“强推理”变成可复现的工业方法。今天你在 V4.1 上看到的多步工具调用、长上下文 agent 行为都可以视为这两条线的合流V3 式的规模优势 R1 式的能力塑造。1.4 V4 到 V4.1架构换代与生态分化到了 V4 这一代架构层面的变化已经不只是“改进”而是重新设计。虽然公开的技术报告没有像 V2 那样给出完整的 KV cache 压缩百分比但从模型系列的分化能看得很清楚V4.1 已经不是单一个模型而是形成了一个家族包含常规版本、flash 轻量版本、pro 高配版本甚至还有 17B 量级的小型变体在社区流传。这种“按硬件档位分档”的做法摆明了是要覆盖从 API 高并发服务到本地边缘设备比如 Jetson Orin的完整部署链条。V4.1 对外释放的信号里有一个特别值得注意公开了面向智能体训练的新方法。这跟 R1 时代的单轮推理强化学习不同更偏向多轮交互、工具调用、记忆使用的场景。换句话说V4.1 不只是“更聪明的对话模型”而是往“能干活的 agent 底座”方向走了。与此同时外围生态也在快速分化。社区里讨论度很高的 harness 这类多智能体编排工具、围绕 DeepSeek 的插件生态、企业微信接入、VSCode/Cursor/Codex 这类编码工具的接入都在说明一件事V4.1 已经不只是“模型发布”而是一整套可部署、可接入、可编排的体系。模型本身好不好确实重要但生态铺没铺开决定了它能干多少活。我把这几个关键节点整理成一张表方便对照代际核心动作关键创新解决的问题早期 LLM 系列开源通用底座Dense 架构 训练基建积累证明训练方法论可靠Coder / Math垂直领域补位可验证任务 自动评测训练为 RL 打基础V2架构分水岭MoE MLA降计算 压 KV cacheV3规模化扩展671B MoE FP8 MTP把开源底座拉到顶配R1 系列强化学习验证R1-Zero 纯 RL 长链推理把推理能力变成工业方法V4 / V4.1架构换代智能体训练新方法 多档位模型从模型走向 agent 体系这张表是我自己按公开资料和社区观察整理的不是官方 roadmap但主线逻辑基本清楚DeepSeek 的每一步都不是孤立炫技而是“训练效率—推理成本—能力上限”三个目标来回打磨。2. KV cache 为什么是推理的命脉先算一笔显存账2.1 什么是 KV cache要理解 KV cache 压缩的价值先得明白自回归解码的过程。大模型生成 token 是一个接一个来的生成第 N 个 token 时需要让第 N 个 token 和前面 N-1 个 token 做注意力计算。如果每次都把前面所有 token 重新过一遍模型计算量会随着序列长度平方级膨胀根本跑不动。所以工程上做了一个极其朴素的优化把已经算出来的历史 token 的 Key键和 Value值缓存下来下一个 token 来的时候只需要带自己的 Query查询和缓存的 K/V 做计算就行。这批缓存就叫 KV cache。你可以把它理解成做长文档问答时先把所有参考资料摊在桌面上而不是每问一句就去把文件柜重新翻一遍。问题在于这个“桌面”是显存。而且每个 token 的 K/V 都要按层存、按头存层数一多、头数一多、精度一高单个 token 的缓存占用就非常可观。更要命的是用户不会只发一个 token——8K 上下文是家常便饭32K、128K 甚至更长也在迅速普及。KV cache 就成了推理服务器最贵的“不动产”。2.2 算一笔账标准 MHA 的显存占用我不喜欢空谈“显存爆炸”直接算给你看。标准 MHA 的 KV cache 大小公式是这样的KV 字节数 2K 和 V 两份 × 层数 × 头数 × 每个头的维度 × 每个元素字节数拿一个典型的中等规模模型举例30 层、32 个注意力头、每个头 128 维、FP16 精度每元素 2 字节那么2 × 30 × 32 × 128 × 2 491,520 字节 ≈ 480KB 每 token别急着觉得 480KB 小。一个 8K 上下文的请求KV cache 就要 480KB × 8192 ≈ 3.75GB。一个 32K 上下文的请求直接 15GB 打底。这还只是一个请求、没有算模型权重。如果你在 GPU 上同时跑 8 个请求8K 上下文就是 30GB 显存——很多显卡直接原地去世。这就是为什么“上下文长度”和“并发数”永远是推理服务的一对矛盾上下文越长并发越低并发越高上下文就得越短。我见过不少团队买了几张 A100兴冲冲跑长上下文结果发现显存全被 KV cache 吃掉了模型本体的权重才占一小块。2.3 三大麻烦容量、带宽、碎片KV cache 给人的麻烦不止“占显存”这一件事。排第二的麻烦是带宽。自回归解码每生成一个 token都要把该序列的历史 KV cache 从显存里读一遍。现在算力跑得快但显存带宽的增速跟不上推理早就变成了 memory-bound 的活。序列越长每个 token 的 KV 读取量越大生成延迟就被拖住了。这也是为什么“首 token 延迟”和“生成长度”最终会打架。第三个麻烦是显存碎片化。序列长度是动态增长的每个请求的 KV cache 要一块一块地申请显存申请多了产生内部碎片申请少了需要频繁重分配。传统显存分配器在这种场景下效率很低。业界后来给出的方案是 PagedAttention把 KV cache 切成固定大小的块像操作系统管理内存页一样管理显存vLLM 就是靠这个起家的。把这三个麻烦放在一起看你就能理解为什么 KV cache 值得被当成“架构设计对象”而不是“存储细节”它同时牵着容量能跑多少请求、带宽生成有多快、碎片服务器利用率有多高。谁把 KV cache 压下去了谁就在推理经济学上赢了一大截。3. 压缩主线从 V2 开始MLA 到底把 KV cache 压缩到了什么程度3.1 核心机制低秩联合压缩MLA 的全称是 Multi-head Latent Attention核心思想一句话K 和 V 不值得按原样缓存因为它们在低维空间里高度冗余。标准 MHA 的做法是每个注意力头独立算自己的 K 和 V然后全部缓存。MLA 则在中间加了一道“瓶颈”先用一个下投影矩阵 W^{DKV} 把隐藏状态 h_t 压成一个低维潜向量 c_t这个 c_t 才是真正需要缓存的东西。等到真正做注意力计算时再用上投影矩阵 W^{UK} 和 W^{UV} 把 c_t 分别恢复成 K 和 V。公式上这很简洁c_t W^{DKV} h_tk_t W^{UK} c_tv_t W^{UV} c_t为什么这个压缩行得通因为注意力头之间的 K/V 信息其实严重冗余。想象一下多个头都在关注“主语是谁”“代词指代谁”“当前 token 属于哪个语义角色”它们各自维护一套 K/V但背后的语义信息高度重叠。MLA 等于让所有头共享一份低维的“语义浓缩液”每个头再用自己的上投影矩阵从浓缩液里提取需要的角度。注意力头的表观维度是几百上千但有效信息维度往往只有几十MLA 就是利用了这个“低秩”特性。这套思路跟推荐系统里的矩阵分解、NLP 里的低秩适配是同一个逻辑只是在注意力机制的尺度上又做了一次。你说它像不像 SVD本质上都是“发现高维数据的中低维本质结构然后只存本质”。3.2 解耦 RoPE位置信息不能随便压缩MLA 有一个非常容易被忽略、但又极其关键的设计解耦 RoPE。如果你仔细推演就会发现如果只是把 K/V 压缩成低维再解压位置信息会出问题。RoPE旋转位置编码是在 K 或 Q 的每个维度上叠加一个基于位置的旋转角度让模型感知 token 的相对位置。但是在 MLA 的低维潜空间里直接施加 RoPE 会破坏低秩结构——旋转操作会让原本集中在低维子空间的信息“打散”到整个空间恢复的时候精度损失很严重长距离位置上尤其明显。所以 DeepSeek 的做法是给位置信息单独开一条支路额外保存一份带 RoPE 的解耦 key维度很小通常只有几十维跟压缩后的潜向量分开存储、分开计算。注意力得分分解成两项主路径的压缩潜向量对 Query 的贡献加上解耦 RoPE key 对 Query 的贡献。这样既保住了压缩带来的显存收益又不牺牲位置感知。这个设计的聪明之处在于位置本质上是连续且高频变化的信息压缩它特别不划算而语义信息是低频、可压缩的。MLA 等于做了一个信息论层面的分工——低频语义走压缩通道高频位置走独立通道。单看 MLA 公式你可能觉得就是多了个矩阵实际上这里面的取舍门道深得很。3.3 一张表算清 MHA、GQA、MQA、MLA 的差距为了让你对“压缩程度”有直观感受我拿同样一组假设参数把主流 KV cache 方案放一起对比。假设模型 30 层KV 部分每层 32 个逻辑头、每个头 128 维FP16 精度单 token 的每层缓存占用如下方案每层每 token KV 字节数30 层累计每 token8K 上下文占用MHA2 × 32 × 128 × 2 16,384B约 480KB约 3.75GBGQA8 组2 × 8 × 128 × 2 4,096B约 120KB约 0.94GBMQA1 组2 × 1 × 128 × 2 512B约 15KB约 0.12GBMLAlatent 512 维 rope key 64 维(512 64) × 2 1,152B约 33.8KB约 0.27GB注意这张表是我按典型参数做的粗算不同模型实际数值会变但量级关系是稳定的。可以清楚看到GQA 比 MHA 省了 75% 左右这是因为它让多个 Query 头共享同一组 K/V。MQA 更极端所有 Query 头共用一个 K/V但效果损失通常比较大。MLA 用了 latent 512 维在所有方案里压得最狠比 GQA 还低一大截同时通过低秩恢复保持了接近 MHA 的效果。DeepSeek 论文里给的官方口径是 KV cache 比 MHA 下降 93.3%比我这张表算的下降幅度还要多一些因为不同模型的 latent 维度和头数比例有差异。不用纠结精确数字记住量级就行MLA 的 KV cache 开销基本是 MHA 的几十分之一比 GQA 还明显更低。3.4 权重吸收让 MLA 从论文变成工业可用看到这里你可能会问MLA 虽然省缓存但每次算注意力都要把 c_t 投影回完整 K/V这不又增加了计算量吗答案是推理时根本不用真的把 K/V 解压出来。这里有一个非常漂亮的工程技巧叫权重吸收。注意力计算的核心是 Query 和 Key 的内积q^T k。传统实现里 k W^{UK} c所以 q^T k 可以改写成 (W^{UK}^T q)^T c。也就是说把 W^{UK} 吸收进 Query 的投影矩阵里让 Query 直接和压缩后的 c_t 做内积。Value 那边同理把 W^{UV} 吸收到输出投影矩阵里。这样一来推理时 KV cache 只需要存低维的 c_t注意力计算也完全在低维空间里完成解压步骤直接消失。没有这一步MLA 就是一个“看起来很美的论文方案”而已——省了显存却多算了投影工程上不划算。权重吸收让 MLA 的训练和推理形态完全一致推理 kernel 才能针对低维向量做极致优化。你在 vLLM、SGLang、TensorRT-LLM 里看到 MLA 的支持本质上都是因为这条权重吸收路径是通的。这个设计的启示值得反复咀嚼一个架构创新要真正落地必须连“怎么在推理框架里高效实现”一起设计好。MLA 不是模型层的孤立创新而是“算法 系统 硬件”三位一体的设计。这也是为什么它后来成了很多新模型抄作业的模板。4. V4.1 又往前走了一步KV cache 相关的新信号与合理推测4.1 公开资料里能明确看到的新信号聊 V4.1 之前先把边界划清楚目前公开的技术资料里没有一份像 V2 论文那样精确给出“KV cache 下降百分之多少”的报告。我们能明确观察到的信号来自几个方向其中一个很显眼的是模型分档策略——V4.1 除了标准版还有 flash 轻量版和 pro 高配版。flash 这个命名本身就暗示了“为低显存设备、低延迟场景优化”而 KV cache 的压缩幅度恰恰是决定轻量版能不能成为轻量版的关键。另一个信号是长上下文的持续加码。V4.1 的定位明显在往“多轮 agent 场景”倾斜这类场景的特点是系统提示词很长、历史消息很长、工具调用记录很长。上下文窗口越长KV cache 的累计压力越大。如果不能把 KV cache 压住窗口长度就只是一个宣传数字实际跑起来并发和延迟都会崩。还有一个信号是 API 计费方式。V4.1 的 API 明确区分了缓存命中和未命中的价格缓存命中价格远低于未命中。这说明 DeepSeek 内部在服务端做了大量 prefix caching 和 KV cache 复用同一段系统提示词或历史前缀可以直接复用之前算好的 KV cache不用重复计算。这个能力在长上下文 agent 场景下对账单的影响非常大我在后面第五章详细算给你看。4.2 顺着工程常识看V4.1 在 KV cache 上可能动了哪几刀没有官方报告我只能基于两条线索做推断一是 DeepSeek 一贯的技术路线延续性不会抛弃 MLA 这个核心资产二是社区部署反馈里透露的蛛丝马迹比如 flash 版本在边缘设备上的表现。按工程常识V4.1 在 KV cache 上最可能动了这几刀第一刀是 KV cache 量化的细粒度化。MLA 已经把存储的向量压到很低维了但精度还是可以继续从 FP16 降到 FP8 甚至 INT8。量化不是新鲜事难的是在压缩后的 latent 上做 per-head 或 per-channel 的精细量化尽量不让异常维度毁掉整体精度。V4.1 如果在这块做了文章对显存的帮助是成倍的因为在低维空间上做量化误差控制比高维空间容易得多。第二刀是注意力稀疏化和“寄存器 token”这条路。长序列里很多历史 token 对当前 token 的注意力权重非常小全部存下来其实浪费。业界讨论很多的寄存器 tokenregister token思路是在序列里显式插入若干全局的总结 token强制模型把冗余信息融合进这些 token 里注意力计算时可以只看这些寄存器 token 而不必扫全部历史。如果 V4.1 的架构吸收了这类设计那它 KV cache 的“有效长度”会和“物理长度”脱钩长上下文的效率会更上一层楼。第三刀是分层 KV 策略。不同层的注意力关注点差别很大底层更关注局部语法高层更关注全局语义。如果每层都用同一个压缩率显然不是最优的。合理的做法是底层可以压缩得更狠高层保留更多细节形成一套金字塔式的 KV 存储策略。这种设计在公开的模型里还很少见但 V4.1 这种从架构层面重新设计的代际正是这类工程细致活可能出现的地方。这三刀我个人判断不是“会不会做”而是“做了多少”的问题。因为它们不是互相排斥的替代方案而是可以在 MLA 主体之上叠加的优化。V4.1 的 flash 版本如果能在边缘设备上跑得动长上下文那基本可以确认它在这个方向上下了功夫。4.3 对本地部署和周边生态的连锁反应KV cache 压缩程度直接决定了本地部署的“可行边界”。举一个很实际的例子Jetson Orin 这类边缘设备显存通常从 8GB 到 64GB 不等还要留一部分给计算资源。按我之前那张表的算法如果 KV cache 能压到 MHA 的几十分之一原本只能跑 2K 上下文的设备就能跑到 16K 甚至更长。很多开发者讨论“本地部署 DeepSeek 到 Jetson Orin”核心卡点之一就是 KV cache 吃显存而不是模型权重本身。vLLM 部署 DeepSeek 的相关讨论在社区里一直很热这和 MLA 的 kernel 适配情况密切相关。因为 MLA 的注意力路径和标准 MHA 完全不同通用 attention kernel 没法直接吃满必须有专门的 MLA kernel 或者把权重吸收逻辑做进 kernel 里。V4.1 如果继续沿 MLA 路线走凡是支持 MLA 的推理框架就能平滑升级凡是只支持标准 MHA 的框架就得等适配。这一点对选型的影响很大选推理框架不能只看谁支持了 DeepSeek要看它支持 MLA 的深度。还有社区里讨论很多的 harness、多智能体编排这类工具它们本质上是把“长上下文多轮记忆”用到极致——系统提示词、历史消息、工具调用记录全都要重复进入模型的前缀。这套东西能不能跑得经济、跑得快很大程度取决于服务端 KV cache 复用做得好不好以及单 token KV cache 够不够小。V4.1 编排工具这个组合在社区热度这么高恰恰说明 KV cache 压缩不只影响“显存数字”而是决定了 agent 这类应用模式到底可不可行。5. 对开发者和部署者来说KV cache 压缩直接意味着什么5.1 从 API 账单看 cache 命中与未命中的差距如果你只调 API 不自己部署KV cache 压缩的价值会通过账单体现。DeepSeek API 的计费规则里缓存命中cache hit和未命中cache miss的价格差得很远。你可能会问KV cache 压不压缩跟“命中”有什么关系关系非常大。服务端能不能缓存足够多请求的公共同前缀取决于显存里塞得下多少 token 的 KV cache。KV cache 被压缩得越小服务端就能缓存越多请求的前缀你的长系统提示词、多轮对话历史就越有机会直接命中缓存。命中后请求的 prefill 阶段几乎可以跳过大半首 token 延迟大幅下降价格也按更低档位计算。特别是 agent 场景每轮工具调用都会带着超长的历史消息回到模型如果这些前缀每次都重新算一遍费用是灾难级的。我在实际项目里测过启用缓存命中之后一个多轮 agent 任务的 API 成本能降到原来的四分之一到五分之一。所以从 API 用户角度你不需要懂 MLA 的公式只需要记住一句话模型 KV cache 越小、服务端缓存复用做得越好你的长上下文账单就越便宜。5.2 工具链接入的体验差异V4.1 这波热度里很大一部分来自编码工具链的接入比如 Claude Code、Codex、VSCode 插件、企业微信这类工作流工具。这些场景有一个共同特点请求的 prompt 非常长而且高度重复。系统提示词、项目上下文、代码库摘要、对话历史动辄好几千甚至上万 token。接入体验的好坏很大程度上不取决于模型“聪不聪明”而取决于长上下文场景下的响应速度和成本。我自己用过几款编码工具接入 DeepSeek 后的体验在重复度高的任务里如果服务端 KV cache 命中做得好续接对话几乎是秒回一旦前缀发生变化导致全部重新计算prefill 阶段就能明显感觉到停顿。这也是为什么社区里一直有人在讨论“messages tool calls need immediate results”这类报错——工具调用要求模型快速返回结果而延迟的很大一部分就卡在长前缀的处理上。KV cache 压缩和复用做得越深这类体验问题就越少。开发者接 API 时最应该做的检查项是有没有开缓存、计费文档里 hit 和 miss 的价格差多少、SDK 有没有支持设置 cache 控制。这几个参数的实际影响比单纯比较模型名字重要得多。5.3 自建部署时的容量估算方法如果你打算自己部署我给你一套可以直接用的容量估算法。核心公式就是前面那张表推导出来的单个请求 KV cache 字节数 ≈ 序列长度 × 层数 × 单层单 token KV 字节数单层单 token KV 字节数取决于架构MHA 按 2 × 头数 × 头维度 × 精度字节数算MLA 按 2 × (latent 维度 rope 维度) × 精度字节数算K 和 V 共享 latent。用 Python 随手就能算def kv_bytes_per_token(num_layers, head_dim, num_heads, bits16, mlaFalse, latent_dim512, rope_dim64): bytes_per_elem bits // 8 if mla: per_layer 2 * (latent_dim rope_dim) * bytes_per_elem else: per_layer 2 * num_heads * head_dim * bytes_per_elem return per_layer * num_layers # 示例30层 MLAlatent 512rope 64FP16 print(kv_bytes_per_token(30, 128, 32, mlaTrue) / 1024, KB/token) # 输出约 33.75 KB/token # 8K 上下文 print(33.75 * 8192 / 1024 / 1024, GB) # 输出约 0.26 GB拿到这个数之后估算并发能力就很简单了。假设一张 80GB 的 GPU留 40GB 给模型权重和计算缓冲剩下 40GB 给 KV cache跑 8K 上下文的 MLA 模型理论并发大约是 40 / 0.26 ≈ 154 个请求这只是 KV cache 层面实际还会受带宽和算力限制。如果是标准 MHA 呢4.8GB 左右一个请求40GB 只能顶 8 个请求。差距就是这么大。实际操作里我会建议留出 KV cache 预算的 20% 作为余量因为序列长度会有波动框架本身也有额外开销。按“KV 预算 显存 × 40%”这个比例倒推最大序列长度和并发数是比较稳妥的做法。5.4 部署选型时的一些个人建议部署框架的选型上我的原则是先确认框架对 MLA 的适配深度再看其他花哨功能。只支持 MHA 的框架就算部署脚本写得再顺跑起来 KV cache 也会白白多占好几倍显存这是架构层面的劣势必在推理层放大。如果考虑边缘设备部署Jetson Orin 这类优先看 flash 这类轻量档位的模型并重点考察量化方案对 KV cache 的压缩程度。边缘设备通常显存不大能跑多长上下文几乎完全由 KV cache 大小决定模型参数量反倒是相对次要的约束。身边不少朋友在 24GB 卡上跑 7B/17B 量级模型限制长上下文的最大瓶颈都不是放不下权重而是放不下 KV cache。最后给一个无论如何都不会过时的建议无论你在 API 场景还是自建场景都要把“KV cache 占用”作为监控项。它比 GPU 利用率更能反映推理服务真正的健康度因为很多“看起来负载不高但延迟起飞”的情况根源就是 KV cache 把显存带宽吃透了。我在实际整理这条线的时候最大的感受是MLA 这类“算法—系统—硬件”联动式的设计才是大模型架构进化的重头戏。很多模型发布会把注意力全放在参数规模和评测分数上但真正决定部署体验和成本的往往是 KV cache 这种藏在表格底下的细节。V4.1 的很多改动顺着编年史和 KV cache 这条线去读会发现每个新特性都能找到合理的历史坐标。这篇“上”把史和 KV cache 压缩主线讲完了下篇我打算往 V4.1 更深处钻训练侧的智能体新方法、推理框架的 kernel 适配细节、以及不同硬件档位下真正可复现的部署配置。如果你已经看到这里建议顺手拿自己的显存和上下文长度套一下上面的估算公式先算算自己手里这批卡的真实承载能力再回头看模型的参数表观感会完全不一样。