Naive-N0.5-Flash – NaiveAI 开源的首个 MoE 大模型

Naive-N0.5-Flash是NaiveAI于2026年9月开源的首个MoE 大模型，主要用于长上下文编程与 AI 研发任务，基于小米 MiMo-V2.5 基座改造，原生支持 100 万 token 上下文，并配套自研推理系统 NaiveRT。

Naive-N0.5-Flash 的核心能力

在长上下文场景中，注意力层的计算量随序列长度迅速上升，显存占用同步增长。Naive-N0.5-Flash 将整网注意力改为稀疏结构，以支撑百万级上下文的可用性。理解这类模型的定位，可先了解 大语言模型 的基本原理。

长上下文编程

模型原生支持 100 万 token 上下文，可以一次容纳大型代码仓库与长程软件工程任务。窗口内没有任何全注意力层，生成单个 token 所需的计算量基本不随上下文长度增长，长序列解码的开销因此明显低于常规结构。

AI 研发辅助

除代码任务外，模型可以读论文、复现方法、执行实验并分析结果，直接参与模型研发流程。官方把这种模式概括为让 AI 参与制造 AI：模型负责实现架构候选、开展对比实验与排查训练系统缺陷，研究者负责设定目标、约束与最终判断。

推理加速与 NaiveRT

配套的推理系统 NaiveRT 通过巨型算子融合、算子重叠执行与在 GPU 内推进的投机解码循环，把单轮解码延迟继续压低。官方给出的极速模式单流解码峰值为 2,122 tokens/s，投机解码周期 3.4 毫秒，其对照的 SGLang 为 12.3 毫秒。

自主科研能力

研究者这一侧只需要给出目标、预算上限与验收口径，课题拆解、方案试错、结果归因等环节由模型自行串联推进。官方举例称其曾在约 400 小时内训出一个世界模型并登顶 WorldArena 榜单，这类结果目前仍以官方说明为准。

混合稀疏注意力设计

该设计的取舍在于：输入序列中绝大多数 token 只需与邻近 token 交互，为全部位置计算两两注意力并不经济。模型因此在 48 层中保留 39 层滑动窗口负责局部依赖、9 层稀疏注意力负责长程依赖，两者按 5:1 的比例交替堆叠；同时将 DeepSeek 稀疏注意力中的多头部潜注意力改为分组查询注意力，索引器查询头由 64 个降至 16 个，索引挑选环节的耗时相应下降 44%。其结果是全网络不再包含全注意力层，而主干每次仍可获取按重要性筛选出的 top-2048 个 token。

Naive-N0.5-Flash 与同类模型的对比

下表从参数规模、上下文与能力侧重等维度，对比三款常被放在一起评估的模型。

上表 Naive-N0.5-Flash 一列取自 NaiveAI 官方项目说明，DeepSeek-V4.1-Flash 与 Hy4 preview 两列取自各自官方资料。三者的训练目标并不相同：Naive-N0.5-Flash 把研发能力作为主线，配套的推理系统强调单流解码速度；DeepSeek-V4.1-Flash 以低成本与原生多模态作为主力档定位；Hy4 preview 面向企业级生产力场景，强调长上下文与吞吐表现。选型时可以先明确任务属于研发类还是通用类，以及是否需要原生多模态输入。

如果想先了解开源编程方向的另一个选项，可以参考 GLM-5.3（智谱推出的编程与网络安全特化开源大模型，与 Naive-N0.5-Flash 同属开源模型路线，区别在于前者在代码审计与漏洞发现上做了专项训练）。

Naive-N0.5-Flash 的应用场景与适用人群

结合原生百万上下文与研发辅助两项能力，以下几类任务与其适用性最为契合：

• 整仓级代码的完整输入：将整个代码仓库连同历史提交一并纳入单次输入，由模型自行完成跨文件的依赖梳理与缺陷定位，无需人工切分片段或分批补入上下文。
• 实验环节的端到端执行：从论文研读、方法复现、实验执行到结果整理，均可交由模型连续推进，研究者仅需保留命题设定与结果验收两个环节。
• 数小时级的终端任务：在终端操作与多轮工具调用等长时交互中，历史对话全程保留于上下文窗口，任务执行期间不受压缩或截断影响。
• 强化学习中的批量采样：结合单流解码速度与可按随机种子复现的采样机制，用于长程 rollout 时可缩短采样耗时，并减少因采样偏差产生的无效样本。
• 长文档的离线批处理：因整网不含随上下文长度线性增长的全注意力层，同等硬件条件下处理长文档的吞吐表现优于常规架构，适用于合同、财报、日志等需成批处理且实时性要求不高的材料。
• 自有语料上的继续预训练：权重以 MIT 许可开放，允许修改与再分发，团队可基于内部语料开展二次训练并按自身场景发布衍生版本，这一能力是多数仅提供 API 的模型所不具备的。

适用人群：适用范围涵盖模型研发团队、需处理大型代码仓库的工程团队，以及构建 Agent 与强化学习流程的技术人员。需要注意的是，开放权重并不等于零成本运行：本地部署既要求 GPU 支持 FP8，也需为约 315GB 的权重体积预留相应存储，硬件成本应在选型阶段一并评估。

Naive-N0.5-Flash 的使用方法

本地部署的难点集中在硬件与依赖两部分，以下五个环节覆盖从获取权重到生成首段回复的完整流程：

1. 确认硬件条件：FP8 权重对算力与磁盘均有要求，GPU 需支持 FP8 数据格式，权重文件约 315GB，建议按权重体积的 1.2 倍以上预留磁盘空间；除显存外，加载阶段所需的主机内存也需一并计入。
2. 获取权重与安装依赖：从 Hugging Face 获取 NaiveAI/Naive-N0.5-Flash-FP8，磁盘容量充足时也可改用主模型权重，两者的区别在于 FP8 版体积更小、加载更快，能力上并无差异；依赖侧执行 pip install "transformers[torch,kernels]>=5.17.0"，其中 kernels extra 提供模型所需的自定义算子，缺装该组件将导致加载阶段报算子缺失。
3. 完成一次短对话验证：通过 AutoTokenizer 与 AutoModelForCausalLM 载入本地权重，加载时需传入 trust_remote_code=True —— 模型包含自定义的稀疏注意力实现，未显式授权该部分代码将导致加载失败；device_map="auto" 用于在多卡之间分摊权重。输入侧以 apply_chat_template 将多轮消息拼接为张量，再由 model.generate() 生成、tokenizer.decode() 还原文本。建议先以数十 token 的短提示确认调用链路可用，再替换为长输入。
4. 按任务设定生成参数：官方给出的通用取值为 temperature=1.0 与 top_p=0.95；代码补全等对稳定性要求较高的任务可将 temperature 降至 0.2~0.4，发散型探索任务则可适当放宽。执行长程任务时需留意输出长度上限，避免接近百万 token 的输入占用过多生成空间。
5. 评估是否需要 NaiveRT：若调用频率较低，原生 transformers 路径已可满足需求，无需额外维护一套部署环境；仅当需要达到官方公布的 2,122 tokens/s 极速解码时，才有必要获取 NaiveRT 的开源代码与 Docker Compose 环境进行自建部署，配套基准脚本可用于复测。相关代码与说明见 Naive-N0.5-Flash 官方仓库。

建议先在单机环境完成小规模部署验证，确认显存占用与生成质量符合预期后再考虑多机横向扩展。多卡部署时通过 device_map="auto" 自动切分权重，若 FP8 权重仍超出显存容量，可进一步降低精度或提高并行度。出现算子未定义的报错时，应优先检查 kernels extra 是否安装完整，此类报错通常并非源自模型本身。官方公布的基准数据均来自其自测口径，正式投产前应以自有任务重新评测一轮。

Naive-N0.5-Flash 的价格与开源情况

Naive-N0.5-Flash 以 MIT 许可证开放模型权重与推理代码，允许商用、修改与再分发，官方在 Hugging Face 上提供了主模型与 FP8 版本，权重文件约 315GB，需要自行准备算力。除本地部署外，官方也提供 API 服务，具体计费方式以官方页面为准。

MIT 属于限制较少的开源许可，对企业与个人开发者均适用；需要注意的是，权重开放并不等于推理免费，本地运行的算力成本与 API 调用的计费仍需单独核算，正式投入前建议按自身调用量做一次成本估算。

Naive-N0.5-Flash 的常见问题