IBM vừa release Granite 4.1 — họ model open source dành cho enterprise. Ba kích cỡ, license Apache 2.0, train trên 15 nghìn tỷ token với mức độ obsession về pipeline đáng để hiểu rõ.
Một kết quả trong benchmark sẽ không hợp lý cho đến khi bạn hiểu cách họ build model này.
Bản 8B. Dense architecture, không có MoE tricks, không có extended reasoning chains. Nó match hoặc vượt Granite 4.0-H-Small ở hầu hết benchmark họ chạy. Model cũ kia có 32 tỷ params với 9 tỷ active. Cái này chỉ có 8 tỷ.
Điều này nghĩa là model cũ build chưa đủ tốt, hoặc kết quả mới quá ấn tượng. Có lẽ là cả hai.
Kết quả khiến bạn phải nhìn lại
Trên ArenaHard — benchmark mà GPT-4 đánh giá xem model handle 500 prompt thực tế khó như thế nào — bản 8B instruct đạt 69.0. Granite 4.0-H-Small (32B MoE, 9B active) trước đó đạt thấp hơn. Trên BFCL V3 (benchmark chuẩn cho tool calling), bản 8B đạt 68.3 vs 64.7 của 32B MoE. Trên GSM8K (math reasoning cấp tiểu học), bản 8B đạt 92.5. Trên AlpacaEval, MMLU-Pro, BBH, EvalPlus, MBPP — tình hình tương tự.
Một model dense hơn, đơn giản hơn, nhỏ hơn lại đang thắng. Một cách nhất quán.
Nghĩa là IBM đã cải thiện đáng kể về training giữa hai thế hệ. Granite 4.0-H-Small không phải build kém — đó là thứ tốt nhất họ có lúc đó. Granite 4.1 8B là kết quả khi bạn dành thời gian giữa hai thế hệ để obsess về data quality thay vì chỉ scale params.
Ba kích cỡ, một obsession: cách họ build
Granite 4.1 có 3 size: 3B, 8B, 30B. Tất cả đều dùng cùng decoder-only dense transformer, cùng pipeline training, cùng data strategy. Khác biệt duy nhất là kích cỡ. Không có MoE routing, không sparse layers, không reasoning chains kéo dài làm phình token. Bạn gửi gì vào, model xử lý đúng cái đó — predictable mỗi lần.
Model dựa vào long reasoning trace khó cost-predict và khó latency-budget. Granite 4.1 bỏ tất cả những thứ đó by design. Nhưng architecture không phải là điểm chính. Điểm chính là 15 nghìn tỷ token họ train và mức độ kỹ lưỡng khi xử lý chúng.
IBM chạy 5 phase training riêng biệt, mỗi phase có data mixture khác, learning rate schedule khác, và mục tiêu khác:
- Phase 1: rộng — CommonCrawl 59%, code 20%, math 7%
- Phase 2: math nhảy lên 35%, code lên 30%
- Phase 3-4: blend chain-of-thought reasoning trajectories và instruction data với web content chất lượng cao nhất
- Phase 5: extend context window, cuối cùng là 512K tokens cho 8B và 30B
Hầu hết team chọn một data mix và giữ nguyên. IBM thay đổi 4 lần với chủ đích rõ ràng mỗi lần.
Filter loại bỏ data xấu trước khi nó gây hại
IBM dành đủ thời gian cho data quality pipeline đến mức nó xứng đáng được giải thích riêng.
Sau pre-training, họ cần biến base model thành thứ thực sự follow instructions reliably. Việc đó cần fine-tune trên ví dụ về good behavior. Nhưng các ví dụ xấu trong dataset đó không bị bỏ qua — chúng được học. Một câu trả lời hallucinated, một response ignore instruction, một calculation sai mà confident — model treat tất cả như signal.
Vì vậy IBM build filtering system trước khi một sample fine-tuning nào chạm vào model. LLM-as-Judge đánh giá mỗi assistant response trên 6 dimension: instruction following, correctness, completeness, conciseness, naturalness, calibration. Mỗi response được score, sample dưới threshold bị cắt. Nhưng một số thứ trigger automatic rejection bất kể score: hallucinations, false premises, incorrect computations. Không có partial credit.
Judge không đọc prompts hoặc user input riêng lẻ. Nó đánh giá những gì model nói given full context có sẵn. Trong RAG settings, nếu response không grounded trong document được retrieve, đó tính là hallucination. Trong tool-calling, output được check đối với tools cho phép và parameter schema.
Trên cùng đó, một rule-based pipeline riêng check structure như length, formatting, schema validation, deduplication trên toàn dataset. Mọi thứ đều logged và auditable.
Kết quả ra: 4.1 triệu sample. Nghe nhiều. Nhưng đó là 4.1 triệu được curate có chủ đích.
4 rounds RL và lý do họ cần tất cả
Đây là phần thú vị nhất của Granite 4.1 paper, vì nó honest về việc gì đó đã đi sai giữa training và cách họ fix.
Sau fine-tuning, IBM chạy reinforcement learning trong 4 stage tuần tự:
Stage 1: train model jointly trên 9 domain cùng lúc — math, science, logical reasoning, instruction following, structured output, text-to-SQL, temporal reasoning, general chat, in-context learning. Lý do làm tất cả cùng nhau: joint training ngăn model quên domain trước khi nó tốt hơn ở domain sau. Mỗi gradient update thấy full range tasks.
Stage 2: RLHF training trên general chat prompts dùng reward model để improve helpfulness. Hoạt động — AlpacaEval scores nhảy ~18.9 điểm so với fine-tuned checkpoint.
Rồi gì đó break. Stage RLHF, dù cải thiện chat quality, làm math benchmark scores giảm. Cả GSM8K và DeepMind-Math đều regress.
Stage 3: identity và knowledge calibration ngắn — khoảng 40 training step để stabilize cách model represent chính nó và những gì nó biết. Stage nhỏ, cải thiện đo được trên self-identification.
Stage 4: dedicated math RL run riêng để recover những gì RLHF đã làm hỏng. Hoạt động — GSM8K recover và vượt fine-tuned baseline ~3.8 điểm. DeepMind-Math recover ~23.5 điểm.
Benchmark
| Benchmark | Test gì | 3B | 8B | 30B |
|---|---|---|---|---|
| IFEval | Instruction following | 82.1 | 87.1 | 89.7 |
| BFCL V3 | Tool calling | 60.8 | 68.3 | 73.7 |
| GSM8K | Math reasoning | 87.0 | 92.5 | 94.2 |
| DeepMind-Math | Advanced math | 64.6 | 80.1 | 81.9 |
| EvalPlus | Coding | 67.1 | 80.2 | 82.7 |
| ArenaHard | Real-world chat | 37.8 | 69.0 | 71.0 |
| MMLU-Pro | General knowledge | 49.8 | 56.0 | 64.1 |
Bản 30B đứng top BFCL V3 chart của IBM với 73.7, vượt Gemma-4-31B (72.7). Bản 8B (68.3) vượt Granite 4.0-H-Small (64.7), và bản 3B (60.8) vẫn vượt Qwen3-8B (60.2) — model gấp đôi kích cỡ.
Về instruction following qua IFEval: Gemma dẫn đầu với 94.1, nói thẳng. Nhưng bản 8B (87.1) ngang Qwen3.5-9B (87.2), và bản 30B (89.7) vượt mọi Qwen model trên chart bất kể kích cỡ.
Bản 3B là câu chuyện thầm lặng. 82.1 IFEval, 87.0 GSM8K, 60.8 BFCL V3. Với param count đó, đây là số khó bỏ qua nếu bạn nghĩ về edge deployment hoặc cost-constrained inference.
Một caveat honest: comparison chart là của IBM, dùng evaluation harness của họ. Số tuyệt đối plausible và nhất quán với báo cáo third party, nhưng benchmark methodology luôn cần scrutiny. Đây là self-reported results.
512K context: làm sao mà không break short-context
Làm model handle 512K token là một vấn đề. Làm nó handle 512K mà không quên cách handle 4K là vấn đề khác và khó hơn.
IBM giải quyết bằng staged extension approach trong Phase 5. Họ không nhảy thẳng lên 512K. Đi 32K trước, rồi 128K, rồi 512K. Mỗi stage dùng cùng data mix như Phase 4 cho đến extension cuối, họ switch sang 80% books và 20% code repository data cho riêng bản 8B và 30B. Books và long code repos là natural long-context data — có structure mạch lạc qua hàng chục nghìn token, điều mà web data không có.
Sau mỗi extension stage, IBM làm model merge. Đây là phần bảo vệ short-context performance. Bằng cách merge long-context checkpoint với weights cũ thay vì cứ tiếp tục train, họ preserve behaviors model đã học ở length ngắn.
RULER benchmark (test xem long-context capability có thực hay chỉ superficial) cho thấy bản 8B base đạt 83.6 ở 32K, 79.1 ở 64K, 73.0 ở 128K. Bản 30B holds up tốt hơn: 85.2, 84.6, 76.7. Có degradation khi context tăng — expected và honest — nhưng score không rơi vực.
Bản 3B chỉ extend đến 128K, không phải 512K. Cần biết nếu long context là hard requirement.
Cách run
Cách nhanh nhất: Ollama. Pull size phù hợp hardware — bản 3B chạy thoải mái trên consumer machine, bản 8B cần thêm headroom, bản 30B cần GPU machine. Cả 3 đều có trên Hugging Face dưới ibm-granite.
Production use: vLLM và Transformers đều support out of the box. Muốn evaluate trước khi commit infrastructure local, IBM có model qua API của họ.
FP8 quantized variants đáng thử nếu memory bị constraint — khoảng nửa footprint với hiệu năng gần như nguyên vẹn.
Apache 2.0 toàn bộ — commercial use clean.
Ai nên quan tâm
Nếu bạn build cái gì cần reliable tool calling, predictable latency, và license không tạo headache pháp lý sau này, Granite 4.1 đáng look kỹ. Bản 8B là sweet spot — cạnh tranh thực sự với model tốn nhiều hơn để run, và honest đủ trong benchmark để bạn không gặp surprise lúc deploy.
Bản 3B thú vị cho edge use case hoặc tight inference budget. Bản 30B dành khi bạn cần ceiling và có hardware match.
Thứ IBM build ở đây là một production-first model family từ team rõ ràng dành nhiều thời gian fix vấn đề hơn là announce chúng. 4-stage RL pipeline catch và correct được mid-training regression là loại detail không tạo headlines nhưng tuyệt đối show up trong real-world reliability.