640GB显存才装得下的552B DeepSeek，1张4090跑出27 tok/s

一、同一份权重，两种装法

官方给 DeepSeek-V4.1-Flash 写的 vLLM 部署配方是 8 张 80GB 的卡，640GB 显存起步。检查点本身 510GB，装完之后剩下的 130GB 要同时养 KV 缓存、激活值和运行时开销。

另一台机器上只有四样东西：一张 RTX 4090、锐龙 7 5700X、90GB DDR4 内存、一块 NVMe 硬盘。

10 月 17 日，一个署名 Indra's Mirror 的开发者把这 552B 的模型放到了这一台上。解码 26.8 tok/s，预填充 180 到 320 tok/s（6.1K 和 16.5K 提示词上的实测点分别是 178 和 268），上下文开到 512K。

这不是"能回一句话"的演示。21 道 HumanEval、10 个工具调用任务、3 个 agent 修 bug 循环，全部走真实服务端，思考预算给到 32K，结果是 21/21、10/10、3/3。

引擎叫 Xolotl，仓库在 github.com/Indras-Mirror/Xolotl，10 月 6 日建，MIT 协议，203 星。它在 Strata 之上加了约 7.1 万行代码，同一个二进制还顺手跑 GLM-5.3-Flash（25.3 tok/s）、Qwen3.8-Flash-Next（127.8 tok/s）和稠密的 Qwen3.8-27B（98.5 tok/s）。

640GB 对 24GB，是 26 倍的差距。这条线过去被当成硬边界：想碰前沿模型，先买一台八卡机。Xolotl 干的事，是把边界从"显存够不够大"改写成"你的硬盘答不答得过来"。

二、秘密不在压缩，在"哪些东西可以等"

官方 vLLM 配方

这一台

显存

8 × 80GB = 640GB

1 × 24GB

检查点

510GB

163GB 权重 + 203GB 查表

权重放哪

全在显存

显存 + 60GiB 内存 + NVMe

硬盘

可不落地

366GB

解码

未给单机数

26.8 tok/s

163GB 不是简单压出来的。它把 15,360 个路由专家按重要程度分成三档：三元 1.75 位占 42.8%，2.25 位占 39.2%，3.44 位占 18%，平均 2.25 位。稠密的那半边反而给到 Q8_0，嵌入表保持 F16。同一个体积下，比全用 2.25 位少 17% 的输出误差。

真正的机关在别处：552B 里有 196B 参数是一张哈希表，DeepSeek 管它叫 Engram，按当前 token 的 2 到 4 元组去查，地址由哈希直接算出来，不需要先算什么再找什么。

地址既然在计算之前就知道，它就可以不待在显存里。

每 token 12 KiB 对 2.22 GiB

Engram 两张表，101.5GB 一张，共 203GB，留在盘上。每生成一个 token，引擎从中读大约 48 行，每行 256 字节，合计 12 KiB。

同一时刻，专家权重那边要搬 2.22 GiB：top-6 专家乘 40 层，8.49B 参数按 2.25 位算。

差约 19 万倍。

这就是"552B 塞进 24GB 卡"的全部原因。不是把 552B 压成了 20B，而是把占比最大、又基本不参与计算的那一块请出了显存。真正要搬来搬去的专家权重，分三级放：

装什么

数量

怎么进出

显存 24GB

最热的专家

约 1,300–1,600 个

LRU，路由偏置偏向常驻者

内存 60GiB

次热

约 6,700 个

DMA 直送显卡

NVMe

剩下的

约 8,700 个

O_DIRECT 读，提前一层预取

10 月 17 日那版还加了一条"对话自适应"：两轮之间，把这段对话实际用到的、原本在盘上的专家挪进内存，NVMe 读量降 21% 到 30%，6K 上下文下一个 180 token 的追问从 8.5 秒降到 7.6 秒。

三个账本，五分钟能自己算一遍

# 三个账本：精度换体积、每 token 的搬运量、KV 缓存P = 552e9              # 主干参数；其中 15,360 个路由专家占 543.6BENG = 203              # 两张 Engram 表（FP8 行），原样留盘，不参与量化print("== 账本一：同一份主干，精度换体积 ==")for bpw, name in [(1.75, "全三元"), (2.25, "混合配比"), (4.0, "4 位"), (8.0, "FP8 原样")]:bb = P * bpw / 8 / 1e9print(f"{name:6s} 主干 {bb:6.1f} GB + Engram {ENG} GB = {bb + ENG:6.1f} GB")print("实际发布文件 163 GB（比 2.25 位的理论值多 8 GB：稠密半侧 Q8_0、嵌入 F16）")print("\n== 账本二：每生成一个 token 要搬多少 ==")params = 543.6e9 * 6 / 384          # top-6 / 384exp_gib = params * 2.25 / 8 / 2**30eng_kib = 48 * 256 / 1024print(f"专家权重 {exp_gib:5.2f} GiB（{params / 1e9:.2f}B 参数 × 2.25 位）")print(f"Engram   {eng_kib:5.0f} KiB（48 行 × 256 字节）")print(f"倍数      {exp_gib * 2**30 / (48 * 256):,.0f} 倍")print("\n== 账本三：890 字节/token 的 KV ==")for ctx in (32_768, 131_072, 524_288):print(f"{ctx:>7d} 上下文 {890 * ctx / 1e6:6.1f} MB")

跑出来的结果：

== 账本一：同一份主干，精度换体积 ==全三元    主干  120.8 GB + Engram 203 GB =  323.8 GB混合配比   主干  155.2 GB + Engram 203 GB =  358.2 GB4 位    主干  276.0 GB + Engram 203 GB =  479.0 GBFP8 原样 主干  552.0 GB + Engram 203 GB =  755.0 GB实际发布文件 163 GB（比 2.25 位的理论值多 8 GB：稠密半侧 Q8_0、嵌入 F16）== 账本二：每生成一个 token 要搬多少 ==专家权重  2.22 GiB（8.49B 参数 × 2.25 位）Engram      12 KiB（48 行 × 256 字节）倍数      194,407 倍== 账本三：890 字节/token 的 KV ==32768 上下文   29.2 MB131072 上下文  116.7 MB524288 上下文  466.6 MB

这里能读出两件反直觉的事。

一是官方那 640GB 的余量，其实不是留给 KV 的。890 字节每 token，开到 512K 也只吃掉 466MB。130GB 余量是留给激活值、批处理并发和运行时开销的——换句话说，官方配方的贵，贵在"同时服务很多人"，不在"装下这个模型"。

二是 Engram 这 203GB 一分都压不掉。主干能从 510GB 压到 163GB，是因为权重可以按位重新分配；而这张表是按字节寻址、随机读几行的，压了它就要改成按块解压，读一行变成读一串。作者的取舍是原样保留 FP8 行，让它体积不动、访问方式不动。

压完之后，还是不是同一个模型

校准集 49,146 个 token 上，困惑度 5.645，原检查点 4.915。拆开看更有意思：agent 类 2.118 对 2.121，几乎持平；代码 1.98 对 1.74，中文 7.64 对 6.83，差距都在这儿。top-1 一致率 0.674 对 0.701。

最值得看的是分层的账。第 20 到 31 层，量化后输出误差只有 0.03% 到 0.44%，几乎不敏感；第 32 层一层就占 14.8%，是整份模型里最敏感的地方，校准把它找了出来，也给它多分了位。这套分配不是按参数平均分，是按"每一层说话一样重"的预算去抢。

三、27 tok/s 是有代价的，代价写在作者自己的表里

先把话说清：这个速度不是白来的，作者也没藏。

Xolotl 解码时会用两个"只选不混"的路由偏置——常驻显存的专家加 1.0 分，在盘上的减 0.6 分。混合权重本身不变，每个专家理论上都还能被选中，但"这一 token 由谁算"被改写了。作者在 112 份官方 API 的对照样本上，把四档偏置都跑了一遍：

路由

与 API 一致率

NLL

解码 tok/s

精确

86.2%

约 2.6

× 0.25

85.2%

12.6 / 7.4

× 0.5（当前默认）

81.7%

18.4 / 11.2

× 1.0 加 0.6 罚

72.1%

29.9 / 20.6

精确路由只有 2.6 tok/s，因为大部分专家在盘上，每一步都在等 I/O。把偏置拉满，速度翻十倍，与官方 API 的一致率掉到 72.1%。作者自己补了一句：默认偏置在贪心解码下，会让某些提示词陷进复读循环。

这张表是全文最该看的一行。它把"能跑"和"跑得对"放到了同一根轴上——想快，就得让模型少用那些躺在盘上的专家；少用，它算出来的就不是原来那个模型了。

这个代价是结构性的，不是调参没调好。MoE 的路由本来就是离散的：每个 token 只挑 6 个专家，挑谁由门控网络决定。当一部分专家躺在盘上，引擎就有动机影响这个决定——说白了，就是把够得着的往前排。速度与一致性的交换，在这套架构里是物理属性。

第二笔代价是"想得更久"。LiveCodeBench 那一组，官方 API 在 60 题切片上 90.0%；本地把整轮限制在一小时，只跑完 3 题，同样的题思考量是 API 的 3 到 12 倍，一道题 5 到 20 分钟。7 道多轮 agent 题里，API 解出 5 道，本地解出 4 道，总分 6.20 对 6.41。

这组数字比"跑分差 3%"难听，也真实：它快在每次吐字，慢在吐字之前先想很久，而后者不出现在 tok/s 里。

社区里最先被顶起来的三条质疑，值得摆出来。一位叫 kenashe 的读者做了技术复盘，"能跑"和"可靠"不是一回事，长上下文会暴露失效模式，工具调用十次干净、第十一次崩；另一条更具体，27 tok/s 只测了生成，SSD 分页最痛的恰恰是预填充，180 到 320 这个区间没有延迟分布；第三条是量化的账，1017 版权重还是 510GB，架构没变速度可以平移，但校准和量化要全部重跑。

作者的回应基本都在仓库里，没在评论区。预填充这次给了两个点：6.1K 提示词 178 tok/s，16.5K 提示词 268 tok/s；长提示时把投机解码的草稿挪出显卡之后是 187 和 317。第一、三条质疑算是被数据接住了。第二条没被接住——512K 上下文下的预填充，至今没有公开数字。

还有一句更诚实的，写在 README 里：多出来的思考量到底来自量化、来自去审查，还是来自路由偏置，作者说他自己也还不知道。

四、想试的人，先测三样东西

门槛不长，但每一项都硬。

要求

显卡

24GB NVIDIA

Linux，CUDA 12.x 或 13.x

内存

90GB 起

专家区默认 60GiB，可下调，代价是速度

硬盘

366GB

模型 163GB 加查表 203GB

临时空间

再 203GB

解表期间需要，解完可删

首次加载

约 50 秒

要先把 60GiB 内存钉住

真正决定成败的是硬盘，而且不是顺序读。每生成一个 token 要读约 48 次 256 字节的随机行，两块表分放两块盘最理想。顺序读写 3GB/s 的盘在这件事上帮不上忙——先用 fio 或 diskspd 跑一遍 4K 随机读，这块盘最好能过每秒 1GB，过不了就别折腾了。

第二件事是把上下文压到 32K 再试。512K 是自报值，作者速度表里最长的真实测试是 20 到 32K 上下文下的 22.7 到 28.2 tok/s。一上来就开满，等来的不是惊喜。

第三件事是别把这台机器当服务器。26.8 tok/s 是单请求，整份 README 没提并发。说白了，它是给一个人用的；多几个人一起用，立刻回到"专家在盘上排队"的状态。

这份量化的地址是 huggingface.co/IndrasMirror/DeepSeek-V4.1-Flash-GSQ-Uncensored，下载完还要单独取两张 Engram 表。

手头只有 64GB 内存、显卡也更小的话，同一个引擎里的 Qwen3.8-Flash-Next 更合适，同一张 4090 上 127.8 tok/s，内存和显存压力都小一截。先用它把 Engram、O_DIRECT、专家分层这套流程走一遍，再决定要不要为 552B 备 366GB 的盘。

五、它证明的和它没证明的

它证明了一件事：一个 552B 的模型能不能在消费级机器上跑，取决于它的参数里有多少是必须算的、多少是查一下的。这一次，查的那部分占了三分之一还多，于是 24GB 的卡就有了机会。

它没证明的是：这套东西在真实仓库、真实长会话、真实并发下还站得住。所有数字来自一台机器、一个人、一份自报的 README。

一个问题留给看到这里的你：如果 27 tok/s 需要用"跟原模型七成一致"来换，你更愿意要一个速度打七折但算得准的版本，还是一个跑得飞快、偶尔陷进复读循环的版本？