Granite 4.2：IBM如何把推理、工具调用与智能体训练放进三款开放模型

IBM 在 Hugging Face 发布 Granite 4.2 技术细节，推出 3B、8B、30B 三种开放模型，重点是工具调用与智能体强化学习并扩展到最长 512K 的上下文。模型以 Apache 2.0 许可开源，8B/30B 版本额外接受智能体 RL 训练以支持终端、代码执行和搜索等多步骤任务，同时提供可切换的思考、非思考与低投入思考模式以优化推理成本。

IBM Granite 团队在 Hugging Face 发布技术长文，详细介绍 Granite 4.2 推理模型家族的训练过程。这一代模型包括 3B、8B 和 30B 三个规模，重点不只是让模型“想得更久”，而是让它能够在工具、终端和搜索环境中完成多步骤任务。

Granite 4.2 的三个版本都支持思考与非思考模式，也提供一种低投入思考模式：模型只使用较短的推理预算处理相对简单的问题。8B 和 30B 版本则进一步接受了智能体强化学习训练，学习在真实的沙箱环境中调用工具、编辑和运行代码、操作终端以及进行网页搜索。

IBM 将全部 Granite 4.2 语言模型以 Apache 2.0 许可证开放。这意味着开发者和企业可以下载、微调并部署模型，许可证本身不会构成商业使用障碍。

从长上下文到智能体强化学习

根据 Hugging Face 的技术文章《Granite 4.2 LLMs: How They’re Built》，模型采用密集型、仅解码器 Transformer 架构，使用分组查询注意力、SwiGLU 激活和 RMSNorm。三个模型的基础序列长度为 131,072 个 token，经过五阶段预训练后，上下文窗口扩展到 512K token。

文章称，Granite 4.2 的预训练数据规模约为 15 万亿 token。前两个阶段主要进行基础预训练，第三和第四阶段通过逐步提高数据质量进行中期训练，第五阶段则用于长上下文扩展。这样的安排反映出长上下文并非只靠在模型配置中提高一个数字，而是需要相应的训练阶段让模型适应更长的输入。

不过，IBM 公开材料目前存在一个需要进一步厘清的口径差异。Hugging Face 技术文章把 Granite 4.2 描述为“从头预训练”的模型，而官方 GitHub 仓库则写道，Granite 4.2 密集模型是在 Granite 4.1 基础模型之上进行后训练。两种说法可能分别对应基础模型训练和发布检查点的关系，但在没有更完整说明前，不宜把它们简单合并为同一条结论。

训练进入监督微调阶段后，IBM 使用约 720 万个样本、约 1000 亿 token 的数据。数据中约 31.6% 来自智能体任务，涵盖软件工程、工具调用、终端使用、数学、搜索和行动等类别；其余数据则包括指令遵循、编程、数学、多语言、科学、推理和安全等任务。

这些智能体轨迹并非只围绕一种运行框架生成。技术文章列出了 OpenHands、OpenCode、Terminus-2、SWE-agent、MiniSWE、OpenResearcher、Gemini CLI、Hermes、Codex 和 Goose 等脚手架与工具环境。对模型训练而言，这种多环境设置的意义在于减少模型对单一工具格式或单一代理框架的依赖。

8B和30B版本获得额外的行动能力

监督微调之后，Granite 4.2 进入多阶段、多环境强化学习流程。IBM 没有把强化学习作为一次统一的“总训练”，而是把数学、代码、科学、指令遵循、工具使用、结构化输出、软件工程、终端和网页搜索拆分为多个阶段，每个阶段从前一阶段的检查点继续训练。

所有三个规模都接受基础强化学习训练，重点是数学、科学、编码、推理和工具调用。这个阶段同时使用可验证奖励和奖励模型，试图让模型既能得到可直接检查的结果，也能获得对答案质量的更高层次评估。

8B 和 30B 版本还会经过额外的智能体强化学习阶段，顺序覆盖软件工程、终端和搜索任务。IBM 研究团队在Granite 4.2 的发布说明中表示，模型需要在企业式工作流中识别应用、决定工具调用顺序，并在执行后检查结果，而不是盲目地逐步执行预先写好的动作。

这也是 Granite 4.2 与此前 Granite 版本的主要区别。IBM 早期的 Granite 模型已经强调指令遵循、检索增强生成和工具调用，但 Granite 4.2 把“先思考、再行动、再验证”作为模型家族的核心能力。3B 模型仍然可以调用工具，但只有 8B 和 30B 版本接受了完整的智能体强化学习模块。

30B 模型还额外进行了一轮面向智能体编码的监督微调。在这轮训练中，软件工程、智能体和编码数据被提高采样比例，同时保留约 16% 的原始微调数据作为回放，以避免模型在强化某一能力时丢失此前获得的通用能力。

“思考”不必每次都打开

推理模型的一个现实问题是，较长的思考过程通常意味着更高的延迟和推理成本。IBM 因此把 Granite 4.2 设计成可以在思考、非思考和低投入思考之间切换。

在需要复杂规划、代码分析或多步决策时，开发者可以启用思考模式；对于事实查询、简单分类或高吞吐量任务，则可以关闭思考，避免为不需要的推理过程支付额外计算成本。低投入模式则试图在两者之间取得平衡，让模型用较短的推理预算处理难度有限的问题。

这种开关并不是 IBM 第一次尝试。IBM 此前在“Bringing reasoning to Granite”中就曾介绍过可由开发者控制的推理能力，并指出长链式思考可能拖慢交互、增加成本。Granite 4.2 将这一思路从预览能力扩展到一个完整的模型家族，同时加入原生工具调用和面向智能体的后训练。

对企业来说，真正重要的可能不是模型是否“会推理”，而是能否把推理预算放在值得的地方。一个实际系统可能让小模型以非思考模式处理大量常规请求，再把需要编程、搜索或复杂规划的任务转交给 8B 或 30B 模型。这种按任务分层的使用方式，也与企业正在探索的多模型路由和成本管理方向相呼应。

开放权重不等于部署没有门槛

Granite 4.2 的开放许可和多个参数规模降低了试用门槛。开发者可以从官方 GitHub 项目获取推理示例，并通过 Hugging Face 模型仓库使用 3B、8B 和 30B 版本。项目还提供了思考模式、非思考模式、工具调用、多轮工具响应以及与 OpenCode、Pi、OpenHands 等智能体框架配合的说明。

量化支持则决定了模型能否更容易进入本地和边缘部署场景。IBM 的 GGUF 转换与量化仓库列出了 Granite 4.2 的 3B、8B 和 30B 版本，并注明相关转换流程使用 Transformers 5.8.0 和 llama.cpp b9850。仓库同时列出从 BF16 到多种 GGUF 量化格式的支持。

但开放权重并不意味着企业可以直接把模型放进生产系统。模型的工具调用能力越强，权限、沙箱、凭据管理、日志审计和失败回滚就越重要。AIFlux 此前报道过的DeepSeek Harness 多模态与子代理更新也说明，真正的智能体系统不仅由模型构成，还涉及会话管理、终端状态、子代理调度和运行记录。

部署成本同样需要单独评估。模型规模越大，复杂任务的潜在能力通常越强，但显存、并发能力和服务成本也会随之上升。Granite 4.2 提供 3B、8B 和 30B 三种选择，给企业留下了在质量、延迟和成本之间调整的空间；至于每个规模在真实业务中的性价比，仍不能只根据训练方法推断。

IBM的路线：更小的模型承担更具体的工作

IBM 对 Granite 4.2 的定位并不是用一个超大模型包办所有任务，而是把不同规模的密集模型放进企业工作流的不同位置。3B 模型可以处理高吞吐量、相对简单的任务；8B 模型在成本和智能体能力之间取得平衡；30B 模型则承担更复杂的推理、编码和多步骤执行。

这一策略也延续了 Granite 家族此前强调的企业属性：模型需要能够在云端、本地数据中心和边缘环境中部署，并且尽量保持架构简单、许可证清晰和工具链兼容。IBM 在发布说明中还介绍了 1 万亿 token 的合成代码训练、用于提高推理能力的中期训练，以及用于加速输出的推测解码层。

Granite 4.2 能否在开放模型竞争中站稳脚跟，最终仍取决于独立评测和实际部署，而不是训练流程本身。尤其需要继续观察三个问题：第一，8B 和 30B 在不同智能体环境中能否保持稳定的任务完成率；第二，512K 上下文在真实长文档和长会话中的有效利用率如何；第三，模型的工具调用、权限控制和安全评估能否满足企业生产要求。

目前可以确认的是，IBM 正在把 Granite 从“可用于企业的开放模型”进一步推进为“可在企业环境中执行任务的开放模型”。Granite 4.2 的技术路线说明，下一阶段的模型竞争不只在参数量和基准分数之间展开，也会越来越多地围绕训练环境、工具使用、推理成本以及模型能否在真实工作流中完成闭环。