Models and Geometry.zh

模型与几何结构

English | Русский | 中文

每个模型在 4× RTX PRO 6000（96 GB GDDR7，TP4）上需要多少空间。选热门预算前先读这一页 —— 本页旧版公布的热门集大小装不进一张卡；下面的算术才是规划器实际做的事。

规划器计算什么

balance.json 给出 layers、experts、topk、cell_mib_full（一个完整专家在一层的 字节数）。专家库：

完整库（全部 rank） = layers × experts × cell_mib_full
每 rank 库（TP4）   = 完整库 / 4        # 每个专家切分到 4 个 rank

热门预算 HOTSPLIT_HOT_GIB 是每 rank 的，单位 GiB 的 rank 本地行。规划器按 “路由占比 / 字节数”贪心填充。热门专家数量是输出，不是输入。

各模型数字

数值由模型 config.json 算出；cell_mib_full 为约数，实际张量大小在加载时测量 （见配方 README）。这些是规划数字，不是测量值。

MiMo-V2.6-Pro（参考配方）

属性	值
层数 × 专家数，top-k	69 × 384，top-8
完整库（全部 rank）	~492 GiB
每 rank 库（TP4）	~123 GiB
每卡可用显存	~89 GiB（96 GB 减驱动/上下文开销）

整库装不进一张卡。 必须 hot + cold 切分。安全的初始热门预算要给 KV cache 和 CUDA graph 缓冲留出空间：

热门预算 ≈ 可用显存 − KV cache − 保留

例如 8 GiB KV + 2 GiB 保留：89 − 8 − 2 ≈ 79 GiB → 规划器装下多少热门专家就取多少， 此几何下约 384 个中的 240–250 个。确切数量取决于路由直方图 —— dry-run （HOTSPLIT_DRYRUN=1）后看 hotsplit plan 行：它打印预算和得到的热门格数。

本页旧版把 “384 个中的 295 个” 当作默认热门集。那个数字是之前单 GPU 测量的锚点 （7360 槽的 pin-hot-experts 切分），不是每 rank 的显存预算。19 MiB × 295 ≈ 每 rank 94 GiB，在 96 GB 卡上和 KV cache 放不下。不要当作目标。

DeepSeek-V4.1-Flash

属性	值
层数 × 专家数，top-k	40 × 384，top-6
完整库	~280 GiB
每 rank 库（TP4）	~70 GiB
建议热门预算	52 GiB（梯度 47 / 52 / 57 GiB）

有余量：52 GiB 热门 + KV + 保留在 89 GiB 上很宽裕。

GLM-5.3

属性	值
层数 × 专家数，top-k	75 × 256，top-8
完整库	~380 GiB
每 rank 库（TP4）	~95 GiB
建议热门预算	36 GiB（梯度 31 / 36 / 41 GiB）

每 rank 库接近卡的极限 —— 热门 36 GiB 给 KV cache 留出显存。

GLM-5.3-Flash（glm5_next）

属性	值
层数 × 专家数，top-k	42 × 288，top-8
完整库	~160 GiB
每 rank 库（TP4）	~40 GiB
建议热门预算	31 GiB（梯度 26 / 31 / 36 GiB）

整库能装进显存 —— 热门 31 GiB 给 KV cache 留出空间。⚠ 在原版 vLLM 上被阻塞（SM120）—— 见 FAQ。

怎么选热门预算 —— 安全默认值

情况	预算
首次运行，流量未知	配方默认（tp4.env.example 中的锚点）
长上下文、多并发请求	调低预算，把空间让给 KV cache
短上下文、单流	调高，注意日志行 hotsplit mem

经验法则：

• HOTSPLIT_HOT_GIB 留空 = “使用原版放置所用的 GPU 常驻专家字节数” —— 不是 “装下整个专家库”。原版放置从不超出显存；留空默认安全但保守。
• HOTSPLIT_VRAM_RESERVE_GIB=2 是下限，不是承诺。KV cache 由 vLLM 在模型加载后分配； 长上下文会吃掉它。128K 上下文请规划几十 GiB KV，而不是 2。
• 启动后总要验证：bash scripts/check-hotsplit-tp4.sh <container> <dynamic|static> 和日志中的 hotsplit plan 行。