IBM Granite 4.2 30B
关于 IBM Granite 4.2 30B 的完整介绍(点开看;上面就是结论表)
IBM **2026-08-25 发布**的 Granite 4.2 家族旗舰档(IBM Research 官博一手:"Granite 4.2 brings native reasoning to enterprise agents",同批 3B / 8B / 30B + Granite Speech 5.0;HF blog + the-decoder 交叉一致)。**开放权重 Apache 2.0**——盘点文档(2026-11-08)把 Granite 4.2 误列入「闭源 API 24 个」,本轮按官方源改判(口径纠错)。config 一手核到(hf-mirror):64 层 dense、GQA 32 Q 头 / 8 KV 头 / head_dim 128、131,072 原生 ctx(官方文档 512K 为外推口径,未进 arch_detail)、thinking/non-thinking 双模(官方 low-effort 模式)、8B/30B 经 agentic RL 训练(OpenHands 沙箱写码跑测试 + Harbor/Terminus-2 终端 agent + 实时联网搜索多跳问答)。训练 15T token、NeMo-RL + NeMo-Gym、GB200 NVL72(CoreWeave 托管)。官方自报:SWE-bench Verified 30B 57.00 / 8B 47.67,Terminal-Bench 2.1 29.24 / 20.56(vendor 口径未复现)。显存档位:Q4_K_M 约 18G(官方 GGUF 17.7G 实测文件大小),**24G 卡主力档**,12G 卡 Q4_K_S(16.7G)也紧、建议 16G+;131K 长文 KV 1G/4K(dense 全注意力,与同规模稠密持平)。AA 快照(2026-11-07):30B 未在本站 AA 快照单列(8B/3B 各 5 分)。**他测(2026-11-09 B-066 补,单源 C 级)**:30B 首条他测 = CMP 170HX 64G 矿卡魔改 FP8(vLLM 0.32.0rc1,@Sandberg/LocalMaxxing 10-31)单流 0ctx **35.4 tok/s**(prefill 8K 2016;并发矩阵 c2 70.0 / c4 137.6 / c8 267.1 / c16 510.3 聚合;长 ctx 单流 16K 32.5 / 32K 30.0 / 64K 26.4 / 120K 21.6)——矿卡 PCIe Gen2 x4 + 2018 双路 E5 平台与消费卡档不可横比,价值是「64G 大显存便宜卡单卡全载 30B FP8 可行性」证据;8B/3B 仍按容量表推算。
实测速度:什么卡、什么量化、多少 token
| 显卡 | 卡数 | 量化 | 上下文 | 框架 / 版本 | decode tok/s | prefill tok/s | 单流/并发 | 投机 | 口径 | 来源 |
|---|---|---|---|---|---|---|---|---|---|---|
| NVIDIA CMP 170HX 64G(矿卡魔改) | 1 卡 | FP8(ibm-granite/granite-4.2-30b-fp8 官方量化) | 未报 | vLLM · 0.32.0rc1.dev249+g18305948a(morrowmake/vllm-cmp170hx 镜像,--kv-cache-dtype fp8 --max-model-len 131072) | 35.4 | 2016 | 单流 | 无 | 口径不全·不进对比 缺 2 项 | granite-4.2-30b-fp8 on CMP 170HX 64GB: speed test matrix(LocalMaxxing @Sandberg,llm-inference-bench v0.8.0,全矩阵) @Sandberg(LocalMaxxing 社区) · 2026-10-31 |
每行是一次真实测量的完整口径:哪张卡、几张卡、什么量化、多大上下文、哪个框架哪个版本、单流还是并发、开没开投机—— 缺一项就会标出来,缺项的行不参与对比与偏差计算。本站实测行没有外链,但日志路径就是原始数据所在。 想看同一张卡跑别的模型,从这个表的显卡名点进那张卡的页面。
速查:什么卡、跑多少 token
推算值按 Q4_K_M、8K 上下文、单流;真实测量看下面的实测速度表。没有实测的模型这里只有推算,本站不把推算写成实测。
架构常数(已核实)
来源:ibm-granite/granite-4.2-30b / config.json(抓取于 2026-11-09)。KV 公式:2 × 层数 × KV头数 × 头维 × 精度字节 × token(滑窗层按 — 封顶)。
上下文档位(按 Q4_K_M)
| 上下文 | KV | 总需显存 | 16G 水位内 |
|---|---|---|---|
| 4K | 1 G | 20 G | 超 |
| 8K | 2 G | 21 G | 超 |
| 32K | 8 G | 27 G | 超 |
| 128K | 32 G | 51 G | 超 |
* 含 1G 框架开销;可用水位按 Windows 口径 88% = 14.1G。
各显存档位能开多大
| 显存 | 推荐量化 | 8K 总需 | 最多可开 |
|---|---|---|---|
| 4G | 装不下 | — | — |
| 6G | 装不下 | — | — |
| 8G | 装不下 | — | — |
| 10G | 装不下 | — | — |
| 11G | 装不下 | — | — |
| 12G | 装不下 | — | — |
| 16G | 装不下 | — | — |
| 20G | 装不下 | — | — |
| 22G | Q4_K_M(估算) | 21G | 1536(约 2K) |
| 24G | Q4_K_M(估算) | 21G | 8192(约 8K) |
| 32G | Q6_K(估算) | 27.6G | 10240(约 10K) |
| 48G | Q8_0(估算) | 34.9G | 37888(约 37K) |
| 64G | Q8_0(估算) | 34.9G | 95744(约 94K) |
| 96G | Q8_0(估算) | 34.9G | 131072(约 128K) |
| 128G | Q8_0(估算) | 34.9G | 131072(约 128K) |
| 256G | Q8_0(估算) | 34.9G | 131072(约 128K) |
| 512G | Q8_0(估算) | 34.9G | 131072(约 128K) |
「最多可开」已扣掉权重与 1G 开销;标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 150 token(估算值,未逐项核实)。量化档后带「(估算)」= 官方仓库没核到这档、按公式算的权重体积(方向保守偏高);不带 = 核过官方仓库真实文件体积。
估算速度(Q4_K_M · 8K)
推算 本站暂无这一模型的实测记录。
| 显卡 | 状态 | 估算 tok/s |
|---|---|---|
| NVIDIA RTX 5090 32G | 能跑但紧 | 60–85 |
| NVIDIA RTX 5090 D 32G | 能跑但紧 | 60–85 |
| NVIDIA CMP 170HX 64G(矿卡魔改) | 流畅 | 50–70 |
| NVIDIA RTX PRO 5000 Blackwell 48G(工作站) | 流畅 | 45–63 |
| AMD Instinct MI100 32G(老数据中心卡) | 能跑但紧 | 41–58 |
| AMD Instinct MI50 32G(数据卡) | 能跑但紧 | 34–48 |
| AMD Radeon VII 16G | 装不下 | 需 offload ≈9–14 |
| NVIDIA RTX 4090 24G | 能跑但紧 | 34–48 |
| NVIDIA RTX 3090 Ti 24G | 能跑但紧 | 34–48 |
同一套公式也用于显卡页,两页数字必然一致。带宽按 60–85% 效率折算(offload 场景更低),并对单流解码设经验上限,因此这里的数字比纯带宽公式保守。 总需显存 = 21G,对比各卡可用水位。
实测数据区
上传实测数据
推理框架命令
llama.cpp
# 1) 取 GGUF 权重(本站核实过的仓库名)
huggingface-cli download ibm-granite/granite-4.2-30b config.json
# GGUF 量化版通常在第三方转换仓库,搜「ibm-granite/granite-4.2-30b GGUF」
# 2) 起服务(Linux/macOS 用 ./llama-server,Windows 用 llama-server.exe)
llama-server -m GRANITE-4-2-30B-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080Ollama
# 本站没核实到 Ollama 仓库里有 IBM Granite 4.2 30B 的可用标签,所以不给命令
# 自己去查一眼:https://ollama.com/search?q=IBM%20Granite%204.2%2030B宁可不给命令,也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。
vLLM
vLLM 直接吃 Hugging Face 仓库名,这条最可靠:
vllm serve ibm-granite/granite-4.2-30b --max-model-len 8192 --gpu-memory-utilization 0.90LM Studio
模型页搜「ibm-granite/granite-4.2-30b」→ 选 Q4_K_M 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大仓库名 ibm-granite/granite-4.2-30b 是本站核实过的(架构常数就取自它)。Ollama 标签与 GGUF 文件名会随发布方变动,本站不保证一定存在,拉取失败请搜同名前缀。
优化要点
- Q4_K_M 权重 18G(估算)、Q6_K 24.6G(估算)、Q8_0 31.9G(估算):带「估算」的是公式值(官方仓库没核到这档),不带的核过真实文件;先在容量表里确认 8K 上下文还剩多少,再决定档位
- 上下文从 8K 提到 32K,KV 增加约 6G(本模型 64 层 / 8 KV头 / 头维 128)
- 模型原生上下文上限是 128K,把 -c 设得更高属于超纲使用,质量不保证
- 想要更长上下文:-ctk q8_0 -ctv q8_0 让 KV 减半,几乎不掉质量
- 稠密模型每个 token 都要读全部权重,所以速度上限就是带宽 ÷ 权重大小
- 本站对单流解码设了经验上限 200–200 tok/s(依带宽分档),超出上限的数字是公式失真而不是你的卡快