上次写 MLA（多头潜在注意力）的时候，留了个尾巴：这东西省显存是真的，但你想自己跑一个 MLA 模型，该用什么推理框架、要注意什么，没展开。这篇补上。
先说清楚我的情况：手头是树莓派，没有 NVIDIA 显卡，vLLM 装不上也跑不起来。所以这篇不是实测跑分，而是把 vLLM 官方文档和源码里关于 MLA 的部分翻了一遍，数字全部来自官方材料，文末附核对说明。想看实测跑分的朋友，这里先说声抱歉。为什么明知没卡还要写这篇？因为查下来发现，MLA 模型部署的资料散落在文档各个角落，坑还不少，整理一遍自己也省得下次再翻。
MLA 模型在 vLLM 里的地位
vLLM 目前的版本是 v0.32.0（2026 年 10 月 18 日发布，Apache 2.0 协议）。翻开它官方文档的支持模型列表，DeepSeek 系列占了一整块：
- DeepseekV3ForCausalLM：对应 DeepSeek-V3、R1、V3.1
- DeepseekV32ForCausalLM：对应 V3.2
- DeepseekV4ForCausalLM：对应 V4-Flash、V4-Pro
这些模型用 V2 及以后架构的，注意力层都是 MLA。也就是说，你下载 R1 想自己部署，vLLM 里跑的注意力后端就是 MLA 实现。MiniMax-M2 也在支持列表里，不过它是 GQA 架构（48 个查询头、8 个 KV 头），走的不是 MLA 路线，这篇按下不表。
顺便说一句，上篇文章我纠正过一个自己的错觉：「新模型都用 MLA」不成立。这里再确认一遍：Kimi K3 用 KDA，MiniMax-M2 用 GQA，DeepSeek V4 也换了混合稀疏注意力。MLA 是 DeepSeek V2、V3、R1 这条线的方案。
为什么 MLA 模型值得用 vLLM 跑
KV 缓存是推理部署的硬成本。R1 的配置文件里写着：61 层、隐藏层 7168、128 个查询头，kv_lora_rank 512。按上一篇算过的账，MLA 把每 token 的 KV 缓存压到 GQA 方案的几十分之一。缓存小了，同样一张卡能塞下的并发请求就多，吞吐自然上去。
这笔账对自部署的人很实际。我上一篇文章算过：128 头全量 KV 的方案，32K 上下文一个请求要吃 100GB 量级的缓存，而 MLA 压完只要 2GB 出头。前者一张 80GB 的卡连一个请求都装不下，后者能同时服务几十个。框架再怎么优化，也绕不开注意力架构划下的这条硬边界，所以先选对模型架构，再谈调框架。
vLLM 对 MLA 的支持不是简单移植。源码里有专门的 MultiHeadLatentAttentionWrapper，配合 PagedAttention 的分页管理来用。KV 缓存按页分配，配合 MLA 的小缓存，显存浪费很少。
还有个容易被忽略的点：vLLM 启动时会打印一行日志，告诉你 GPU KV cache size 能装多少 token、每个请求 40960 token 时最大并发是多少倍。这行日志是官方文档推荐的容量规划依据，部署 MLA 模型时可以直接拿它算并发上限。
实际部署：两条命令的事
vLLM 部署 R1 这类模型，核心就一条命令：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \
--reasoning-parser deepseek_r1这里用 1.5B 蒸馏版举例，因为它能在单卡上跑。完整的 R1 671B 需要多卡张量并行，那是另一个话题。选蒸馏版还有个好处：它的推理输出格式和完整版一致，验证推理解析器的配置是否正确，用小模型最省事。
模型下载下来，vLLM 读到 config.json 里的 kv_lora_rank 等字段，自动启用 MLA 后端，你不需要手动指定注意力实现。这一点比一些老版本框架友好，早期有些版本要手动开关 MLA 支持，现在判断逻辑内置了。
如果跑的是推理模型，加 --reasoning-parser 参数，输出里会把思考过程和最终回答分开：
response = client.chat.completions.create(model=model, messages=messages)
reasoning = response.choices[0].message.reasoning
content = response.choices[0].message.content这里有个官方文档特意警告的坑：这个字段以前叫 reasoning_content，后来改名 reasoning。旧客户端代码如果还读老字段名，会静默拿到空值，不报错。升级 vLLM 之后记得搜一遍代码。
流式输出也支持。delta 里有 reasoning 字段时是思考过程，有 content 字段时是正式回答。OpenAI 官方 Python 客户端没有定义 reasoning 这个属性，要用 getattr 才能取到，文档里给了示例代码。
长文本与工具调用的两个注意点
第一，思考预算。vLLM 支持 thinking_token_budget 采样参数，给推理模型的思考过程设上限。配合 --reasoning-config 设置思考的起止标记，token 数到达预算就强制结束思考。适合那些思考三分钟、回答三行字的场景，账单能省不少。
第二，工具调用。官方文档写明：开启推理解析器后，工具调用只从 content 字段里解析，reasoning 字段里的内容不参与。如果你的 Agent 在思考过程里「决定」调工具但没在正式回答里输出，那不会生效。排查 Agent 不调工具的问题时，先看这个。
V3.2 之后的 MLA 变了味
写这篇查资料时发现一个新情况：DeepSeek-V3.2 的注意力已经不是原教旨 MLA 了。如果你的部署清单里有 V3.2 和 V4，这段要重点看。
V3.2 引入稀疏注意力后，vLLM 源码里对应出现了 DeepseekV32Indexer 和 SparseAttnIndexer 这些类。它保留 MLA 的压缩思路，但每个 query 只和选出来的 top-2048 个 token 精算注意力，不再是全量注意力。V4 系列更进一步，模型卡里直接写了混合注意力架构（CSA 加 HCA），1M 上下文下 KV 缓存只有 V3.2 的一成。
所以如果你部署的是 V3.2 或 V4，看到的实现和 R1 那代 MLA 有差别。vLLM 的支持模型列表里这些都标着支持，框架层面你不用操心，但看源码或排查问题时，别拿着 R1 时代的 MLA 代码硬套。
核对说明
这篇的数字来源：vLLM 版本号和协议来自 GitHub releases 接口；支持模型列表、reasoning 输出文档、并行部署文档来自 vLLM 官方仓库 docs 目录；R1 的层数、头数、kv_lora_rank 来自 Hugging Face 官方 config.json；V3.2 稀疏索引器和 V4 的情况来自 vLLM 源码与 DeepSeek 官方模型卡。检索时间 2026 年 10 月 23 日。
Kimi K3 用 KDA、MiniMax-M2 用 GQA 这两个说法，在我上一篇 MLA 文章里核实过，这次没有重复验证，引用时请注意时效。
如果你也在折腾本地部署，KV 缓存的账怎么算，可以看之前写的KV 缓存那篇；MLA 本身的原理（为什么能压到 2%）在MLA 那篇里。推理框架选型的整体对比，vLLM 入门篇讲过 PagedAttention 的思路。
下一篇想写 MiniMax-M2 这类 GQA 模型的部署账，GQA 的 KV 头数对不同框架的影响，和 MLA 是两套逻辑。感兴趣的话过几天来看。