NVIDIA Nemotron 模型推理挑战赛邀请了 Kaggle 社区探讨一个重点问题：当每个人都从相同的开放模型、基准测试、基础设施和评估限制开始时，哪些技术可以提高推理准确性？
反响非常热烈。比赛结束时，4000 个团队的 5000 多名活跃参与者提交了数千份作品，并发布了 1000 多篇讨论帖子。竞争对手训练了 LoRA 适配器，构建了合成思维链数据集、逆向工程谜题系列、调试的基础设施，并随着排行榜的移动在公共线程中分享了发现结果。
最强的参赛作品将推理视为完整的工程工作流程。他们检查训练痕迹的质量，压缩长推理步长以适应令牌预算，为最困难的谜题类型构建有针对性的求解器，在公开排行榜之外进行验证，并谨慎地调整训练设置。同样重要的是，许多最好的见解来自社区讨论，参与者在讨论中比较了失败，提出了边缘案例，并将实验转化为可重复使用的知识。
挑战约束也塑造了新出现的技术。参与者在评估时无法使用互联网访问、修改推理代码或提交完整模型。提交的作品仅限于适用于排名为 32 或更低的 Nemotron-3 -Nano-30B 的 LoRA 适配器，最终得分出现在私人排行榜上。模型必须推理隐藏的转换，产生任何推理痕迹，并在令牌预算内返回最终答案。
此外，每一次提交的作品都在搭载 NVIDIA RTX PRO Blackwell GPU 的相同 Google Cloud G4 VM 上运行，使团队能够专注于推理工作流而不是基础设施管理，同时在吞吐量、内存和成本方面的实际限制条件下工作，这反映了这些系统在生产环境中运行的方式。这使比赛成为对实际推理工作流的有用测试：更好的数据、
以下是排行榜和论坛中的五节课，有助于提高您工作流程中的推理性能。
课 1. 让思维链数据可验证，而不仅仅是添加
我们观察到的
许多顶级团队都使用合成思维链数据进行了训练；示例展示了用于得出答案的步骤。最强的方法构建了用于生成痕迹、检查这些痕迹是否有效，以及在不有效时进行修复的工作流。
用处较小：
prompt → final answer
更实用：
prompt → solver-generated trace → check or repair trace → train
为何如此重要
推理痕迹看起来很有说服力，但仍然会教授错误的捷径。处理代码或数学证明之类的痕迹：每个步骤都应该是可检查的。其目标是教授从问题到答案的可靠路径。
如何应用
审核中间步骤，而不仅仅是最终答案。使用求解器、规则检查器、单元测试或人工审查来验证每个追踪是否可重现。
追踪质量检查
- 每个步骤都可以重现吗？
- 追踪是否使用了已显示的证据？
- 有缺陷的痕迹在训练之前是否被拒绝或修复？
来自排行榜
Team re 的第一名解决方案生成了合成问题，附加了求解器生成的痕迹，并使用 SFT 在这些痕迹上训练模型。 vli 中排名第二的 writeup 描述了类似的工作流程，其中包含用于生成合成提示词的单独文件，并且推理会追踪经过训练的模型。 Shehab Anwer 对 ATLAS 的讨论 也强化了这一点；经过验证的痕迹比未过滤的规模更重要。
课 2. 适合令牌预算的设计推理
我们观察到的
一些强大的解决方案将 token 预算视为推理问题的一部分，而不仅仅是运行时限制。长追踪可能包含正确的逻辑，但如果模型空间不足、重复过多或代表简单数据的 token 占用过多，则仍然会失败。
用处较小：
show every possible step in full
更实用：
compress repeated structure → preserve the logic → leave room to reason
由于每个答案都必须符合生成预算，因此最好的方法可以在不模糊的情况下缩短痕迹。
为何如此重要
长推理追踪可能会失败，原因与填充过度的提示失败相同：重要信号在那里，但模型无法有效地使用它。紧凑的表示有助于模型在困难的步骤上花费上下文，而不是在重复的支架上。
在构建者向模型传递长提示词、检索结果、工具输出、日志、表格或多步骤追踪时，这一点非常重要。
如何应用
寻找重复结构：长字符串、表格、标签、样板文件、候选列表或复制的上下文。然后测试是否可以在不隐藏逻辑的情况下更紧凑地表示相同的信息。
Token 预算检查
- 重复的内容是什么？
- 能否进行更紧凑的编码？
- 压缩是否保留了推理信号？
- 模型是否仍有验证和回答的空间？
来自排行榜
Tong Hui Kang 的 Open Progress Prize 工作 成为了后续解决方案的基础，因为它展示了表征的重要性。他的 位操作策略 避免了浪费性的暴力推理，同时将有用的结构保留在模型的完成预算范围内。
Team re 的 第一名解决方案、vli 的 第二名写入 和 YS-L 的 第三名写入 通过 HEX、混合十六进制二进制签名和压缩的 Hui Kang 风格痕迹扩展了这一想法。
课 3. 将模型应记住的内容与应解决的内容分开
我们观察到的
最强的推理工作流将稳定的知识与实时推理分开，而不是要求模型从头开始解决所有问题。可以存储或检索可重复使用的模式、查找表和紧凑签名，而模型则将其推理预算用于从问题到问题的更改部分。
用处较小：
make the model rediscover reusable structure every time
更实用：
store reusable structure → solve the new case → verify the answer
重点不在于记住答案。这是为了避免浪费可以预先计算的结构上的推理步骤。
为何如此重要
模型可能会因不知道答案而失败，但也可能会因工作流要求其同时执行过多作业而失败：推理规则、搜索空间、跟踪约束条件以及验证结果。将内存从计算中分离出来可减少在生成过程中必须正确处理的事项数量。
关键在于存储可重复使用的结构，而非最终答案。这样可以缩小实时推理步骤的规模，同时仍然需要模型对其前面的案例求解。
如何应用
寻找可在许多示例中重复使用的任务部分：模式、公式、运算符模式、单元规则、符号映射或常见故障案例。将这些视为内存。然后，设计提示、追踪或工具工作流程，以便模型使用该内存来解决其面前的特定情况。
内存与求解检查
- 示例中哪些要素保持不变？
- 此特定情况有何变化？
- 可重复使用的结构是否可以存储或检索？
- 模型能否验证最后一步？
当“内存”是可重复使用的结构，而非记忆输出时，这种方法效果最佳。
来自排行榜
Team re 的第一名解决方案使用签名目录来处理加密模式，让模型在进行较短的一致性检查之前依赖于可重复使用的结构。vli 的第二名表述与存储与计算分割理念相同。YS-L 的第三名写入也使用了将记忆与执行分离的两阶段方法。
课 4. 使用工具创建更好的推理数据，而不仅仅是提供更好的答案
我们观察到的
由于团队在评估时无法运行外部程序，因此在上游更好地使用了工具：创建更好的训练数据，而不是在提交时计算答案。工具可帮助发现准确性容易产生误导的地方：因错误原因找到正确答案、跳过搜索过程、隐藏冲突或超出令牌预算的痕迹。
用处较小：
tool → answer
更实用：
tool → trace → audit → failure cases → train
目标不是增加标签。这是一个训练信号，模型实际上可以从中学习。
为何如此重要
最终答案只能告诉我们目的地。可回放的轨迹可以指示路线，但前提是路线有效、可见且足够短，以便模型学习。
如何应用
使用求解器、脚本、符号引擎或其他模型生成中间推理构件，而不仅仅是标签。然后在训练之前进行审核。
工具检查
- 这些步骤是否可以回放或测试？
- 它能回答正确但推理无效的问题吗？
- 它是否包括有用的失败，而不仅仅是纯粹的成功？
- 模型能否在令牌预算内学习追踪？
当答案取决于隐藏的结构 (代码、数学、检索、规划、数据转换或域故障排除) 时，这一点非常有用。
来自排行榜
Mayur Pawar 的 “打破 SFT 上限” 文章使用求解器工程、可执行的思维链审核和故障驱动的合成数据来寻找答案正确的痕迹无法教有效的求解过程的案例。
StSTXion的密码/CSP 讨论基于搜索过程本身进行训练：候选选项、约束传播、冲突、回溯和提交。Shehab Anwer的ATLAS 讨论也强调了用于生成验证痕迹的增强求解器。
课 5. 按类型衡量推理权衡
我们观察到的
由于最终得分隐藏在私人排行榜上，因此真正的经验是寻找权衡取舍：一种推理技能的提升在其他地方造成回归，格式合规性掩盖了推理失败，噪声分数使弱结果看起来像进步。
用处较小：
track one aggregate score
更实用：
measure by task type → inspect failures → rebalance or retest
单个分数可以隐藏模型是在学习更好的推理过程，还是只是在任务类型之间改变性能。
为何如此重要
总体准确性可以让进度看起来更清晰。模型在符号搜索方面的表现可能会更好，在算术方面可能会更糟糕，在处理大量检索任务时可能会保持不变，而平均值几乎不会移动。
简单来说：如果您只测量平均值，则可以优化最容易移动的物体，而不是真正阻碍性能的物体。
如何应用
将评估分解为有意义的任务类型，然后跟踪每个任务的准确性和失败模式。当您添加新数据、更改提示、调整适配器或引入工具时，请留意回归。
验证检查
- 改进了哪些任务类型？
- 哪些任务类型有所下降？
- 哪些错误是格式问题与推理问题？
- 重复运行或样本的分数是否稳定？
- 验证集是否与您关注的案例匹配？
这不仅适用于基准测试：客户支持路由、代码修复、数学辅导、代理式工作流、企业搜索，以及任何“正确”取决于不同类型推理的系统。
来自排行榜
EnDream的每个类别错误分析揭示了汇总分数不足以满足需求的原因。他们的分析将格式成功与真实推理质量分开，并出现了单个分数可能隐藏的特定类别的瓶颈。
Yurnero的第2次公开/第6次私人撰写将验证视为该解决方案的核心部分，使用全训练验证和每个域的公共检查来了解哪些更改有助于哪些任务类型。Taha的非确定性讨论增加了另一个警告：当重复提交可能会移动几个点时，验证需要衡量稳定性，而不仅仅是峰值分数。
展望未来：从排行榜课程到更好的推理系统
Nemotron 模型推理挑战赛表明，提高推理性能并不是一个神奇的提示、一个更大的数据集或一个训练技巧。
最强的工作结合了几个实际习惯：
- 从可以验证的推理痕迹开始，而不仅仅是更多示例。
- 将标记预算视为推理问题的一部分。
- 当任务结构清晰时，请使用专用求解器。
- 针对您真正关心的故障模式进行验证。
- 做出保留推理行为 (而不仅仅是排行榜分数) 的训练选择。
一些最有价值的贡献从未出现在排行榜的顶端。它们出现在 Notebook、调试线程、共享脚本、实施说明和社区讨论中，帮助其他团队加快工作速度。这也是本次挑战赛发挥作用的部分原因：当建造者试图使用开放模型和可复制的基准来提高推理准确性时，参与者共同绘制了有效的地图。
感谢每一位参与者、获奖者、笔记本作者、讨论贡献者和社区成员，感谢他们为本次挑战赛提供了积极的学习环境。还要感谢 Kaggle 主办和支持本次比赛。
开放实验
像 Nemotron 这样的开放模型使这种学习成为可能。由于模型、数据集和训练方法可用于实验，因此社区可以检查行为、测试想法、比较方法，并将个人发现转化为共享技术。因此，对于任何构建推理系统的人来说，这是一本更实用的手册。
本次挑战赛在搭载 NVIDIA RTX PRO Blackwell GPU 的 Google Cloud G4 VM 上运行，参赛者可以获得所需的性能和内存，以便微调、运行推理、对提示词和数据工作流进行迭代，以及根据真实基准评估 Nemotron 模型。
在社区探索该堆栈的过程中，他们还获得了有关在尖端 Blackwell 基础设施上运行开放推理工作负载的实践经验，将设置挑战和优化路径转化为下一波构建者的共享知识。
如果开发者想要重现挑战设置，或根据自己的工作负载调整这些技术，则可以利用 G4 VM，引入 Nemotron 或其他开放模型，并应用相同的推理操作手册。
如需了解有关挑战赛的更多背景信息以及 NVIDIA Kaggle Grandmasters 在整个比赛中观察到的情况，请观看我们的 Nemotron Labs 直播回放。
您也可以在 7 月 24 日加入我们，与获胜团队进行现场讨论，我们将深入探讨排行榜背后的方法。添加到日历 >
