一句话:把整条自研 NVFP4 引擎线 profile(性能剖析)到底,得到一张「力学图」——单流(single-stream,单用户一次一个请求)的杠杆在「格式」、并发(concurrent,多请求批量)的杠杆在「服务系统」,自研引擎在这两条轴上都不是杠杆点。于是引擎线收口,主线回到产品(蒸馏编排器),前沿 NVFP4 放回它真正起作用的并发侧。不是打不过生态,是测明白了力该往哪使。

📄 完整复盘:引擎线收口复盘 · 全口径 benchmark 附录:NVFP4 benchmark appendix

① 主线 = 蒸馏任务编排器(产品的大脑,不是引擎)。 用 LoRA(r=64 / α=128 / 1842 样本)把 DeepSeek-V4-Pro 在 thinking-on 时的多步推理 + 自我验证思维方式蒸进 Qwen3.6-35B-A3B(MoE,3B 激活)。实测(同 harness,thinking-on,vs 原版):端到端编排 26.6s(快 2.3×)/ GPQA-Diamond 80.3%(+7.6pp) / MMLU-500 90.2(持平)/ 编排假验证 0/20。蒸的是「思维方式」,红利是更少 token 到结论。 📦 ModelScope Merkyor/Qwen3.6-35B-A3B-DSV4Pro-Thinking-Distill · HuggingFace nerkyor/Qwen3.6-35B-A3B-DSV4Pro-Thinking-Distill(BF16 + Q4_K_M gguf)。

② 单流推理(single-stream)= 最快的 llama.cpp。 单流 decode(单 token 生成)是带宽 / launch(内核启动)的游戏,自写内核打不过成熟的 llama.cpp。同模型同卡单流 tok/s:

端侧 / 桌面主推理选 llama.cpp(单流最快、生态成熟、全平台),并把实测改进回馈上游:llama.cpp #24273(NVFP4 转换 / 后端 / 基准实测指南文档,review 中)。

③ 并发服务(concurrent)= vLLM + NVFP4 —— 不放弃前沿。 NVFP4 的真红利不在单流 decode,而在并发吞吐——但兑现它的瓶颈是 PagedAttention(分页注意力)+ continuous batching(连续批处理)这套服务系统,而 vLLM / SGLang 本质就是这套系统。同张 R6000 VLLM_MOE_FORCE_MARLIN=1:

NVFP4 vs FP8(同机同 harness)每档都赢 1.14–1.34×。 把这条 W4A16 NVFP4 Marlin 路径的回归测试 / 文档 / 正确性门禁回馈 vLLM(3 个 open PR,review 中):#44671 / #44672 / #44673。

加入生态,但没放弃 NVFP4。 自研引擎收束为研究资产 + 4 个上游 PR;NVFP4 放回它真正起作用的并发侧持续科研。没造出护城河,但把「怎么把 NVFP4 用对」从私有内核知识变成了生态公共证据。本仓库没白干留下的真东西:① decode-only 删 shadow(影子权重)→ 常驻显存 88 → 28 GiB(腾 60 GiB 给 KV / 长上下文);② 一整套「让实测改路线」的工程纪律 + 跨设备量化知识;③ 想清楚了护城河在产品(那个会派活的蒸馏编排器),不在格式 / 内核 / 几个 TPS。

📚 以下为研发期(2026-05 ~ 06)完整证据账本(归档) —— 记录我们怎么一步步走到上面那张「力学图」与收口结论,供复盘与同行复核留存。结论以顶部收口为准;下方各「路线 / 后续」表是当时在推进的研究方向,已被收口收敛。

诚实边界: Spark sm_121 当前 deliverable decode 仍是 ~44-45 TPS;60 GiB shadow-drop 是服务显存/产品化赢,不是速度杠杆;P4C 只 bank route/numeric/profile/basic-smoke,不 bank fused speed/default promotion。speed 火力转向两件事:MTP eager-runtime 去开销 / token-exact batched verify,以及把 decode hot loop 从 Python 搬到 compiled/C++ 服务循环以降低 per-launch host dispatch;但首轮 GPU-idle probe 是 borderline(host-gap 24.7%),所以先做 Nsight/小样,不直接押月级重写。reusable decode CUDA graph 已实测 0.75× 净负并关闭,不是当前路线。Python 只做控制面和验证;追赶 llama.cpp 靠 native runtime + kernels,在 FP4-MMA 硅上才完整兑现。

机器分工: Spark 负责当前 35B 服务链、60 GiB 显存生命周期、MTP runtime、compiled hot-loop ROI 与 RC/quality 回归;R6000 负责 Spark 做不了的 FP4-MMA/CUTLASS/CuTe/vLLM Marlin-Machete census 与 grouped-MoE native kernel POC。两条 evidence lane 不混用:Spark 不能 claim FP4-MMA payoff,R6000 也不替 Spark 的 decode TPS 背书。

后续路线不是两条,而是分线推进:

🆕 2026-06-03 Decode 内核启动开销战役 — Spark NVFP4 35B-A3B 单流 38.96 → ~45 TPS,质量 RC 等价。 实测 decode 是 launch-bound(census:~1527 CUDA launch/token,~40% 时间耗在 CPU 端 dispatch)。逐簇融合 launch + 消拷贝:fused RMSNorm(最大头)/ shared-expert / linear-attn g/beta-fold / full-attn(token-exact)/ NVFP4 _scaled_mm bf16-out copy-elision,5 个 RC-validated launch-cut——在 structured/V9/GPQA/tool-call/long-form 上 40/40 greedy 输出与 baseline 逐字一致,继承 MMLU 84.40 / GPQA-Diamond 49.49。全部 gated、默认安全、可回滚。

🎯 关于对标 llama.cpp(口径已据 6/3 evidence-lock 校正)。 同硬件 Q4_K_M 69.77 领先 ~1.5×。起初以为根因是 BF16 dequant-shadow 的 ~2× 带宽墙、写个零-shadow 内核就能把墙从 ~40 推到 ~140;6/3 实测(2 个无头 CLI 代码 trace + 4 个 Spark 探针)把这个前提证伪了:read-4bit 其实已做(MoE 专家走「packed-4bit→寄存器反量化→bf16 GEMV」Triton 核)、那 60 GiB BF16 是 prefill 专用(decode 整块删掉照跑、TPS 不降 42.4→43.7)、把 attn 改读 FP4 无收益甚至更慢(full-attn 0.999× / linear out_proj 0.775×)、reusable decode CUDA graph 净负 0.75×。→ decode 是 launch-bound,且 Spark sm_121(无 FP4 MMA)结构性卡 ~45。 与 69.77 的差距是 llama.cpp 手写、低 host-dispatch、成熟度极高的 ggml CUDA/C++ runtime —— 需 ground-up hot-loop/kernel 重写 + FP4-MMA 硅兑现,不是 Spark 的交付目标。本轮 bankable 红利:decode-only 删 shadow → 常驻 87→27 GiB(腾 60 GiB 给 KV/长上下文/batch)。跨设备内核 moat(同套 NVFP4 权重挪 FP4-MMA 卡变 native)逻辑仍在,有那张卡时才兑现。详见 decode launch-overhead campaign。

🆕 2026-05-28 Qwen3.6-35B-A3B update — Spark 已切到最快 APEX-MTP I-Balanced 单流路线。 当前 lynn-apex-mtp-llamacpp.service 使用 Qwen3.6-35B-A3B-APEX-MTP-I-Balanced.gguf + --spec-type draft-mtp --spec-draft-n-max 4。 短 A/B:单流 77.01 tok/s vs AR 60.65 tok/s(+27%);生产 sanity 中位 76.19 tok/s。 既有 32K thinking-on 质量锚点:MMLU500 90.00% / GPQA198 78.79% naive,83.87% excl parse fail / tool-call 12/15。 详见 APEX-MTP service A/B, 32K quality refresh status,以及 知乎/公众号草稿。

🆕 2026-05-27 Active R&D update — Lynn engine 没有放弃,正在把 Nemotron-style self-spec 的可移植部分落到 Qwen35 APEX-MTP。 (历史记录;最新口径以顶部 6/3 重启校正为准)当时客户端默认走 llama.cpp/GGUF,engine 研发线持续推进: Qwen3.6-35B-A3B W4A16 + official APEX/MTP sidecar 已跑通 K=2 verify/accept/crop/full-accept/prefix-repair token-exact smoke。 当前 blocker 不是算法控制流,而是 K2 verifier 的 T=1-equivalent attention / o_proj kernel 成本。详见 5/27 active status 和 Qwen35 MTP block verifier log。

简单说:产品 fallback 先用 llama.cpp,但 Lynn engine 主线正在继续吃 APEX-MTP / K=N / self-spec 这条硬路线。

🆕 2026-05-20 状态变更(⚠️ 已被顶部 6/3 重启校正取代)— 当时把 Lynn engine 降级为 R&D 持续探索路径;现引擎已重启为对标 llama.cpp 的并行主线。 Lynn 客户端短期投奔 llama.cpp 生态作为默认本地推理底层(Mac Metal / Win MSVC / Linux CUDA 全平台 + Q4_K_M GGUF)。 默认 ship 模型 = Qwen3.5-9B Q4_K_M-imatrix(5.3GB) thinking-on excl_pf MMLU 90+ / GPQA 80+。 历史决策见 5/20 Release Notes;当前权威状态见 6/3 Restart Notes。

Lynn engine 工程财产全留(5 CLI 并行 + 7 bug fix trail + 178s repack + autotune sweep 2160 config 都是真东西)。回主线门槛:同硬件同模型速度接近或超过 llama.cpp,且质量有不可替代优势。

⚠️ 以下 5/16 状态文档保留作历史进度记录,最新状态以 RELEASE_NOTES_20260603 为准。

为 NVIDIA Blackwell 写的 Lynn 27B-A3B NVFP4 单模型推理引擎。 从零写,锁定 Lynn 自家的 variable-pruned MoE + NVFP4 格式,目标很窄也很硬:Spark 负责 35B 服务/内存/runtime 证据,R6000-class FP4-MMA 硬件负责 native FP4/CUTLASS 证据,把 Lynn MoE 基座跑成可生产、可优化、可长期接管的推理内核。

• Read in English · 6月知乎连载 · 战略文档 · 架构设计
• 6/3 Restart Notes · 5/20 历史 Release Notes
• Stage 6 evidence ledger · Stage 6 GPU gate suite
• P2-O basic packed-prefill smoke · P2-O rc-mini non-long shard · P3-A grouped-MoE contract probe · P3-A batched-down diagnostic · P3-B selected-prefill gate · P3-C resident-prompt basic · P2-O runbook · P3/P4 runbook family starts here
• P4C active-reuse decision · P4C tile2 basic server smoke · Decode GPU-idle ROI probe · R6000 FP4-MMA PASS census · R5-A layout bridge PASS · R5-B e8m0 repack negative · R5-C CUTLASS UE4M3 ABI PASS · R5-C1 CUTLASS numeric smoke PASS · R5-C2A MoE shape census PASS · R5-C2 selected-expert gate/up PASS · R5-C2C real D-row scatter PASS · R5-C3A gate/up timing trace · R5-C3B gate/up value materialization PASS · R5-C3C down/weighted parity PASS · R5-C4 full active-MoE speed A/B contract · R6000 grouped-MoE FP4-MMA POC contract

6/3 战略校正(取代 5/20 pivot):Lynn engine 重启为并行主线,目标对标 llama.cpp —— 不再是"降级为 R&D / 客户端投奔 llama.cpp"。客户端短期仍以 llama.cpp/GGUF 作务实默认后端,但引擎同步推进:同模型同硬件对标 llama.cpp。6/3 实测口径(Spark sm_121 无 FP4 MMA,decode 结构性卡 ~45,parity 是降低 per-launch host dispatch 的 compiled/C++ hot loop + native kernel + FP4-MMA 硅目标,不是 reusable graph)见顶部 6/3 战役与 6/3 Restart Notes;5/20 决策背景仅作历史记录。

5 个 CLI 并行 + 23 commit 推 Wave 2 W4A8 FP8 e2e。最终 retry #4 暴露架构信号:Python overhead 在 decode dominant,30 MoE × 8 active expert × per-expert _scaled_mm = 240+ kernel launches/token,graph disabled 后每个 launch 吃 full Python/CUDA dispatch overhead。修不掉的 7 号 bug,需要 vectorized expert dispatch + CUTLASS grouped GEMM + C++ service loop,月级工程量。

关键发现:35B 量化三档 GPQA 几乎平(BF16 / Q4_K_M-imatrix / Lynn NVFP4 都在 49.5±1pp)。我们以前期待的 "NVFP4 GPQA 优势"在足量样本上不成立。

普通用户最直观的卖点 = "本地无限 token":9B 跑本地,无 quota / 无 API key / 无跨境延迟,智能体跑一晚不限消费。

• Lynn engine 已重启为并行主线,目标是同模型同硬件对标 llama.cpp,不是停在 R&D 降级状态。
• 已 bank: 35B NVFP4 decode-only shadow release,常驻 88→28 GiB,token-exact,TPS 0.998×。
• 已过 P0.2: release 后剩余 BF16 resident 只有 4.72 GiB,下一刀优先 projection / embed / lm_head,router 不是第一杠杆。
• 已过 P1 单投影: linear_attn.in_proj_qkv packed Triton matvec numeric/no-shadow/microbench 全过,1.186× vs BF16 shadow。
• P1-A 反证完成: naive 与 tiled scalar batched bridge 都 numeric/no-shadow 过,但 M>1 都输 BF16 tensor-core GEMM;不进入 serving。
• P2 census 已过: 单层 MoE 证实 stream_bf16 是 20s no-reload proof 的主耗时,small-M verifier 内存干净但慢。
• P2-A..P2-N 证据: 单 expert gate/up 输 BF16;routed active path M64=23.83ms/layer;P2-F engine opt-in mode M64=20.23ms/layer;P2-H/P2-I selected full prefill 继续 numeric/no-shadow/speed 通过;P2-J trace 显示 chunk_gated_delta_with_state 占 linear-attn prefill traced wall 71-76%;P2-KA 反证逐 token 复用 decode recurrent kernel;P2-KB/P2-L 接通 block linear-attn;P2-M/P2-N selected full prefill 继续过关。
• 下一关: P2-O basic 已 bank active-MoE no-reload packed-prefill correctness/memory smoke(3/3 exact,88.16→28.18 GiB,reload 0);P2-O rc-mini non-long shard(idx0-4)也已 bank(5/5 exact,同样释放 60 GiB,reload 0)。full rc-mini 的 long-context prompt 仍未 clean:2048 run 配置拒绝,8192 full run slow-mode 超时。P3-A layer0 grouped active-MoE contract probe 已 bank(numeric/argmax/shadow-absent PASS,但 speed 0.744×,不 bank fused kernel)。P3-B layers 0-3 selected-prefill 已 bank(cos min 0.999949,argmax true,reload not called,avg 1.020× vs P2-N,但不 bank server/RC/default)。P3-C basic resident prompt 也已 bank(3/3 generated-ID exact,88.161→28.178 GiB,reload not called,但 prefill 151.861s avg,不 bank 吞吐/server/default)。P3-D/P3-E 继续等待 Spark artifacts;P3-D 只 bank opt-in server smoke,P3-E 只 bank RC quality smoke,默认 promotion 与完整 leaderboard 仍需后续 release battery。P4B native zero-shadow 已 bank fail-loud route + single-CTA output-returning numeric reference + 两个 microbench anti-proof(single-CTA 串行慢、multi-CTA 重算 active 更慢)。P4C active-reuse bridge/profile/basic smoke 已 bank,但 RC-mini 已拒绝:fused_zero_shadow_active_reuse_contract 在 Spark real-runner 路径 PASS;component profile 显示 gate/up 是 63.8% 主耗时;tile2 basic server smoke 记录 P4C call delta 240、40 层调用、text-exact 2/2、release/reload healthy;但 wider rc-mini completion exact 3/6(chat 2/2),shadow-cycle first-divergence 只证明算术 prompt 8 步 top-1 不分叉、但 logits drift 已出现。P4C fused speed/default promotion 保持关闭;下一刀是 P3-D server smoke 或先削 P3-C slow-mode,MTP runtime 去开销、compiled/C++ hot loop,不是继续扩大 P4C RC。
• Spark sm_121 诚实口径: decode 结构性卡 ~45,追 69.77 需要 native runtime + fused kernels + 最终 FP4-MMA 硅。
• Wave 2 全部 commit 留在 main 分支不 revert — 5 CLI 并行 + 7 bug fix trail + 178s repack + autotune sweep 2160 config 全是真实工程财产。

以下 5/15-5/16 R6000 27B Lynn-native NVFP4 工程记录保留作历史进度参考。当前公开数据 + 引擎重启口径以本节(2026-06-03)和 RELEASE_NOTES_20260603 为准。

5/15 R6000 sm_120a 上 Lynn-native NVFP4 milestone:107-108 TPS strict default(P25 512 实测 107.43,P37 + 40/40 prompt 全过 strict),三口径:

• 107.23 TPS serving replay
• 103.44 TPS strict full path 含最终 lm_head(真过 100 的硬数)
• 99.86 TPS strict full path no FP4 lm_head

详细 P3 → P108 系列时间线(118.73 TPS R6000 → A100 W4A8 Recovery → SM120a FP4 contract → W4A8 hardware route):

注:5/15 27B 主力 artifact 为 Lynn 27B A3B variable-pruned MoE Recovery step5000(BF16 ~60G / NVFP4 ~20G,Lynn-native variable-expert format,通用框架不能直接加载)。5/17 路线 pivot 回原版 Qwen3.6-35B-A3B 后,Lynn 27B 自蒸馏整线弃 — Lynn engine 收敛到为原版模型族提供专项加速(Spark W4A8 FP8 / R6000 NVFP4 native FP4)。

当前 production 配置:resident dequant→BF16 slow path,no MTP(V Pro Distill 没 MTP head),单流。性能起飞要等 P4/P5 native FP4 GEMM 替掉 scalar bridge。

当前 R6000 推荐环境:

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
export LYNN_PREFILL_WARMUP=1
export LYNN_LINEAR_ATTN_RECURRENT_BACKEND=triton_fused_prepare
export LYNN_LINEAR_ATTN_RECURRENT_INPLACE=1
export LYNN_MOE_IMPL=packed_nvfp4
export LYNN_MOE_GATE_BLOCK_INTER=8
export LYNN_MOE_GATE_BLOCK_HIDDEN=256
export LYNN_MOE_DOWN_BLOCK_HIDDEN=8
export LYNN_MOE_DOWN_BLOCK_INTER=512
export LYNN_MOE_GATE_NUM_WARPS=4
export LYNN_MOE_DOWN_NUM_WARPS=8
export LYNN_QK_NORM_ROPE_BACKEND=triton_pair
export LYNN_RMSNORM_GATED_BACKEND=triton
export LYNN_LINEAR_ATTN_INPROJ_FUSED_NATIVE_FP4=1
export LYNN_NATIVE_FP4_LM_HEAD=1
export LYNN_LINEAR_STATE_UPDATE=inplace
export LYNN_LINEAR_BLOCK_GRAPH=1
export LYNN_LINEAR_BLOCK_GRAPH_REUSE=1
export LYNN_LINEAR_BLOCK_GRAPH_PREWARM=1
export LYNN_PACKED_DECODE=0
export LYNN_PACKED_DECODE_PREPARE_NATIVE=0
export LYNN_PACKED_SHARED_EXPERT=0

实测 final step5000 NVFP4:

strict full path:      118.73 tok/s  (P23 int32 expert-id cleanup + P22/P21/P20/P19)
serving replay/body:   123.78 tok/s  (40-layer graph ceiling)
OpenAI server decode:   ~99-100 tok/s (P25 reusable block graph env,512-token wall TPS 87.7)
BF16 lm_head path:     99.86 tok/s
quality smoke:         6/6 coherent + strict tool-call + no-think loop guard PASS

Native FP4 lm_head 是当前的 deterministic/greedy opt-in 优化:6/6 prompt top-1 match,top-20 overlap 最低 15/20,logits cosine 最低 0.9924。采样型生产流量默认仍保留 BF16 lm_head fallback,直到更大规模 parity gate 完成。

CUDA graph 说明:P10-S 已记录 full-token graph family 的跨 token 漂移边界,所以 future-window full-token graph 仍不进默认生产。P25 采用的是更保守的 reusable linear-block graph 服务路径,已经把 OpenAI server decode 推到 ~99-100 TPS;155TPS 剩余差距仍来自 active expert kernel,不是 HTTP wrapper。详见 docs/LYNN_ENGINE_P10S_GRAPH_BOUNDARY_20260515.md 和 docs/LYNN_ENGINE_P25_SERVER_100TPS_20260516.md。

P15 配置说明:不要把 LYNN_PACKED_DECODE=1 当成“更 packed 就更快”。R6000 实测它会把 full graph path 从 103.48 tok/s 拉低到 88.15 tok/s,因为 Q/K/V/O 等小 decode linear 走 generic packed native path 反而慢。当前正确配置是 MoE active experts packed、linear-attn fused native、lm_head native,但 generic packed decode 关闭;shared expert 也保留 BF16,因为 packed scalar/native shared 都更慢。详见 docs/LYNN_ENGINE_P15_RUNTIME_CONFIG_20260516.md。

P16 155TPS 说明:profiling 证明非-MoE 路径 replay-only 可到 208.8 tok/s,skip active routed experts 可到 173.8 tok/s,但 top-k 近似和 block-size sweep 都无法安全到 155。结论是 155 不是再调 env var,而是要写新的 grouped native-FP4 active expert kernel。详见 docs/LYNN_ENGINE_P16_155TPS_ACTIVE_MOE_20260516.md。

P17 说明:Triton 3.6 的 tl.dot_scaled(e2m1) 已在 R6000 上通过 raw packed FP4 layout probe,真实 gate/up 形状 1x2048 @ 2048x8192 只需 0.0125ms。scale probe 进一步确认 rhs_scale=[N,K//32] 且 synthetic two-sided neutral byte 为 127。这证明 FP4 tensor-core compute 不是瓶颈;下一关是把 Lynn per-16/e4m3 scale contract 桥接到 e8m0/group32 grouped native dot。详见 docs/LYNN_ENGINE_P17_TRITON_DOT_SCALED_20260516.md。

P18 说明:三条 scale bridge 都已实测,dot_scaled raw gate/up 可到 0.018ms(当前 scalar bridge 约 0.050ms),但质量不过线:per-16→group32 fold 最佳 inter cosine 0.894,BF16→e8m0/group32 re-quant 0.980,padded per-16 0.936。结论:155TPS 仍有硬件 headroom,但不能用简单 e8m0 bridge 牺牲质量,下一步转 custom per-16 grouped native FP4 kernel / CUTLASS 或更强 engine-native quant artifact。详见 docs/LYNN_ENGINE_P18_SCALE_CONTRACT_DECISION_20260516.md。

P25 说明:补齐 LYNN_LINEAR_BLOCK_GRAPH=1 / REUSE=1 / PREWARM=1 后,OpenAI-compatible server 不再停在 88-89 TPS 旧路径,而是稳定到 ~99-100 decode tok/s;512 token 请求端到端 87.7 tok/s。这证明服务层不是 155 的主 blocker,剩余差距仍在 active expert kernel。详见 docs/LYNN_ENGINE_P25_SERVER_100TPS_20260516.md。

P24/P26 说明:两个 Triton-only 捷径都被关掉。P24 的 per-16 dequant→tl.dot 数值过但最快 0.0807ms,比生产 scalar gate/up 0.0335ms 慢;P26 的 merged-topk 调度 cosine=1.0,但四个代表层都 2.06-2.09× 更慢。结论进一步明确:155TPS 需要 CUDA/CUTLASS 级 custom per-16 grouped native-FP4 expert kernel,不是继续 rearrange Triton program grid。详见 docs/LYNN_ENGINE_P24_TL_DOT_NEGATIVE_20260516.md 和 docs/LYNN_ENGINE_P26_MERGED_TOPK_NEGATIVE_20260516.md。

P27 说明:R6000 native CUDA extension build/load/launch gate 已通过。当前环境为 PyTorch 2.10.0+cu128 + CUDA toolkit 12.8 + sm_120;torch.utils.cpp_extension.load 可成功编译并加载 Lynn 自有 CUDA extension,1M float add_one smoke kernel max_abs=0,平均 0.0047ms。这不是 TPS 提升本身,但它把下一步 custom per-16 grouped native-FP4 active expert kernel 的工程地基打通。详见 docs/LYNN_ENGINE_P27_CUDA_EXTENSION_SMOKE_20260516.md。

P28 说明:第一个真实 active-MoE CUDA extension 契约已打通。gate_up_silu_scalar 直接消费 Lynn 27B final 的 grouped packed NVFP4 tensor、per-16 scale、top-k expert ids,输出 [top_k,512] intermediate。四个代表层对 Triton reference cosine≈1.0 / max_abs≈0,但速度 0.035ms 略慢于 Triton 0.034ms,所以这是 contract PASS,不是 speed promotion。下一步是在同一 C++/CUDA 入口内部替换 scalar inner loop 为真正 grouped native-FP4 math。详见 docs/LYNN_ENGINE_P28_NATIVE_GATEUP_CONTRACT_20260516.md。

P29 说明:active MoE 的第二半 down weighted-sum CUDA extension 契约也已打通。down_weighted_sum_scalar 消费 [top_k,512] intermediate、routing weights、down packed/scale/global,输出 [2048] hidden。四个代表层对 Triton reference cosine=1.0,速度 0.030ms 慢于 Triton 0.026-0.027ms,所以同样不 promoted,但 P28+P29 已经组成完整 native active-MoE 数据契约。详见 docs/LYNN_ENGINE_P29_NATIVE_DOWN_CONTRACT_20260516.md。

P30 说明:完整 active routed expert path 已经能由 Lynn 自有 CUDA extension 串起来:CUDA gate/up scalar → CUDA down weighted-sum scalar,四个代表层对 production Triton active path cosine=1.0 / max_abs≈0。速度 0.064-0.068ms/layer 慢于 Triton 0.058ms/layer,所以不作为 runtime 默认;但 P27-P30 已经把 native extension build、gate/up、down、完整 active MoE 契约全部打通。接下来真正影响 155TPS 的工作只剩替换 scalar inner loop 为 grouped native-FP4 tensor-core math。详见 docs/LYNN_ENGINE_P30_NATIVE_ACTIVE_MOE_CONTRACT_20260516.md。

P31 说明:把 P30 native active-MoE scalar path 接入 production moe_forward_decode_packed_nvfp4 后,在函数边界反而比默认 Triton backend 快 1.48-1.59×,且四个代表层 exact/cosine=1.0。这说明 native extension 砍掉了一部分 Python/Triton wrapper 开销。但它仍是 opt-in,默认不开;promotion 前必须跑 full-token decode parity、full graph/server TPS、tool-call/no-think guards。详见 docs/LYNN_ENGINE_P31_NATIVE_ACTIVE_MOE_RUNTIME_GATE_20260516.md。

P32-P34 说明:full-generate gate 明确否决了直接推广 cuda_scalar。全层 cuda_scalar + reusable linear-block graph 虽然能看到 121.7 tok/s,但从第 2 个 decode token 开始进入 token-0 / ! loop;关掉 graph 后文本恢复连贯,但 greedy ids 仍不匹配;只替换 full-attention eager 层也仍有 top-1 drift。runner 已加 fail-loud guard,禁止 cuda_scalar 与 linear-block graph 的不安全组合静默上线。详见 docs/LYNN_ENGINE_P32_P34_NATIVE_ACTIVE_MOE_GENERATE_NEGATIVE_20260516.md。

P35 说明:graph-slot 路线不是死路,但它比 eager/full-graph 路径更挑 router 顺序。把 LYNN_ROUTER_TOPK_SORTED=1 打开后,4 类 prompt × 3 prefix 的 full-token graph-slot gate 12/12 strict PASS,所有行 max_abs=0,replay 97.7-111.5 tok/s。结论:当前稳定 serving 可继续用 P20 unsorted top-k,但未来 graph-slot serving 模式必须强制 sorted-router contract。详见 docs/LYNN_ENGINE_P35_SORTED_ROUTER_GRAPH_SLOT_20260516.md。

P36 说明:把 decode hot loop 里的 MoE 函数选择、linear-attn recurrent backend、state update 策略固定到 runner 初始化阶段,移除 per-layer/per-token env/import 分派。R6000 gate 显示 greedy ids 完全一致,legacy median 100.55TPS,fast-dispatch median 100.53TPS。结论:这是安全工程清理,默认保留;但 100→155 的主瓶颈不在 Python 分派,仍在 active routed expert kernel / graph-owned serving path。详见 docs/LYNN_ENGINE_P36_DECODE_FAST_DISPATCH_20260516.md。

P37 说明:layer28 分段 profile 显示当前 MoE 由 router 0.036ms、active packed NVFP4 experts 0.107ms、shared BF16 expert 0.060ms 组成;孤立 block sweep 里 down_block_hidden=16 看似有 0.7% 小优势,但 full generate gate 跑到 94.94TPS 且 3/3 prompts greedy ids 漂移。结论:继续抠 Triton block-size 不是 155TPS 的正路,下一步必须转 grouped native-FP4 active expert kernel 或严格 parity 的 graph-owned serving。详见 docs/LYNN_ENGINE_P37_MOE_BLOCK_RETUNE_CLOSED_20260516.md。

P38 说明:把 P37 的单层 profile 扩到 6 个采样层(2/8/14/20/28/36),结果高度一致:full MoE 平均 0.193ms/layer,其中 router 0.037ms,active routed packed NVFP4 experts 0.112ms,shared BF16 expert 0.060ms。结论:没有异常慢层可捡,155TPS 的主攻方向就是 active expert grouped native-FP4 kernel,shared expert 是第二优先级。详见 docs/LYNN_ENGINE_P38_MOE_MULTILAYER_PROFILE_20260516.md。

P39-P40 说明:active 内部拆分后,gate/up 0.033ms、down 0.025ms,split 结果与 combined active exact;随后把当前 R6000 best MoE config 固化为 LYNN_MOE_FAST_FIXED 路径。layer-level candidate 平均 1.079×,full-generate gate greedy ids 全一致,默认开启后复核 median 100.79TPS。这是安全小刀,但不是 155TPS 的大突破;下一步仍然是 fused/grouped native-FP4 active expert kernel。详见 docs/LYNN_ENGINE_P39_P40_FAST_FIXED_MOE_20260516.md。

P42 说明:重新测试 cuda_scalar native active-MoE backend,即使只 allowlist 到 full-attention 层、避开 linear-block graph capture,full-generate 仍然 0/3 greedy match,且有一题掉到 48.50TPS。结论:cuda_scalar 只保留为 native extension contract/diagnostic backend,不再作为生产提速捷径。详见 docs/LYNN_ENGINE_P42_CUDA_SCALAR_RETEST_NEGATIVE_20260516.md。

P43-P44 说明:155TPS 路线继续收窄。P43 证明 shared expert fused path 只从 0.0609ms 降到 0.0556ms/layer,绝对收益太小;P44 重新关掉 merged-topk 调度(最快约 production 的 0.48×)和 cross-expert torch._scaled_mm 拼接(mm-only 约 0.39×,quant+mm 约 0.15×,且 min cosine 0.97698)。结论:不能靠包装/调度偷过 155,必须写真 grouped/block-diagonal FP4 active expert kernel。详见 docs/LYNN_ENGINE_P43_P44_ACTIVE_MOE_NATIVE_FP4_TRIAGE_20260516.md。

P45-P46 说明:P45 把 native active-MoE 固定成 one-call CUDA ABI:active_moe(hidden,expert_ids,routing_weights,gate_up*,down*) -> out[2048],数值与 two-call scalar reference 对齐(min cosine 0.99999988),但仍慢于 Triton(0.0658ms vs 0.0583ms)所以只作为 kernel 地基。P46 试了单 kernel fused-atomic bridge,速度 0.1768ms 远慢于 Triton 0.0592ms,并有轻微 accumulation drift。结论:P47 必须做非 atomic grouped/block-diagonal kernel,不是继续叠 wrapper。详见 docs/LYNN_ENGINE_P45_NATIVE_ACTIVE_MOE_CONTRACT_20260516.md 和 docs/LYNN_ENGINE_P46_FUSED_ATOMIC_NEGATIVE_20260516.md。

P48-P50 说明:第一版非 atomic 路线选择了 down projection 子段,新增 tile-hidden CUDA kernel。isolated microbench 在 6 个代表层上从 Triton down 0.02586ms 降到 0.02067ms(1.25×),P49 进一步证明真实 decode-state 下仍有 1.27× 局部收益(max rel_l2 8.74e-05)。但 P50 关闭 CUDA graph 后跑完整 decode,仍在 step 1/layer 27 出现微小漂移,step 5 翻 top1。结论:P48 是 kernel 级正信号,但 tiny accumulation drift 足以影响 greedy,不能进默认路径。详见 docs/LYNN_ENGINE_P48_DOWN_TILE_NONATOMIC_20260516.md。

P51 说明:为了排除“少算专家就能到 155TPS”的捷径,新增 opt-in LYNN_MOE_TOPK_LIMIT / LYNN_MOE_SKIP_SHARED 预算阶梯。结果很明确:top6+shared 仍 coherent 但只提升 1.6%,top4+shared 提升 4.5% 已出现 <think> 污染;skip shared 最快 124.39TPS 但输出崩坏。结论:不能靠裁专家到 155,必须继续 grouped native-FP4 active expert FFN 或 exact graph-owned route。详见 docs/LYNN_ENGINE_P51_ACTIVE_MOE_BUDGET_LADDER_20260516.md。

P52 说明:路线正式分叉为两条:一条是 exact-owned serving,保持当前 Triton active MoE 数学不变,继续压 orchestration / graph overhead;另一条是真 grouped native-FP4 active expert FFN,用 CUTLASS/CuTe 或 custom CUDA 表达 block-diagonal selected experts,不再用 _scaled_mm 包装或 top-k 近似。P52-A/B 进一步证明:只把 selected gate/up 换成 torch._scaled_mm 会更慢且 active cosine 只有 0.976,主要误差来自把 Lynn 的 FP32 per-16 scale 压进 FP8 scale_b contract(min cosine 0.972),不是神秘 tensor-core 累加问题。MTP/spec decode 不是近期主线,它是之后的 serving multiplier,不是底座 kernel。详见 docs/LYNN_ENGINE_P52_GROUPED_NATIVE_FP4_CONTRACT_20260516.md。

P53 说明:针对外部 review 提出的 Triton 免费优化假设,新增 scale-hoist 与 E2M1 decode 简化两个 opt-in probe。scale-hoist 朴素版 JIT/body 过重,不构成免费收益;轻量 LUT 表达式数值 exact,前三个代表层快 6-8%,但 layer36 慢到 0.536×,平均 0.936×。结论:这个方向保留为 allowlist/变体研究,不替换默认 Triton active MoE。详见 docs/LYNN_ENGINE_P53_TRITON_RETUNE_REVIEW_20260516.md。

P54 说明:为了回应“能否直接做一份 NVIDIA/ModelOpt 友好的 e8m0/group32 NVFP4 artifact 然后吃官方 kernel”,新增离线 scale-search 上界 probe。search_recon_mse 代表可部署式静态重构搜索,search_dot_upper_bound 是激活感知点积上界;四个代表层 best upper-bound inter cosine 仍只有 0.9869-0.9918,全部低于 0.995 safety gate。结论:官方 NVFP4/Blackwell 路线证明方向正确,但 Lynn 当前 per-16 FP32 scale artifact 不能靠简单离线 exponent search 转成 vendor scale contract;主线继续写 Lynn-native per-16 grouped active expert kernel。详见 docs/LYNN_ENGINE_P54_VENDOR_LAYOUT_FEASIBILITY_20260516.md。

量化 v2 说明:imatrix / 层策略 / activation-aware scale search 对 Lynn 有价值,但它是量化质量线,不是当前 100→155TPS runtime blocker 的替代品。近期最适合先用于 GGUF/Q4_K_M 公开版,降低 PPL/KLD 并提升 V8/V9/tool/longctx retention;下一阶段再从 BF16 final 重新探索 vendor-compatible NVFP4 v2 artifact。详见 docs/LYNN_ENGINE_QUANTIZATION_V2_ROADMAP_20260516.md。

P55 说明:新增 gate/up 侧 tile_inter CUDA scalar probe,让一个 block 同时计算多个 intermediate row 并复用 hidden 读取。四个代表层上 tile_inter=2 全部 max_abs=0,局部比 Triton gate/up 快 1.09-1.14×;tile_inter=4/8 反而慢。结论:这是 P56 grouped per-16 kernel 的正向 tile 形态信号,但仍只是局部 scalar probe,不会单独进默认生产。详见 docs/LYNN_ENGINE_P55_GATEUP_TILE_INTER_20260516.md。

P56 说明:把 P55 tile_inter=2 接进 runtime opt-in gate 后,中位 decode TPS 从约 99.15 提到 114.43(+15.4%),但 full-generate greedy 不匹配并出现 ! loop。结论:tile shape 有真实速度信号,但 scalar tile-inter runtime 不安全,不 promote;下一步直接把 tile_inter=2 作为真 grouped per-16 native-FP4 kernel 的形态提示。详见 docs/LYNN_ENGINE_P56_GATEUP_TILE_RUNTIME_REJECTED_20260516.md。

P57 说明:官方/ModelOpt 路线不丢人,但它需要一份从 BF16 final 重新量化的 vendor-friendly NVFP4 v2 artifact,而不是把当前 Lynn-native per-16 artifact 硬转过去。R6000 当前 env 无 modelopt/llmcompressor,只有 compressed_tensors 的 modelopt_nvfp4 converter,且 27B 是物理 variable-expert、hf_vanilla_compatible=false,所以官方路线还需要 padding/mask 回固定 256 experts 或 vendor 侧 variable-expert 支持。详见 docs/LYNN_ENGINE_P57_VENDOR_ROUTE_INVENTORY_20260516.md。

双 artifact 策略:允许同时保留 Lynn-native NVFP4 final 和 vendor-friendly NVFP4 v2。前者继续服务 Lynn engine / per-16 grouped kernel;后者从 BF16 final 重新量化,用于官方生态兼容。两份产物必须不同目录、不同 manifest、不同验证门,不得互相覆盖。详见 docs/LYNN_ENGINE_DUAL_NVFP4_ARTIFACT_POLICY_20260516.md 和 docs/LYNN_ENGINE_VENDOR_VS_LYNN_NATIVE_TRADEOFF_20260516.md。

P58 说明:为排除“P56 只是 CUDA extension 与 linear-block graph 交互坏掉”的可能,重跑 cuda_tile_inter 并关闭 LYNN_LINEAR_BLOCK_GRAPH*。结果候选中位 28.43TPS,且 greedy mismatch 仍存在。结论:这不是 graph-only bug,而是 scalar tile-inter 累加/调度顺序本身足以扰动 greedy decode;该 runtime 线正式关闭,只保留 tile 形态信号。详见 docs/LYNN_ENGINE_P58_GATEUP_TILE_GRAPH_OFF_REJECTED_20260516.md。

P59 说明:新增 metadata-only NVFP4 layout classifier,在加载 tensor 之前区分 lynn_native_per16_variable、compressed_tensors_nvfp4、modelopt_nvfp4、bf16_or_unquantized 和 unknown packed FP4。目标是一个 Lynn engine 同时支持我们的原生 NVFP4 与未来官方/vendor-friendly NVFP4 v2,但任何交叉误加载都 fail-loud。详见 docs/LYNN_ENGINE_P59_DUAL_NVFP4_LAYOUT_DISPATCH_20260516.md。

P85-P89 说明:官方/ModelOpt 路线继续保留,但 runtime 主线不再等待重重量化。P85-P87 已证明 SM120a blockscaled FP4 MMA、E2M1 <<2 shift 和 CuTe fragment layout 全部正确;P88 把真实 Lynn 27B gate/up packed-code tile 跑到 max_abs=0;P89 进一步证明当前 Lynn-native per-16 scale artifact 可以用 split16 neutral-scale MMA + 显式 per-group scale accumulate 直接消费,误差仅 rel_l2=1.0e-7。简单把两个 K16 scale 折成一个 K32 scale 会漂移(best rel_l2 仍 0.0227),所以官方/vendor-friendly NVFP4 v2 应放到 MTP/retrain + re-quant 批次,不阻塞 P90 真 active expert kernel。详见 docs/LYNN_ENGINE_P85_BLOCKSCALED_FP4_MMA_CONTRACT_20260516.md、docs/LYNN_ENGINE_P86_FP4_SHIFT_CONTRACT_20260516.md、docs/LYNN_ENGINE_P87_FP4_LAYOUT_TILE_CONTRACT_20260516.md、docs/LYNN_ENGINE_P88_REAL_GATEUP_TILE_CONTRACT_20260516.md 和 docs/LYNN_ENGINE_P89_PER16_SCALE_TILE_CONTRACT_20260516.md。

P90 说明:第一版真实 split16 gate/up kernel 已经把 P89 从 tile proof 推到 full-K row tile。输入是真实 Lynn 27B layer28 expert116、真实 activation、真实 packed gate/up weight,输出 8 个 gate rows + 8 个 up rows,K=2048 全维度。结果 max_abs=2.38e-7, rel_l2=1.53e-7,tolerance PASS。结论:当前 Lynn-native artifact 可以直接喂 native FP4 gate/up kernel,无需等待官方/vendor re-quant;P91 开始扩大 row tile 并减少 atomic/launch overhead。详见 docs/LYNN_ENGINE_P90_SPLIT16_GATEUP_KERNEL_20260516.md。

P91 说明:row-tile sweep 直接给出下一步形态。8/16/32/64 行全部在 1e-5 tolerance 下 PASS;64 行 median 0.0443ms,rows/ms 从 8 行的 350 提到 2892。这说明扩大 row tile 没有破坏 P90 数学,还显著摊薄 launch/atomic overhead。P92 应直接尝试 full 512-row gate/up expert shape。详见 docs/LYNN_ENGINE_P91_SPLIT16_ROWTILE_SWEEP_20260516.md。

P92 说明:完整 gate/up expert 子算子已经通过。真实 Lynn 27B layer28 expert116,512 个 gate rows + 512 个 up rows,K=2048 全维度,median 0.0502ms,max_abs=4.77e-7,rel_l2=1.53e-7。这回答了核心路线问题:当前 Lynn-native artifact 可以直接驱动完整 native-FP4 gate/up expert 子算子。后续工作从“能不能吃当前 artifact”转为“怎么把 launch/atomic/row ownership 做成生产 backend”。详见 docs/LYNN_ENGINE_P92_FULL_GATEUP_EXPERT_20260516.md。

P19 说明:在不改变数值路径的前提下,active MoE kernel block retune 把 R6000 full graph 从 103.40/107.13 TPS 提到 115.41/120.25 TPS。推荐配置已成为默认:gate_hidden=256,down_inter=512,并保留 env override 方便后续设备差异调参。详见 docs/LYNN_ENGINE_P19_ACTIVE_BLOCK_RETUNE_20260516.md。

P20 说明:router topk(sorted=False) 已验证同 expert set、同配对权重,代表层 MoE 输出 max_abs=0,把 full graph 进一步推到 117.55/122.43 TPS。详见 docs/LYNN_ENGINE_P20_ROUTER_TOPK_UNSORTED_20260516.md。

P21 说明:shared expert 保持 BF16,只把 gate/up 两个小 GEMM 融成一个 BF16 GEMM,代表层 max_abs=0。full graph 小幅提升到 117.71/122.71 TPS。详见 docs/LYNN_ENGINE_P21_SHARED_GATEUP_FUSION_20260516.md。

P22 说明:MoE active kernel 暴露 num_warps 调参后,R6000 最优为 gate/up 4 warps、down 8 warps,full graph 小幅提升到 118.25/123.25 TPS。详见 docs/LYNN_ENGINE_P22_MOE_WARP_RETUNE_20260516.md。

P23 说明:active MoE 全层画像确认没有异常慢层,40 层 active routed experts 几乎均匀在 ~0.069ms/layer,router 约 0.049ms/layer,shared expert 约 0.057ms/layer。1D top-k、手写 softmax、Triton fused top-k+softmax 都没有进入生产价值;唯一 promoted 的安全小刀是 expert id 在 router 后一次性转 int32,避免 gate/up 和 down 重复 cast,full graph 提到 118.73/123.78 TPS。详见 docs/LYNN_ENGINE_P23_ACTIVE_MOE_ACCOUNTING_20260516.md。

Packed-resident memory 说明:当前默认 server 仍保留 BF16 shadow 以支持多请求 prefill。P11 已证明 session-scoped 生命周期中,prefill 后可以释放 56.47 GiB BF16 shadow,显存从 81.06 GiB 降到 24.59 GiB 且 greedy decode ids 完全一致。P12 进一步把这个能力接到 OpenAI server 的 opt-in one-shot 模式:首请求释放 56.47 GiB,第二请求明确 HTTP 409 fail-loud;并验证 release 后 current-position graph slot 仍与 eager decode exact match。详见 docs/LYNN_ENGINE_P11_PACKED_RESIDENT_MEMORY_20260515.md 和 docs/LYNN_ENGINE_P12_ONESHOT_SERVER_20260515.md。

27B 来自 Qwen 3.6 35B-A3B BASE 的 variable-expert 剪枝路线:

BASE 35B-A3B
  → activation profile
  → variable-target expert pruning(1010 experts cut,front layers protected)
  → router fine-tune
  → Recovery LoRA
  → step5000 selected as final
  → BF16 merge
  → Lynn-native NVFP4 quantization

已知质量结论:

Recovery v1.1 targeted longctx/chem/sql 已试过,但未取代 step5000:它没有改善 longctx,并拉低总分。因此当前基座选择 step5000 final。

详见 RELEASE_NOTES_20260603.md 当前重启口径。客户端短期仍可把 llama.cpp/GGUF 作为务实 fallback,但 Lynn engine 已回到并行主线:用自研 native kernels 追赶 llama.cpp。

llama.cpp 负责"跑得起来、跑得快、装得小"。Lynn 负责"会用模型、会调工具、会记忆、会自动配置"。

回主线门槛(两条必过):

1. 速度:同硬件同模型下,Lynn engine 接近或超过 llama.cpp
2. 质量:有不可替代优势(GPQA / long-ctx / 稳定性 stddev / 工具调用等)

R&D 主要方向(都在 main 分支保留 commit trail,不 revert):

• W4A8 FP8 vectorized expert dispatch + CUTLASS grouped GEMM:绕开 Python decode overhead(Wave 2 retry #4 暴露的架构信号)
• C++ service loop:host gap > GPU compute gap 时再触发(memory LYNN_ENGINE_CPP_RUST_REWRITE_ROI_20260517 已分级 3 tier)
• R6000/RTX PRO 6000 96GB-class FP4-MMA lane:PASS census artifact 后再恢复 native FP4 grouped-MoE POC;不要用 32GB 消费卡/Spark 结果替代 R6000 证据
• MTP K=1 sequential 6/6 @ 26.4 TPS correctness-clean baseline 持续磨,等 W4A8 base 稳后叠加
• 长 ctx 6.77× SGLang at 16K 数据点保留,作 NVIDIA Pro "高级模式"卖点

5/15-5/16 锁定的以下决策已在 5/20 后失效:

• 推理主格式:Lynn-native NVFP4 only → 生产默认 GGUF Q4_K_M-imatrix(llama.cpp ecosystem);NVFP4 / W4A8 FP8 留 R&D
• 模型锁定:Lynn-27B-A3B variable-pruned family → 5/17 战略 pivot 回原版 Qwen3.6-35B-A3B + Qwen3.5-9B(质量下降 10% 弃 27B 自蒸馏)
• vertical companion 给 Lynn LoRA + 剪枝训练流水线 → Lynn engine 收敛到为原版模型族提供专项加速,LoRA 训练侧独立路线
• 推理范围:单 prompt + batch=1 保留(不做 PagedAttention)— Lynn 客户端用户场景就是单用户,无需 batched serving
• 推理硬件:Blackwell sm_12x 保留(DGX Spark / 5090 / R6000 PRO),但优先级降到 R&D

写 Lynn engine 时,我们挖出了 Qwen 3.6 35B-A3B 跟 Llama / Qwen 2 不一样、文档没写明的怪癖。共 7 篇深度文章在 tutorials/:

tutorials/posts/zhihu_qwen36_engine_postmortem.md 是知乎博客风格的合集长文。

当前不绑定租赁主机编号;本次已在 RTX PRO 6000 96GB / 880GiB data workspace bank PASS artifact: R6000 FP4-MMA PASS census。 R5-A layout bridge 也已在同类 R6000 上 bank: R5-A layout bridge PASS。 结论是 per-16 grouping 可通过 padded group32 保真,但当前 Lynn E4M3-like scale 不能 zero-copy (PASS_R5A_LAYOUT_BRIDGE_E8M0_REPACK_REQUIRED)。随后 R5-B simple e8m0 repack 已被 R6000 反证(best rel_l2≈0.166 / cosine≈0.986)。R5-C0 已 bank: CUTLASS UE4M3 ABI PASS 证明 CUTLASS/CuTe 暴露 sm120 mxf4nvf4 block16 E2M1 + UE4M3 scale 路径。R5-C1 也已 bank: CUTLASS numeric smoke PASS 证明 CUTLASS 79d native NVF4+UE4M3 grouped GEMM 两种 schedule 均通过 host-reference verification。 R5-C2A 也已 bank: MoE shape census PASS 证明 79d 有 SM120 native NVF4+UE4M3 执行但缺 MoEProblemShape/tokens_per_expert, 92 有 MoE shape 语义但走 Sm100 schedule。R5-C2 selected-expert gate/up smoke 已 bank: R5-C2 selected-expert gate/up PASS 把 tokens_per_expert=[32,64,64,96] 映射到 79d per-group M shape,Cooperative/Pingpong 双 schedule host-reference PASS。R5-C2C real D-row scatter 也已 bank: R5-C2C real D-row scatter PASS 捕获真实 CUTLASS D/ref row digests,按 R5-C2B inverse-order scatter 到 [T, top_k, N_gateup],Cooperative/Pingpong 各 256 rows 全过。仍不宣称 epilogue selected-output kernel、SwiGLU/down、grouped-MoE FP4-MMA speed 或默认速度提升。 后续换机时仍先按 R6000 FP4-MMA bring-up runbook 跑 census gate;PASS 前不启动新的 FP4-MMA kernel POC。AutoDL 主机上可用:

scripts/r6000_stage6_autodl_bootstrap.sh --install-basics --cutlass-dir /root/autodl-tmp/src/cutlass

engine/
  loader.py                       FP8 e4m3 反量化 + 单层 safetensors 加载器
  qwen36_block.py                 早期完整 transformer block(P1.1,带 bug 的 reference)
  qwen36_linear_attn_block.py     GatedDeltaNet 移植 — 跟 HF bit-exact
  full_forward.py                 40 层端到端 forward(已修正)
  inference_state.py              单 request 的 KV cache + recurrent state
  incremental_decode.py           prefill / decode 原语(Phase 3.1)
  moe_optimized.py                MoE 三档优化(active / bmm / indexed bmm)
  convert_fp8_to_bf16.py          离线 FP8 → BF16 转换器(CPU)
  test_*.py                       逐层 alignment 测试 + 多 prompt 验证

triton_kernels/
  attention.py / rope.py / rmsnorm.py / moe.py   P1 spike 内核
  moe_expert_ffn.py               Phase 3.2.3 融合 MoE 内核(scaffold)

server/
  openai_http.py                  FastAPI OpenAI 兼容 server
  README.md                       brain 接入指引

docs/
  STRATEGY.md                     ⭐ 战略 + 长期路线图
  DESIGN.md                       架构 + 实施日志(长)
  PHASE3_KV_CACHE_DESIGN.md       Phase 3.1 设计文档
  NVFP4_QUANTIZATION.md           NVFP4 量化 pipeline(C 阶段末 + B 阶段输入)

pruning/
  calibration/
    seeds.jsonl                   102 手工策划 seed prompt(19 类别)
    expand.py                     DeepSeek API 扩到 1440 prompts
    calibration_set_v1.1.jsonl    生成的完整集
  profile_activations.py          Phase 1 W1: 激活画像脚本
  decide_pruning.py               Phase 1 W2: drop 30 expert 决策算法
  training/
    recovery_lora_qwen36.yaml     Recovery LoRA r=384 配置(LLaMA-Factory)

benchmarks/
  lynn_27b_vs_35b.py              Phase 1 W4 gate test(自动跑 V9 比较)

tutorials/
  README.md + 7 篇 tutorial + Zhihu 长文

Lynn brain 用 Qwen 3.6 35B-A3B 当主链,每天处理几千个 agent 请求。6/3 后的 Spark 口径已经校正:当前 decode 主要是 launch/host-dispatch bound,不是继续押“内存带宽/零 shadow 速度杠杆”。Spark lane 先 bank 服务显存生命周期、MTP runtime、compiled hot-loop ROI 与质量回归;R6000 lane 再兑现 native FP4-MMA/CUTLASS 内核护城河。

但更重要的产出是通过自己写引擎获得的理解 — 上面的 tutorials 就是这个理解的固化。

❌ 锁定 Qwen 3.6 35B-A3B(及其剪枝衍生)+ Blackwell sm_12x
❌ Qwen 升 3.7/4 不兼容时,需要 4-6 周重写
❌ 不做批处理 / 多并发(单 prompt 焦点)
❌ 不做采样(只 greedy);不做 beam / speculative
❌ 不支持 FP8/INT4/AWQ/GPTQ 等(NVFP4 唯一生产格式)
✅ 完全契合 Lynn brain 的部署模式
✅ 跟 LoRA + 剪枝训练流水线 vertical 整合
✅ 所有架构细节都给后人写下来了

❌ Continuous batching / PagedAttention(vLLM 主场)
❌ 多模型 loader(锁 Lynn-27B-A3B 家族)
❌ 多量化格式(NVFP4 唯一)
❌ Hopper / Ada / Ampere 支持(Blackwell 唯一)
❌ TP / PP / 多机分布式(单机单 GPU)
❌ Vision encoder 整合(Lynn 不接图像;后续看)
❌ 与 vLLM 通用 API 完全兼容(只兼容 brain 用的子集)
❌ 投 paper(Lynn 是产品,不是论文)

TBD(大概率 MIT,B 阶段生产切换前定下来)。

• 战略 / 路线图(STRATEGY.md)
• 架构设计(DESIGN.md)
• Phase 3 incremental decode 设计
• NVFP4 量化 pipeline
• 剪枝 pipeline(calibration / profile / decide / LoRA)
• HTTP server(brain 接入指引)
• English README
• 📝 知乎 2026年6月连载:从零开始 Qwen 3.6 35B-A3B 写专用推理引擎踩坑心得分享
• 📝 历史工程复盘:从零开始 Qwen 3.6 35B-A3B 写专用推理引擎(2026-05-11 mega-post) — Phase 2 + Phase 3.2 + NVFP4 路线决策三段合并
• Toolabstain 论文(姊妹项目)