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

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 日）

为什么要在 Mac 上重造一个引擎

MiniMax 在 8 月 3 日把 H3 正式开源，这是一个能同时吃进文本、图像、音频、视频、再一次性吐出最长 15 秒带原生立体声视频的通用生成模型。官方提供了 Hugging Face 权重和基于 SGLang、MLX 等的参考实现，社区也很快出现了 PipeNetwork 的 MLX 移植版。

但 antirez 选择了一条更硬核的路：不依赖现成框架，自己用 C 实现推理内核，再用 Metal 把矩阵运算落到苹果芯片的 GPU 上。这样做的好处是能精细控制统一内存的占用与复用——视频模型权重动辄上百 GB，能否塞进 Mac 的有限内存，取决于推理引擎怎么分批搬运张量。h3.c 目前仍在开发中，仓库显示它已能跑通提示词到视频、首尾帧约束，以及参考图、视频、音频的 Ref2VA 条件控制。

速度能快多少

项目 README 里给出了一组在 M5 Max 上的实测。以一段 512 像素见方、22 帧的红狐踏雪短片为基准：用默认 20 步去噪需要约 26.4 秒；而采用 4 步的激进调度，耗时压缩到约 3.5 秒，画面对照 29 步参考稿的全片结构相似度（SSIM）仍有 0.556，独立的冲浪者测试为 0.547。换句话说，用不到七分之一的时间，就能拿到一个可用、但细节更糙的预览。

模型核心是一个 33B 的稠密 Transformer（H3-Omni-Transformer），文本编码器复用 Qwen 系模型，权重以 BF16 精度常驻。在开启预览的激进配置下，峰值显存占用约 25.9 GiB（int8 估算）。仓库还提供多档预设：默认 20 步、最慢 50 步参考、最快 4 至 7 步，开发者可以一次只调一个旋钮来权衡速度与画质。

能拿来做什么

h3.c 内置了一个类似 Iris 的交互会话：启动时加载模型与分词器，之后输入提示词即可连续生成，重复提示词换随机种子时不必重新加载。它支持首帧与末帧锚定，让镜头从 A 画面运动到 B 画面，也支持按顺序追加多张参考图，标记为图片 1、图片 2，让模型据此生成「让图片 1 里的人挥手」这类指令。

分辨率方面，512×512 是被反复验证的开发尺寸，768p 级别的横竖构图也已验证，画布上限受机械限制约 768×1344。更短的 256 见方预览会自动降低空间位置编码频率，消除长镜头里出现的网格伪影。

对普通用户而言，h3.c 的意义在于把在云端排队、按秒计费的视频生成，变成在自己电脑上离线跑的一件事。代价是需要一台内存充足的 Apple Silicon Mac，以及等待项目继续打磨工程完整度。antirez 本人以把复杂系统写到极简著称，h3.c 最终能否成为 Mac 上跑 H3 的默认选择，还要看后续的内存优化与稳定性。

来源：Hacker News | antirez | https://github.com/antirez/h3.c

这份配置最近登上 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