本篇选取 8 篇相关论文/系统，覆盖 MoE 模型设计、推理引擎竞争、chiplet-aware 执行、Blackwell 内核和 MoE serving 策略，与 TokenSpeed 在推理引擎设计这一核心问题上形成多维对比。
DeepSeek-V3 (2412.19437) — TokenSpeed 最核心的优化目标模型。DeepSeek-V3 定义了 671B MoE + MLA 的架构范式（256 routed experts, MLA 512-dim latent KV, DualPipe），TokenSpeed 则围绕这个架构做推理引擎。两者在并行化哲学上有深层对应：DualPipe 将训练的 forward/backward 拆为 attention/dispatch/MLP/combine 四个细粒度组件实现 compute-comm overlap，TokenSpeed 的 Placement 编译器则将推理的通信拆为 ATTN_TP/DENSE_TP/MOE_TP_EP 三个独立并行组并在边界自动插入 resharding——两者都拒绝了 one-size-fits-all 的并行度，分别在训练和推理场景下实现了不对称并行。DeepSeek-V3 的 all-to-all kernel（PTX 手写、20 SM warp specialization）和 TokenSpeed 的 MLA CuTe DSL 内核代表了同一种 insight 的不同实例化：为 MoE+MLA 架构定制的 hardware-aware 内核比通用库有质的优势。MLA 的 KV cache 压缩到 512 维使得 decode 时 KV cache 不再是瓶颈，但 attention compute 因 MLA 的 absorb + project 结构变得更复杂——TokenSpeed 的 q-head 折叠正是对这一特殊 compute pattern 的精准优化。Kind: baseline。
DeepSeek-V4 (deepseek-v4) — TokenSpeed 的下一代模型适配目标，也是其 Placement 编译器灵活性的试金石。V4 从 MLA 切换到 hybrid CSA+HCA attention（CSA 4× 压缩 + sparse top-k，HCA 128× 压缩 + dense），引入异构 KV cache 布局（State Cache + Classical KV Cache）和 mHC 残差连接。TokenSpeed 的调度器已支持 V4 的多 cache group（sliding-window layers 和 full-history layers 使用不同的 PagedCacheGroup），其 hybrid prefix cache 同时管理 KV 页面和 Mamba 状态。但 V4 的 CSA Lightning Indexer 操作——FP4 量化的 indexer attention + top-k 稀疏选择——引入了 TokenSpeed 内核注册表此前未覆盖的 kernel family。V4 还将 active experts 从 8 降到 6 但总 expert 数增到 384，改变了 MoE TP/EP 的最优并行度——Placement 编译器的三组 ParallelGroup 设计是否足以表达 V4 的 expert-level 异构性，是一个开放问题。Kind: related。
DynaServe (2504.09285) — TokenSpeed 和 DynaServe 都面向推理 serving 优化，但从截然不同的维度切入。DynaServe 的 micro-request 抽象（在任意 token 边界分割请求为 α/β 段）统一了 colocation 和 disaggregation 两种范式，通过两级调度（全局 binary search + 本地 SLO-aware batching）实现动态负载均衡。TokenSpeed 的调度器则是 C++ FSM + RAII 类型安全设计，关注点不在 P/D 分割的灵活性，而在 KV cache 资源安全性和 agent 场景的 retraction 机制。两者是正交互补的：DynaServe 解决"请求该怎么分配给 GPU"，TokenSpeed 解决"GPU 拿到请求后怎么安全高效地执行"。TokenSpeed 的 PD disaggregation 通过 Mooncake 实现但 PR 未合并，DynaServe 的 chunk-based KV 传输可能与 TokenSpeed 的 retraction（KV 写回 host 再重新调度）形成互补的 memory pressure 应对策略。Kind: complementary。
Fleet (2604.15379) — Fleet 和 TokenSpeed 都瞄准"将硬件拓扑差异暴露为软件一等公民"这一范式，但面向不同硬件和不同层级。Fleet 在 AMD MI350 上为持久化 megakernel 引入 Chiplet-task 抽象（对应 XCD + 4 MB 私有 L2），通过 M-major 协作式 tile 遍历实现跨 XCD 的 L2 复用。TokenSpeed 在 NVIDIA Blackwell 上为 MLA 引入 q-head 折叠（将 q_seqlen 折叠到 head 维度填充 Tensor Core tile），是 agent 小 batch decode 的精准优化。两者共享一个深层设计原则：kernel 性能的上限由 workload-hardware 匹配度决定，通用库无法获得最优。关键差异：Fleet 优化 dense transformer 的 linear GEMM（占 decode 95% 时间），TokenSpeed 优化 MoE+MLA 模型的 attention compute（MLA 的 absorb + project 结构使 attention 计算量增大）。Fleet 的 chiplet 感知对 TokenSpeed 有直接启发——TokenSpeed 目前的 MLA 内核仅支持 SM100/SM103，Hopper/MI350 标注为 ongoing，但 MI350 的 8 XCD 拓扑意味着 TokenSpeed 的 MLA 内核若移植到 AMD 必须像 Fleet 一样处理 L2 分区问题。Kind: related。
SageAttention3 (2505.11594) — TokenSpeed 的 Blackwell MLA 内核和 SageAttention3 在 Blackwell attention kernel 这一赛道上直接竞争。SageAttention3 利用 NVFP4 microscaling Tensor Core 实现 FP4 attention（RTX5090 上 1038 TOPS，5× FlashAttention2），核心创新是 two-level quantization 解决 softmax 输出 P 在 FP4 量化时 scale factor 动态范围过窄的问题。TokenSpeed 的 MLA 内核则用 CuTe DSL 实现，核心创新是 q-head 折叠——在 agent 场景小 batch decode（q_seqlen=4-16）下将 q_seqlen 折叠到 head 维度填充 UTCMMA tile。两者的优化目标不同：SageAttention3 面向视频生成等长序列 prefill 场景（compute-bound，追求 TOPS），TokenSpeed MLA 面向 agent decode 场景（memory-bound，追求延迟）。但在 MoE+MLA 模型的 prefill 阶段，SageAttention3 的 FP4 attention 和 TokenSpeed 的 MLA 内核可能形成竞争——如果 SageAttention3 适配 MLA 的 absorb + project 结构，其 5× 加速在 prefill 阶段可能超越 TokenSpeed 的 CuTe DSL 实现。TokenSpeed 的内核注册表 5-band 优先级设计允许以 PLUGIN 带集成 SageAttention3 作为外部内核——这是 TokenSpeed 架构灵活性的具体体现。Kind: related。
Optimizing Attention on MI300X (2511.02132) — 这篇论文与 TokenSpeed 共享 MLA 优化的问题空间，但从 chiplet NUMA 角度切入。论文发现 FlashAttention2 在 MI300X 的 8 XCD 上因 round-robin WG 调度导致 L2 cache hit rate 暴跌至 ~1%，提出 Swizzled Head-first Mapping 将同一 attention head 的所有 workgroups 映射到同一 XCD，实现 90-97% L2 hit rate 和 50% 性能提升。TokenSpeed 的 MLA 内核目前仅针对 Blackwell（SM100/SM103），但 MLA 的 head 结构（所有 head 共享一个 latent KV）意味着 chiplet NUMA 优化的形态与标准 MHA 完全不同——MLA 不需要 per-head K/V 独立调度，而是需要所有 head 高效访问同一组 latent KV。如果 TokenSpeed 的 MLA 内核扩展到 MI350/MI300X，需要重新设计 chiplet-aware 策略来匹配 MLA 的"多 head 共享 KV"访问模式，而非本文的"per-head 独立 KV"模式。Kind: related。
HipKittens (2511.08083) — HipKittens 和 TokenSpeed 的 CuTe DSL 内核代表了两种 kernel authoring 方法论在不同硬件上的实践。HipKittens 为 AMD GPU 提供 C++ embedded tile-based DSL（8-wave ping-pong 调度、chiplet-aware XCD scheduling），TokenSpeed 用 NVIDIA CuTe DSL 编写 Blackwell MLA 内核。两者共同验证了一个趋势：DSL-based kernel authoring 正在取代手写汇编成为高性能内核的主流方法——HipKittens 在 MI355X 上匹配或超越 AITER 手写汇编，TokenSpeed 的 MLA 内核已被 vLLM 采纳。关键差异在 DSL 层级：HipKittens 的 tile 抽象（typed tiles + PyTorch-style bulk operators）比 CuTe DSL 更高层，代码量更少（FP8 GEMM 48 行 vs CuTe DSL 的更多代码），但 CuTe DSL 对 Blackwell 的 UTCMMA、TMA 等硬件特性有更精细控制。TokenSpeed 内核注册表的 5-band 优先级设计（REFERENCE < PORTABLE < PERFORMANT < SPECIALIZED < PLUGIN）与 HipKittens 的 "单 DSL 覆盖多 kernel family" 理念互补——TokenSpeed 可以用 PLUGIN 带集成 HipKittens 内核实现 AMD 支持。Kind: related。
ZeRO-Prefill (2605.02960) — TokenSpeed 和 ZeRO-Prefill 都面向 MoE 推理效率优化，但从截然不同的抽象层次切入。ZeRO-Prefill 提出 AsyncEP——反转传统 EP 的数据流方向（不再把 activation 路由到 expert，而是把 expert weight 流式搬运到 activation 所在 GPU），利用 prefill 大 batch 的长 compute window 在后台完成 D2D AllGather。TokenSpeed 的 Placement 编译器则在模型定义层面用静态注解消除手写通信，通过三个独立 ParallelGroup（ATTN_TP, DENSE_TP, MOE_TP_EP）支持不对称 TP。两者解决问题的阶段不同：ZeRO-Prefill 优化 MoE 的 expert dispatch 通信（prefill-only，吞吐导向），TokenSpeed 优化整个 forward pass 的并行编排（通用推理，兼顾延迟和吞吐）。ZeRO-Prefill 的 "expert weight 是可调度资源而非静态参数" 这一 insight 可以被 TokenSpeed 吸收——在 TokenSpeed 的 Placement 编译器中增加 dynamic expert placement 语义，让 MoE TP_EP group 的通信模式从 AllToAll 切换为 weight streaming，尤其在 prefill-heavy agent 场景下。Kind: complementary。
TokenSpeed 的核心 delta 是 三层协同设计——C++ FSM 类型安全调度（控制面）、Placement 静态 SPMD 编译器（模型面）、分层内核注册表 + Blackwell MLA 特化内核（执行面）——在 agentic workloads 下取得 TRT-LLM 级性能和 vLLM 级可用性的平衡。
| 维度 | TokenSpeed | DeepSeek-V3 | DeepSeek-V4 | DynaServe | Fleet | SageAttention3 | MI300X Attn | HipKittens | ZeRO-Prefill |
|---|---|---|---|---|---|---|---|---|---|
| 优化目标 | Agent 推理延迟+吞吐 | MoE 训练 compute-comm overlap | 百万 token 推理效率 | Serving goodput under SLO | Chiplet-aware decode 延迟 | Attention kernel TOPS | Chiplet L2 hit rate | AMD kernel 可编程性 | MoE prefill 吞吐 |
| 核心抽象 | FSM + Placement + Kernel Registry | DualPipe 四组件 | CSA+HCA 混合压缩 | Micro-request α/β 分割 | Chiplet-task (XCD scope) | Two-level FP4 quant | ACC-to-XCD mapping | Tile-based DSL | AsyncEP (weight streaming) |
| 调度模型 | C++ FSM 13 states, RAII KV safety | 双向 pipeline, SM 分配 | mHC 残差 + sparse indexer | 两级调度 (全局+本地) | Per-XCD 软件 scheduler | N/A (kernel only) | Swizzle mapping | 8-wave ping-pong | Frontend 三规则 + T 阈值 |
| 内核系统 | 5-band registry + CuTe MLA | PTX 手写 all-to-all | TileLang DSL + DeepGEMM | 继承 vLLM kernels | Mirage MPK 持久化 | CUTLASS 3.x FP4 | Triton swizzle (~15行) | C++ embedded DSL | 继承 vLLM kernels |
| 并行化方式 | 静态 Placement 3-group 不对称 TP | DualPipe 16PP + 64EP | EP + DualPipe + fine-grained overlap | 动态 GPU 分配 | 单 GPU 8-XCD 内 | N/A | 单 GPU 8-XCD 内 | 单 GPU XCD scheduling | AsyncEP (weight AllGather) |
| 类型安全 | ✅ 编译期 RAII | ❌ 运行时 | ❌ 运行时 | ❌ 运行时 | ❌ | N/A | N/A | N/A | ❌ 运行时 |
| 模型覆盖 | MoE+MLA (DS-V3/V4, Kimi K2.5, Qwen) | DeepSeek-V3 only | DeepSeek-V4 only | 通用 AR LLM | Dense transformer only | 通用 attention | MHA/GQA (FA2) | GEMM + attention | Qwen3-235B MoE |
| 规模验证 | Kimi K2.5 on B200 (Preview) | 2048 H800 14.8T tokens | 33T tokens 训练 | 8 A100 GPUs | MI350X 单 GPU | RTX5090 单 GPU | MI300X 单 GPU | MI325X/MI355X 单 GPU | 8×H100 |
| 开源 | ✅ MIT | ❌ 框架未开源 | ❌ 框架未开源 | ❌ 未发布 | ❌ 未披露 | ✅ pip install | ✅ 代码 | ✅ GitHub | ✅ vLLM 集成 |
TokenSpeed vs DeepSeek-V3/V4 — 训练系统与推理引擎的镜像设计。DualPipe 将训练 pipeline 的通信拆为四个可重叠组件（attention/dispatch/MLP/combine），Placement 编译器将推理的通信拆为三个独立并行组（ATTN_TP/DENSE_TP/MOE_TP_EP）。两者独立发现了同一个 insight：MoE+MLA 架构的 attention 和 expert 对并行度的需求本质不同，不应强制统一。DualPipe 用 20 SM warp specialization 动态分配 compute 和 comm 资源，TokenSpeed 用 FusedReduceNormOp 和 ResidualAllGatherOp 在编译期静态融合通信与计算。DeepSeek-V4 进一步用 hybrid CSA+HCA 替换 MLA，TokenSpeed 的 MLA 内核不适用于 V4，但其 Placement 编译器的多 cache group + 不对称 TP 设计预示了对 V4 异构 attention 的适配路径。
TokenSpeed vs Fleet — Blackwell 和 MI350 上的 workload-hardware 匹配。Fleet 面向 dense transformer decode 的 memory-bound regime（linear GEMM 占 95%），用 Chiplet-task 让 8 颗 XCD 协作复用 L2 中的权重列，L2 hit 率从 16% 提到 51%。TokenSpeed 面向 MoE+MLA 模型的 agent decode，用 q-head 折叠让小 batch decode 的 Tensor Core 利用率接近最优，延迟近乎减半。两者的共同 insight：推理引擎的 kernel 层必须感知硬件拓扑差异——L2 分区、die 边界、tile scheduling 粒度——而不能假设统一的设备抽象。Fleet 在 bs≥64 时被 vLLM 反超（compute-bound 区未实现 K-split），TokenSpeed 在 non-MLA 模型上优化深度不明——两者都有 binding 到特定 workload-hardware 区间的风险。
TokenSpeed 的独有增量：
std::variant<13 states> 配合 move 语义消费前一状态的 unique_ptr 和 unique_ptr，使 KV cache 双重释放或遗漏释放在编译期就是错误。这不只是工程品味，在 1000+ 并发请求的 agent 场景下是正确性的关键保障。以下攻击针对 TokenSpeed L2 代码解读中论证链的具体步骤。
Attack 1: MLA q-head 折叠的适用性被 DeepSeek-V4 的 CSA+HCA 架构淘汰 (L2 Design Decision 4)
TokenSpeed 的 MLA q-head 折叠——将 q_seqlen 折叠到 head 维度（H_eff = num_heads × F）以填充 Tensor Core tile——是针对 MLA 的 absorb + project attention 结构设计的。但 DeepSeek-V4 已将 MLA 完全替换为 hybrid CSA+HCA，CSA 的 shared KV MQA 和 HCA 的 dense attention 都不使用 MLA 的 latent KV 结构。如果 V4 成为下一代主力部署模型（V4-Flash 以不到 V3 一半的激活参数在多数 benchmark 上超越 V3），TokenSpeed 的核心 kernel 优势——MLA decode 延迟近乎减半——将失去目标模型。V4 的 CSA Lightning Indexer（FP4 量化的 indexer attention + top-k 稀疏选择）和 HCA 的极端压缩（128× KV 压缩 + dense attention）需要全新的内核家族，当前 TokenSpeed 的 kernel registry 中只有 4 个 family（attention, gemm, moe, quantize）通过 register_kernel 注册，layernorm/kvcache/embedding 等 10 个 family 中的 6 个不走 registry——这暴露了 registry 的覆盖率不足以应对模型架构的快速迭代。TokenSpeed 声称支持 V4 通过多 cache group（PagedCacheGroup），但这只解决了 KV cache 管理，未解决 V4 独有的 kernel 需求。
Attack 2: "编译期 KV 安全" 的实际收益被 Preview 状态稀释 (L2 Design Decision 1, 3)
TokenSpeed 将 C++ std::variant<13 states> + RAII move 语义标榜为推理引擎的方法论升级，声称 KV cache 双重释放或遗漏释放在编译期就是错误。但这个安全保证的实际收益需要在生产规模下验证——77 commits、3 个月开发、PD disaggregation 未合并、L3 prefetch 未激活、metrics 未接入。在如此 preview 的状态下，FSM 的 13 个状态本身是否足以覆盖所有并发边界情况？vLLM 的 Python BlockManager 虽然是运行时 check，但经历了 2 年+、数千 PR、大规模生产部署的打磨。类型安全消除了一类 bug，但引入了另一类复杂性——C++ FFI 边界（nanobind）、独立的 GoogleTest 套件、C++ 与 Python 两个 codebase 的同步维护。而 Retraction（Decoding → Retracting → Retracted）作为 FSM 一等公民将状态数从 ~8 增加到 13，retraction 需要额外的 host 内存——在 agent 场景 >50K tokens 的 context 下，host memory 可能成为新瓶颈（一个被 retract 的请求的 KV cache 需要写回 host）。论文未量化 retraction 的频率和 host memory 占用。
Attack 3: Placement 编译器的不对称 TP 缺乏通用验证 (L2 Design Decision 2)
TokenSpeed 声称三个独立 ParallelGroup（ATTN_TP, DENSE_TP, MOE_TP_EP）支持不对称 TP——例如 Kimi K2.5 的最佳配置是 Attention TP4 + MoE TP4。但这个设计的灵活性在以下场景下未经验证：(1) V4 的 CSA top-k 稀疏 attention 和 HCA dense attention 交错排列，每层的并行策略可能需要不同——三个 ParallelGroup 是否足以表达层级异构？(2) ZeRO-Prefill 的 AsyncEP 提出了"expert weight 是可调度资源而非静态参数"的新范式，Placement 编译器的静态注解无法表达 runtime 的 weight streaming 行为。(3) 当模型同时使用 attention+Mamba 混合架构（如 V4 代码中的 Mamba cache 支持）时，三个 ParallelGroup 的语义是否自然覆盖 Mamba 的线性 recurrence 并行？编译器的静态性是推理时零开销的前提，但也是灵活性的天花板——DTensor 的动态 dispatch 虽有开销，但能在运行时改变并行策略，这在模型快速迭代的 2026 年可能比编译时优化更重要。
Attack 4: 内核注册表的 PLUGIN 带未经外部验证 (L2 Design Decision 5)
5-band 优先级（REFERENCE < PORTABLE < PERFORMANT < SPECIALIZED < PLUGIN）声称提供"局部推理"——插件作者只需选 PLUGIN 带就能保证覆盖内置注册。但截至 2026-05，无任何外部团队实际使用 PLUGIN 带注册过内核。SageAttention3 已有 pip install、HipKittens 已有 GitHub repo、Fleet 的 Mirage MPK 是开源的——但没有一个被集成到 TokenSpeed 的 registry 中。PLUGIN 带每带内只有 4 个相对位置（band+0 到 band+3），如果两个外部插件都想覆盖同一个内置 attention kernel 且互有优劣（例如 SageAttention3 在 prefill 更快、TokenSpeed MLA 在 decode 更快），4 个位置不足以表达条件化选择。registry 的 select_kernel(family, mode, dtype, platform, features) 缺少 workload 特征参数（如 batch_size、seq_length），无法实现"small batch 用 MLA 内核、large batch 用 SageAttention3"的条件分发。
Attack 5: 性能对比缺少可复现数据和关键 baseline (L2 核心三问 Q3)
TokenSpeed 声称 "Kimi K2.5 on B200: Pareto 全面优于 TRT-LLM（min-latency 快 ~9%，100 TPS/User 吞吐高 ~11%）"，但性能对比仅以 PNG 图表形式发布，无可复现的 CSV 数据。更关键的缺失 baseline 包括：(1) SGLang——RadixAttention 是 agent 场景的重要优化，TokenSpeed 的 radix prefix sharing 与 SGLang 的 RadixAttention 在同一问题空间竞争；(2) vLLM with TokenSpeed MLA（PR #41778 已合并）——如果 vLLM 采纳了 TokenSpeed 的 MLA 内核后性能已大幅提升，那 TokenSpeed 相对 vLLM 的 "增量" 来源就不再是内核而是调度器和 Placement 编译器，需要更精细的 attribution；(3) MLA 内核的最优路径依赖未开源的 binary .so——tokenspeed-mla/objs/ 中的 AOT binary 不在 repo 中，外部无法复现 blog 中的性能数字。
Attack 6: FluentLLM 传承债务限制了架构创新空间 (L2 Tech Debt)
TokenSpeed 脱胎于 FluentLLM（meituan-longcat/SGLang-FluentLLM），engine、entrypoint 结构中 FluentLLM 的影子随处可见。这不只是代码质量问题，而是架构约束：FluentLLM 的 AsyncLLM + ZMQ IPC + scheduler subprocess 架构假设了"单一调度器进程管理所有请求"的模型。在 agent serving 的实际部署中，1000+ 并发请求需要更灵活的调度拓扑——例如 NVIDIA Dynamo 的分层调度（cluster scheduler → instance scheduler → worker）或 ThunderAgent 的 program-aware scheduling。TokenSpeed 的 C++ FSM 调度器是单线程设计（"无锁"），在极高 QPS 下 ZMQ IPC 可能成为瓶颈。更深层的问题是：FluentLLM 传承代码阻碍了 TokenSpeed 向 multi-instance、multi-model serving 演进——这是 agent workload 的实际需求（一个 agent 可能同时调用 reasoning model + tool-use model + embedding model）。
范式定位：TokenSpeed 代表了推理引擎从"通用框架"到"workload-specialized 系统"的范式转移。vLLM 和 TensorRT-LLM 都是面向"通用 LLM serving"的引擎——前者追求可用性（Python 全栈、社区活跃），后者追求极致性能（C++ 全栈、NVIDIA 深度优化）。TokenSpeed 的设计哲学是：agent workload 的特征（长 context >50K、高多轮、speculative decode、严格 TPS 要求）足以定义一个专用引擎。这个定位有三个独特价值：(1) C++ FSM 的编译期 KV 安全为 agent 的高并发场景提供了 correctness-by-construction，vLLM 的 runtime check 在同等并发下无法保证；(2) Retraction 机制（KV 写回 host 而非丢弃重算）避免了 agent 长 context 的昂贵重新预填充，vLLM 的 preemption 丢弃后必须重算；(3) MLA q-head 折叠在 speculative decode 的 typical decode 工作负载下延迟几乎减半，TRT-LLM 的通用 MLA 没有这个优化。
LightSeek Foundation 生态集成：TokenSpeed 的依赖栈由四层组成：
thirdparty/ 统一导入，通过 registry 选择相比 TRT-LLM 对 NVIDIA 生态的深度绑定（闭源、限制性许可），TokenSpeed 的 MIT 许可和多组织协作模式（NVIDIA DevTech, AMD Triton, Qwen, Together AI, Mooncake, Dynamo）提供了更开放的采纳路径。但核心团队分布在多个组织的风险在于：长期维护承诺不明确，且多个核心 PR 未合并（PD、EPLB、KV store、Mamba cache、VLM、metrics）。
采纳信号：
竞争方案生态位对比：
| 生态位 | 方案 | TokenSpeed 相对优势 | TokenSpeed 相对劣势 |
|---|---|---|---|
| Agent 推理引擎 | vLLM | C++ FSM 编译期安全 + MLA 内核 + Retraction | vLLM 已生产就绪、社区 2000+ 贡献者 |
| 极致性能引擎 | TensorRT-LLM | Python 模型定义 + Placement 编译器 | TRT-LLM 在 NVIDIA 硬件上有深度硬件绑定优化 |
| Agent 调度优化 | SGLang | C++ FSM 调度器微秒级 + 编译期安全 | SGLang RadixAttention 更成熟、prefix sharing 已经过大规模验证 |
| Blackwell 注意力内核 | SageAttention3 | MLA 特化 + CuTe DSL 可控性 | SageAttention3 在 prefill 场景 5× 加速 |
| MoE Serving | ZeRO-Prefill | Placement 编译器的通用性 (不限 prefill-only) | ZeRO-Prefill 在 prefill 场景 1.35× 且已集成 vLLM |
| AMD 推理优化 | Fleet + HipKittens | Blackwell 上 MLA 性能已验证 | AMD 市场份额增长中，TokenSpeed 目前无 AMD 支持 |
| PD 分离 | DynaServe | 正交互补——调度+执行分层设计 | DynaServe 的动态分割更灵活 |
定位判断：TokenSpeed 在 Blackwell + MoE+MLA 模型 + agent workload 的交集场景下价值最大——此时 vLLM 的 Python 调度器和 runtime KV check 在 1000+ 并发下成为瓶颈，TRT-LLM 的全 C++ 模型定义让新模型适配周期过长，TokenSpeed 的三层协同设计（FSM 安全 + Placement 效率 + MLA 性能）提供了最优 trade-off。对外部团队的价值主要在三个可移植设计思想：(1) C++ FSM + RAII 的 KV 安全范式；(2) Placement 静态编译器的不对称 TP；(3) 5-band 内核注册表的开放生态接口。
方向 1: TokenSpeed Placement 编译器 + ZeRO-Prefill AsyncEP 的融合。当前 TokenSpeed 的 Placement 编译器假设 expert weights 是静态放置的（ModuleSpec 在编译时固定并行策略），ZeRO-Prefill 证明 expert weights 可以是运行时流式调度的资源。融合设计：在 Placement 注解中增加 DynamicPlacement 语义——模型作者标注 MOE(input=Replicate(MOE_TP_EP), output=Partial(MOE_TP_EP), weight=Streaming(AllGather))，编译器根据当前 batch size 和 compute window 自动选择是静态 AllToAll 还是动态 weight streaming。具体实现：TokenSpeed 的 C++ FSM 调度器在 NextExecutionPlan() 中增加 estimateComputeWindow() 检查——如果当前 batch 的 FLOPs ≥ T（ZeRO-Prefill 的饱和阈值），切换 MoE 通信模式为 AsyncEP；否则保持标准 AllToAll。这将 ZeRO-Prefill 的 prefill-only 优化扩展到 TokenSpeed 的通用推理场景，尤其在 agent workload 的 prefill 阶段（长 context >50K tokens，compute window 足够长）获得额外的通信消除收益。
方向 2: 内核注册表的 workload-aware 条件分发。当前 select_kernel(family, mode, dtype, platform, features) 缺少 workload 特征参数。扩展为 select_kernel(..., workload={batch_size, seq_length, q_seqlen, kv_length, sparsity})，让 registry 在运行时根据 workload 特征选择最优内核。具体场景：(1) MLA decode with q_seqlen=1 选择 q-head 折叠内核，q_seqlen=16（speculative decode 验证）选择标准 MLA 内核；(2) prefill with seq_length>4K 选择 SageAttention3 的 FP4 kernel（PLUGIN 带），短 prefill 选择 FlashAttention3（PERFORMANT 带）；(3) V4 CSA 的 top-k indexer 在 k>512 时选择 approximate nearest neighbor 内核，k<512 时选择 exact top-k。这需要 registry 的 CapabilityRequirement 增加 workload-range 语义，并在 SelectedKernel 缓存中加入 workload bin 作为 cache key——预计新增 ~200 行代码但大幅扩展 registry 的适用范围。
方向 3: Fleet Chiplet-task 抽象在 TokenSpeed 中的 MLA-aware 适配。TokenSpeed 的 MLA 内核扩展到 AMD MI350 时，不能简单复用 Fleet 的 M-major 协作式 tiling——MLA 的所有 head 共享同一组 latent KV（512 维），访问模式是"多 head 同时读同一 KV"而非"每 head 独立读自己的 KV"。MLA-aware Chiplet-task 设计：将 8 颗 XCD 按 head 维度分区（类似 MI300X attention 论文的 Swizzled Head-first），但因 MLA 的共享 KV，真正的协作不是 head-level 而是 batch-level——同一 XCD 上的 worker 处理不同 batch 的 query 但共享 KV latent vector。具体地，每颗 XCD 负责 batch 的 1/8，KV latent 在该 XCD 的 L2 中驻留，所有该 XCD 的 head 复用。这与 Fleet 的 N-split（每 XCD 分到不同输出列）正交——Fleet 沿 N 切、MLA-aware 方案沿 batch 切。预测 L2 hit rate 需要修改 Fleet 的 Eq.(1)：$R = \min(W, \lceil B/T_B \rceil)$ 其中 $T_B$ 是 batch tile 大小而非 M tile 大小。
方向 4: C++ FSM 调度器的形式化验证。TokenSpeed 声称 C++ std::variant<13 states> 配合 move 语义在编译期保证 KV cache 安全，但 C++ 的类型安全并不等同于形式化验证——move 语义保证了"同一时刻只有一个 owner"，但不保证"状态转移的前置条件总被满足"或"并发调度不会产生死锁"。下一步是用 TLA+ 或 Dafny 对 FSM 的 13 个状态和转移规则进行模型检验，验证以下属性：(1) KV cache 页面的活性（liveness）——每个已分配的页面最终都会被释放；(2) 无死锁——不存在两个请求互相等待对方释放 KV 页面的场景；(3) Retraction 的公平性——被 retract 的请求在有限时间内被重新调度。这对 agent 场景尤为重要——1000+ 并发请求 × 13 个状态的组合爆炸使得穷举测试不可行，形式化方法是唯一的覆盖手段。veRL 的 hybrid single/multi-controller 设计也面临类似的并发正确性挑战，形式化的 FSM 验证方法论可跨系统复用。
方向 5: TokenSpeed 内核注册表 + DeepSeek-V4 TileLang 的统一内核生态。V4 的 infrastructure 引入了 TileLang DSL（将数百个 Torch ATen 算子替换为融合 kernel，集成 Z3 SMT solver 做形式化分析），这与 TokenSpeed 的 CuTe DSL 内核和 5-band 注册表形成了两个并行的内核管理体系。统一方向：将 TileLang 作为 TokenSpeed 内核注册表的"内核生成后端"——模型作者用 TileLang 编写融合 kernel，TileLang 编译器生成的 kernel 自动注册到 TokenSpeed registry 的 SPECIALIZED 或 PLUGIN 带，registry 的 select_kernel 根据 workload 特征决定是用 TileLang 生成的内核还是手写 CuTe DSL 内核。TileLang 的 SMT-solver-assisted 形式化分析可以与 TokenSpeed FSM 的编译期安全互补——TileLang 保证内核数值正确性，FSM 保证调度正确性，两者共同为 agent 推理提供端到端的 correctness guarantee。
方向 6: Retraction + Prefix Sharing 的协同优化 in agent 多轮场景。TokenSpeed 的 Retraction（KV 写回 host）和 Radix Prefix Sharing 目前是独立机制。在 agent 多轮场景下两者有深层协同：当 memory pressure 触发 retraction 时，被 retract 的请求的 KV cache 中有大量 prefix 与其他 active 请求共享——这些共享 prefix 的 KV 不需要写回 host，因为其他请求仍在使用。具体优化：在 Retraction 的 FSM 状态转移 Decoding → Retracting 时，调度器检查被 retract 请求的 radix tree 节点是否被其他请求引用——如果是，只 retract 非共享的后缀 KV，共享 prefix 保留在 GPU。重新调度时，从 host 加载后缀 KV 并与仍在 GPU 上的 prefix KV 重新拼接，避免 prefix 的重新预填充。这需要 FSM 增加 PartialRetraction 状态（介于 Decoding 和 Retracted 之间），使 retraction 从"全有或全无"变成"按共享度梯度化"。预计在 agent 典型场景（多个请求共享 >50K tokens 的 system prompt + context）下，retraction 的 host memory 写回量降低 60-80%。