이미지: Hugging Face · METAL LAB 편집
摘要
- IBM以Apache 2.0协议开源了首批推理型Granite模型4.2,共3B、8B、30B三种规格
- 预训练用了约15万亿token,上下文窗口扩展到512K token,只有8B和30B加入了按SWE(软件工程)、终端、搜索顺序排列的智能体强化学习
- 30B还额外做了一轮专攻智能体编程的二次SFT,让它更适合直接修改代码仓库
- 모델 크기
- 3B, 8B, 30B (밀집형·디코더 전용)
- 사전학습 토큰
- 약 15조 토큰, 5단계 학습
- 컨텍스트 윈도우
- 최대 512K 토큰
- 라이선스
- Apache 2.0
- SFT 데이터 규모
- 약 720만 샘플, 약 1000억 토큰(학습 반영 약 650억 토큰)
- 에이전트 RL 대상
- 8B·30B (SWE→터미널→검색 순), 3B는 미포함
- 데이터 품질 심사 모델
- gpt-oss-120b, Gemma 4
曾经只会乖乖听话的模型,现在开始"思考"了
IBM研究院发布了Granite语言模型系列的新版本Granite 4.2。此前的Granite系列一直以"忠实执行指令的助手"著称,而从这次的4.2开始,模型第一次具备了在给出答案之前自主生成思维链(chain of thought)的推理能力。就在8月10日Meta发布Muse Glimmer之后,30B级开源模型的竞争仍在继续,而IBM这次一口气推出了3B、8B、30B三种规格,全部以Apache 2.0协议开放。
三款模型采用相同的Transformer架构,也走了相同的训练流程——从预训练到监督微调(SFT),再到多阶段强化学习——但最终真正落到手里的能力,却因模型体量而不同。真正让模型动手操作工具的智能体训练,只加到了8B和30B里,3B被直接跳过了。也就是说,三者都会"思考",但会不会"动手"却完全是两码事。
15万亿token,分五个阶段打底
Granite 4.2是从零开始重新训练的模型。整个预训练用了约15万亿token,分五个阶段完成:第一、二阶段是基础预训练;第三、四阶段是数据质量逐步收窄的中期训练;第五阶段则专门用来把上下文窗口扩展到512K token。512K token意味着可以一次性塞进好几本厚书的内容,让模型通读消化。
之后的SFT阶段,把模型真正打磨成了一个可用的助手。SFT数据规模约为720万条样本、大约1000亿token(实际参与训练的约为650亿token),其中智能体数据占31.6%,通用指令与推理数据占68.4%。
| 智能体数据细分领域 | 占比 |
|---|---|
| 软件工程(SWE) | 69.0% |
| 工具调用 | 12.1% |
| 终端使用 | 8.0% |
| 数学 | 3.5% |
| 网页搜索 | 0.8% |
| 动作类 | 0.2% |
智能体数据来自OpenHands等多种智能体框架,包括OpenCode、Terminus-2、SWE-agent、Gemini CLI、Hermes、Codex、Goose,并叠加了IBM自建强化学习环境生成的数据。质量校验环节引入了OpenAI的开放权重模型gpt-oss-120b和Google DeepMind的Gemma 4作为评审模型,用来过滤掉带幻觉的回答,以及调用未定义函数的工具请求。去重则是把工具列表和对话内容合并后,用SHA-256哈希来处理的。
8B和30B,连"怎么用工具"都学会了
SFT之后是多阶段强化学习。模型先要经过RLVR阶段,针对数学、代码、科学、指令遵循、工具使用、结构化输出等可验证任务给予奖励训练,然后依次通过按软件工程(SWE)→终端使用→网页搜索顺序排列的智能体RL模块。最后一步是融入人类偏好与安全性的RLHF。
每个阶段都是独立的GRPO(组相对策略优化)运行,承接上一阶段的检查点继续训练。RLVR第一轮的做法是:每256个提示词各采样16个回答,组成4096条数据的批次进行训练——3B和8B把这一轮重复了两次,30B则重复了三次。
| 模型 | 参数量 | 智能体RL(SWE→终端→搜索) | 追加SFT |
|---|---|---|---|
| Granite 4.2 3B | 30亿 | 无 | 无 |
| Granite 4.2 8B | 80亿 | 有 | 无 |
| Granite 4.2 30B | 300亿 | 有 | 智能体编程二次SFT(约1个epoch,学习率3.0e-6) |
3B只走完基础RL和对齐阶段,跳过了智能体模块。而30B则多做了一轮SFT,这一轮里SWE和编码类数据的占比被特意提高,同时保留了原SFT数据16%作为"回放"数据,以避免模型丢失原有能力。
一个能开关的"思考"开关,以及工具调用能力
三款模型都可以在思考模式(thinking)和非思考模式(non-thinking)之间切换,中间还有一个"低算力"(low-effort)模式,专门用较少的推理预算处理简单问题。工具调用则完全沿用了OpenAI的函数调用格式,只要用vLLM之类兼容OpenAI接口的服务端部署,就能无需任何格式转换,直接接入现有的智能体框架。SGLang食谱里也已经提供了可以直接上线使用的部署方案。
该怎么上手
Granite 4.2的3B、8B、30B权重都可以在github.com/ibm-granite/granite-4.2-language-models仓库下载,三款模型均为Apache 2.0协议,商用改造没有限制。用vLLM或SGLang部署后,工具调用会直接以OpenAI函数调用格式输出,这意味着已经为OpenAI模型写好的智能体代码,基本上只需要换个模型就能直接迁移过来。
实际使用中真正需要权衡的是尺寸选择。如果只是不涉及工具调用的聊天、摘要类任务,3B已经够用;但如果要交给模型完成修改代码、跑终端命令、搜索网页这类真正的智能体工作流,就必须选择经过智能体RL训练的8B以上型号。30B在此基础上又额外接受了针对软件工程任务的二次SFT,所以最适合用作直接修改代码仓库的编程智能体。
编辑视角
IBM在一直以指令遵循见长的Granite系列中加入推理能力,时机选得相当巧妙。这一整年,由DeepSeek引发的开源推理模型竞赛从未停歇,而就在不久前,Meta才刚刚推出面向本地智能体场景的30B级密集模型Muse Glimmer。IBM在同一个30B体量级别上,还额外叠加了针对智能体编程的二次SFT,这释放出一个信号:它瞄准的不是聊天质量的竞赛,而是企业内部"直接修改代码"的智能体市场。
3B故意不加智能体RL这一点,同样值得关注。这并不是在性能上打折扣,而是在明确划分用途——3B被留在本地部署或低成本API场景下,继续扮演"听指令的助手"角色,而工具操作能力则集中给了8B和30B。以往的开源模型,往往是把同一种能力按体量简单地缩放、复制到各个尺寸;而这次这种"直接把某项能力从某个体量中拿掉"的做法,反而让实际部署的边界更清晰——如果选了3B,一开始就不该指望它能完成智能体任务。
对于希望在本地私有环境中搭建智能体流水线的国内团队来说,Apache 2.0协议加上兼容OpenAI的函数调用格式,是实打实的优势——已经为OpenAI或其他厂商模型写好的工具定义和框架代码,基本可以原封不动地保留,只需要换掉底层模型即可。不过究竟该用8B还是30B,还是得先掂量清楚GPU预算和任务难度再做决定——单纯的工具调用用8B可能就够了,而涉及整个代码仓库修改的任务,经过二次SFT的30B大概率会更稳定。
接下来几周内,应该会有关于这款模型在智能体编程基准测试中的成绩,与其他30B级开源模型并列比较的数据出炉。这场比较能否证明IBM强调的"SWE专项二次SFT"确实转化为了代码修改成功率上的实质差距,将是检验这次"只给8B和30B配备工具能力"这一选择是否正确的第一道试金石。
评论