前沿 AI 模型的构建，如今已不再仅仅是一项研究工作，更需要一套复杂的、工业化的研发体系。全球领先的人工智能公司依靠庞大的专家团队分工协作，支撑这套体系的运转。模型架构、基础设施、训练、推理、部署与评测，只是其中的一部分。每个前沿模型的背后，都是一个持续不断的实验、迭代与优化的循环。

而在 NaiveAI，从成立的第一天起，我们就摒弃了传统以人类为中心的研发体系，让 AI 模型直接参与 AI 研发：写代码、跑实验、监控进展、分析结果，再据此迭代。人类研究员把精力集中在三件事上：确定方向，设定约束与评价标准，以及作出关键决策。人的价值主要体现在经验、洞察与判断上。

NaiveAI 为此建立了一套以 AI 模型为中心的研发基础设施，支撑大规模生产运行，并为模型提供安全的工作环境与 GPU 算力。系统每周支持近千万个沙箱运行，峰值并发达 10 万个。统一的控制平台负责大规模算力、环境、工具、权限与安全管理。

Naive-N0.5-Flash 正是以这种方式构建的。其混合非全局注意力架构的探索与设计，以及高性能训练、推理和部署系统的优化，均由 AI 在研究员的指导下完成，关键决策由研究员作出。与此同时，Naive-N0.5-Flash 本身也面向 AI 研发任务进行针对训练，使其能直接参与后续研发过程，逐步形成递归式自我改进（Recursive Self-Improvement, RSI）的闭环。

模型概览

Naive-N0.5-Flash 是一款面向编程与 AI 研发的 MoE 模型，总参数量为 309B，激活参数量为 15.5B。

  • 原生 1M 上下文，不含全局注意力机制。 Naive-N0.5-Flash 将滑动窗口注意力机制（SWA）与采用 GQA4 的轻量化 DeepSeek 稀疏注意力机制（DSA）相结合，主要采用每 5 层 SWA 搭配 1 层 DSA 的布局。整个网络结构仅使用局部或稀疏注意力机制，不含任何全局注意力机制。
  • AI 优化推理，速度最高可达 2,000 tokens/s。 NaiveRT 是为 Naive-N0.5-Flash 构建的推理系统，其构建与优化均采用以 AI 为中心的研发方式。通过 mega-kernel fusion、程序化依赖启动（Programmatic Dependent Launch，PDL）与投机解码，标准模式下每位用户的输出速度为 50 tokens/s，而极速模式下最高可达 2,000 tokens/s。
  • 开放权重与 API。 模型权重与推理代码均以 MIT 许可开源发布。同时将提供API访问，API 输入、输出和缓存读取价格分别为每百万 tokens 0.6、2.6 和 0.07 人民币。

评测结果

评测设置：我们默认使用 Claude Code 2.1.207 对 Naive-N0.5-Flash 进行评测，上下文窗口为 1M tokens，temperature 为 1.0，top-p 为 0.95。评测框架（harness）仅提供基础文件读写与 Bash 工具。

基准测试分数的来源

以 AI 为中心的研发实践

Naive-N0.5-Flash 协助研究员开展 AI 研究与系统工程中的开放式工作。

案例一

NaiveRT —— 由 AI 优化、面向 RL 的 2,122 tokens/s 推理运行时

NaiveRT：由 AI 优化、面向 RL 的 2,122 tokens/s 推理运行时

为了充分发挥 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 —— 由 AI 研发、WorldArena 跻身第一梯队的世界模型

AutoWM：由 AI 研发、WorldArena 跻身第一梯队的世界模型

如果把一项超出 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 模型承担下一代模型的研发工作，并让每一代模型能够承担更多的研发工作。

技术细节

模型结构

模型以开源的 MiMo‑V2.5 base 为起点，该模型结构简洁，并具有良好的世界知识和Deep Research等基础开源共性能力。其大部分层采用滑动窗口注意力（SWA），单 token 的解码开销不随上下文长度增长；少数全局注意力层用于保留长程信息。但在百万 token 级上下文下，解码开销很大一部分来自这几层全局注意力。

Naive-N0.5-Flash 将这些全局注意力层替换为 DeepSeek 稀疏注意力（DSA）。轻量索引器对全部历史位置打分，主干网络只对选中的部分 token 计算注意力。索引器仍需扫描全部历史，完整 KV 缓存也仍需保留；但稀疏注意力大幅减少的是注意力计算量与访存量。注意力结构改变后模型需要重新适应，这也是进行继续预训练的原因之一。

这一架构由 NaiveAI 的研究员与 AI 模型共同探索得到。研究员设定目标与评测协议，要求在百万 token 级上下文下提升解码效率，同时保持模型质量；AI 模型负责实现候选架构与训练方案，运行消融实验并汇总结果。在满足目标的候选架构中，研究员最终选择了工程实现最简洁的方案之一。

SWA–DSA 混合注意力架构

网络由 8 个模块组成，每个模块 6 层。标准模块的前 5 层为 SWA，最后 1 层为 DSA；第 1 个模块的第 1 层也设为 DSA。SWA 的窗口大小为 128 tokens，DSA 则选取 top-2,048 tokens 参与主干网络的注意力计算。两种注意力均引入 sink bias。

与最初基于 MLA 的 DSA 实现不同，Naive-N0.5-Flash 将 MLA 替换为采用 4 个 KV 分组的分组查询注意力（GQA）。通过基础设施与算法协同设计，我们开发了具有 16 个 query 头的轻量索引器，在保持 1M 上下文下 agent 任务性能的同时，将索引选择耗时相较原始 DSA 实现降低了 44%。

训练流程

架构修改后，Naive-N0.5-Flash 在原生 1M-token 上下文配置下需完成多阶段训练，累计训练长度为 3.25T tokens，包括 50B tokens 的索引器预热、3T tokens 的稀疏注意力训练，以及 200B tokens 的学习率衰减阶段。这一过程使模型适应了新的稀疏注意力架构，并大幅提升了 AI 研发与编程能力。

  • 索引器预热（Indexer Warmup）—— 50B tokens。 这一阶段冻结模型其余参数，仅训练新引入的 DSA 索引器。将切换为 DSA 的层仍在 1M 上下文下采用全局注意力完成前向计算，SWA 层保持不变。训练以这些层的全局注意力分布为监督信号，通过 KL 散度损失对齐索引器与主干的注意力分布，为后续切换至稀疏注意力建立索引基础。
  • 稀疏注意力训练（Sparse Attention Training）—— 3T tokens。 完成预热后，模型切换至稀疏注意力，进入继续预训练（CPT）阶段，以语言建模（LM）损失为训练目标，在固定学习率下重点强化 AI 研发与编程能力。整个阶段始终保持 1M 上下文。继续预训练使模型适应新的信息选择与聚合机制，同时强化长上下文建模能力，为需要保留任务历史、关联分散信息和持续交互的任务提供支撑。
  • 退火阶段（Decay Stage）—— 200B tokens。 随后，模型进入监督微调（SFT）阶段，继续保持 1M 上下文配置、稀疏注意力计算路径与 LM 训练目标，并在最后 200B tokens 的训练中逐步降低学习率。

训练系统

从全局注意力切换至稀疏注意力

在索引器预热期间，将切换为 DSA 的层仍采用全局注意力，SWA 层保持不变。在切换至稀疏注意力前，索引器先通过 KL 散度损失对齐全局注意力参考分布。

为验证这一切换，AI 以全局注意力结果为参照，自动分析了索引器 top-2,048 选择结果的 top-k recall（召回率），发现并修复 top-k 选择中的数值稳定性问题，再独立验证修复结果。研究员据此确定切换时机与精度阈值，并统一训练与部署阶段的验证标准。

混合序列的并行化计算

AI 模型在分析 1M 上下文下的注意力计算时，发现了混合架构的一项关键并行特性：DSA 需要访问完整历史，而 SWA 只关注左侧 128-token 窗口。据此，AI 模型提出并验证了混合序列并行方案，为两种注意力采用不同的执行路径。

DSA 层采用 Ulysses 序列并行（Ulysses Sequence Parallelism），通过 all-to-all 重分配访问完整序列；SWA 层采用 SWA 重叠序列并行（SWA Halo Sequence Parallel），通过重叠分片，仅与左侧相邻分片交换必要的重叠区（ghost region），重叠范围由样本边界确定。这既保留了 DSA 的全局建模能力，也将 SWA 的通信复杂度从 O(L) 降至 O(w)。

同样的思路也延伸到推理侧：长上下文预填充、按行分片计算和索引检索分别采用对应的上下文并行方案，而不共用同一套跨卡通信方式。

显存优化

显存管理同样由 AI 模型深度参与。针对稀疏索引与注意力对齐产生的中间激活，AI 模型扩展了训练框架的激活值显存管理机制；通过分析重计算路径，将卸载（offloading）粒度细化至单个算子的输出，每项中间激活均可独立配置卸载策略。top-k 索引则显式保留，避免重计算改变已选位置。

在 1M 长序列下，正确性检查与性能剖析还发现了位置编码的精度问题和序列索引的越界风险。

从数值稳定性、混合序列并行和张量布局转换，到长序列支持与显存优化，AI 模型直接参与了分析、发现、修复与验证的工程闭环。研究员定义目标、约束与决策边界，AI 模型承担自动分析、问题发现与独立验证——这也是NaiveAI「用 AI 模型构建 AI 模型」的具体实践。

在 1M-token 上下文配置下，这套训练系统使用 512 张 GPU，约 4 天即可完成 1T tokens 的训练。

开源许可

Naive-N0.5-Flash 的模型权重与推理代码均以 MIT License 许可发布。

引用

如果 Naive-N0.5-Flash 对你的研究或工作有所帮助，欢迎引用：

@misc{naiveai2026naiven05flash,
  title        = {Naive-N0.5-Flash: Building Frontier AI with AI},
  author  = {{NaiveAI Team}},
  year       = {2026},
}

致谢

Naive-N0.5-Flash 基于开源社区构建，也回馈于开源社区。感谢小米 MiMo 团队开放MiMo-V2.5 base模型，感谢 DeepSeek 团队在 DeepSeek 稀疏注意力（DSA）上的工作，也感谢 SGLang 团队与社区提供的开源推理基础设施。

联系我们

如有问题、反馈或合作意向，欢迎通过 contact@naive.ai 与我们联系，或关注微信公众号「Naive AI」获取最新动态。您也可以在 GitHub 和 Hugging Face 查看我们的开源项目与模型发布。