这道题看起来只是在算显存，但面试官真正想测试的，是你对 MoE 架构、量化策略、注意力机制和推理系统的综合理解。
上周有位读者面了一家做模型部署的创业公司，面试官出了一道题：
MiniMax M3 模型，428B 参数，8 张 A6000 Pro，问你能不能部署？能部署多少并发？
这不是八股文，这是一道非常实在的工程题。如果只会背 Transformer 结构，拿到这道题会很懵。
今天我们就拆解这道题，搞清楚大模型部署面试到底在考什么。
这道题到底在考什么？
先说结论：这道题不是让你背公式的。
面试官想确认你 4 个层面的能力：
| 考察维度 | 具体能力 | 对应题目 |
|---|---|---|
| 🎯 量化与显存估算 | 知道 INT8/FP16/BF16 各占多少字节，能快速估算模型加载所需显存 | 问题 1 |
| 🎯 注意力机制理解 | 知道 GQA、MHA、稀疏注意力的区别，以及它们对 KV Cache 的影响 | 问题 2 |
| 🎯 推理系统瓶颈判断 | 能区分显存瓶颈和计算瓶颈，给出合理的并发估算 | 问题 3 |
| 🎯 长上下文扩展理解 | 理解 KV Cache 与序列长度的线性关系，能推算扩展代价 | 问题 4 |
如果你只记住了答案，但没有理解背后的选择逻辑，换一个模型、换一个硬件你就不会了。
先用一句话理解
这道题的核心就一句话：
模型推理需要两样东西：放权重的空间 + 放中间结果的空间。
权重就是模型学到的参数------你把它量化压缩后能省不少地方。
KV Cache 就是中间结果------模型每多处理一个 token，就要多存一点 Key 和 Value 的计算结果，上下文越长，占的地方越大。
面试官让你算的，就是这两种空间各占多少，剩下的还能放多少个请求。
核心原理拆解
模型有多大？需要多少显存？
MiniMax M3 总参数量 428B，这是一个 MoE（混合专家）模型。
MoE 的一个关键特性 ：虽然是稀疏激活------每次只激活 23B 参数------但推理时所有专家权重都必须加载到显存，因为你不确定这次推理会路由到哪些专家。所以不能按 23B 算，必须按 428B 算。
题目要求做 INT8 量化，每个参数占 1 字节：
权重显存=428×109×1=428 GB \text{权重显存} = 428 \times 10^9 \times 1 = 428 \text{ GB} 权重显存=428×109×1=428 GB
8 张 A6000 Pro，单卡 96 GB，总显存 768 GB。扣除 10% 的系统开销后有效显存 691.2 GB。
428 < 691.2 ✅ 可以完整加载。
剩余空间：691.2−428=263.2 GB691.2 - 428 = 263.2 \text{ GB}691.2−428=263.2 GB，用来放 KV Cache。
KV Cache 到底占多少？
这里有个非常重要的细节------M3 用了 GQA（分组查询注意力）。
传统 MHA（多头注意力）有 64 个 KV 头，而 M3 的 GQA 架构只有 4 个 KV 头。
人话理解：GQA 相当于你把 64 个小组并成了 4 个大组来管理 Key/Value，存储量直接降到原来的 1/16。这是一个非常实用的工程优化，几乎不影响模型质量，但大幅节省显存。
单 token KV Cache 计算公式：
KV 显存=2(K+V)×层数×KV 头数×头维度×字节数 \text{KV 显存} = 2 \text{(K+V)} \times \text{层数} \times \text{KV 头数} \times \text{头维度} \times \text{字节数} KV 显存=2(K+V)×层数×KV 头数×头维度×字节数
代入 M3 参数：
2×60×4×96×2=92,160 字节≈90 KB/token 2 \times 60 \times 4 \times 96 \times 2 = 92,160 \text{ 字节} \approx 90 \text{ KB/token} 2×60×4×96×2=92,160 字节≈90 KB/token
128K 上下文时单请求 KV Cache：
90 KB×128×103≈11.5 GB 90 \text{ KB} \times 128 \times 10^3 \approx 11.5 \text{ GB} 90 KB×128×103≈11.5 GB
作为对比，如果用传统的 64 头 MHA，单请求 KV Cache 是 184.3 GB------单卡压根放不下。
这就是 GQA 的价值：没有 GQA，长上下文推理根本做不了。
并发数怎么算？
并发数=可用 KV 显存单请求 KV 显存=263.211.5≈22.9 \text{并发数} = \frac{\text{可用 KV 显存}}{\text{单请求 KV 显存}} = \frac{263.2}{11.5} \approx 22.9 并发数=单请求 KV 显存可用 KV 显存=11.5263.2≈22.9
理论最大并发：约 22~23 个请求。
⚠️ 生产环境警告 ：这是显存维度的理论极限。实际部署必须考虑：
- 计算延迟（GPU 算不过来）
- 网络调度开销
- 突发流量波动
通常预留 30%~50% 安全余量 ，实际可用并发约 11~15 个。
扩展到 1M 上下文会怎样？
KV Cache 与序列长度是严格线性关系：长度扩大多少倍，KV Cache 就扩大多少倍。
从 128K 到 1M，扩大了 8 倍：
单请求 KV=11.5×8=92 GB \text{单请求 KV} = 11.5 \times 8 = 92 \text{ GB} 单请求 KV=11.5×8=92 GB
并发数=263.292≈2.9 \text{并发数} = \frac{263.2}{92} \approx 2.9 并发数=92263.2≈2.9
并发缩减到原来的 1/8，只剩 2~3 个请求。
面试官问这一问，其实是想看你有没有意识到：
长上下文不是免费的------1M 窗口的代价是并发能力的大幅下降。MSA 稀疏注意力可以加速解码（官方说最高 15 倍），但它不减少 KV Cache 的存储量，所以并发上限不变。
关键细节和常见误区
| 误区 | 正解 |
|---|---|
| MoE 只算激活参数 | ❌ 不对，MoE 推理必须加载全部专家权重 |
| INT8 量化后只占原 1/4 空间 | ✅ 从 BF16（2 字节）到 INT8（1 字节）减半，不是 1/4 |
| MSA 稀疏注意力节省 KV Cache | ❌ MSA 加速计算，不减少存储，GQA 才省存储 |
| 并发数算到小数直接取整 | ⚠️ 22.9 不是"22"，也不是"23"，是显存极限，生产要留余量 |
| 1M 上下文用 MSA 就能解决并发问题 | ❌ MSA 加速解的是计算瓶颈，不是存储瓶颈 |
为什么这道题值得重视？
这道题的价值不在答案本身，而在于它把一个真实的部署场景压缩成了一个面试问题。
如果你能完整回答这道题，说明你：
- 清楚 MoE 和量化是怎么影响显存的
- 知道 GQA 对推理系统的实际价值
- 能区分计算瓶颈和存储瓶颈
- 理解长上下文的真实代价
这些都是大模型工程化部署中每天都要面对的问题。
面试 30 秒回答
第一，模型权重：428B 参数做 INT8 量化后约 428 GB，8 张 A6000 Pro 扣掉系统开销剩 691.2 GB，能装下。
第二，KV Cache：M3 的 GQA 架构只有 4 个 KV 头，128K 上下文单请求约 11.5 GB。
第三，并发：剩余 263.2 GB 可放 KV Cache，理论并发约 22~23。生产环境建议打五折，按 11~15 个估算。
第四，长上下文：1M 窗口 KV Cache 扩大 8 倍，并发降到 2~3 个。
面试 2 分钟回答
如果面试官让你展开讲，按这个结构：
第一步：先确认前提。
首先确认这是 MoE 模型，推理时必须加载全部 428B 专家权重，不能只算 23B 激活参数。
第二步：算权重。
INT8 量化后 428 GB，A6000 Pro 集群 8×96 GB = 768 GB，扣 10% 开销剩 691.2 GB，有 263.2 GB 余量。
第三步：解释 GQA 的作用。
M3 用了 GQA，KV 头从 64 降到 4，KV Cache 只有传统 MHA 的 1/16，128K 下单请求仅 11.5 GB。
第四步：算并发。
263.2 ÷ 11.5 ≈ 22.9，理论 22~23 并发，但生产要预留余量，建议按 11~15 规划。
第五步：讲长上下文的代价。
1M 上下文时 KV Cache × 8，并发降到 2~3。MSA 加速解码但不省存储，长上下文仍受显存限制。
最后点出核心判断。
这道题的关键不是算数，而是理解存储和计算是两层不同的瓶颈，以及 GQA 这样的架构设计对推理系统有巨大价值。
总结
这道 MiniMax M3 部署估算题，其实考察的是你对大模型推理系统的整体认知：
| 关键点 | 一句话 |
|---|---|
| MoE 加载 | 稀疏激活，但权重必须全装 |
| GQA 优化 | KV Cache 降到 1/16，长上下文场景价值巨大 |
| MSA 注意 | 加速计算，不省存储 |
| 并发估算 | 理论 22~23，生产按一半算 |
| 长上下文代价 | 每扩 1 倍长度，KV Cache 翻倍 |
面试官要的从来不是一个数字，而是你对系统瓶颈的判断力。
💬 互动问题：你面试时遇到过最出乎意料的大模型工程题是什么？欢迎在评论区分享。
附录：完整的原始计算过程
本文所有计算均基于原文的严谨推导，保留了完整的数学过程，供需要深入研究的读者参考。
补充参数表（来自 MiniMax M3 官方公开配置）
| 参数项 | 数值 | 说明 |
|---|---|---|
| 隐藏层维度 hidden_size | 6144 | Transformer 层特征维度 |
| 注意力查询头数 | 64 | Query 分支注意力头总数 |
| KV 头数（GQA 架构） | 4 | 分组查询注意力，仅 4 组 Key/Value 头 |
| 单注意力头维度 | 96 | 由 6144 ÷ 64 推导得出 |
| BF16 单元素字节数 | 2 | KV Cache 默认存储精度 |
| INT8 单元素字节数 | 1 | 权重量化后单参数占用 |
核心公式
- 模型权重显存 = 总参数量 × 单参数字节数
- 单请求 KV Cache 显存 = 2 × 层数 × KV 头数 × 单头维度 × 序列长度 × 单元素字节数
- 理论最大并发 = 可用 KV 总显存 ÷ 单请求 KV 显存
完整计算汇总
| 指标 | 数值 |
|---|---|
| 权重显存（INT8） | 428 GB |
| 8 卡有效显存（扣 10%） | 691.2 GB |
| 可用 KV Cache 显存 | 263.2 GB |
| 128K 单请求 KV（GQA） | 11.5 GB |
| 128K 理论并发 | 2223 |
| 1M 单请求 KV（GQA） | 92 GB |
| 1M 理论并发 | 23 |
| 并发缩减比例 | 87.5%（1/8） |