①不同框架对于各种算子和量化格式的兼容性差别太大，paiton这个框架的W3A4模型居然只是给unsloth的nvfp4格式套了个壳，类似于是一个微调过的模型。Flash next，因为这个采用了新的框架模型权重本身是可以通过套同样壳子的方式逆向出来的，但是这个外挂的第二分片也就是ple模块对精度要求比较高，到4bit就崩了。阻止了模型整体进一步的量化。
②另外的话就是虽然有些底层的算子在不同平台之间可以迁移，但是他们的那个运算的框架适配起来也是非常难的，因为涉及到调度，而到这一层几乎是皮秒必争，而不是毫秒。这个开发难度就真的是大仙级别的人才能搞了，独立让AI还是不太行。
③开发方法的问题，Deepseek VS flash虽然是标称一兆上下文，但是实际的情况是过了500k以后，模型就有一点顾头不不顾尾了（而且有一次居然又开始重测之前测试出来一条死路），尤其在这种比较有难度的任务里面。指令遵循和有些设定条件就开始忘了。后来想了一个办法，是开了两个对话，一个作为指挥官来搭建框架和测试清单，然后用另外一个对话来具体执行，这样的话，不污染主对话的缓存池也就是脑子🧠。这个方法换了以后，明显测试的效率和靠谱程度有了肉眼可见的提升。

不过，虽然是如此Deepseek V41 flash现在的能力貌似还是不足以做这种设计底层框架的，但便宜是真的便宜啊，几乎是连续跑了40个小时，中间偶有间断，才花了45人民币。哪怕只是算子级别的迁移也不行，但是调度这些算子做测试，然后优化他们还是可以的。这个大概也是解释了为什么GitHub上做这种项目的联合开发者里面基本都是claude。下周换新工作了，会比较忙，目前需要搁置一下，周末再看看有没有时间精力来搞。

二、尝试过的路径与结果

路径 1：官方 Paiton 原生栈（3-bit / 4-bit 镜像）

结论：24 层 243 是显存容量下的真实上限（3.3 倍 Strata）；全 48 被 96.4 GB 权重卡死。

路径 2：旧自定义 tiered 栈（tiered_qwen4.py）

• CPU-all：2.04 tok/s；native 热混合：1.70 tok/s。
• 结论：Python 模型跑不动，放弃。

路径 3：vLLM走GGUF插件路线（Strata IQ3_XXS 71G）

• 插件 HIP 移植成功（_C_gguf.so 编译通过，type 42 别名、block size 8）；
• 解析出 Strata 的 GSQ-RCO 是混合量化：ffn_gate/up 是 IQ2_XS/IQ3_S/IQ4_XS，ffn_down 是 type 42（2.25 bpw、72 字节块、640 行 = 2.5 块）；
• 结论：640 行 2.5 块的布局需要自定义 dequant 内核，标准插件吃不下，未跑通。

路径 4：CPU 冷（Strata 的“分层计算”）

• 3 层验证：CPU 冷 37.54 vs 纯 tier 90.34，慢 2.4 倍；
• 全 48 从未跑完（挂载、设备、图捕获、/tmp 满等一连串配置错误）。
• 结论：16 核 Xeon 上 CPU 算 3-bit 专家（138 µs/专家）不如 PCIe 搬权重，方向被证伪。

路径 5：PLE 2-bit（方向错误，已纠正）

• 转换成功：51.2 GB → 14.1 GB；3 层 q2 23.21（比 e4m3 慢）；
• 第一次 PPL 142.6（漏乘 row_scale），修正后未复测；
• 结论：PLE 不是“模型权重”，不该压 2-bit；已停止并清理。

路径 6：专家 2-bit（纠错上步，真正的“2-bit 全驻留”）

• 3-bit dequant 布局用 bench_expert.c 验证：LEVEL=[-8,-5,-3,-1,1,3,5,8]、e4m3 scale/64、32 码/3 uint32；
• 4 档 2-bit 的 cos(3bit,2bit)=0.598（偏低）；
• 3 层 2-bit 容器生成（3.1 GB，NFS）；容量账 31.7+48.9+8=88.6 < 104，全驻留可行；
• _Q2Experts 的 Python forward 连续 4 次失败（缺 load_fnq、设备不匹配、shared-expert 混设备），PPL 3222 跑的是旧路径。
• 结论：存储层打通，质量未验证，核心结论空缺。

三、目标达成情况

四、还有希望的方向（按性价比排序）

1. 修 _Q2Experts 到纯 GPU 路径（只剩这一步就能拿到真实 2-bit PPL）：

   • xr、g、dn 全部放 GPU，去掉 .cpu()；
   • 和 shared-expert 的设备边界统一；
   • 预计 1-2 轮内能跑出数字，然后才知道 4 档 0.598 的 cos 到底崩不崩。

2. 8 档 2-bit（每 32 元素一 scale）：cos 可到 0.8+，体积仍远小于 3-bit（约 40 GB），是质量与容量的折中。

3. GGUF IQ3_XXS 的自定义 dequant：640 行 2.5 块 + 混合类型，工作量大但能直接复用 Strata 的 71G 权重，理论 74 tok/s。

4. 接受 3-bit 现状收尾：24 层 243 作为“半模型上限”，全 48 5.34 作为“104GB 硬件的真实天花板”。

@fcme 说:

这太tm有挑战了

https://github.com/Dyluhn/R9V

記得這是最早用vllm+r9700+qfn的方案，參考看看。

@fcme 说:

我的天呐！哈哈哈

太厉害了。人才辈出啊，等你打通后，坛里大神再移植到7900XTX，造福我们79族

1. 先做离线拆解，找到了真正的大头

离线基准（15 个活跃专家，稳态）：

根因：页内存的 H2D 只有 4 GB/s（理论 13.8），且 CPU gather 每次都在 314 MB 的大张量上随机取行、cache 不友好。

2. 模型内实测（单卡、无热集、util 0.60）

四路输出全部正确（Paris）。

3. 现在的瓶颈已经换人了

单 token 拆解：MoE ≈ 288 ms（48 层 × 6 ms），总耗时 ≈ 1,050 ms
→ 非 MoE 部分约 760 ms（注意力 / HC 混合 / 框架开销）

也就是说：MoE 不再是主要矛盾，下一步要看那 760 ms 花在哪。最可疑的是：

1. 我们测试容器里禁用了 Paiton 平台插件（VLLM_DISABLE_PAITON_PLATFORM=1），GDN 线性注意力的优化内核全部没生效；
2. HC 混合（10240 维的多流状态）在 eager 模式下没有融合。

4. 下一轮

1. 用 CUDA event 把"非 MoE 部分"按模块拆开（block 整体 vs MoE 占比，再逐段插桩）；
2. 如果确认是 GDN 注意力，就尝试在保留我们 MoE 补丁的前提下，把 Paiton 的 GDN 优化内核重新打开（这是纯配置/加载顺序问题）。

状态

paiton-8080 正在自启（约 5 分钟就绪）
strata-8080 已停、已禁自启
vLLM 改造：MoE 6 ms/层、4 路 2.06 tok/s（历史最好）