移植Strata技术路线到vLLM以适配R9700并让Flash Next真正带并发可用！
-
本轮：批量内核打通，输出变正确，4 路并发首次跑出真实数字
1. 把两个内核都修对了
- gu：尺度组修正为 64，20 个 tile 逐个对拍
diff 0.0； - dn：真正的错误是行块数量算错——我按 8 个块（512 行）写，实际 2560 行需要 40 个块；改成
s = tile//40, rb = tile%40、网格(n, 200)后，全量对拍diff 9.9e-5。
现在每个专家只有 2 次内核 launch（原来 15 次），一个前向的 launch 数从约 2.6 万降到约 4 千。
2. 端到端结果（一个窗口内测完）
ready=200 single (8 tokens): 20 s -> " Paris.\nThe capital of France is" ✅ 正确 4-way (4×8 tokens): 33 s 1 ' Paris. Is this statement true or false' 2 ' Paris' 3 ' Paris' 4 ' Paris' ✅ 四路都对指标 数值 单流 8 token / 20 s ≈ 0.40 tok/s（2.5 s/token） 4 路聚合 32 token / 33 s ≈ 0.97 tok/s 并发增益 2.4 倍（4 路 vs 单路） 质量 四路全部正确回答 "Paris"（PLE 仍关闭） 3. 意义
这是第一次同时拿到：正确输出 + 真实的并发加速 + 有理论依据的瓶颈定位。剩下的差距是纯性能工程，不再是"能不能"的问题：
- 每 token 2.5 秒里，大头是 1920 次 Python 循环 × 每专家 3.6 MB 的 H2D 拷贝（40 专家 × 48 层 × 3.6 MB ≈ 6.9 GB/次前向）；
- 下一步做两件事就能上一个数量级：按层把活跃专家合并成一次批量内核（把 1920 次循环压到 48 次），以及层内专家驻留显存（热集），把 H2D 从 6.9 GB 降到接近 0。
4. 下一轮
- 层内批量：一次 launch 处理该层所有活跃专家（需要原子累加，接口已经验证）；
- 热集驻留：把 48 层的专家按访问频率排序，前 X GB 常驻显存；
- 然后复测单流 / 4 路，目标 单流 >20 tok/s、4 路聚合 >60 tok/s；
- PLE 仍待修（独立模块）。
- gu：尺度组修正为 64，20 个 tile 逐个对拍
-
-
-
-
-
，
T terry 固定了此主题
-
-
-
＠fcme打下来特团长请你吃山西菜
-
-
＠fcme打下来特团长请你吃山西菜
-
-
本轮：按 Strata 逻辑把"频率热集"钉进显存，4 路从 24.7 秒降到 20 秒
实现
- 用 139 万 token 的真实路由统计算出每个专家的命中频率，生成四档热集（
/data/paiton-full/hot_set.json：2000 / 4000 / 6000 / 8000 个专家，含每层具体 id）； - 启动后按层把热专家的 gu/dn 码本一次性搬进显存并常驻（不是 LRU，是频率钉死）；
- 推理时热专家直接命中显存，冷专家才走原来的搬运路径；
- vLLM 的
--gpu-memory-utilization从 0.72 降到 0.60，给热集腾出空间。
实测（4000 档，7.4 GiB，理论覆盖率 34.3%）
指标 之前（LRU 2GB） 现在（频率热集 4000） 4 路 32 token 24.7 s 20.0 s 聚合吞吐 1.30 tok/s 1.60 tok/s MoE 每 block 17-19 ms 14.5-17.3 ms 质量 Paris Paris（四路全对） 这个结果说明了什么
- 热集确实有效，但只快了 23%，和"搬运只占 1.2 ms"的估算吻合：MoE 的 850 ms 里，真正搬运只占一成多，剩下全是"每个专家一次 Python 调用 + 一次内核 launch"；
- 也就是说：Strata 的分层逻辑我们已经复刻了（热集常驻 + 按需取冷），但它治不了我们的主要瓶颈；
- 要再上一个量级，必须把"每层 10 个专家"合并成一次内核调用——即前面写好、但存在 0.02-0.13 数值差异的 grouped 内核。
下一轮
- 在热集已常驻的前提下，把 grouped 内核接回来（此时不需要拷贝，纯计算，最有条件跑对）；
- 用"同一前向内 grouped vs 逐专家"的对照继续定位那 0.02-0.13；
- 目标：MoE 从 15 ms/block 降到 2-3 ms/block，单流进入 0.3-0.4 s/token，4 路聚合 3-4 tok/s。
- 用 139 万 token 的真实路由统计算出每个专家的命中频率，生成四档热集（
-
-
-
-
-
-
本轮：按 Strata 逻辑把"频率热集"钉进显存，4 路从 24.7 秒降到 20 秒
实现
- 用 139 万 token 的真实路由统计算出每个专家的命中频率，生成四档热集（
/data/paiton-full/hot_set.json：2000 / 4000 / 6000 / 8000 个专家，含每层具体 id）； - 启动后按层把热专家的 gu/dn 码本一次性搬进显存并常驻（不是 LRU，是频率钉死）；
- 推理时热专家直接命中显存，冷专家才走原来的搬运路径；
- vLLM 的
--gpu-memory-utilization从 0.72 降到 0.60，给热集腾出空间。
实测（4000 档，7.4 GiB，理论覆盖率 34.3%）
指标 之前（LRU 2GB） 现在（频率热集 4000） 4 路 32 token 24.7 s 20.0 s 聚合吞吐 1.30 tok/s 1.60 tok/s MoE 每 block 17-19 ms 14.5-17.3 ms 质量 Paris Paris（四路全对） 这个结果说明了什么
- 热集确实有效，但只快了 23%，和"搬运只占 1.2 ms"的估算吻合：MoE 的 850 ms 里，真正搬运只占一成多，剩下全是"每个专家一次 Python 调用 + 一次内核 launch"；
- 也就是说：Strata 的分层逻辑我们已经复刻了（热集常驻 + 按需取冷），但它治不了我们的主要瓶颈；
- 要再上一个量级，必须把"每层 10 个专家"合并成一次内核调用——即前面写好、但存在 0.02-0.13 数值差异的 grouped 内核。
下一轮
- 在热集已常驻的前提下，把 grouped 内核接回来（此时不需要拷贝，纯计算，最有条件跑对）；
- 用"同一前向内 grouped vs 逐专家"的对照继续定位那 0.02-0.13；
- 目标：MoE 从 15 ms/block 降到 2-3 ms/block，单流进入 0.3-0.4 s/token，4 路聚合 3-4 tok/s。
- 用 139 万 token 的真实路由统计算出每个专家的命中频率，生成四档热集（
-
-
版主审定：本帖设为精华，作者 +6 积分奖励，希望再接再厉！
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励！