2026年7月6日，NVIDIA在HuggingFace上开源了Nemotron-Labs-3-Puzzle-75B-A9B。这是Nemotron-3-Super-120B-A12B的压缩部署优化版本，通过Iterative Puzzle后训练压缩框架将120.7B参数的MoE模型压缩至75.3B，活跃参数从12.8B降至9.3B。几乎保持原始推理精度的同时，部署吞吐提升了约2倍，单张H100上的百万Token并发数从1个变成8个。
Nemotron家族新开源力作
NVIDIA Nemotron 3系列是2025年底推出的开源大模型家族。三个规模等级：Nano（30B总参、3B活跃）、Super（120B总参、12.8B活跃）和Ultra（550B总参）。全系列采用混合Mamba-Transformer MoE架构，针对agentic AI场景设计，支持最高100万tokens上下文。
Puzzle-75B-A9B就是Super的压缩变体。从"Puzzle"这个名字就能看出它的定位：像拼图一样把大模型重新组合成更小的尺寸。目标很直接——不降低推理能力的前提下削减部署成本。
发布不到48小时，HuggingFace上获得了28个赞和近160次下载，社区对这个方向的关注度很高。
核心参数规格速览
从Super 120B到Puzzle 75B的参数变化：
| 指标 | Nemotron-3-Super | Puzzle-75B-A9B | 压缩比例 |
|---|---|---|---|
| 总参数量 | 120.7B | 75.3B | 62.4% |
| 活跃参数量 | 12.8B | 9.3B | 73.1% |
| MoE路由专家中间尺寸 | 2688 | 1280-2688 | 均值59.9% |
| 每Token激活专家数 | 22个 | 4-18个 | 均值50% |
| Mamba SSM状态尺寸 | 128 | 96 | 75% |
数据来源：论文Table 1
Puzzle-75B-A9B保留了Super版本的核心架构优势：
- • 混合MoE架构：交错排列的Mamba-2状态空间层、MoE路由层和自注意力层
- • 多Token预测（MTP）：支持推测解码加速推理
- • 超长上下文：最高100万tokens（HuggingFace默认配置256K）
- • 多语言支持：中、英、法、德、意、日、西共7种语言
- • 开源许可：OpenMDW-1.1协议，允许商用部署和二次开发
BF16部分占用约156GB磁盘空间，共31个分片加1个MTP头文件。
Iterative Puzzle压缩原理
Iterative Puzzle（迭代拼图压缩）是这个模型最核心的技术。基本思想是渐进式结构压缩：不是一步到位剪枝，而是分多轮执行"压缩—恢复"循环。每轮压缩有限幅度，然后通过知识蒸馏（Knowledge Distillation）恢复精度，再进入下一轮。
三个维度的联合优化：
MoE权重通道剪枝：每个路由专家的中间层都有大量通道参数。压缩时按比例剪枝，但不同层剪枝比例不同——敏感度高的层少剪，低的层多剪。中间尺寸从2688降至1280-2688。
活跃参数预算缩减：这是效果最明显的维度。原始Super每处理一个Token激活22个路由专家，压缩后降到4-18个，按层异质分配。论文中特别强调："压缩模型不是均匀缩小的教师模型，而是按层敏感度分配活跃MoE容量的逐层架构。"某些层只需4个专家就能保持精度，有些层需要18个。
Mamba状态剪枝：Mamba SSM状态向量尺寸从128通道压缩至96通道。基于各通道对最终输出的贡献度排序，剔除最低的通道。这一优化带来了约1.2-1.3倍的解码速度提升。
快速上手部署指南
Puzzle-75B-A9B提供了三种精度的checkpoint：
- • BF16：完整精度，适合Hopper和Blackwell GPU
- • FP8：针对Hopper的8位量化版，显存需求更低
- • NVFP4：针对Blackwell的4位NVIDIA浮点格式
三个版本均可通过HuggingFace直接下载。
使用vLLM部署（推荐）
以BF16或FP8在Hopper GPU上部署为例：
vllm serve "$model_path" \
--tensor-parallel-size 2 \
--enable-expert-parallel \
--mamba-backend flashinfer \
--trust-remote-code \
--speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
--tool-call-parser qwen3_coder \
--reasoning-parser nemotron_v3
推荐2张GPU（tp=2），推测Token数3个。需要更高吞吐时调整--gpu-memory-utilization 0.9和--api-server-count 4。用4张GPU时推测Token数可以提升到5个。
OpenAI兼容API调用
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="EMPTY"
)
response = client.chat.completions.create(
model="nvidia/NVIDIA-Nemotron-Labs-3-Puzzle-75B-A9B-BF16",
messages=[{"role": "user", "content": "请用中文解释MoE架构的优势"}],
max_tokens=16000,
extra_body={
"chat_template_kwargs": {"enable_thinking": True}
}
)
关闭thinking模式：enable_thinking=False。低功耗推理：额外加"low_effort": True。编码Agent场景加"force_nonempty_content": True避免输出空内容。
Transformers直接加载
from transformers import AutoTokenizer, AutoModelForCausalLM
tokenizer = AutoTokenizer.from_pretrained(
"nvidia/NVIDIA-Nemotron-Labs-3-Puzzle-75B-A9B-BF16"
)
model = AutoModelForCausalLM.from_pretrained(
"nvidia/NVIDIA-Nemotron-Labs-3-Puzzle-75B-A9B-BF16",
torch_dtype=torch.bfloat16,
device_map="auto",
trust_remote_code=True
)
该模型使用自定义建模代码，必须设置trust_remote_code=True，Transformers版本不低于5.3.0。
四阶段训练恢复管线
Puzzle-75B-A9B不是简单的"剪枝即用"，而是经过四阶段训练管线，每个阶段针对特定的压缩损失进行恢复。
阶段一：Iterative Puzzle压缩
压缩分为三个子阶段，每轮压缩后用知识蒸馏恢复：
| 子阶段 | MoE压缩幅度 | Mamba压缩 | 蒸馏恢复Token数 |
|---|---|---|---|
| 第1步 | MoE权重75% | Mamba SSM 75% | 24B tokens |
| 第2步 | MoE权重60% | 保持不变 | 43.2B tokens |
| 第3步 | Top-k降至50%（异质分配） | 保持不变 | 52.8B tokens |
序列长度统一为32K tokens。渐进迭代比单步压缩在平均基准上高出0.57个点。
阶段二：长上下文知识蒸馏
目标：保留Super的超长上下文处理能力。教师模型是Nemotron-3-Super-120B。数据配比30%预训练加70% SFT。序列长度逐步扩展：32K→128K→512K，每阶段最多消耗100B tokens做蒸馏训练。
训练量很大——总共约120B tokens用于压缩恢复，长上下文阶段每阶段最多100B tokens。这种计算量的投入保证了压缩后的模型不会因为参数减少而丢失长距离依赖建模能力。
阶段三：强化学习恢复
针对软件工程和agentic任务。NVIDIA设计了两阶段SWE-RL管线：
- • SWE 1：单步工具使用对比训练，16次rollout，最大序列长度131K
- • SWE 2：端到端沙箱环境，32次rollout，最多200轮交互
最终checkpoint通过对多个学习率（1e-7到5e-6）的权重平均获得。常规权重平均比策略平均效果好。
阶段四：部署优化
- • FP8量化：MoE GEMM和Mamba线性层转FP8，KV缓存也转FP8。Mamba SSM状态保持FP32——FP16+SR在Hopper上反而更慢
- • NVFP4量化：针对Blackwell的激进量化，按层类型选最优精度
- • MTP持续训练：继续训练多Token预测头，缓解teacher forcing与自回归的不匹配。接受长度提升了25-30%
量化与部署优化方案
NVFP4版本在Blackwell GPU上表现突出。BF16和NVFP4的分数几乎一样：
| 基准测试 | BF16 | NVFP4 | 差距 |
|---|---|---|---|
| MMLU-Pro | 82.4 | 82.2 | -0.2 |
| AIME25（无工具） | 89.7 | 89.9 | +0.2 |
| GPQA（无工具） | 78.6 | 78.0 | -0.6 |
| LiveCodeBench v5 | 81.1 | 79.9 | -1.2 |
| SWE-Bench（OpenHands） | 56.9 | 56.9 | 0 |
| RULER @ 1M | 92.2 | 93.2 | +1.0 |
| Arena-Hard-V2 | 68.6 | 69.0 | +0.4 |
| AA-LCR | 56.9 | 57.0 | +0.1 |
数据来源：论文Table 3及NVFP4模型卡
NVFP4量化在数学推理（AIME25 89.9分持平）、长上下文（RULER 1M 93.2分反超）和对话质量（Arena-Hard）上都没有明显退化。
部署收益方面，Puzzle-75B-A9B相比Super的提升：
| 部署场景 | Super吞吐 | Puzzle吞吐 | 提升比例 |
|---|---|---|---|
| 8×B200，50K/2K，UT≥100 | 5,128 tok/s | 8,210 tok/s | 1.60× |
| 8×B200，8K/64K，UT≥100 | 20,939 tok/s | 42,601 tok/s | 2.03× |
| 8×B200，8K/64K，UT≥150 | 8,522 tok/s | 18,047 tok/s | 2.12× |
| 单H100，1M上下文并发 | 1个请求 | 8个请求 | 8.00× |
论文还给出了精度与效率的二维权衡图，Puzzle-75B-A9B在NVFP4下的完成请求数是Super单步解码的约2.18倍，精度从71.93%微降至70.74%。
性能评测与精度对比
推理与数学能力
Puzzle-75B-A9B在数学推理上表现不错。AIME25（无工具）89.7分，比120B教师低2.5分。HMMT Feb25 93.4分，MMLU-Pro 82.4分。压缩几乎没有触及数学推理核心能力——可能是因为知识蒸馏阶段有大量数学数据恢复训练。
编码与Agent能力
LiveCodeBench v5上81.1分，比教师低1.0分。SWE-Bench（OpenHands）56.9分，比教师低2.6分。参数量减少了37.6%，这个精度损失完全可以接受。
长上下文能力
RULER @ 1M评测92.2分（BF16），与教师的93.9分差1.7分。1M Token场景对模型容量要求极高，能保持这个分数说明长上下文知识蒸馏的设计起了作用。
论文的数据显示，128K长度下RULER分数基本与教师齐平，只有到1M极限长度时才出现微小差距。
多语言能力
MMLU-ProX多语言平均77.5分，覆盖7种语言。各语言之间差异较小，多语言能力在压缩过程中保留得不错。
适用场景与部署建议
适合的场景
- • 高吞吐对话系统：同时服务大量用户的聊天机器人、客服系统，8×B200节点轻松做到42K tok/s
- • 长上下文应用：代码仓库全量分析、长文档问答、多轮Agent对话
- • Agentic AI系统：多子Agent协作的工作流，可配合Nemotron系列其他模型构建多层架构
- • Blackwell GPU环境：NVFP4精度下性价比最佳
不适合的场景
- • 单卡低显存环境：BF16版本约156GB存储，至少80GB×2显存，消费级GPU跑不动
- • 延迟极度敏感的场景：整体吞吐高，但MoE路由和Mamba的状态空间计算有一定延迟
硬件配置建议
| 环境 | 推荐配置 | 预估吞吐 |
|---|---|---|
| 生产部署 | 4-8张H100/B200 | 8K-42K tok/s |
| 开发测试 | 2张H100（tp=2） | 中等吞吐 |
| Blackwell集群 | NVFP4 + MTP推测解码 | 最佳性价比 |
开源意义与展望
Puzzle-75B-A9B采用OpenMDW-1.1协议，允许商用部署、微调和二次分发。NVIDIA同期开源了训练数据、NeMo Gym和NeMo Evaluator，从数据到部署形成了一套完整的开源体系。
Iterative Puzzle压缩框架的意义可能比模型本身更大。它把"大模型能力"和"小模型效率"之间的矛盾变成了可量化的工程问题：你有120B模型，但预算只够75B？分三步压缩，每步蒸馏恢复，最后RL微调补救，一套流程下来精度损失可以控制在1-2个点以内。
对开发者来说，如果你因为硬件成本在模型选型上犹豫，Puzzle类压缩模型值得一试。不牺牲能力，只优化效率，而且完全开源。