【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就好了 ?
-
-
-
