百万上下文这七天：我把三家的账自己算了一遍

百万上下文这七天：我把三家的账自己算了一遍

10 月 15 号那天，我的信息流里连着跳出三条消息：Meta 放了 Muse Spark Open，816B 总参、42B 激活、1M 上下文；NVIDIA 发了 Nemotron 3.5 Super VL，120B 总参、12B 激活，也是 1M；同一天阶跃星辰开了 Step 5 Preview 的权重，600B 总参、27B 激活，还是 1M。

三个模型、三家厂商、同一个数字。我看完的第一反应不是「厉害」，是想知道这个 1M 到底要花多少东西才喂得进去。于是我把官方页面翻了一遍，又自己写了个脚本算账。算完我发现，「1M 上下文」这个数字本身，可能是整场发布里最不重要的那个信息。

官方自己先留了一句活话

我先把三组数字核了一遍。Meta 官方博客（research.meta.ai，核对日期 2026-10-17）写的是 816B 总参、42B 激活、1M 上下文，重点强调两台 M5 Ultra Mac Studio 就能跑；NVIDIA 的模型卡（build.nvidia.com 与 Hugging Face 上是同一份文本）写的是 120B 总参、12B 激活、NVFP4 精度、最高 1M；Step 5 Preview 是 600B 总参、27B 激活、1M 上下文，BF16 和 FP8 两个版本。

真正让我停下来的是 NVIDIA 模型卡里那句话：

Individual deployment recipes may use a smaller context window to accommodate the available GPU memory and concurrency.

翻过来就是：具体部署时，为了迁就显存和并发，实际窗口可能比 1M 小。厂商自己先把活话留了。同一份模型卡里，DGX Spark 的 vLLM 启动参数写着 --max-num-seqs 1——一台机器，一次只服务一个序列。

这就值得我自己算一遍了。

第一笔账：权重装不装得下

我把官方参数乘上精度字节数，得到权重体积（GiB）：

对照官方硬件：DGX Spark 128 GiB 统一内存、H200 SXM 141 GiB HBM3e、单台 M5 Ultra 最高 512 GiB（两台合计 1024 GiB）。

这里有个我算之前没想到的结论：Meta 那个「两台 Mac Studio 就能跑」的说法，把精度选择直接锁死了。1024 GiB 的池子，装 4bit 的 380 GiB 绰绰有余，装 FP8 的 760 GiB 还行，但 BF16 的 1520 GiB 根本塞不进去。所以「桌面跑旗舰」不是一句营销话，它背后是一条硬约束——你必须量化，而且大概率是 4bit。

Nemotron 的 56 GiB 是另一回事：它小到能进 128 GiB 的 DGX Spark，这就是为什么 NVIDIA 敢把它列成桌面部署选项。

第二笔账：生成速度是被内存带宽钉死的

decode 阶段每生成一个 token，都要把用到的权重从内存里读一遍。我把这个量算出来，再除以官方标称带宽，得到单并发的理论上限：

// bytes/token = 激活参数 × 每参数字节数；tok/s = 带宽 ÷ bytes/token
// batch=1 时只读激活参数（MoE 大 batch 会退化成接近读全量专家，这里是乐观上界）
const perTok = gig(m.active * bp);      // 例如 42e9 × 0.5 = 19.6 GiB
const tps = hw.bw / perTok;             // 带宽 GB/s ÷ GiB/token

跑出来是这样（单位 tok/s）：

我看这张表看了挺久。统一内存的好处是容量，代价是带宽——DGX Spark 的 273 GB/s 只有 H200 的十八分之一，所以同一个模型在桌面上只能跑到十几 tok/s。M5 Ultra 的 1.2 TB/s 已经很体面了，但 42B 激活参数摆在那儿，4bit 下也就 61 tok/s。

这里我得给自己的数字打个补丁：我算的是纯自回归、batch=1、没有投机解码的上界。NVIDIA 模型卡里明确写了原生 MTP（Multi-Token Prediction）投机解码——一次前向出多个 token，这个天花板是可以被打破的。我看到有报道说 Nemotron 单卡峰值到 1,860 tok/s，比我算的 859 高一倍多，但那是二手来源，我没核实，也不打算拿它当结论。我只敢说：我这张表是「不开投机、不批处理」的最坏情况，真实部署会更高。

第三笔账：1M 上下文真正的开销在 KV cache

前面两笔账跟上下文长度没关系，是模型本身的固定成本。真正随 1M 线性膨胀的是 KV cache：

function kvGiB(nLayers, kvHeads, headDim, seqLen, bytes) {
  return gig(2 * nLayers * kvHeads * headDim * seqLen * bytes); // 2 = K 和 V
}

问题是我拿不到官方的注意力层数、kv 头数和 head_dim——这些数字厂商都不在模型卡里写。所以我改成分档扫描：层数固定用 Step 5 官方技术博客提到的 92 层，seq_len 1M，dtype FP8，扫 kv 头数 × head_dim × 注意力层占比：

（单位 GiB。kv_heads / head_dim 是我扫的参数，不是官方数字，这三家都没公布。）

对照一下：H200 是 141 GiB，DGX Spark 是 128 GiB。也就是说，只要是全注意力架构，1M 上下文的单条 KV cache 就能吃掉一整张卡甚至更多，权重还没算进去。

这一下我就明白两件事了。NVIDIA 为什么要用 Mamba-2 和 Transformer 做混合——Mamba 层没有 KV cache，把 attention 层占比压下去，这张表的列直接往右移。Step 5 为什么强调 Sparse GQA——同一个道理。这些不是「优化」，是让 1M 成立的前提条件。 厂商没在标题里说，但架构选择已经把答案写出来了。

3.3 MB 的文本，175 GB 的缓存

算到这儿，我突然想验证一个直觉：1M token 的原文到底有多大？我顺手扫了自己工作区 daily/ 目录下的 24 篇 Markdown：

本机 daily/ 目录实测：24 篇 md，总 217 KiB，均 9.0 KiB/篇
  中位 9.5 KiB，最大 13.7 KiB，最小 4.1 KiB

按常见的 3.0～4.0 bytes/token 折算（这是经验区间，不是我实测的），1M token 大约是 2.9～3.8 MiB 文本，相当于我那 24 篇里的 324～432 篇——也就是说，够装下我这一年写的全部博客还好几倍。

然后我把两个数字并排放：

3.3 MiB 的文本，为了让它待在上下文里，你得准备 175 GiB 的显存。放大了五万倍。

这个数字把我之前对长上下文的理解整个推翻了。我一直以为长上下文的瓶颈是「模型能不能读那么多」，现在我发现瓶颈是「你愿不愿意为它付多少倍的存储」。文本本身小得可怜，贵的是让它可被注意到的那个中间状态。

顺手也算了下 prefill：按 2 × 激活参数 × seq_len 估，塞满 1M 要 24～84 PFLOPs，在 H200 的 dense FP8 算力（1979 TFLOPS）下是 12～42 秒。我按 40% MFU 折算后是 30～106 秒——这个 40% 是我拍的经验值，不是实测，官方从来不公布 MFU。但不管怎么算，每次新会话塞满 1M，用户都得先等半分钟以上。

我的判断

我把这三笔账算完后的结论是：「1M 上下文」现在是个营销单位，不是个使用单位。

厂商报的 1M 是架构上限，不是你能舒服用到的长度。NVIDIA 自己那句「部署配方可能用更小的窗口」已经说得很清楚了。真要判断一个模型能不能扛住长上下文，我现在会看三个数：注意力层占比（不是层数）、KV cache 的 dtype、以及它给的目标硬件带宽。总参和激活参数这两个被反复宣传的数字，跟长上下文能力几乎没有关系。

还有一点我以前搞反了：我以为小模型配长上下文更划算，现在看不是。KV cache 只跟注意力层数和头数有关，跟总参数量无关——一个激活 12B 的模型和一个激活 42B 的模型，同样 1M 上下文，KV cache 开销可能在一个量级上。贵的从来不是模型，是上下文。

所以「两台 Mac Studio 跑 816B」这件事，我的看法是：它证明的是统一内存的容量价值，不是桌面推理的实用性。1024 GiB 听起来很爽，但 1.2 TB/s 的带宽配上 42B 激活，4bit 下也就 61 tok/s，还得先等几十秒的 prefill。它适合跑一次跑很久、不太关心延迟的长程 agent 任务——这恰好是 Meta 演示的那类场景（改代码、剪视频）。要聊天式的响应，还是得回 H200 这类卡上。

至于我要不要自己搞一套：算完这笔账，我的答案是不要。我没有 GPU，按表里的数字，就算有，单卡也就能给我 800 tok/s 的理论上限、实际更早撞上 KV cache 的墙。真要用长上下文，我会去按量付费的推理平台上跑——比如硅基流动（https://cloud.siliconflow.cn/i/pyV0lE45，这是我的邀请链接，注册我有返利），把「买一张卡」换成「买几小时的算力」，先确认这个长度真的能解决我的问题再说。

1M 上下文真正的门槛从来不在模型那边，在你愿不愿意为那 3.3 MB 文本付 175 GB 的钱。

信息源与核对日期（2026-10-17）

• Muse Spark Open 参数与 Mac Studio 部署：Meta 官方博客 research.meta.ai/blog/muse-spark-open
• Nemotron 3.5 Super VL 模型卡（120B/12B、NVFP4、1M、混合架构、DGX Spark 配置）：build.nvidia.com 与 Hugging Face nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4
• H200 141 GB / 4.8 TB/s：NVIDIA 官方产品页；DGX Spark 128 GB / 273 GB/s：NVIDIA 官方支持页
• Step 5 Preview 参数（600B/27B/1M/BF16+FP8/92 层/Sparse GQA）：官方公告与南方+ 报道转述，平台文档 platform.stepfun.com
• 未核实、文中已标注：Nemotron 单卡 1,860 tok/s（二手报道）；各模型的 kv_heads 与 head_dim（官方未公布，我为扫描取值）；40% MFU（经验值）；3.0～4.0 bytes/token（经验区间）