一、先搞清楚这两个东西分别是什么

Strata 是什么

一个推理引擎（不是模型），作者 Niko1221，MIT 协议，2026 年 9 月下旬开源。它只干一件事：

把 Qwen3.8-Flash-Next（125B MoE，48 层，24,576 个专家，每个 token 只激活约 10 个）塞进一张 12GB 显存的消费级显卡。

做法不是把模型压缩掉，而是把整台电脑当成一个分级仓库：

在这个三级结构上再叠两招：

• 量化：ISTA-DASLab 的 GSQ-RCO 方案，把权重压到 2–3 bit。Q2_0 档全部专家只要 34 GB 内存。
• 原生 MTP（多 token 预测）：小草稿层先猜几个 token，大模型一次验证。官方声称 1.6–1.8×，且输出内容不变。

官方基准机是 RTX 5070 12GB + Ryzen 5 7600 + 64GB 内存：

DeepSeek V4 Flash 是什么

284B 总参数 / 13B 激活 / 256 个路由专家 + 1 个共享专家 / 43 层 / 1M 上下文 / MIT 授权。

我的 Huihui-DeepSeek-V4-Flash-BF16-abliterated-ds4-Q4_K.gguf 是社区在 FP4 原生专家权重上做的 Q4_K 对齐版：

153.33 GiB = 164,633,502,304 bytes

注意这个体积。它是后面所有讨论的地基。

二、实测 A：DeepSeek V4 Flash GGUF 到底长什么样

用 Python 直接解 GGUF 头（gguf-py 的 GGUFReader），结果是：

general.architecture = deepseek4
1328 张量

逐项拆开：

逐层组件矩阵（数了每一层有什么）：

它独有的机制：mHC hyper-connection、CSA/HCA 压缩器、sparse indexer、hash 路由、attn_sinks、sliding_window=128、rope yarn×16。

它没有的机制：没有 PLE（per-layer embedding）表，也没有 n-gram 表。

最后这一条，是整件事的关键。

三、实测 B：Strata 的源码绑死了什么

1. 架构守卫只认一个字符串

// include/strata/artifact/gguf_reader.hpp:584
// 只接受 general.architecture == "qwen4exp"

模型是 deepseek4。第一个门就过不去。

2. 几何常量写死在编译期，还散落 14 个文件

include/strata/core/layout.hpp:27-59 里的 ModelGeometry 全是字面量（2560 / 48 层 / 512 / 640 / ssm_* / 24 / 2 / 256 …）。

唯一从 GGUF 读出来的只有两个值：

// src/generate.cpp:2395-2396
expert_count       = <from gguf>;
expert_used_count  = <from gguf>;

同一组几何散落在 14 个文件里：

src/prefill.cpp:93            src/kernels.cu:21
include/strata/core/expert.hpp:34-45    include/strata/core/ngram.hpp:31-42
include/strata/qsa.hpp:109-116          src/plan.hpp:24-58
tools/pack_layer.py:40                  tools/iq_pack.py:202
tools/mtp_rt.py:27                      tools/make_profile.py:33
tools/strata_pack.py:234                tests/native_expert_bench.cpp:46
include/strata/artifact/gguf_reader.hpp:576    include/native_ple_postops.hpp:6

3. 层型是位置算术，不是查表

// include/strata/core/layout.hpp:64
bool is_qsa_layer() { return layer % q.gsa_interval == q.qsa_interval - 1; }
// 实际效果：layer % 4 == 3

也就是说，Strata 认为「每 4 层里第 4 层是特殊层」是数学规律，不是可配置项。

4. 专家 blob 大小是编译期常量，还有硬性宽度检查

// include/strata/core/expert.hpp:45
constexpr BLOB = 1,382,400;

// src/expert_source.cpp:2291
// 宽度不等于 2560 直接拒绝

Deepseek专家宽度是 4096。

5. 注意力是最大障碍

Strata 的 QSA 是一个稀疏 cell 选择器：

indexer → topk_512 → gather → GQA

topk_512 是单个 block 实现的，而且有上限：

// include/strata/qsa.hpp:282-284
kTopkMaxCells = 32768

更麻烦的是 KV cache：

// include/strata/qsa.hpp:63-71
// KV cache 是明文 FP16 GQA — 没有压缩，没有 MLA

而 DeepSeek V4 Flash 的 KV cache 恰恰是 MLA（MLA 就是为压缩 KV cache 而生的）。

在 src/ 目录里搜这些关键词，零命中：

sliding | MLA | kv_lora | compress

四、为什么「改源码」这条路本身就不成立

理由一：Strata 缺的是「机制」，不是「参数」

把两边的机制清单摆在一起看：

机制	Qwen3.8-Flash-Next（Strata 支持的）	DeepSeek V4 Flash（你要跑的）	Strata 里有没有
层数	48	43	写死 48
专家数	24,576	256	从 GGUF 读
每 token 激活	~10	6	从 GGUF 读
专家粒度	小专家	大专家（2048×4096/个）	无概念
n-gram / PLE 表	51B 表，28.8 GB	没有	核心机制，用不上
注意力	明文 FP16 GQA	MLA 64Q/1KV	无
KV 压缩	无	CSA 4× / HCA 128×	无
稀疏选择器	QSA（每 4 层）	sparse indexer（偶数层）	有类似物但不是这个
hyper-connection	无	mHC，43 层	无
attn_sinks	无	43 层	无
hash 路由	无	层 0–2	无

最能说明问题的一行是 n-gram 表。

Strata 的加速逻辑是：

你只用到 24,576 个专家里的 10 个 → 一张巨大的查表告诉你「下一步大概会用哪几个」→ 提前从 SSD 预取 → 等路由真的问到的时候，数据已经在内存里了。

这套东西成立的前提是：专家数量极多、单个专家极小、路由极度稀疏。

DeepSeek V4 Flash 是 256 个专家、每个是大矩阵、激 6 个。它的瓶颈根本不是「预测哪个专家」，而是「专家张量本来就大」。Strata 那张表在这个形状上没有任何价值。

理由二：Strata 的设计哲学就是「一个模型一个引擎」

官方文档第一句就写死了：

Strata runs one model, Qwen3.8-Flash-Next.

这不是「暂时只支持一个」，是刻意的设计选择。作者把整个引擎的 kernel、内存布局、调度器都围绕这一个模型的形状去塑形。这正是它比通用引擎快的原因——

社区里对它有个很准的称呼：「napkin runtime」（餐巾纸运行时）。一位开发者在实测对比里写道：

在同一台 RTX 4070 12GB 的机器上，把 llama.cpp 调到极限是 27 tok/s；换 Strata，在 6 万 token 上下文下跑出 53.2 tok/s。

差值不是来自更好的优化，而是来自放弃通用性。

同一批「偏科引擎」还包括 ninfer、DwarfStar、Splash、llamAmpere、gufo——每一个都只服务一个模型 + 一类硬件。

那到底要写多少代码？

粗估：6,000–10,000 行新 C++/CUDA，用来实现一个 deepseek4 后端。

而且要注意，这不是「在现有代码上加分支」。Strata 的几何常量是通过编译期字面量渗透进 kernel 的，加第二个架构意味着这些常量要全面泛化——而它们散落在 14 个文件里，其中一部分在 .cu 里直接影响性能假设。

五、那正确的路怎么走

路径 A：DwarfStar（ds4）—— 这就是为 DeepSeek V4 写的引擎

最直接、最对症的一条路。 作者是 antirez（Salvatore Sanfilippo，Redis 的作者），MIT 协议，纯 C。

官方定位：

ds4 is intentionally narrow: it supports a small, opportunistic set of model families.
Today that means DeepSeek V4 Flash and PRO, DeepSeek V4.1 Flash, GLM 5.x and Qwen3.8 Flash Next.

后端已经不只 Metal 了：

可选模型档位：

./download_model.sh ds4f-q2        # Flash · 96–128GB
./download_model.sh ds4f-q2-q4     # Flash · q2 + 最后 6 层专家 q4
./download_model.sh ds4f-q4        # Flash · 4-bit · 256GB+
./download_model.sh ds4f-mxfp4     # Flash · 原生 MXFP4 专家 · ~156GB
./download_model.sh ds4f-dspark    # Flash · DSpark 投机解码支持文件

路径 B：llama.cpp —— 通用、稳、但慢

上游 llama.cpp 从 b9843 起支持 deepseek4 架构。官方 GGUF 已经现成：

# MXFP4，约 155 GB，2 个分片
llama-server -hf ggml-org/DeepSeek-V4-Flash-0731-GGUF:MXFP4

路径 C：如果你还想用 Strata —— 就用它原本的模型

Strata 就是为 Qwen3.8-Flash-Next 造的。本机在双卡上其实已经跑通了，实测数字也拿下过（热请求 ~140.8 tok/s 含 TTFT）。让它继续跑它擅长的模型，是收益最高、成本最低的选择。

路径 D：如果只是想复刻 Strata 的调度思路

Strata 真正值得抄的不是它的 CUDA kernel，而是调度层：

• serve/server.py（7,517 行，零模型常量）
• CUDA graph 捕获
• VMM 弹性 arena
• 专家缓存的 admit / never-evict 策略 + 按层准入窗口
• CPU/GPU 专家瀑布（miss 在 CPU 上并行算，不阻塞 GPU）
• MTP 投机框架
• 多卡 peer experts

这些是可以剥离出来挂到别的后端上的。但注意：调度框架能复用，调度参数不能。 专家槽位数量、准入窗口大小、预取深度，全都是按「24,576 个小专家、激活 10 个」调出来的。换成「256 个大专家、激活 6 个」，这些值必须重调。

六、一句话总结

附：这件事背后更值得想的一个问题

##### 虽然没折腾成功吧， 但是我觉得也算是给大家一个科普，让大家知道为什么Strata只能跑Qwen3.8 Flash , 也大概知道一下原理。 对自己的硬件， 和后续的投资， 有一个清醒的认识。

Strata 这类「偏科引擎」（社区叫 napkin runtime）最近集中出现，不是偶然。

推理优化有一个很特殊的性质：它的目标函数异常清晰。

输入：一个固定的权重文件 + token id
约束：输出必须和参考实现在容差内一致
目标：每秒更多 token、更少内存

这种「可机器校验」的目标，让 AI coding agent 能围着硬件计数器反复迭代。结果是——写一个高性能推理引擎的成本，从「资深系统工程师几个月」降到了「几周甚至更短」。

但代价也写在同一张纸上：目标越窄，优化越狠；模型一换代，引擎可能直接作废。

有开发者立了一个可检验的预测：到 2027 年 4 月，这批偏科引擎里至少 4 个会连续 60 天没有任何提交。

所以更可能的未来不是「偏科引擎取代通用引擎」，而是：

通用引擎继续做格式、量化研究、各后端的参考 kernel，退成「零件库」；
偏科引擎从里面拆零件，拼成一次性快消品。

别跟推理引擎绑定。 真正稳定的那一层是它上面的接口——OpenAI / Anthropic 兼容的 HTTP API。引擎可以换，客户端不用动。