【Strata】4090单卡可以把DeepSeek V4.1 Flash跑到 30+tok/s , 但我不打算试了,因为...
-
因为需要差不多600GB的 SSD 空间, 还是算了...具体看下面说明。
仓库地址: https://github.com/Indras-Mirror/Strata-DSV4.1
一、前排
- 一句话:把官方 552B(+196B Engram)的 V4.1-Flash,用"每个专家单独决定量化格式"压到 151.8 GiB,再靠显存 LRU / pinned RAM arena / NVMe 三层缓存把剩余专家当磁盘文件跑,单张 RTX 4090 + 90 GB 内存就能跑通。
- 速度:prefill 244–288 tok/s(逐位精确);decode 25.5–26.3 tok/s,开 DSpark 推测解码 31.7–39.5 tok/s;真实 agent 会话(20–32K 上下文)22.7–28.2 tok/s。
- 门槛:Linux · NVIDIA ≥24 GB 显存 · ≥64 GB 内存 · 372 GB 快盘起步 · 要下 366 GB。
- 不是通用 GGUF:用了 llama-tq 的
PTQ1_0(GGUF type 143,三值 5 trits/byte),llama.cpp / Ollama / LM Studio 都加载不了,只能上 Strata-DSV4.1。 - uncensored 来自 abliterated 基座,原话:"no refusal behaviour, and you are responsible for how you use it"。MIT。
- decode 默认有损:精确路由能拿 86.2% 的 API top-1,默认偏置 ×0.5 掉到 81.7%,而精确路由只跑 ~2.6 tok/s。
二、硬件需求
项目 要求 说明 系统 Linux
️ 无 Windows 路径;依赖 hugepage + cgroup 限内存GPU NVIDIA ≥ 24 GB 显存 官方构建示例 sm_89(RTX 40xx)。仓库无 40xx 以外实测数据 CPU 官方示例 8 核 Ryzen CPU 参与部分专家计算(三值 kernel 加速 3.9–7.7×) 内存 ≥ 64 GB(arena 60 GiB) --arena-gib可调小,换速度。作者机器 90 GB硬盘 TLC NVMe,随机读 4.5–5.3 GB/s decode 每 token 约 48 次随机 256-byte O_DIRECT 读,SATA/QLC 会塌 CUDA 13.x toolkit 并发 一次一条序列 仓库原话 "one sequence at a time" 显存怎么花:Q8_0 稠密半边 + KV cache + 1,300–1,600 个专家槽。
--kv-fp4(bit-exact 4-bit KV)在 512K 下只多占 1.1 GiB。内存为什么非要 60 GiB:那不是 KV,是
cudaHostRegister的 pinned arena,装 ~6,700 个最热专家,目的是避免 decode 中途读 NVMe。实测加到 62/65 GiB 只少 10% NVMe 读而 decode 不动(24.4–25.2 / 24.5 / 24.7 tok/s)—— 60 GiB 已经够了,别为多装几个专家去加内存。三、硬盘空间需求(重点)
文件 / 阶段 GiB GB 来源 V41-GSQ.gguf.part-01..16(16 分片)151.8 163.0 本仓库 拼接后的 V41-GSQ.gguf151.8 163.0 产物 V41-MTP-Vision.Q2_K.gguf(推荐侧车)5.27 5.66 本仓库 两个 Engram safetensors(各 101.5 GB) 189.1 203
️ 不在本仓库,要去 dealignai 或 deepseek-ai 单独下抽出的 Engram 表( layers.1/layers.14)189.1 202.8 extract_engram.py产物,跑起来必须存在rank.bin+experts.json+tokenizer/~5 MiB — 本仓库 侧车二选一:Q2_K 5.27 GiB(省 2.76 GB 显存给专家缓存,接受率不变,光这一项 decode +10%)或完整版 7.84 GiB。
场景账(这张才是买盘要看的):
场景 单盘峰值 稳态 备注 全塞一块盘 + 不删分片 687 GiB / 738 GB 346 GiB 分片 152 + 拼接 152 + Engram 源 189 + 表 189。不推荐 全塞一块盘 + --delete-parts535 GiB / 575 GB 346 GiB 边拼边删 Engram 源放另一块盘 + --delete-parts346 GiB / 372 GB 346 GiB
推荐,作者的做法跑起来之后 — 346 GiB / 372 GB Engram 源此时可删 结论:最低 1 TB,推荐 2 TB TLC NVMe,最好模型和 Engram 表分盘。抽 Engram 表时源文件和处理结果会同时存在(+203 GB),除非源文件下在另一块盘。别忘下载流量 366 GB。
对账:543.6B 专家 × 2.25 bit ÷ 8 = 152.9 GB(对上 163 GB 文件);Engram 196B × FP8 = 196 GB(对上 203 GB 两个分片)。
四、4090 实测速度
测试机:RTX 4090 24 GB · Ryzen 7 5700X(8 核 AVX2)· 90 GB DDR4-3200 · NVMe
指标 数值 Prefill,8K token prompt 244–248 tok/s(one-shot,tensor-core 专家) Prefill,16K / 20K 288 / 266 tok/s Decode(256-token prompt) 25.5–26.3 tok/s(开 fused ggml op 26.6–28.9) Decode + DSpark(one-shot, greedy) 31.7–39.5 tok/s(docs 39.5 / code 35.6 / python 31.7) 真实 agent 会话(20–32K 上下文) 22.7–28.2 tok/s 模型加载 ~50 s(要钉 60 GiB arena) 对比起点(2026-10-11 第一次跑通 GPU):prefill ~27 tok/s → 现在 244;decode 3.4 → 25.5;加载 211 s → 50 s。
DSpark 在 ×0.5 默认偏置下(置信度门控 verify 的收益):prose 9.5 → 17.3,code 18.8 → 25.5,python 26.6 → 29.1 tok/s。原理是用 checkpoint 自带的
mtp.0-2草稿头起草 4 token、一次 batched verify 全验,任意温度下输出分布都是模型自己的。五、原理(三段话)
1. 量化:为什么不能按层统一量化。 V4.1 的路由专家是在 FP4 里训的,所以同一层 384 个专家共享同一套 per-32 权重分布 —— 第 0 层每个专家的 round-to-nearest 误差三位小数全一样。纯权重指标排不了名次,只能看激活:拿真实 agent 会话记录 + ds4 的 4,690 条 prompt 做标定(128 条 × 2048 token,其中 30 条 held-out 只测量),逐层跑官方
model.py做 teacher 前向,再逐专家 GPTQ。scale 在 GPTQ 之前先按 diag(H) 加权搜好并舍入到各格式能精确表示的值 → 每个结果都能在它的 GGUF type 里精确表示。GPTQ 每组都打赢 RTN(误差比 0.58 三值 / 0.70 Q2 / 0.74 Q3)。格式 bits/weight 专家权重占比 PTQ1_0(三值 {−1,0,+1}) 1.75 42.8% Q2_0 2.25 39.2% Q3_K 3.44 18.0% 全部 2.250 预算是**"全 Q2_0"的精确字节数**(预算中性),用拉格朗日松弛(λ 上二分)+ 贪心补零头分配,关键设计:代价 = held-out 误差 ÷ 该层 routed 输出能量 → 每层等权,前 2 层和后 3 层算双倍。护栏:每层三值 ≤ 50%,held-out token 少于 8 个的专家锁死在 Q2_0。最后再跑一遍顺序量化:每层都拟合在已量化过的下层输出上。实测同体积下比均匀 Q2_0 输出误差低 17%。最戏剧性的一层是 layer 32(全模型最敏感,误差 14.8%),标定把它揪出来单独付了 3-bit。
2. 三层缓存:装不下就当文件。 151.8 GiB 塞不进 24 GB 显存,所以专家当缓存分层:显存 LRU(最热 ~1,300–1,600 个)→ pinned RAM arena(~6,700 个 / 60 GiB,DMA 直送 GPU)→ NVMe 文件层(剩 ~8,700 个,O_DIRECT 读、提前一层预取)。再加 DSpark 推测解码。
3. Prefill 精确 vs decode 有损(最关键)。 Prefill 每一个加速都保证 last-token logits 逐位一致(8192-token 检查 md5
ee31507a0e88)。但 decode 为了速度走了两个"只影响选择"的路由偏置(常驻 +1.0 / 要读 NVMe −0.6):混合权重保持精确、每个专家仍可达,但偏置改变了"这 token 算哪些专家"。路由设置 API top-1 Decode tok/s(docs / python) 精确(bias 0 / 0) 86.2% ~2.6(I/O 绑死) ×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 作者的取舍:speed-first 用默认,quality-first 用 0.25。旧默认还会在部分 prompt 上引发 greedy 复读。
六、坑
- 不是通用 GGUF ——
PTQ1_0是 llama-tq 的自定义 type 143,只有 Strata-DSV4.1 能加载。 - Linux only,且要 hugepage + cgroup(
memguard.sh)。 - Engram 不在仓库,要另外下 203 GB,两个
.NEED-TO-DOWNLOAD-ENGRAM.txt就是提示。 - 磁盘必须 TLC NVMe。
- 一次一条序列。
- 模型加载 ~50 s(钉 arena),
STRATA_NO_LARGEPAGES=1提速钉页。 - 视觉还没做完 —— 侧车带 vision tower,但引擎侧支持未完成。
- HumanEval 20/21 只在 21 道题上量的,别当官方分数(官方 base 卡 Pass@1 是 79.4)。
- 质量对照 FP8 teacher:agent 2.118 vs 2.121、reasoning 6.19 vs 5.83、code 1.98 vs 1.74、zh 7.64 vs 6.83。
七、结论
值得试:有 4090/5090 + ≥90 GB 内存 + 2 TB NVMe + Linux,愿意先花 366 GB 流量 —— 552B 前沿模型在家用主机上跑,prefill 还精确,已经接近"能干活"的门槛下沿。
劝退:16–20 GB 显存、Windows、只有 512 GB SSD。
技术上最值得抄的三条(跟具体模型无关):
- MoE 专家的比特分配必须看激活,纯权重指标在同分布下完全失效。
- 预算可以在专家之间交易,但要每层等权(除以该层 routed 输出能量),并加护栏防无证据降级。
- prefill 可以精确提速,decode 不行。decode 想要速度就得动"选哪些专家",86.2% → 81.7%。任何声称"无损提速"的 MoE 方案,先去问它 prefill 的 last-token logits md5 变没变。
模型与引擎均 MIT。abliteration 由 dealignai 提供,本文不为其行为背书,责任自负。
-
论坛里面有没有愿意试试的?
-
再等等吧....
-
-
因为需要差不多600GB的 SSD 空间, 还是算了...具体看下面说明。
仓库地址: https://github.com/Indras-Mirror/Strata-DSV4.1
一、前排
- 一句话:把官方 552B(+196B Engram)的 V4.1-Flash,用"每个专家单独决定量化格式"压到 151.8 GiB,再靠显存 LRU / pinned RAM arena / NVMe 三层缓存把剩余专家当磁盘文件跑,单张 RTX 4090 + 90 GB 内存就能跑通。
- 速度:prefill 244–288 tok/s(逐位精确);decode 25.5–26.3 tok/s,开 DSpark 推测解码 31.7–39.5 tok/s;真实 agent 会话(20–32K 上下文)22.7–28.2 tok/s。
- 门槛:Linux · NVIDIA ≥24 GB 显存 · ≥64 GB 内存 · 372 GB 快盘起步 · 要下 366 GB。
- 不是通用 GGUF:用了 llama-tq 的
PTQ1_0(GGUF type 143,三值 5 trits/byte),llama.cpp / Ollama / LM Studio 都加载不了,只能上 Strata-DSV4.1。 - uncensored 来自 abliterated 基座,原话:"no refusal behaviour, and you are responsible for how you use it"。MIT。
- decode 默认有损:精确路由能拿 86.2% 的 API top-1,默认偏置 ×0.5 掉到 81.7%,而精确路由只跑 ~2.6 tok/s。
二、硬件需求
项目 要求 说明 系统 Linux
️ 无 Windows 路径;依赖 hugepage + cgroup 限内存GPU NVIDIA ≥ 24 GB 显存 官方构建示例 sm_89(RTX 40xx)。仓库无 40xx 以外实测数据 CPU 官方示例 8 核 Ryzen CPU 参与部分专家计算(三值 kernel 加速 3.9–7.7×) 内存 ≥ 64 GB(arena 60 GiB) --arena-gib可调小,换速度。作者机器 90 GB硬盘 TLC NVMe,随机读 4.5–5.3 GB/s decode 每 token 约 48 次随机 256-byte O_DIRECT 读,SATA/QLC 会塌 CUDA 13.x toolkit 并发 一次一条序列 仓库原话 "one sequence at a time" 显存怎么花:Q8_0 稠密半边 + KV cache + 1,300–1,600 个专家槽。
--kv-fp4(bit-exact 4-bit KV)在 512K 下只多占 1.1 GiB。内存为什么非要 60 GiB:那不是 KV,是
cudaHostRegister的 pinned arena,装 ~6,700 个最热专家,目的是避免 decode 中途读 NVMe。实测加到 62/65 GiB 只少 10% NVMe 读而 decode 不动(24.4–25.2 / 24.5 / 24.7 tok/s)—— 60 GiB 已经够了,别为多装几个专家去加内存。三、硬盘空间需求(重点)
文件 / 阶段 GiB GB 来源 V41-GSQ.gguf.part-01..16(16 分片)151.8 163.0 本仓库 拼接后的 V41-GSQ.gguf151.8 163.0 产物 V41-MTP-Vision.Q2_K.gguf(推荐侧车)5.27 5.66 本仓库 两个 Engram safetensors(各 101.5 GB) 189.1 203
️ 不在本仓库,要去 dealignai 或 deepseek-ai 单独下抽出的 Engram 表( layers.1/layers.14)189.1 202.8 extract_engram.py产物,跑起来必须存在rank.bin+experts.json+tokenizer/~5 MiB — 本仓库 侧车二选一:Q2_K 5.27 GiB(省 2.76 GB 显存给专家缓存,接受率不变,光这一项 decode +10%)或完整版 7.84 GiB。
场景账(这张才是买盘要看的):
场景 单盘峰值 稳态 备注 全塞一块盘 + 不删分片 687 GiB / 738 GB 346 GiB 分片 152 + 拼接 152 + Engram 源 189 + 表 189。不推荐 全塞一块盘 + --delete-parts535 GiB / 575 GB 346 GiB 边拼边删 Engram 源放另一块盘 + --delete-parts346 GiB / 372 GB 346 GiB
推荐,作者的做法跑起来之后 — 346 GiB / 372 GB Engram 源此时可删 结论:最低 1 TB,推荐 2 TB TLC NVMe,最好模型和 Engram 表分盘。抽 Engram 表时源文件和处理结果会同时存在(+203 GB),除非源文件下在另一块盘。别忘下载流量 366 GB。
对账:543.6B 专家 × 2.25 bit ÷ 8 = 152.9 GB(对上 163 GB 文件);Engram 196B × FP8 = 196 GB(对上 203 GB 两个分片)。
四、4090 实测速度
测试机:RTX 4090 24 GB · Ryzen 7 5700X(8 核 AVX2)· 90 GB DDR4-3200 · NVMe
指标 数值 Prefill,8K token prompt 244–248 tok/s(one-shot,tensor-core 专家) Prefill,16K / 20K 288 / 266 tok/s Decode(256-token prompt) 25.5–26.3 tok/s(开 fused ggml op 26.6–28.9) Decode + DSpark(one-shot, greedy) 31.7–39.5 tok/s(docs 39.5 / code 35.6 / python 31.7) 真实 agent 会话(20–32K 上下文) 22.7–28.2 tok/s 模型加载 ~50 s(要钉 60 GiB arena) 对比起点(2026-10-11 第一次跑通 GPU):prefill ~27 tok/s → 现在 244;decode 3.4 → 25.5;加载 211 s → 50 s。
DSpark 在 ×0.5 默认偏置下(置信度门控 verify 的收益):prose 9.5 → 17.3,code 18.8 → 25.5,python 26.6 → 29.1 tok/s。原理是用 checkpoint 自带的
mtp.0-2草稿头起草 4 token、一次 batched verify 全验,任意温度下输出分布都是模型自己的。五、原理(三段话)
1. 量化:为什么不能按层统一量化。 V4.1 的路由专家是在 FP4 里训的,所以同一层 384 个专家共享同一套 per-32 权重分布 —— 第 0 层每个专家的 round-to-nearest 误差三位小数全一样。纯权重指标排不了名次,只能看激活:拿真实 agent 会话记录 + ds4 的 4,690 条 prompt 做标定(128 条 × 2048 token,其中 30 条 held-out 只测量),逐层跑官方
model.py做 teacher 前向,再逐专家 GPTQ。scale 在 GPTQ 之前先按 diag(H) 加权搜好并舍入到各格式能精确表示的值 → 每个结果都能在它的 GGUF type 里精确表示。GPTQ 每组都打赢 RTN(误差比 0.58 三值 / 0.70 Q2 / 0.74 Q3)。格式 bits/weight 专家权重占比 PTQ1_0(三值 {−1,0,+1}) 1.75 42.8% Q2_0 2.25 39.2% Q3_K 3.44 18.0% 全部 2.250 预算是**"全 Q2_0"的精确字节数**(预算中性),用拉格朗日松弛(λ 上二分)+ 贪心补零头分配,关键设计:代价 = held-out 误差 ÷ 该层 routed 输出能量 → 每层等权,前 2 层和后 3 层算双倍。护栏:每层三值 ≤ 50%,held-out token 少于 8 个的专家锁死在 Q2_0。最后再跑一遍顺序量化:每层都拟合在已量化过的下层输出上。实测同体积下比均匀 Q2_0 输出误差低 17%。最戏剧性的一层是 layer 32(全模型最敏感,误差 14.8%),标定把它揪出来单独付了 3-bit。
2. 三层缓存:装不下就当文件。 151.8 GiB 塞不进 24 GB 显存,所以专家当缓存分层:显存 LRU(最热 ~1,300–1,600 个)→ pinned RAM arena(~6,700 个 / 60 GiB,DMA 直送 GPU)→ NVMe 文件层(剩 ~8,700 个,O_DIRECT 读、提前一层预取)。再加 DSpark 推测解码。
3. Prefill 精确 vs decode 有损(最关键)。 Prefill 每一个加速都保证 last-token logits 逐位一致(8192-token 检查 md5
ee31507a0e88)。但 decode 为了速度走了两个"只影响选择"的路由偏置(常驻 +1.0 / 要读 NVMe −0.6):混合权重保持精确、每个专家仍可达,但偏置改变了"这 token 算哪些专家"。路由设置 API top-1 Decode tok/s(docs / python) 精确(bias 0 / 0) 86.2% ~2.6(I/O 绑死) ×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 作者的取舍:speed-first 用默认,quality-first 用 0.25。旧默认还会在部分 prompt 上引发 greedy 复读。
六、坑
- 不是通用 GGUF ——
PTQ1_0是 llama-tq 的自定义 type 143,只有 Strata-DSV4.1 能加载。 - Linux only,且要 hugepage + cgroup(
memguard.sh)。 - Engram 不在仓库,要另外下 203 GB,两个
.NEED-TO-DOWNLOAD-ENGRAM.txt就是提示。 - 磁盘必须 TLC NVMe。
- 一次一条序列。
- 模型加载 ~50 s(钉 arena),
STRATA_NO_LARGEPAGES=1提速钉页。 - 视觉还没做完 —— 侧车带 vision tower,但引擎侧支持未完成。
- HumanEval 20/21 只在 21 道题上量的,别当官方分数(官方 base 卡 Pass@1 是 79.4)。
- 质量对照 FP8 teacher:agent 2.118 vs 2.121、reasoning 6.19 vs 5.83、code 1.98 vs 1.74、zh 7.64 vs 6.83。
七、结论
值得试:有 4090/5090 + ≥90 GB 内存 + 2 TB NVMe + Linux,愿意先花 366 GB 流量 —— 552B 前沿模型在家用主机上跑,prefill 还精确,已经接近"能干活"的门槛下沿。
劝退:16–20 GB 显存、Windows、只有 512 GB SSD。
技术上最值得抄的三条(跟具体模型无关):
- MoE 专家的比特分配必须看激活,纯权重指标在同分布下完全失效。
- 预算可以在专家之间交易,但要每层等权(除以该层 routed 输出能量),并加护栏防无证据降级。
- prefill 可以精确提速,decode 不行。decode 想要速度就得动"选哪些专家",86.2% → 81.7%。任何声称"无损提速"的 MoE 方案,先去问它 prefill 的 last-token logits md5 变没变。
模型与引擎均 MIT。abliteration 由 dealignai 提供,本文不为其行为背书,责任自负。
-
因为需要差不多600GB的 SSD 空间
不知道會不會跑久了把 SSD弄壞? 資料不見了會損失慘重
DeepSeek V4.1 Flash 用線上 API就好了 ?
-
-
-
