"เปรียบเทียบ Kimi K3 กับ GPT-5.6-SOL: ทดสอบคณิต ฟิสิกส์ และการเขียนโปรแกรมระดับยาก"
"ทดสอบ kimi-k3 และ gpt-5.6-sol ภายใต้ OpenAI-compatible API เดียวกันและพรอมป์ต์เดียวกัน โดยวัดเวลา stopping ของโหมด โจทย์ฟิสิกส์เรื่องโมเมนต์ความเฉื่อยของรอกที่มีล้อ และโจทย์เขียนโปรแกรมเรื

Kimi K3 เทียบกับ GPT-5.6-SOL: ทดสอบหนักด้านคณิตศาสตร์ ฟิสิกส์ และโปรแกรมมิง#


รอบนี้ไม่ได้ลองถาม-ตอบง่าย ๆ แต่กำหนดโจทย์สามข้อที่ต้องใช้เหตุผลต่อเนื่อง ได้แก่ โจทย์ความน่าจะเป็นที่มี pattern ซ้อนทับและโมเมนต์อันดับสอง, โจทย์ฟิสิกส์ที่มีโมเมนต์ความเฉื่อยของรอกและการเปลี่ยนเฟสเมื่อเชือกหย่อน, และโจทย์ Python ที่อาศัย closure, ความจุหลายวัน, กับ tie-break สามชั้น สองโมเดลใช้ interface เดียวกัน prompt เดียวกัน และเพดาน output ใกล้เคียงกัน โดยไม่เปิดใช้เครื่องมือหรือการเชื่อมต่ออินเทอร์เน็ต
สรุปก่อนเลย:
gpt-5.6-solตอบครบทั้งสามข้อ และคำตอบอ้างอิงในคณิตกับฟิสิกส์ถูกต้องkimi-k3ในรอบแรกที่จำกัด6500token คณิตกับฟิสิกส์จบด้วยfinish_reason=lengthและไม่มีคำตอบที่มองเห็นได้; พอเพิ่มเพดานคณิตเป็น10000ก็ยังถูกตัดกลางทาง ส่วนโจทย์โปรแกรมมิง timeout หลังประมาณ 245 วินาที- การ implement โค้ดของ GPT-5.6-SOL ผ่านการตรวจแยกอิสระเรื่อง dependency closure, capacity, tie-break, dependency ที่ผิดกติกา และวงจร dependency แต่ sample assertion แรกที่มันแนบมามี expected value ผิดอยู่เอง แปลว่า “ตัวฟังก์ชันถูก” กับ “ชุดทดสอบตัวอย่างถูกทั้งหมด” ต้องแยกตรวจคนละเรื่อง
ค่า latency ในบทความนี้คือค่าที่สังเกตได้จาก request รอบนี้ ไม่ได้หมายถึง SLA แบบคงที่ รอบแรกที่ยิงพร้อมกัน GPT ฝั่งคณิตและฟิสิกส์เคยได้ HTTP 408 มาก่อน แล้วค่อยเปลี่ยนไป retry แบบ sequential ดังนั้นความเร็วที่เห็นไว้ใช้ดูประสบการณ์เรียกใช้งานเท่านั้น ไม่ใช่เอาไปสรุปอันดับแบบเด็ดขาด
การตั้งค่าการทดสอบ#
เวลาทดสอบคือ 2026-07-17 ถึง 2026-07-18 ตามเวลา Beijing interface คือ:
POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2
รอบแรกตั้งค่าเหมือนกันทั้งหมด: คณิตและฟิสิกส์ max_tokens=6500, โปรแกรมมิง max_tokens=7500 ทุกโจทย์บังคับให้โมเดลแสดงวิธีทำที่ตรวจสอบย้อนกลับได้หรือโค้ดที่รันได้ และบันทึก finish_reason, completion/reasoning token, latency ของ request, ความถูกต้องเชิงตัวเลข และโค้ดสามารถรันเดี่ยวใน Python 3.11 ได้หรือไม่
ตารางผลลัพธ์รวม#
| งาน | kimi-k3 | gpt-5.6-sol | ข้อสรุป |
|---|---|---|---|
| คณิต: ค่าคาดหมายและความแปรปรวนของ HHTH | length,186.98 s,6500 tokens;ไม่มีเนื้อหาที่มองเห็นได้ | sequential retry stop,236.07 s,6872 tokens | GPT ตอบครบ; Kimi รอบแรกยังไม่สร้างคำตอบ |
| ฟิสิกส์: รอก, ตกถึงพื้น, สปริง | length,202.05 s,6500 tokens;ไม่มีเนื้อหาที่มองเห็นได้ | sequential retry stop,156.29 s,4501 tokens | GPT ครบและค่าตัวเลขถูกต้อง |
| โปรแกรมมิง: dependency closure knapsack | หลัง 245.54 s ได้ TimeoutError | stop,87.96 s,4514 tokens | โค้ด GPT รันได้; Kimi ไม่ได้โค้ดที่สมบูรณ์ |
| Kimi คณิตรอบทวนสอบ | length,286.99 s,10000 tokens | — | เพิ่มงบแล้วยังไม่จบ |
ในคำขอคณิตและฟิสิกส์ของ Kimi ค่า reasoning token ที่รายงานโดย interface อยู่แถว ๆ 6497 ส่วนคณิตรอบทวนสอบอยู่แถว ๆ 9997 ตรงนี้ไม่ได้แปลว่า Kimi ไม่มีความสามารถในการคิด แต่ชี้ว่าเมื่อเจอ prompt และ routing แบบนี้ งบ reasoning หมดได้ง่ายมาก จนฝั่งเรียกใช้งานไม่ได้คำตอบสุดท้าย
โจทย์คณิต: pattern ซ้อนทับไม่ได้กระทบแค่ค่าคาดหมาย แต่กระทบความแปรปรวนด้วย#
โจทย์คือ: ความน่าจะเป็นออกหัว p=3/5 ออกก้อย q=2/5 ทอยเหรียญไปเรื่อย ๆ จนเจอลำดับ HHTH ครั้งแรก โดยอนุญาตให้ pattern ซ้อนทับกัน จงหา E[T] และ Var(T).
สถานะของ prefix automaton ที่ถูกต้องคือ S0=คำนำหน้าเปล่า、S1=H、S2=HH、S3=HHT、S4=HHTH(สถานะดูดกลืน) การเปลี่ยนสถานะสำคัญคือ S2 --H--> S2 เพราะเมื่อมี HH อยู่แล้วถ้าออก H อีกครั้ง suffix ที่ยาวที่สุดยังคงเป็น HH ไม่ควรถอยกลับไปสถานะว่างแบบผิด ๆ
สมการโมเมนต์อันดับหนึ่งที่ GPT-5.6-SOL ตั้งไว้คือ:
M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0
เมื่อสร้างสมการโมเมนต์อันดับสองต่อ จะได้:
E[T] = 715/54 ≈ 13.2407407407
E[T²] = 195335/729 ≈ 267.9492455418
Var(T) = 270115/2916 ≈ 92.6320301783
ค่าคาดหมายยังตรวจสอบซ้ำแบบอิสระได้จากสูตรขอบเขตด้วย HHTH มี border ที่ไม่ว่างและเป็น proper border แค่ตัวอักษร H เดียว ดังนั้น E[T] = 1/p + 1/(p³q) = 715/54 คำตอบเต็มของ GPT ครอบคลุมทั้ง transition ของสถานะ, การขยายโมเมนต์อันดับสอง และ sanity check ไปพร้อมกัน ส่วน Kimi ที่จำกัด 6500 และ 10000 ไม่ได้แสดงวิธีทำที่มองเห็นได้ จึงยังให้คะแนนความถูกต้องเชิงคณิตไม่ได้ในรอบนี้ ทำได้แค่บันทึกว่า “ยังไม่เสร็จภายในงบ”
โจทย์ฟิสิกส์: พอชนพื้นแล้วข้อจำกัดขาด ห้ามฝืนใช้สมการพลังงานชุดเดิมต่อ#
โจทย์กำหนดว่า m_A=4.0 kg อยู่บนทางลาดหยาบ 25° โดยมี μ_k=0.18; m_B=3.0 kg แขวนอยู่; รอกมี M_p=1.2 kg、R=0.10 m; B ลงมา 1.50 m แล้วชนพื้น เชือกหย่อนทันที; A ไถลขึ้นต่ออีก 0.10 m แล้วไปแตะสปริง k=250 N/m; g=9.8 m/s².
ก่อนชนพื้น เชือกตึงและไม่ลื่น โมเมนต์ความเฉื่อยเชิงผลของรอกคือ I/R²=(1/2)M_p=0.60 kg เมื่อตั้งสมการร่วมของวัตถุทั้งสองกับสมการการหมุนของรอก จะได้:
a ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x ≈ 0.0835 m = 8.35 cm
หลังชนพื้น ความเร็วของ B ถูกการชนกับพื้นเปลี่ยนไป ขณะที่ A ยังมีความเร็วขึ้นตามทางลาด และรอกก็อาจยังหมุนต่อได้ แต่โจทย์ระบุชัดว่าเชือกหย่อนทันที ดังนั้นจึงใช้ v_A=v_B=Rω ต่อไม่ได้ ช่วงถัดไปต้องวิเคราะห์เฉพาะ A:
v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x
GPT-5.6-SOL ยังตรวจเช็กทั้งมิติหน่วย ระยะหยุดก่อนชนสปริง และความสอดคล้องระหว่างพลังงานสปริงกับการสูญเสียจากแรงเสียดทาน/แรงโน้มถ่วง ผลตัวเลขเข้ากันได้ดี ส่วน Kimi ในรอบแรกไม่มีคำตอบที่มองเห็นได้ จึงเทียบคุณภาพการตั้งโมเดลช่วงกลางทางไม่ได้

โจทย์โปรแกรมมิง: แกนหลักของอัลกอริทึมผ่านตรวจแยกอิสระ แต่ sample ของโมเดลมีบั๊ก#
โจทย์โปรแกรมมิงให้เขียน optimize_release_plan(items, capacity_by_day, dependencies) เพื่อจัดการความจุรายวัน ความจุของวันที่ไม่ได้กำหนดให้เป็น 0 dependency closure ทั้งทางตรงและทางอ้อม การตรวจ dependency ที่ผิดกฎและวงจร รวมถึง tie-break สามชั้นแบบ value → risk → รายการ id ที่เรียงแล้ว โดยมี items <= 18 ดังนั้นการ brute-force แบบ bitmask ถือเป็น baseline ที่เหมาะสม
GPT-5.6-SOL ใช้การ cache dependency closure และไล่ subset ทั้งหมด 2^n เราดึงโค้ดออกมาแล้วตรวจแยกอิสระใน Python 3.11 พบว่า dependency closure, sample ความจุหลายวัน, tie-break สามชั้น value/risk/id, ความจุของวันที่ไม่ได้กำหนด, dependency ที่ไม่มีอยู่จริง และวงจร dependency รวม 6 ชุดผ่านหมด
แต่ assert ตัวแรกที่โมเดลแนบไว้ท้ายโค้ดล้มเหลว: มันเขียน A -> B -> C แต่ยังใส่ X ที่มีมูลค่า 11 เข้าไปด้วย ภายใต้ความจุที่กำหนด B + C + X ให้มูลค่ารวม 13 ซึ่งสูงกว่า A + B + C ที่ได้ 12 ดังนั้นคำตอบที่ถูกต้องคือฟังก์ชันต้องคืน ['B', 'C', 'X'] การเขียน assert เป็น ['A', 'B', 'C'] จึงเป็นข้อผิดพลาดของ test fixture เอง
ประเด็นนี้สะท้อนให้เห็นชัดว่า งานโค้ดห้ามดูแค่ตัวฟังก์ชัน และก็ห้ามเชื่อว่าพอมี assert แนบมา 8 ข้อแล้ว test จะเชื่อถือได้โดยอัตโนมัติ ชุดทดสอบที่โมเดลสร้างขึ้นเองก็ยังต้องมีการตรวจโดยคนหรือด้วย reference implementation เช่นกัน ส่วนคำขอโปรแกรมมิงของ Kimi K3 timeout หลังประมาณ 245 วินาที และไม่ได้โค้ดที่สมบูรณ์กลับมา
สรุปรวม#
| มิติ | kimi-k3 | gpt-5.6-sol |
|---|---|---|
| ความสมบูรณ์ด้านคณิต | ทั้ง 6500/10000 token ถูกตัดกลางทาง ยังประเมินไม่ได้ | ค่าคาดหมาย, โมเมนต์อันดับสอง, ความแปรปรวน และ sanity check ครบ |
| การตั้งโมเดลฟิสิกส์ | รอบแรกถูกตัดกลางทาง | จัดการโมเมนต์รอก, เชือกหย่อน และช่วงสปริงได้ถูกต้อง |
| การส่งมอบโค้ด | รอบนี้ timeout | ตัวฟังก์ชันผ่านตรวจแยกอิสระ แต่มี assert ผิด 1 ตัว |
| ความเสถียรของ output | reasoning กินงบสูง จนมักไม่ได้คำตอบที่มองเห็นได้ | ทั้งสามโจทย์เมื่อ retry แบบ sequential ได้ stop |
| ความเร็วตอบกลับ | ประมาณ 187–246 s และมีอาการถูกตัด/timeout | คำขอที่สำเร็จอยู่ราว 88–236 s; รอบแรกแบบ concurrent มี 408 |
ข้อสรุปที่แม่นกว่าคำว่า “โมเดลไหนฉลาดกว่ากันแบบขาดลอย” คือ:
- ภายใต้ routing และงบประมาณรอบนี้ GPT-5.6-SOL มีแนวโน้มสรุปเหตุผลซับซ้อนได้จนเป็นคำตอบสุดท้ายมากกว่า เหมาะกับงานที่ต้องการอ่านคำอธิบายหรือโค้ดได้ทันที
- ปัญหาหลักของ Kimi K3 คือประสิทธิภาพในการแปลงงบ reasoning ให้กลายเป็น output ที่มองเห็นได้ แม้เพิ่มงบคณิตเป็น
10000token แล้วก็ยังไม่จบ - โค้ดของ GPT-5.6-SOL ก็ห้ามเชื่อแบบไม่ตรวจ มันผ่านตรวจฟังก์ชันหลัก แต่ test fixture ที่แนบมามีการคำนวณค่าผิด
- ถ้าจะเลือกใช้ในงานจริง ควรบันทึก
finish_reason, reasoning token, latency และผลทดสอบในเครื่องทุกครั้ง ไม่ควรดูแค่ประโยคสุดท้ายว่า “คำตอบถูก”
วิธีทำซ้ำการทดลอง#
สคริปต์ทดสอบและผลแบบ retry sequential ของรอบนี้ถูกเก็บไว้ที่ (รวมทั้งสรุปรอบ concurrent แรกที่ถูกเขียนลง output ของสคริปต์แล้ว):
.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json
ถ้าจะรันทวน แนะนำให้ล็อก model ID, prompt, temperature, max_tokens และระดับ concurrency ให้เหมือนเดิม แล้วบันทึก output แต่ละครั้งแยกไฟล์ไว้ต่างหาก โหลดของ upstream, cache hit และสถานะ rate limit ล้วนมีผลต่อ latency บทความนี้จึงบันทึกทั้ง HTTP 408, length และ read timeout ไว้เป็นผลการทดสอบด้วย โดยไม่ได้ตัดทิ้งไป






