2.4 万亿参数，每步只激活 950 亿

这组数字的命名已经写明了规格：「2.4T」代表模型总参数量达到 2.4 万亿；「A95B」代表每次前向计算只为单个词元激活 950 亿参数。实现这一点的，是混合专家（MoE）结构：模型共 92 层，每层拥有 512 个专家，每个词元只路由到其中 10 个路由专家加 1 个共享专家。底层采用 Qwen3.5 架构，并混合了门控 DeltaNet 与门控注意力机制。

相比训练一个 2.4 万亿参数的稠密模型，MoE 让「模型很大、跑起来却只需算一小部分」成为可能，大幅压低了推理成本。原生上下文长度为 262144 个词元，最长可扩展至约 101 万词元，足以覆盖长文档与长周期智能体任务。

和云端 Max 版不是一回事

需要区分的是，放权的开源版与早先上线的云端版 Qwen3.8-Max 并不完全相同。云端 Max 于 8 月初发布，额外支持视觉输入、可关闭的思考模式、默认 100 万词元上下文，以及官方内置工具；而开源版 Qwen3.8-2.4T-A95B 目前只有文本输入，且思考模式默认开启、无法关闭——模型在给出最终回答前会先生成推理过程，并通过 preserve_thinking 标记在多次对话间保留推理上下文，适合需要跨步骤保持「草稿」的智能体循环。

在官方公布的基准中，同架构的云端版本 Qwen3.8-Max 在论文复现基准 PaperBench 取得 93.0 分、在计算机操作基准 OSWorld-Verified 取得 86.1 分、在参数化 CAD 基准取得 91.5 分，均居参评模型前列；不过在 TerminalBench 2.1（86.6）与 SWE-bench Pro（67.7）上仍略低于部分对手。整体定位被千问团队形容为「除 Fable 5 外最强的模型之一」。

自己跑起来要多少硬件

开源权重意味着可以本地部署。官方支持通过 Hugging Face Transformers、SGLang、vLLM、TokenSpeed 等推理框架加载，正式部署时需使用各框架针对 Qwen3.8 的最新配方，并按权重精度与 GPU 数量选择并行策略。

全精度权重体积可观，但开源社区已经给出了瘦身方案。Unsloth 团队用动态 1-bit 分层选择性量化技术，把原始约 4.9TB 的模型压到 397GB，存储空间缩减约 91%；借助其 Unsloth-Desktop 工具，只要设备的内存与显存合计达到 410GB 以上，就能在本地把模型跑起来。对没有数据中心的中小团队而言，这意味着前沿级能力第一次能以自托管的形式落在自己手里。

许可证与价格

开放不等于完全自由。Qwen3.8-2.4T-A95B 采用千问自定义许可证，而非早先常见的 Apache 2.0：个人下载、修改、部署不受限，但大规模商业使用需要另行取得授权。配套发布的还有一颗约 270 亿参数的稠密伴随模型 Qwen3.8-27B，面向算力有限的场景，不过在开源权重放出时尚未同步上线。

云端 Qwen3.8-Max 的国内 API 定价为每百万词元输入 12 元、输出 36 元，海外为每百万词元输入 2 美元、输出 6 美元。

为什么这件事值得关注

把旗舰级权重交到社区手中，意义不只在「又大了一点」。过去一年，西方实验室谈开源时往往只放出 200 亿到 300 亿参数量级的中等模型，而阿里这次直接把自家最强旗舰摆上了桌面。无论动机如何，实际效果是：当前能完全自托管、可离线运行的最强模型之一，来自于中国的开源阵营，且差距明显。

对开发者与研究者来说，这意味着不必再为前沿能力向专有 API 持续付费，也能在本地做微调、评测与私有化部署；对下游应用，则把竞争拉回了「在模型之上能做出什么」这一层。

来源：Hugging Face 模型页 / 千问团队（经 Hacker News 收录）

与动辄几千亿参数的旗舰大模型不同，这款模型走的是「小而快、专干执行层苦力活」的路线。英伟达给它的定位，不是负责复杂规划的「大脑」，而是在多智能体系统里承担代码审查、安全监控、数据处理等高频、重复、对速度与成本极其敏感的执行任务。

300 亿参数，每次只激活 30 亿

Nemotron 3.5 Lightning 采用混合专家（MoE）架构，总参数为三百亿，但每次推理只激活约三十亿参数。这种「总量大、激活小」的设计，让它在资源占用与推理效率之间找到了新的平衡点。

英伟达称，与同级别开源模型相比，它的输出速度最高可提升四倍，相应地把智能体任务的整體完成速度加快约三成。需要指出的是，单项输出速度提升明显，但由于多智能体协作中存在通信与调度开销，整体任务的加速比并没有达到四倍——这也是它被定位为「特定任务」加速器，而非通用全流程加速器的原因。

在基准测试方面，该模型在 PinchBench 上拿到 86 分，与 OpenAI 的 gpt-oss-120b 相当，仅落后规模为其四倍的 Nemotron-Super 两分。英伟达强调，它的核心价值不在绝对性能排名，而在智能体工作流里的执行效率。

本地就能跑，还能自动路由

部署门槛是这款模型的一大卖点。它可以直接运行在本地 AI 设备上，包括搭载 RTX 显卡的 PC、DGX Spark、Jetson 边缘设备，也能扩展到数据中心与云端。发布当天，vLLM、Ollama、llama.cpp 与 LM Studio 等主流推理框架即宣布提供支持。

英伟达同时放出了配套的 NeMo Switchyard 路由库。它允许开发者定义模型池与路由策略，把工作流的每一步调度到最合适的模型上。内部基准显示，借助路由，系统能在维持前沿级任务完成度的同时，把成本压到单独运行 Opus 4.8 的大约三分之一。已有企业在真实场景中验证这套方案：LangChain 在一百四十四个多轮智能体任务里，仅把百分之七的调用量路由给前沿模型，就实现了百分之七十四的成本下降；Ramp 在 SWE-Bench 基准上匹配了前沿模型性能，同时降低百分之五十八的成本与百分之三十三的运行时间。

从卖芯片到卖整套 AI 工作流

多家媒体指出，Nemotron 3.5 Lightning 与 Switchyard 的打包推出，标志着英伟达正从单纯的硬件供应商，向全栈 AI 生态服务商实质性转型。当企业 AI 应用从「单模型对话」走向「多智能体协作」，执行层模型的市场空白正在被打开。

值得注意的是，英伟达并未停下更大模型的脚步。据多家媒体报道，公司还在开发参数规模至少达到一万亿的开源模型 Nemotron 4，意图与全球领先的开源大模型正面竞争。对开发者而言，一个由芯片厂商主导、软硬件协同优化的开源模型生态，正在快速成形。

来源：CNBC / The New Stack / NVIDIA（2026 年 8 月 11 日）

How-To Geek 作者 Nick Lewis 用自己的经历给出了对照：8GB 显存大致只能跑 70 亿参数（7B）模型，12GB 能跑 140 亿（14B），到了 16GB 才够跑 240 亿（24B）量级；而一个 270 亿（27B）的 Q4_K_M 量化模型，单是权重就要吃掉约 16GB 显存。

这还没算注意力缓存（KV cache）。它是模型记住上下文的临时内存，会额外占用显存的 25%（在 8K 上下文下）到翻倍（32K 上下文）。很多工具的默认上下文很短，比如 Ollama 默认只有 4096，所以小测试里显得很省，一旦把上下文拉长，显存立刻见底。

更关键的是，真实场景往往是好几个模型一起跑：主对话模型、负责向量检索的嵌入模型、再做一遍重排序的模型……一条典型的自动化流水线里同时跑 4 到 5 个模型并不稀奇。

混合专家模型（MoE）是个出路。这类模型只在每次推理时激活其中一部分参数，一个 200 亿级量化模型配 6 万上下文，在 RTX 5070 Ti 这样的显卡上能跑出每秒 100 个词以上的速度。优化手段还包括：把注意力缓存量化到 8 位或 4 位（一行配置即可）、主动限制上下文长度、用 MoE 替代稠密模型、把放不下的层卸载到 32GB 或 64GB 的系统内存。

说白了，16GB 不是「过剩」，而是「刚好及格」。想同时舒服地跑多个模型、留足上下文，24GB 才是真正的甜点档。打算本地玩 AI 的人，买卡时显存容量比核心频率更该排在前头。

来源：How-To Geek（作者 Nick Lewis，2026-08-09）

瓶颈不在算力，在搬运

Cursor 训练的是自家的智能体编程模型 Composer。团队在博客中写道，随着训练和推理规模不断放大，混合专家层始终是最主要的瓶颈——视工作负载和训练配置而定，这一层可以吃掉端到端训练时间的一半以上。

原因在于 MoE 的工作方式。这类模型不会让每个 token 都走完整个网络，而是由一个路由器为它挑选少数几个“专家”子网络。省算力的代价是，专家权重被切分存放在不同显卡上，token 必须先被分发（dispatch）到持有对应专家的卡上算完，再被收回（combine）原处加权求和。通信耗时可能和计算本身一样长，两者若串行执行，效率极低。

过去一年 Cursor 也写过自己的 MXFP8、NVFP4 训练算子和面向推理的“warp decode”方案，但那些工作只优化了计算部分，默认通信由别的库另行处理。到了生产环境，通信反而成了限制因素，于是团队决定从第一性原理出发，把整个 MoE 层连同通信一起重写。

一个内核吞下所有环节

MoK 的做法是把 MoE 的全部通信与计算融进单一内核，并且保证完全确定性——同样的输入必定得到逐位一致的输出。它专为英伟达 GB300 NVL72 机架设计：72 张显卡处在同一个 NVLink 域内，为细粒度的计算通信重叠创造了条件；但同一机架里集成的 Grace 中央处理器相对偏慢，显卡很容易空转等它，因此内核必须尽量抹掉主机侧的工作与同步。

团队的几项关键选择颇具反直觉色彩。业界惯例是用“推”（push）的方式散发 token，认为协议开销小、更能跑满链路；Cursor 的实测却发现，分发环节改用“拉”（pull）在专家负载不均时能把 NVLink 带宽利用率再提升最多 29%。更关键的是信令开销：推式分发要等最多 71 个对端的完成信号并刷新整个机架的内存，而拉式分发无需跨卡同步，微基准里两者延迟相差约 5.8 倍——103 微秒对 18 微秒。最终 MoK 选定了前向拉式分发、推式收回的组合。

此外，内核用环形 token 缓冲区复用固定内存，免去主机每步重新计算和分配缓冲区；并把流式多处理器拆开，一部分做矩阵乘法，一部分继续搬数据。在 Blackwell 架构上，凑够 256 个 token 就足以触发一条完整的张量核心矩阵乘指令，于是下一批还在路上时，这一批已经开算。

快了多少

在单个 MoE 层的对比测试中，MoK 的 MXFP8 前向吞吐最高达到最强公开基线的 2.37 倍。参与对比的是 NCCL 加 PyTorch、DeepEP 加 PyTorch、DeepEP 加 Transformer Engine，以及英伟达 HybridEP 加 Megatron 四套组合。

更有说服力的是生产数据。在横跨多个 NVL72 机架、共 512 张显卡的真实训练栈上，端到端每秒处理的 token 数从此前基于 DeepEP 方案的 760.9 提升到 1070.2，相当于 1.41 倍。Cursor 表示，MoK 目前已经支撑着数万张显卡规模的 Composer 训练。

谁会用得上

MoK 针对的是 DeepSeek-V3 式的 MoE 结构——一个共享专家加上数以百计的路由专家。Cursor 在文中直接点名，这一结构被 GLM、Qwen、Kimi（直到 K2.7）等开放权重模型广泛采用。换句话说，任何一家在 NVL72 机架上训练同类架构的团队，理论上都能直接受益。

代码已按 Apache 2.0 协议发布在 GitHub 的 cursor/mixture-of-kittens 仓库。署名作者为 Stuart H. Sul、Nash Brown、Henry Wildermuth、William Lin 和 Federico Cassano。

值得玩味的是发布者的身份：一家靠卖编程助手赚钱、不做芯片也不卖基础设施的应用层公司，公开了能从同一批硬件里多榨出四成吞吐的底层算子。这既说明模型训练成本对它已是实打实的支出项，也说明大规模训练的竞争，正越来越多地落在那些看不见的内核细节上。

来源：Cursor 官方博客

这份配置最近登上 Hacker News，作者 Ryan Zhou 把整套东西开源在 GitHub 上：一张 AMD MI300X 显卡，直接跑官方发布的 deepseek-ai/DeepSeek-V4-Flash-0731 权重，不做额外量化，也不做分层卸载，模型以出厂状态运行。仓库里包含 Docker Compose 部署栈、锁定哈希值的文件覆盖层、对照上游的差异补丁和调优参数表。

能塞下的原因是显存，不是算力

DeepSeek V4 Flash 是一个混合专家（MoE，指模型内部分成很多”专家”子网络，每个词只激活其中一小部分）架构的模型，基础设计 2840 亿参数、每个词激活 130 亿。0731 这一版额外附带了推测解码草稿模块，模型卡上标注的参数量因此是 3040 亿。它以 FP4 加 FP8 的混合精度发布——专家权重用四位、注意力和路由用八位——整个检查点在硬盘上约 149 GiB。

这个数字正是关键。它装不进 H100 的 80GB，也装不进 H200 的 141GB，所以官方推荐方案要么四张 H200，要么一整块 GB200 NVL4 托盘。而 MI300X 有 192GB 显存和 5.3 TB/s 带宽，容量是 H100 SXM5 的 2.4 倍，刚好装得下。

实际加载后，权重占 156.67 GiB，旁边还能放下 20GB 的键值缓存，另有 96 GiB 溢出到内存层，所以主机需要约 235 GiB 系统内存。显存峰值是 205.8GB 里的 204.5GB——余量不到一个 GB，非常紧。

性能数据

作者给出的实测结果如下：单条流解码中位数 168.6 词元/秒；调优后的预填充速度约 7.9 到 8.5K 词元/秒；八条并发流合计 542 词元/秒，每条中位 90.3；六十四条流突发时合计 830 词元/秒，没有显存溢出，也没有引擎报错；上下文验证到 256K，架构本身支持 100 万。

这些数字不是白来的。调优 21 个反复出现的矩阵乘形状，让单双流解码提升了 42% 到 62%，八到六十四流场景提升 10% 到 35%。融合 SiLU 激活加快速路由之后，原生解码从 34.5 提到 56.6 词元/秒，路由内核每层耗时从 42.6 微秒降到 11.9 微秒。还有一处很实用的调度改动：把调度预算设成 2048 词元、长预填充上限设成 1024 词元后，排在一个 5.2 万词元冷提示后面的短请求，首字延迟从 8.2 秒降到 0.5 秒。

代价是九个补丁

真正值得注意的是这套东西为什么需要九个补丁覆盖层。

一处是精度格式。MI300X 用的是 AMD 与 Graphcore 的 fnuz 变体八位浮点，而 MI325X 以及更新的卡用的是行业标准格式。一个假定标准格式的内核跑在 MI300X 上，缩放值可能直接差两倍。另一处更隐蔽：专家路由的位矩阵内核在填充块列时，掩码比对的是全局张量边界而不是逻辑块大小，高并发下填充通道会污染路由矩阵，表现出来是长提示下工具名字对不上、模式被遗忘——而这恰好是这个模型主打的智能体场景。修复只有一行。

软件侧的落差同样明显。vLLM 在 v0.21.0 的发布说明里声称支持 DeepSeek V4 的 ROCm 版本，但官方镜像在 AMD 硬件上启动就崩，报错指向一个只有英伟达 Hopper 架构才有的特性，与此同时官方配方仓库把所有 AMD 型号标为不支持。到 vLLM 0.25，官方配方验证了 MI325X，但只在张量并行度 1、4K 上下文下。MI300X——这张在 AMD 自家开发者云上 1.99 美元一小时就能租到的卡——至今不在官方支持矩阵里。

我的判断

AMD 那笔硬件账其实早就算得过来了：内存受限的混合专家推理场景，单卡显存容量才是硬约束，而 AMD 卖的就是更大的容量，MI325X 到了 256GB，MI355X 是 288GB。真正拖后腿的是硬件之下的那一层。

一个人花九个补丁、一套自建调优表填上的这段路，本该由芯片厂商自己走完。对准备用 AMD 卡做推理的团队来说，这份仓库是难得的参考；但它同时也是一份并不好看的进度报告。

你所在的团队评估过 AMD 卡做推理吗，卡在了哪一步？

来源：GitHub / ryanzhou 项目页，Hacker News

它靠的不是压缩，是搬家。这两代通义千问用的是混合专家架构（MoE，一个大模型内部拆成许多小专家，每次只喊几个干活）：800 亿参数版每层从 512 个专家里挑 10 个，实际每个词元只激活约 30 亿参数。Swiftlet 把常驻不变的那部分留在内存里，只占 1.3GB 到 2.5GB；剩下几万个专家权重打包成固定步长的容器文件放进固态硬盘，用哪个读哪个，一次读取对应一个专家，热门专家再用小缓存兜着，实测命中率 43% 到 70%。

说白了，不是模型变小了，是内存这道门槛被硬盘顶掉了。这类”以存换存”的思路，落地速度大概会快过等更大内存的新机器。

代价也得说清楚。作者自己承认，每个词元只激活 30 亿参数，模型”聊天和写作像大模型，记事实像小模型”；长提示词处理更慢，社区实测一万词元的提示要跑约半小时。项目采用 Apache 2.0 协议，要求苹果芯片、macOS 14 或 iOS 17 以上，同时提供命令行工具和兼容主流接口的本地服务。

为了让数据不出本机，你愿意忍受每秒几个词元的速度吗？

来源：GitHub / leonickson1 · Swiftlet，Hacker News「Show HN: Run an 80B Qwen in 4.3 GB of RAM on a Mac, and a 35B on an iPhone」

它走的是稀疏MoE（混合专家）架构，总参数2.4万亿，每次推理只激活约950亿。上下文长度顶到1M tokens，硬件、显存、推理延迟这些事留给模型自己。定价是国际版每百万token输入2美元、输出6美元，对标Claude Opus 5只到对手的40%和24%。国内千问AI平台价格为每百万token输入12元、输出36元。

动手能力方面，官方甩出三个真实案例：模型从零搭建oh-my-cli项目，无人工介入跑16天，265次提交、127个PR、151个issue；复现一篇推理论文并自我迭代，连续工作125小时、7600行代码、33轮GPU训练，AIME24比原方法再涨2.7分；参加WWW2025多模态对话挑战赛，24小时内击败458支人类队伍。芯片设计任务里，500轮交互把硬件门数从8298压到678，物理面积从106×106微米缩到46×46微米，整体缩小81%。

基准上，PaperBench 93.0、IFBench 82.8、HealthBench 60.2、CoWorkBench 74.8、JobBench 53.4，多项超过Anthropic Fable 5和GPT-5.6 Sol；OSWorld-Verified 86.1、MLVU 90.8，多模态也不落下风。

说白了，这版千问终于把”长程自主”摆到台面上了，标杆不再是单点刷分，而是能不能从一个空文件夹干完一个真实项目。权重下周登陆Hugging Face和ModelScope，Qwen3.8-27B同步开源。能调用Codex、Claude Code、Qoder这些主流框架，国内直接上qianwenai.com。

我的判断是，国产大模型真正可用的临界点，不是榜单分数，而是这种”扔进去一个目标，干完十几个工作日”的工程闭环。等开源权重放出来，你会拿它跑什么？先想好怎么用。

来源：千问官方博客、凤凰网科技、IT之家

在架构上，这是一款 Decoder-only 的稀疏专家模型：总参数量 160 亿，但每处理一个 token 只激活 28 亿参数。它包含 27 个解码层、隐藏维度 2048，采用门控多头潜在注意力（Gated MLA）。专家层面设有 2 个共享专家与 64 个路由专家，每个 token 实际只激活其中 6 个路由专家，再加上 2 个共享专家——稀疏结构让它的计算开销更接近一个参数少得多的稠密模型。

训练方面，Instella-MoE 在 AMD Instinct MI300X 与 MI325X 显卡、ROCm 软件栈上完成了 7.1T（万亿）tokens 的预训练，上下文窗口从初始的 4K 经 YaRN 位置编码扩展至 64K。后训练依次经历监督微调、DPO 偏好对齐与强化学习蒸馏，并推出了”Think”思考模型。

基准表现上，基础模型在标准评测平均得分 76.7，为当时全开放模型最高；在 WinoGrande 拿到 86.5，HumanEval+ 为 65.7，64K 长上下文 RULER 平均 79.4。思考模型平均 73.22，其中 IFEval 83.70、AIME25 73.40、AGIEval 82.50。横向比较，其基础模型强于 SmolLM3-3B、OLMo-3-7B、OLMoE 等开放模型，略低于 Qwen3.5-4B-Base（79.5）；思考模型则高于 Olmo3-7B-Think、Gemma-4-E4B、Qwen3.5-4B 等开放权重模型。

需要留意的是，Instella-MoE 采用 Research RAIL 许可证，仅限学术与研究用途，并非完全自由的商业授权。它的意义更多在于展示 AMD 的 ROCm 生态与开放模型路线——在英伟达几乎主导训练硬件的背景下，一个能完整复现训练全程的开放 MoE，对想要摆脱单一厂商绑定的研究团队颇具价值。

来源：AMD ROCm Blogs《Instella-MoE》（Jiang Liu 等，2026-07-24）