คุยกับ AI ตอนที่ 10: เพิ่ม compute ให้ตอนฝึกหรือตอนตอบ

ตอนที่ 10 จาก 11 ตอนในชุด คุยกับ AI: จากการ Train LLM ถึง AGI

บันทึกบทสนทนาระหว่าง นพ.สุทธิศักดิ์ เด่นดวงใจ กับ ChatGPT-5.6 Reasoning Instant จากแชตต้นฉบับ คงคำอธิบายและตัวอย่างของ ChatGPT ไว้ โดยปรับหัวข้อ ตาราง และสัญลักษณ์สมการให้อ่านบนเว็บได้สะดวก

ดูสารบัญทั้งชุด

ผม: เล่าต่อ

ChatGPT-5.6 Reasoning Instant:

ได้ครับ คราวนี้มาถึงคำถามใหญ่ของวงการ AI:

ถ้ามี compute เพิ่ม 100 เท่า เราควรเอาไป Train สมองที่ใหญ่ขึ้น หรือให้สมองเดิมมีเวลาคิดและทดลองมากขึ้น?

คำตอบปัจจุบันคือ ต้องทำทั้งสองฝั่ง และนี่ทำให้คำว่า “Scaling” มีความหมายกว้างกว่า “เพิ่มจำนวน parameters” มาก 🧠📈

1. Scaling Law คืออะไร?

ยุคแรก ๆ นักวิจัยพบ pattern ที่น่าสนใจว่า เมื่อเพิ่ม

Model size ↑
Training data ↑
Training compute ↑

โดยจัดสัดส่วนอย่างเหมาะสม training/test loss มักดีขึ้นอย่างค่อนข้างเป็นระบบ

ภาพแบบง่าย:

Performance
    ↑
    │                  ●
    │              ●
    │          ●
    │      ●
    │   ●
    └────────────────────→ Compute

ไม่ได้หมายความว่าเพิ่ม GPU 10 เท่าแล้วฉลาด 10 เท่า แต่หมายความว่า ความสามารถบางด้านสามารถพัฒนาต่อได้อย่างคาดการณ์ได้เมื่อ scale เพิ่ม (อ่านขอบเขตของ scaling laws)

นี่เป็นเหตุผลสำคัญที่วงการกล้าลงทุนกับ training cluster ขนาดมหึมา

2. แต่เพิ่ม Parameters อย่างเดียวไม่พอ

สมมติเราสร้าง:

Model A
70B parameters
trained on 10T tokens

แล้วสร้าง:

Model B
700B parameters
trained on 10T tokens เท่าเดิม

ไม่ได้แปลว่า B จะใช้ capacity เพิ่มนั้นได้อย่างคุ้มค่า

เหมือนสร้างมหาวิทยาลัยใหญ่ขึ้น 10 เท่า แต่หนังสือในห้องสมุดเท่าเดิม 📚

จึงต้อง balance:

Model Size ↔ Data ↔ Compute

3. นี่นำไปสู่ Compute-optimal Training

คำถามกลายเป็น:

ถ้ามี budget C เท่านี้ ควรลงทุนกับ model size และจำนวน training tokens เท่าไร?

แทนที่จะถาม:

ทำ model ใหญ่ที่สุดเท่าที่ GPU ยัดไหวได้ไหม?

conceptually:

Compute Budget
     │
     ├── Model capacity
     │
     ├── Training tokens
     │
     └── Training duration

ต้องจัดสมดุล

โมเดลเล็กกว่าแต่ train ด้วยข้อมูลมากและดี อาจชนะโมเดลใหญ่กว่าที่ undertrained ได้

4. แล้วเราเริ่มชนกำแพง

การ scale pre-training มีราคาแพงขึ้นเรื่อย ๆ

ถ้าต้องการ:

More compute

คุณต้องมี:

More accelerators
More electricity
More cooling
More networking
More storage
More data
More engineering

แต่ที่หนักกว่าคือ ข้อมูลคุณภาพสูงไม่ได้เพิ่มอย่างไม่มีที่สิ้นสุด

Internet มีขนาดใหญ่มากก็จริง แต่:

Internet
≠
Infinite high-quality training data

มีทั้ง:

spam
duplicates
SEO sludge
wrong information
machine-generated content
low-quality code

ขยะดิจิทัลมีบุคลิกของมันเอง 🗑️

5. จึงเกิดคำถามใหม่

แทนที่จะถามเพียง:

เราจะสร้างสมองใหญ่ขึ้นได้อย่างไร?

เริ่มถาม:

ทำอย่างไรให้สมองที่เรามีใช้ computation ได้ฉลาดขึ้น?

ตรงนี้คือ Inference-time Scaling

6. Training-time vs Inference-time Scaling

แยกชัด ๆ:

Training-time

ใช้ compute ก่อน deploy

Data
 ↓
GPU cluster
 ↓
Train 3 months
 ↓
Model

หลัง train แล้ว ผู้ใช้ทุกคนได้ประโยชน์จาก weights ชุดนั้น

Inference-time

ใช้ compute ตอนผู้ใช้ถาม

Question
 ↓
Model
 ↓
Think / Search / Try / Verify
 ↓
Answer

โจทย์ง่ายใช้ compute น้อย

โจทย์ยากใช้มาก

นี่เป็นแนวคิดที่ทรงพลังมาก

7. สมมติให้โจทย์ Coding

โจทย์:

Implement parser X

วิธี A

โมเดลตอบครั้งเดียว:

Prompt
 ↓
Solution

อาจถูก 65%

แต่ถ้าให้มันสร้าง 10 solutions:

       Problem
          │
 ┌────────┼────────┐
 ↓        ↓        ↓
Sol A    Sol B   ... Sol J
 ↓        ↓         ↓
Tests    Tests     Tests
 │        │          │
FAIL     PASS       FAIL
          ↓
       choose B

อัตราสำเร็จอาจเพิ่มขึ้นมาก

weights ไม่เปลี่ยนแม้แต่นิดเดียว

สิ่งที่เพิ่มคือ:

Compute per problem

8. Best-of-N

นี่เป็นวิธีที่เข้าใจง่ายที่สุดของ inference scaling

แทน:

Generate 1 answer

ทำ:

Generate N answers
       ↓
Evaluate
       ↓
Choose best

ถ้าแต่ละ attempt มีโอกาสสำเร็จ p และสมมติว่า attempts ค่อนข้าง independent โอกาสที่อย่างน้อยหนึ่งอันสำเร็จคือ:

1 − (1 − p)ᴺ

เช่นสมมติแต่ละ attempt ถูก 50%:

หนึ่งครั้ง:

50%

5 ครั้ง:

1 − (0.5)⁵ = 96.875%

แต่ ตัวเลขนี้เป็นเพียง idealized example เพราะในโลกจริง attempts ไม่ independent และที่สำคัญระบบยังต้อง รู้ว่าอันไหนถูก

ตรงนี้ verifier เข้ามาอีกแล้ว

9. Verifier ทำให้ Scaling มีค่า

ถ้าเราสร้าง 100 คำตอบแต่ไม่รู้ว่าอันไหนถูก:

100 answers
    ↓
🤷

ไม่ได้ช่วยเท่าไร

แต่ถ้ามี:

Compiler
Unit tests
Proof checker
Simulator
Known answer
External data

เราสามารถ:

100 attempts
    ↓
Verifier
    ↓
3 pass
    ↓
select / further evaluate

จึงไม่น่าแปลกที่ coding, mathematics และ formal reasoning เป็นสนามสำคัญของ inference-time scaling

10. Search ก็เป็นรูปแบบหนึ่งของ Compute

สมมติโจทย์มีหลายทาง:

              Problem
                 │
        ┌────────┼────────┐
        ↓        ↓        ↓
      Path A   Path B   Path C
        │        │        │
       bad      maybe    maybe
                 │        │
              Path B1   Path C1
                 │        │
               good     dead end

แทนที่จะ commit กับ token path แรกทันที ระบบสามารถ explore alternatives

แนวคิดนี้เชื่อมกับวิธีเก่าแก่ใน AI:

Search

ดังนั้นสิ่งที่ดูเหมือนของใหม่มาก จริง ๆ กลับมาแตะรากของ AI แบบ classical อีกครั้ง

Neural Network
      +
Search
      +
Verification

เป็นส่วนผสมที่ทรงพลังมาก

11. Agent ก็เป็น Inference Scaling รูปแบบหนึ่ง

Coding agent ที่ทำ:

Read
 ↓
Think
 ↓
Edit
 ↓
Compile
 ↓
FAIL
 ↓
Think again
 ↓
Edit
 ↓
Compile
 ↓
PASS
 ↓
Tests
 ↓
FAIL
 ↓
Debug
 ↓
Fix
 ↓
PASS

กำลังใช้ compute มากกว่า:

Prompt → Answer

มหาศาล

แต่ compute นั้นสร้าง feedback จากโลกจริง

นี่สำคัญกว่าการคิดยาวเฉย ๆ

12. "คิดนาน" ไม่ได้ดีเสมอไป

นี่ต้องพูดตรง ๆ

ถ้าโมเดล reasoning ผิดตั้งแต่ต้น:

Wrong assumption
      ↓
Think harder
      ↓
Elaborate wrong reasoning
      ↓
Beautifully wrong answer

🔥

เพิ่ม compute อย่างเดียวจึงไม่พอ

ต้องมี:

Better search
Better feedback
Better verification
Better tools
Better training

ด้วย

13. Adaptive Compute จึงน่าสนใจ

ทำไมเราต้องใช้ compute เท่ากันทุกคำถาม?

"What is HTTP?"

กับ:

"Find a concurrency bug across this
400,000-line repository."

ไม่ควรมี budget เท่ากัน

แนวคิดที่ดีกว่าคือ:

                 Request
                    ↓
              Estimate difficulty
               ↙          ↘
             Easy          Hard
              ↓             ↓
        small compute    large compute
              ↓             ↓
           answer       reason/tools/
                         verify/iterate

นี่คือเหตุผลว่าทำไมแนวคิดเรื่อง reasoning effort มีความหมาย

14. ตอนนี้เกิด Trade-off ใหม่

สมมติเรามีโมเดล:

Model BIG

ราคา inference:

$$$$

กับ:

Model SMALL
+
Tools
+
Search
+
Reasoning
+
Verifier

ราคา:

$$

แต่บางงาน performance ใกล้กัน

ตัวเลือกหลังอาจคุ้มกว่า

ดังนั้นการแข่งขัน AI ไม่ใช่แค่:

ใครสร้าง neural network ใหญ่ที่สุด?

แต่เป็น:

ใครสร้าง intelligence stack ที่มีประสิทธิภาพที่สุด?

15. Distillation ยิ่งทำให้เรื่องสนุกขึ้น

สมมติมีโมเดลใหญ่:

Teacher

ที่ reasoning เก่งแต่แพง

เราสามารถใช้มันช่วยสร้างข้อมูลสำหรับ model เล็ก:

Teacher
   ↓
high-quality examples
solutions
feedback
reasoning behaviors
   ↓
Student training
   ↓
Smaller model

เรียกแนวคิดกว้าง ๆ ว่า distillation

ผลคือความสามารถบางส่วนจากระบบแพงสามารถถูกถ่ายทอดลงโมเดลที่ถูกกว่าได้

16. วงจรเริ่มเป็น Flywheel

นี่น่าสนใจมาก:

Strong Model
     ↓
Generate better synthetic data
     ↓
Verify / filter
     ↓
Train next model
     ↓
Stronger Model
     ↓
Generate even better data
     ↓
...

แต่ไม่ได้หมายความว่าจะวนแล้วกลายเป็น superintelligence อัตโนมัติ เพราะยังมีปัญหา:

error accumulation
diversity
verification
grounding
compute
data quality
evaluation

17. Hardware ก็พัฒนาไปพร้อมกัน

อีกด้าน:

Better GPU/accelerator
        ↓
Cheaper training
        ↓
Bigger/better models
        ↓
More AI demand
        ↓
More accelerator investment

และ inference optimization:

Quantization
KV-cache optimization
Speculative decoding
Better kernels
Better batching
MoE

ทำให้ model เดิมให้บริการได้ถูกและเร็วขึ้น

ดังนั้น capability/price สามารถดีขึ้นแม้ architecture หลักยังเป็น Transformer

18. นี่ตอบคำถามว่า "ทำไม AI พัฒนาเร็ว?"

เพราะไม่ได้มีคันโยกเดียว

แต่มีหลายคันโยกทำงานพร้อมกัน:

                 AI Capability
                       ↑
        ┌──────────────┼──────────────┐
        │              │              │
   Better Data    Better Training   Better Models
        │              │              │
        ├──────────────┼──────────────┤
        │              │              │
     Better RL     Better Tools    Better Search
        │              │              │
        ├──────────────┼──────────────┤
        │              │              │
 Better Hardware  Better Serving  More Test-time
                                    Compute

ถ้าแต่ละอย่างดีขึ้นปีละนิด ผลรวมอาจดูเหมือนกระโดดแรงมาก

19. และมีอีกตัวที่สำคัญมาก: Algorithmic Efficiency

สมมติปี 2024 ต้องใช้:

100 units of compute

เพื่อ performance ระดับ X

ต่อมา algorithm/training recipe ดีขึ้นจนใช้:

20 units

ได้ performance X เท่าเดิม

เท่ากับ hardware ของเรา ดูเหมือนเร็วขึ้น 5 เท่า สำหรับงานนั้น โดยไม่เปลี่ยน transistor เลย

จึงมีสองเส้นที่วิ่งพร้อมกัน:

Hardware efficiency    ↑
Algorithmic efficiency ↑

และเมื่อคูณกัน ผลกระทบรุนแรงมาก

20. นี่ทำให้ "จำนวน Parameters" เริ่มเป็น metric ที่หลอกตา

เมื่อก่อนคนถาม:

GPT รุ่นนี้กี่ billion parameters?

คำถามนี้ยังมีความหมาย แต่ไม่พอแล้ว

สมมติ:

Model A
1 trillion total parameters
MoE
50B active/token

กับ:

Model B
200B dense
200B active/token

แค่บอก:

A = 1T
B = 200B

แล้วสรุป A เก่งกว่า 5 เท่าไม่ได้เลย

ต้องดู:

Architecture
Active parameters
Training tokens
Data quality
Training compute
Post-training
RL
Inference compute
Tools
Context
Evaluation

จำนวน parameter ตัวเดียวแทบเหมือนบอกว่า:

“รถคันนี้เครื่อง 3,000 cc เพราะฉะนั้นเร็วกว่าทุกคัน 1,500 cc”

ไม่พอครับ 🏎️

ตอนนี้ภาพ AI ทั้งหมดที่เราเดินมาด้วยกันเป็นแบบนี้

                        DATA
                         │
                         ▼
                   PRE-TRAINING
                         │
                         ▼
                     BASE LLM
                         │
                         ▼
                  POST-TRAINING
                  SFT / RL / etc.
                         │
                         ▼
                 REASONING MODEL
                         │
═════════════════════════╪════════════════════════
                         │
                     INFERENCE
                         │
             ┌───────────┼───────────┐
             ↓           ↓           ↓
          Context      Memory       RAG
             │           │           │
             └───────────┼───────────┘
                         ↓
                       MODEL
                         │
                ┌────────┼────────┐
                ↓        ↓        ↓
              Think    Search    Tools
                │        │        │
                └────────┼────────┘
                         ↓
                      Observe
                         ↓
                       Verify
                         ↓
                     Good enough?
                      ↙       ↘
                    No         Yes
                    │           │
                    └──↺      Answer

และตอนนี้เรามาถึงคำถามที่ผมว่า น่าสนใจที่สุดของซีรีส์นี้แล้ว:

ถ้าเราทำ Train → Reason → Tool use → Agent → Verification ได้ดีขึ้นเรื่อย ๆ แล้ว อะไรคือความแตกต่างระหว่าง LLM ที่ “เก่งมาก” กับ AGI?

ตรงนั้นต้องแกะคำว่า AGI ก่อน เพราะคนใช้คำนี้มั่วมาก ตั้งแต่ “ChatGPT ที่เก่งขึ้นหน่อย” ไปจนถึง “AI ที่แทนมนุษย์ทุกอาชีพได้” ซึ่งเป็นคนละเกณฑ์กันเลย 🤖🧩

หมายเหตุประกอบการอ่าน

หมายเหตุเพิ่มเติมจากบทสนทนา: Scaling laws แบบคลาสสิกเป็นความสัมพันธ์เชิงประจักษ์ของค่า loss ภายใต้ขอบเขตการทดลองที่กำหนด ไม่ได้รับประกันว่าความสามารถปลายทางทุกชนิดหรือทุก benchmark จะดีขึ้นอย่างราบรื่นเมื่อเพิ่มขนาดโมเดล ข้อมูล หรือ compute

อ่านงานวิจัยต้นฉบับ: Scaling Laws for Neural Language Models

← ตอนก่อนหน้า: จาก LLM สู่ระบบ AI และ Agent

ตอนถัดไป: จาก LLM ที่เก่งขึ้นไปสู่คำถามเรื่อง AGI →

อ่านทั้งชุด

กลับไปหน้าบันทึกและบทความ