Granite 4.2 LLMs: เจาะลึกเบื้องหลังการสร้างโมเดลภาษาอัจฉริยะ
IBM Granite ได้เปิดตัว Granite 4.2 ซึ่งเป็นตระกูลโมเดลภาษาขนาดใหญ่ (LLMs) แบบ Dense, Decoder-only ที่เน้นความสามารถด้านการให้เหตุผล โดยมีให้เลือก 3 ขนาด คือ 3B, 8B และ 30B โมเดลเหล่านี้ได้รับการฝึกฝนตั้งแต่ต้นบนข้อมูลประมาณ 15 ล้านล้านโทเค็น ผ่านกลยุทธ์ 5 ระยะ ซึ่งขยายหน้าต่างบริบท (Context Window) ได้ถึง 512K โทเค็น พร้อมกับการ Fine-tuning แบบมีผู้สอน (Supervised Fine-Tuning - SFT) ด้วยข้อมูล Chain-of-Thought, การให้เหตุผล และ Agentic Trajectory และปิดท้ายด้วยการ Post-training ด้วย Reinforcement Learning (RL) แบบหลายขั้นตอน ซึ่งรวมถึง Agentic RL ที่โมเดล 8B และ 30B เรียนรู้การใช้งานเครื่องมือในสภาพแวดล้อมจำลองจริง โมเดล Granite 4.2 ทุกรุ่นมีฟังก์ชัน "Thinking/Non-thinking Switch" ที่ช่วยให้เลือกโหมดการคิดแบบประหยัดทรัพยากรสำหรับคำถามง่ายๆ และรองรับการเรียกใช้เครื่องมือ (Tool Calling) แบบ Native ทั้งหมดนี้เผยแพร่ภายใต้ลิขสิทธิ์ Apache 2.0
Granite 4.2: ความสามารถด้านการให้เหตุผลที่เหนือกว่า
Granite 4.2 คือการพัฒนาที่เน้นความสามารถด้านการให้เหตุผลของตระกูล Granite Language Model โดยรุ่นก่อนหน้ามีความโดดเด่นในการทำตามคำสั่ง (Instruction Following) ได้ดีเยี่ยม แต่ Granite 4.2 ได้เพิ่มความสามารถในการให้เหตุผลที่ชัดเจนเข้าไปด้วย ทุกโมเดลสามารถสร้าง "Chain of Thought" ก่อนตอบคำถาม และสามารถทำงานในโหมด "Thinking" หรือ "Non-thinking" ได้ ขึ้นอยู่กับความซับซ้อนของงาน นอกจากนี้ยังมีโหมด "Low-effort" ที่ใช้ทรัพยากรการคิดน้อยลงสำหรับคำถามที่ไม่ซับซ้อน
โมเดลทั้งสามขนาด (3B, 8B, 30B) มีสถาปัตยกรรมและการฝึกฝนที่เหมือนกัน ตั้งแต่ Pre-training, SFT ไปจนถึง Multi-stage RL โดยปรับตามขนาดของแต่ละโมเดล ทั้งหมดนี้มีความสามารถในการให้เหตุผลและทำตามคำสั่งที่แข็งแกร่ง จุดที่แสดงความแตกต่างชัดเจนที่สุดคือในขั้นตอน Post-training โดยโมเดล 8B และ 30B จะผ่านกระบวนการ Agentic RL เพิ่มเติม เพื่อเรียนรู้การทำงานแบบ Agent เช่น การเรียกใช้เครื่องมือ, การแก้ไขและรันโค้ด, การควบคุม Terminal และการค้นหาข้อมูลบนเว็บภายในสภาพแวดล้อมจริง ทุกโมเดลรองรับ Native Tool Calling และสามารถทำงานร่วมกับ API ที่เข้ากันได้กับ OpenAI (เช่น ผ่าน vLLM) โดยส่ง Tool Calls ในรูปแบบ OpenAI Function-Calling และสามารถเชื่อมต่อกับ Agentic Harnesses ได้โดยตรง นอกจากนี้ Granite 4.2 ยังรองรับการใช้งานบน SGLang อีกด้วย
สถาปัตยกรรมเบื้องหลัง Granite 4.2
โมเดล Granite 4.2 สร้างขึ้นบนสถาปัตยกรรม Transformer แบบ Dense Decoder-only ที่ประกอบด้วยส่วนประกอบหลักดังนี้:
- Attention: Grouped Query Attention (GQA) พร้อม 40 Attention Heads และ 8 KV Heads
- Position Embedding: Rotary Position Embedding (RoPE) โดยมีค่า θ = 10,000,000
- Feed-Forward: MLP พร้อม Activation SwiGLU
- Normalization: RMSNorm (ε = 1e-5)
- Embeddings: Input/Output Embeddings แยกกัน (ไม่ผูกติดกัน)
กระบวนการ Pre-training: วางรากฐานความรู้
Granite 4.2 ถูกฝึกฝนตั้งแต่ต้นบนข้อมูลประมาณ 15 ล้านล้านโทเค็น โดยใช้กลยุทธ์การฝึก 5 ระยะ:
- ระยะที่ 1-2: เน้นการ Pre-training พื้นฐาน
- ระยะที่ 3-4: การฝึกกลางทาง (Mid-training) โดยใช้ข้อมูลคุณภาพสูงที่ค่อยๆ ปรับปรุง
- ระยะที่ 5: การฝึก Long-Context เพื่อขยาย Context Window ให้ได้ถึง 512K โทเค็น
แต่ละระยะจะใช้ส่วนผสมของข้อมูล (Data Mixture) และตารางการเรียนรู้ (Learning-Rate Schedule) ที่แตกต่างกัน โดยค่อยๆ เปลี่ยนจากการใช้ข้อมูลขนาดใหญ่บนเว็บไปสู่แหล่งข้อมูลที่มีคุณภาพสูงขึ้น
Supervised Fine-Tuning (SFT): การปรับจูนเพื่อความสามารถที่เฉพาะเจาะจง
SFT เป็นขั้นตอนที่เปลี่ยนโมเดลพื้นฐานให้กลายเป็นผู้ช่วยที่สามารถทำตามคำสั่ง, ให้เหตุผล และใช้งานเครื่องมือได้อย่างน่าเชื่อถือ ชุดข้อมูล SFT ประกอบด้วยข้อมูล Agentic (31.6%) และ Non-agentic (68.4%) รวมประมาณ 7.2 ล้านตัวอย่าง หรือราว 100 พันล้านโทเค็น (โดยมี 65 พันล้านโทเค็นที่สามารถฝึกได้)
- คลังข้อมูล Agentic: ครอบคลุมหลากหลายโดเมน เช่น วิศวกรรมซอฟต์แวร์ (SWE, 69%), การเรียกใช้เครื่องมือ (12.1%), การใช้งาน Terminal (8.0%), คณิตศาสตร์ (3.5%), การค้นหา (0.8%) และการดำเนินการ (0.2%) ข้อมูลเหล่านี้สร้างขึ้นจาก Agent Scaffolds และ Harnesses ที่หลากหลาย เช่น OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex และ Goose ข้อมูล Agentic ผสมผสานระหว่างชุดข้อมูลโอเพนซอร์สและข้อมูลที่สร้างขึ้นเองจากสภาพแวดล้อม RL สังเคราะห์
- คลังข้อมูล Non-agentic: ประกอบด้วยหมวดหมู่หลัก เช่น การทำตามคำสั่ง (18.8%), การเขียนโค้ด (18.8%), คณิตศาสตร์ (14.6%), ภาษาต่างประเทศ (7.0%), วิทยาศาสตร์ (5.4%), การให้เหตุผล (3.0%) และความปลอดภัย (0.8%)
การควบคุมคุณภาพข้อมูล (Data Quality Control)
มีการใช้การควบคุมคุณภาพหลายขั้นตอนก่อนที่ตัวอย่างข้อมูลจะถูกนำเข้าสู่ SFT Mixture:
- การปรับรูปแบบข้อมูล: ข้อมูลจากแหล่งต่างๆ จะถูกทำให้เป็นมาตรฐานและจัดรูปแบบให้อยู่ในรูปแบบ OpenAI Chat ที่สอดคล้องกัน เพื่อให้โครงสร้างการสนทนาและการโต้ตอบกับเครื่องมือเป็นแบบเดียวกัน
- การใช้ LLM เป็นผู้ตัดสิน: ใช้ GPT-OSS-120B และ Gemma 4 เป็นผู้ตัดสินในการประเมินคุณภาพของตัวอย่างข้อมูล ตัวอย่างที่มีคะแนนต่ำจะถูกลบออก รวมถึงข้อมูลที่มีการหลอน (Hallucination) หรือข้อมูลที่ถูกสร้างขึ้น, การโต้ตอบกับเครื่องมือที่ไม่ถูกต้อง หรือการเรียกใช้เครื่องมือที่ไม่ได้ถูกกำหนดไว้ในรายการเครื่องมือที่เกี่ยวข้อง
- กฎ Heuristic เฉพาะ: ใช้กฎ Heuristic ที่ปรับให้เหมาะกับแต่ละชุดข้อมูลเพื่อปรับปรุงคุณภาพและลบแหล่งที่มาของ "Noise" ที่ทราบ
- การขจัดข้อมูลซ้ำซ้อน (Deduplication): ทำทั้งแบบ Local และ Global โดยใช้ SHA-256 Hash ที่คำนวณจากส่วนของเครื่องมือและข้อความ เพื่อลบตัวอย่างที่ซ้ำกันทั้งภายในแหล่งข้อมูลและทั่วทั้ง SFT Mixture
รายละเอียดการฝึก SFT
คลังข้อมูลทั้งหมดจะถูกสุ่ม (Globally Shuffled) ก่อน เพื่อลดผลกระทบจากลำดับการเรียง และรับประกันว่าตัวอย่างจากโดเมนต่างๆ จะถูกผสมผสานกันอย่างดีในการฝึก จากนั้นจะถูกแบ่งออกเป็น .parquet shards ที่มีขนาดเท่ากัน ซึ่งจะถูก Tokenized โดยใช้ Tokenizer ของโมเดลและ Chat Template และเตรียมพร้อมสำหรับการฝึกแบบกระจายขนาดใหญ่ (Large-scale Distributed Training)
ก่อนเริ่มการฝึกขนาดใหญ่ จะมีการปรับ Hyperparameters บนการตั้งค่าที่เป็นตัวแทน โดยทดสอบ Learning-Rate Schedules, Initial Learning Rates และ Warm-up Ratios เพื่อหาค่าที่ทำให้การฝึกมีเสถียรภาพในทุกขนาดของโมเดล
SFT ระยะที่ 2 สำหรับโมเดล 30B
สำหรับโมเดล 30B จะมีการทำ SFT ระยะที่สองเพิ่มเติม โดยเน้นเฉพาะ Agentic Coding โดยข้อมูล Agentic, SWE และ Coding จะถูก Upsample เพื่อเพิ่มการมีส่วนร่วมใน Distribution การฝึก ในขณะที่ประมาณ 16% ของ Mixture จะคงไว้เป็น Replay Data จาก SFT Corpus เดิม จากนั้นโมเดล 30B จะถูก Fine-tune อีกประมาณหนึ่ง Epoch ด้วย Learning Rate ที่ต่ำลง (3.0e-6) ระยะที่สองนี้ช่วยเพิ่มการเรียนรู้ของโมเดลเกี่ยวกับ Agentic Coding Trajectories โดยไม่สูญเสียความสามารถที่ได้รับจาก SFT ระยะแรก
Reinforcement Learning: กระบวนการหลายขั้นตอน หลายสภาพแวดล้อม
หลัง SFT จะใช้กระบวนการ Reinforcement Learning (RL) แบบหลายขั้นตอนและหลายสภาพแวดล้อม แทนที่จะเป็น RL Pass เดียว แต่ละขั้นตอนจะมุ่งเน้นความสามารถเฉพาะ เช่น คณิตศาสตร์, โค้ด, วิทยาศาสตร์, การทำตามคำสั่ง, การใช้เครื่องมือ, โครงสร้างเอาต์พุต, วิศวกรรมซอฟต์แวร์, การใช้ Terminal และการค้นหาเว็บ แต่ละขั้นตอนคือการรัน RL ที่เป็นอิสระ โดยใช้ Checkpoint จากขั้นตอนก่อนหน้าเป็นจุดเริ่มต้น (Warm-start)

รูปภาพ: หลักสูตร RL แบบเป็นขั้นตอน (Staged RL Curriculum) โดย Foundational RL (Verifiable Rewards + Skill Boosters) จะใช้กับทุกขนาด ส่วน Agentic RL Block (SWE → Terminal → Search) ใช้กับโมเดล 8B และ 30B เท่านั้น ทุกโมเดลจะจบด้วย RLHF แต่ละขั้นตอนคือการรัน GRPO ที่แยกกัน โดย Warm-start จาก Checkpoint ก่อนหน้า
วิธีการฝึก (Training Methodology)
ทุกขั้นตอนจะฝึกด้วย Asynchronous GRPO (Group Relative Policy Optimization) เพื่อไม่ให้ Generator และ Trainer บล็อกกันเอง โดย Pool ของ Generation Workers จะสุ่มสร้าง Response และส่ง Trajectories ที่เสร็จแล้วไปยัง Buffer ส่วนกลาง เมื่อ Buffer มีข้อมูลครบหนึ่ง Step, Trainer จะดึง Batch นั้นมา, ทำ Optimizer Step และสตรีม Parameter ที่อัปเดตกลับไปยัง Workers โดยไม่หยุดการทำงาน การ Refresh สามารถเกิดขึ้นระหว่าง Rollout ทำให้ Trajectory เดียวประกอบด้วย Policy สองเวอร์ชันที่อยู่ติดกันได้ โดยอนุญาตให้เกิดสิ่งนี้ขึ้นเพื่อประหยัดทรัพยากร Workers จะใช้ KV Cache เดิมโดยไม่ต้องสร้างใหม่หลังการ Refresh และมี Guardrail จำกัดไม่ให้ล้าหลัง Trainer เกินกว่าหนึ่ง Update เพื่อจำกัดความ Off-policy ของ Sample ใดๆ ส่วนความไม่ตรงกันที่เหลือจะถูกจัดการใน Objective ด้วย Truncated Importance Sampling ซึ่งจะจำกัดอัตราส่วน Log-Probability ระหว่าง Train กับ Generation ให้อยู่ในค่าคงที่ เพื่อป้องกันไม่ให้ Token ที่ล้าสมัยจำนวนเล็กน้อยมีอิทธิพลต่อการ Update มากเกินไป
Advantages จะเป็นแบบ Group-Relative โดยมี Leave-one-out Baseline คือแต่ละ Response จะถูกเปรียบเทียบกับค่าเฉลี่ย Reward ของ Sample อื่นๆ ที่สร้างขึ้นสำหรับ Prompt เดียวกัน ซึ่งช่วยลดความจำเป็นในการใช้ Value Network แยกต่างหาก ตัวอย่างเช่น ใน RLVR ซึ่งเป็น Stage แรกและยาวนานที่สุด แต่ละ Step จะจับคู่ 256 Prompts กับ 16 Sampled Responses ทำให้ได้ Batch ขนาด 4,096 ตัวอย่าง ซึ่ง Trainer จะใช้ในการทำ Optimizer Step เพียงครั้งเดียวก่อนที่ Rollout ถัดไปจะเริ่มขึ้น Stage ต่อๆ ไปจะใช้กลไกนี้เหมือนเดิม และปรับเฉพาะ Shape ของแต่ละ Stage เท่านั้น
Pipeline จะรักษา Backbone ของ Hyperparameters ทั่วทั้งทุก Stage ซึ่งช่วยให้การดำเนินงานและเปรียบเทียบหลักสูตรทำได้ง่ายขึ้น มี Knob จำนวนหนึ่งที่คงที่เสมอ:
| Parameter | 3B, 8B, 30B |
| :------------------ | :---------------------------------------- |
| Optimizer | AdamW |
| Learning Rate | 3.0e-5 |
| Warm-up Ratio | 0.03 |
| Weight Decay | 0.1 |
| Batch Size | 4096 (Global) |
| KL Coefficient | 0.1 (Default, adjusted by schedule) |
| Reward Type | Verifiable, Preference, Agentic Outcome |
| Reward Scaling | 1.0 |
| Value Loss Weight | 0.3 |
| Policy Loss Weight | 1.0 |
| Entropy Bonus | 0 (Default, adjusted by schedule) |
| Rollout Turns | 1024 (Default, adjusted by stage) |
| Max Seq Len | 4096 (Default, adjusted by stage) |
| Generation Batching | Yes |
| Replay Buffer Size | 1024 (Default, adjusted by stage) |
สิ่งที่เปลี่ยนแปลงไปในแต่ละ Stage คือ Shape ของแต่ละ Run: จำนวน Prompts และ Generations ต่อ Step, ความยาวของ Context, การทำงานของ Agent Loop และระดับการดึงกลับไปยัง Reference Policy ตารางด้านล่างแสดงการตั้งค่าที่แน่นอนสำหรับ Chain ของ
ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-granite/granite-4-2