Naive-N0.5-Flash: 用 AI 构建前沿 AI

案例一· NaiveRT

完整案例 · 在下方区域内纵向滑动阅读

为了充分发挥 Naive-N0.5-Flash 轻量化架构在大规模 RL rollout 中的潜力，我们构建了 NaiveRT：一个专门优化 single-stream 解码速度、保证采样结果逐位确定（bitwise deterministic）的推理运行时。配合融合实现的 DFlash 草稿模型，NaiveRT 在 8 张 GPU 上的 single-stream 解码峰值达到 2,122 tokens/s。在同一套系统上，一轮完整投机解码（draft、verify、sampling 与 commit）的耗时，从 SGLang 的 12.3 ms 降至 3.4 ms，降幅为 72.4%。

NaiveRT 由研究员与 AI 模型共同研发，历时 6 天，记录了 151 轮优化实验。

为什么 single-stream 速度对 RL 至关重要

在上下文可达 1M tokens 的 RL 任务中，single-stream 解码速度尤为重要。一条 rollout 的上下文通过两种方式增长：

• 读入的 tokens
  包括观测、工具返回与历史轮次等，速度为 5,000–10,000 tokens/s。
• 生成的 tokens
  在常规解码下，速度为 50–100 tokens/s。

按当前的比例，生成的 tokens 只占约 20–40%，却占据了模型侧几乎全部的实际耗时。一条接近 1M tokens 的 rollout，读入需要数分钟，解码却需要数小时。

这些长 rollout 会成为拖尾任务。在同步管线中，少数缓慢的 rollout 就会让整个 batch 等待。在支持部分 rollout 的异步管线中，一条轨迹可以跨越多个策略版本，但最多只允许滞后 K 步。无法在这一限制内完成的轨迹会被整体丢弃，此前已生成的所有片段也随之作废。

无论哪种情况，代价最终都落在最长的样本上，而它们往往也是最难、最有信息量的样本。批处理无法解决这个问题：它能让多个请求分摊权重开销，却不能让单条序列更快完成。只有提高 single-stream 解码速度，才能缩短 rollout 本身的耗时。

确定性则是第二项要求。Rollout 直接用于梯度计算，如果采样时使用的 logprobs 与训练端计算的 logprobs 不一致，训练便会在不知不觉中变成离策略（off-policy）训练。而给定随机种子后，NaiveRT 的结果具有确定性：同一序列以相同种子解码两次，得到的 tokens、logits 与 KV cache 均逐位一致。我们将这一点作为每一项优化都必须满足的约束，而不是仅在调试时启用的模式。

运行时建模

NaiveRT 的核心是 mega-kernel fusion。在投机解码中，draft、verify、sampling 和 commit 构成首尾相接的执行循环。NaiveRT 将这些阶段重组并融合进更大的 GPU kernel，减少 kernel 启动、同步与中间结果访存的开销，使小 batch size 下的 GPU 也能得到充分利用。

其余 kernel 边界通过程序化依赖启动（Programmatic Dependent Launch，PDL）衔接，使下游 kernel 的启动与上游收尾相互重叠。投机解码循环由 GPU 在设备端自主推进：尾部 kernel 提交 token 后，直接发起下一轮。多轮循环无需 CPU 介入，Host 端主要负责将结果流式输出。

融合也有取舍。下节会介绍注意力层如何整合为单个 mega-kernel；MoE 的 router、up/gate 与 down 投影则保留为独立 kernel，通过 PDL 衔接，原因将在“微基准更快，不代表整网更快”一节说明。

DSA 层：从 29 次 kernel 执行到 1 次

在我们进行性能剖析的 SGLang 配置中，一个 DSA 层在每张 GPU 的每一步解码中，需要执行 29 次 kernel，涵盖 Q/K/V 投影、RoPE、KV cache 写入、indexer GEMM、top-k 选择、稀疏 gather、注意力计算与输出投影。这个计数尚不包含输入端的 RMSNorm 和层间通信。

NaiveRT 将这整条计算链路重组为单个 cooperative mega-kernel，由同一个 grid 内的 148 个 CTA 执行，同时纳入前置 RMSNorm 与结尾的 TP8 通信。其中，4 个上下文并行 kernel 并非逐一融合，而是由 NaiveRT 的执行拓扑替代。原本跨 kernel 的数据交换，现在在融合后的执行路径内完成。AI 模型逐一处理各阶段的数据可见性与同步依赖，确保计算正确。

深入 kernel 内部优化

算子融合并不是终点。AI 模型继续深入 kernel 内部，优化执行流水。

以 QKV 投影的权重搬运为例：权重本身不依赖归一化结果，但在未融合时，读取权重必须等待 QKV 投影 kernel 启动。融合后，每个 CTA 各自计算一份 RMSNorm，省去一次全局同步。124 个负责 QKV 投影的 CTA 则先各自发起一次 128 KiB 的 TMA 搬运，再计算 RMSNorm，直到投影实际用到权重时，才在 barrier 处等待其就绪。

这样，权重搬运与归一化计算便能重叠进行，同一共享内存区域随后也由索引与注意力阶段复用。仅此一项改动，就让整网每步耗时减少了 21–23 μs。

类似的不改变模型本身、仅优化 GPU 执行方式的改动还包括：

• K/V 暂存。
  按 split 将选中的 K/V 行预先搬入共享内存，再执行计算，使该层耗时从 57.0 μs 降至 49.5 μs。
• Tensor Core 重映射。
  每张 GPU 有 8 个 query 头，直接采用 m16n8k16 映射时，需要将这些头对应的行数补齐至 16 行。NaiveRT 重新映射计算，让这 8 个头占据 MMA 的 n8 维度，省去补齐头带来的无效计算。

研发流程

NaiveRT 采用了与 Naive-N0.5-Flash 相同的 AI 原生研发方式。研究员负责制定技术方向、质量约束与验收标准，AI 模型承担大量实现与优化工作：

• 分析整网性能画像；
• 实现候选方案；
• 进行数值验证与多卡测试；
• 分析实验结果；
• 决定哪些改动保留、修改或回滚。

在这种研究员带领、AI 模型执行的研发方式下，核心优化工作被压缩到 6 天，分三个阶段推进：

• 整网工程实现（43 轮实验，28 轮被采纳）。
  在随机权重上打通融合后的整网执行路径，重构路由与数据搬运。
• 切换至真实 checkpoint（45 轮实验，15 轮被采纳）。
  基于真实模型权重优化 Tensor Core 与 TP 执行，去除冗余操作，并实现跨 GPU 执行重叠。
• W8A8 kernel 精细优化（63 轮实验，20 轮被采纳）。
  深入关键 kernel 内部，精细调整加载顺序、计算布局与收尾逻辑。

目标模型前向验证一个 8-token 草稿块的耗时，单位为毫秒。各子图的终点接近 3.1 ms，而非包含草稿生成、采样与提交的完整轮次耗时 3.4 ms。各子图采用不同测试条件，因此台阶降幅不能直接相加。

整个过程共记录 151 轮优化实验：

• 63 轮的改动被采纳；
• 71 轮未通过验证或被回滚；
• 17 轮用于探索备选路径或原型。

每轮实验通常包含多个实现变体与重复测量，累计进行了数千次端到端运行，涵盖编译、性能分析、数值对齐与正确性检验。

微基准测试更快不代表整个网络运行更快

在整个过程中，AI 模型始终依据候选优化在真实模型链路中的端到端表现作出取舍，而非只看单个 kernel 的微基准测试。两者的结果往往并不一致：

• 短上下文旁路。
  一项跳过索引、直接按位置读取 K/V 的优化，在 200 tokens 时能节省约 3 μs；到了 2,200 tokens，反而慢了约 3 μs，因此未被采用。
• TMA 预取。
  前文的预取优化恰好相反：单算子 warm-cache 微基准略慢，但整网每步却能快 21–23 μs。
• MoE 融合。
  一条候选融合路径经过 7 轮实现，每一版数值都正确，端到端性能却全部下降。原有 kernel 边界的开销大部分已被 PDL 重叠，而融合又引入了额外同步。研究员最终叫停了这一方向，因此 MoE kernel 继续通过 PDL 衔接。

正确性是所有优化的前提。任何降低延迟的改动合入前，整网 logits 与 KV cache 都必须通过严格的逐位比对（bitwise comparison），同时完成端到端性能测量。

结果

NaiveRT 在 8 张 GPU 上的single-stream解码峰值达到 2,122 tokens/s。这一峰值取自 41 个 HTML/SVG 生成请求中表现最好的一秒时间窗口；测试关闭思考模式，temperature 为 0.4、top-p 为 0.95，且不计入预填充（prefill）。完整一轮投机解码耗时 3.4 ms，同一系统上的 SGLang 为 12.3 ms。

这一结果来自整条推理链路中多项技术的协同：

• 轻量化稀疏注意力；
• kernel 融合与融合实现的 DFlash 草稿生成；
• 完全由 GPU 驱动的调度；
• 通过轻量原语实现的通信重叠。

如何获取 NaiveRT

NaiveRT 开源，运行系统与复现本文结果所需的内容均提供：

• 源代码。
  NaiveRT GitHub 仓库 包含运行时、融合 kernel，以及本文图表所用的基准测试脚本，我们将在 10 月 12 日之前提供上述内容。
• Docker 构建环境。
  提供可复现的构建环境，包含 NaiveRT 测试所用的工具链与依赖。
• 模型权重。
  NaiveRT Hugging Face 仓库 提供 Naive-N0.5-Flash 的 W8A8 checkpoint 及配套 DFlash 草稿模型。
• 后续更新。
  关注微信公众号「Naive AI」，获取版本发布、评测结果与后续工作进展。

案例二· AutoWM

完整案例 · 在下方区域内纵向滑动阅读

如果把一项超出 NaiveAI 既有研究领域的完整研发任务交给 Naive-N0.5-Flash，会发生什么？

一位 NaiveAI 研究员将构建一个世界模型的任务交给 Naive-N0.5-Flash，并设定目标、算力预算与评测协议。此后，由 Naive-N0.5-Flash 持续推进方案设计、模型训练、评测与结果分析，并决定下一步尝试。

经过累计 400 小时的研究与 15 轮主要实验，最终得到的世界模型 AutoWM 按 WorldArena-1 Track 1 的公开评测协议测试，取得 77.43分，高于当时榜单上已公开的最高成绩 73.64分。

走出既定方案

研究从复现 FlowWAM 的官方方案开始。早期实验探索了无分类器引导（classifier-free guidance）和时间步扫描等常规方向，但提升有限。

随后，Naive-N0.5-Flash 开始调整研究方案本身。它重写视频文字描述（caption），将训练集从 2.5K 段视频扩充至 22.5K 段，过滤 VLM 评分较低的样本，并探索不同的训练样本配比与帧采样策略。

然而这些调整并不总能带来更好的结果。等间隔采样 16 帧的效果优于 8 帧，增加至 32 帧后仍有提升，但额外收益更小。Naive-N0.5-Flash 还调整了 rollout 结构，去掉第二次 rollout，并在单一片段内对齐条件信息。换用更强的基模、配合质量更高的训练样本后，性能进一步提升。

这些尝试并不是沿着一份预先写好的方案依次执行。哪些方向继续推进、哪些转为旁支，都由实验结果决定。

扩展搜索空间

随着研究推进，训练与后处理实验交错进行。

一项关键发现是，WorldArena 的部分指标无需真实参考视频（ground truth）即可计算。Naive-N0.5-Flash 不仅用这些信号评估生成视频，也用它们指导输出选择与后处理。

它探索了多时间步选择，为每段视频挑选最佳时间步，使 AutoWM 的成绩超过此前榜单最高分。随后，它将单帧也纳入搜索空间，并将帧选择建模为用动态规划求解的背包问题。

后续实验进一步探索 Best-of-N 视频选择，以及为每段视频选择最佳后处理策略。在一项 DP 配置对比中，N=32的表现反而不及 N=16。

后期实验以增强视频动态表现为目标，继续探索与闪烁、抖动有关的后处理方法。这些推理时优化与后处理策略，共同大幅提升了 WorldArena-1 Track 1 上的成绩。

在全新领域达到 77.43 分

累计 400 小时的研究结束时，AutoWM 在 WorldArena-1 Track 1 上取得 77.43 分，超过此前已公开的最高成绩 73.64 分。

世界模型并非 NaiveAI 既有的研究方向。AutoWM 表明，当目标、算力预算与评测协议明确时，同样的 AI 原生研发方式可以迁移到新的领域。

在这个案例中，Naive-N0.5-Flash 参与了研究本身：提出方案、运行实验、放弃无效方向，并决定下一步尝试。这正是我们正在探索的递归式自我改进（RSI）路径：让 AI 模型承担下一代模型的研发工作，并让每一代模型能够承担更多的研发工作。