Kimi Code เพิ่มโมเดล k3-256k — ผลลัพธ์เท่าเดิมในคอนเท็กซ์ 256K แต่กินโควตาครึ่งเดียวของ K3 ตัว 1M

หลังจาก Moonshot AI ปล่อยน้ำหนักของ Kimi K3 ออกมาเมื่อวันที่ 27 กรกฎาคม (ซึ่งเราเขียนถึงไปแล้ว) คำถามที่ตามมาสำหรับคนที่ใช้งานจริงผ่าน Kimi Code ไม่ใช่ “โมเดลเก่งแค่ไหน” แต่เป็น “จ่ายโควตาเท่าไหร่ต่องานหนึ่งชิ้น” ล่าสุดเอกสารของ Kimi Code เพิ่ม model ID ใหม่ชื่อ k3-256k เข้ามา พร้อมคำแนะนำที่ตรงไปตรงมาผิดกับสไตล์หน้าเอกสารผลิตภัณฑ์ทั่วไป

“k3-256k is now available. Within 256k context, it delivers the same results. k3 (1M) consumes about twice as much quota.”

แปลได้ว่า: ถ้างานของคุณอยู่ในคอนเท็กซ์ 256K อยู่แล้ว การเรียก K3 ตัว 1M คือการจ่ายโควตาเป็นสองเท่าโดยไม่ได้อะไรกลับมา หน้าเอกสารนี้ขึ้นอันดับต้น ๆ ของ Hacker News เมื่อวันที่ 29 กรกฎาคม 2026 ด้วยคะแนนกว่า 440 — ซึ่งบอกอะไรบางอย่างว่านักพัฒนาสนใจเรื่องต้นทุนต่อโทเคนไม่แพ้เรื่องคะแนนเบนช์มาร์ก

ตารางโมเดลใน Kimi Code ตอนนี้

เอกสารระบุสี่ตัวเลือก แยกตามระดับสมาชิก:

model ID	โมเดล	คอนเท็กซ์	ระดับสมาชิก
k3	Kimi K3 (2.8T params)	ถึง 1M สำหรับ Allegretto ขึ้นไป, 256K สำหรับ Moderato	Moderato ขึ้นไป
k3-256k	Kimi K3	256K คงที่	Moderato ขึ้นไป
kimi-for-coding	K2.7 Code	256K	ทุกระดับ
kimi-for-coding-highspeed	K2.7 Code HighSpeed	256K	Allegretto ขึ้นไป

จุดที่ควรสังเกตคือ k3 กับ k3-256k เป็นโมเดลเดียวกัน ต่างกันที่เพดานคอนเท็กซ์และการคิดโควตาเท่านั้น ทั้งคู่ตั้งค่า reasoning ได้สามระดับ (low / high / max ค่าเริ่มต้นคือ high) ความแตกต่างเล็ก ๆ อีกข้อคือมัลติโมดัล — k3 รับทั้งภาพและวิดีโอ ส่วน k3-256k รับเฉพาะภาพ ถ้าเวิร์กโฟลว์ของคุณต้องป้อนวิดีโอเข้าไป ตัว 256K จะใช้ไม่ได้

อีกตัวที่มักถูกมองข้ามคือ HighSpeed ของ K2.7 ซึ่งให้เอาต์พุตเร็วกว่าราว 5–6 เท่า แต่กินโควตา 3 เท่า — เป็นการแลกที่คุ้มเฉพาะตอนที่คุณนั่งรอผลอยู่หน้าจอจริง ๆ ไม่ใช่งานแบตช์ที่ปล่อยทิ้งไว้ได้

ทำไม “คอนเท็กซ์ยาวขึ้น” ไม่ได้แปลว่า “ดีขึ้น”

สิ่งที่เอกสารนี้พูดออกมาตรง ๆ คือสิ่งที่คนสร้าง agent รู้กันมาสักพักแล้วแต่ผู้ขายไม่ค่อยเขียนไว้บนหน้าโปรโมต: หน้าต่างคอนเท็กซ์ที่ใหญ่ขึ้นคือเพดาน ไม่ใช่โบนัส การมีเพดาน 1M ไม่ได้ทำให้โมเดลตอบดีขึ้นเมื่องานจริงใช้แค่ 80K และในโมเดลจำนวนมาก การยัดคอนเท็กซ์เข้าไปเยอะ ๆ กลับทำให้คุณภาพแย่ลงด้วยซ้ำ

เรื่องนี้สอดคล้องกับเบนช์มาร์ก HANDBOOK.md ที่เราเขียนถึงไปเมื่อเช้านี้ ซึ่งพบว่าโมเดลระดับ frontier ทำตามเอกสารนโยบายยาว ๆ ที่อยู่ใน context ได้แย่อย่างน่าตกใจ — ตัวที่ดีที่สุดผ่านแค่ 36.2% ถ้าโมเดลยังใช้ข้อมูลใน 100 หน้าที่คุณป้อนไปได้ไม่ครบ การจ่ายเพิ่มเพื่อให้ป้อนได้ 1,000 หน้าก็ยิ่งเป็นการจ่ายเพื่อความสบายใจมากกว่าเพื่อผลลัพธ์

มุมมอง AI Curator

ข่าวนี้เล็กมากในเชิงเทคนิค — ไม่มีโมเดลใหม่ ไม่มีสถาปัตยกรรมใหม่ มีแค่ model ID เพิ่มมาหนึ่งบรรทัดในหน้าเอกสาร แต่ผมคิดว่ามันมีค่าที่จะบันทึกไว้ด้วยเหตุผลสองข้อ

ข้อแรก นี่คือการลดค่าใช้จ่ายลงครึ่งหนึ่งที่นักพัฒนาไทยทำได้วันนี้เลยโดยแก้ config บรรทัดเดียว สำหรับทีมเล็กหรือ freelance ที่จ่ายค่าสมาชิก Kimi เป็นเงินบาทจากกระเป๋าตัวเอง ส่วนต่างสองเท่าของโควตาไม่ใช่เรื่องเล็ก ลองดูว่างานที่ทำอยู่จริง ๆ กินคอนเท็กซ์เท่าไหร่ก่อน — ผมเดาว่าโปรเจกต์ส่วนใหญ่ที่ไม่ใช่ monorepo ขนาดยักษ์แทบไม่เคยแตะ 256K ด้วยซ้ำ ถ้าใช่ การอยู่บน k3 ตัว 1M คือการจ่ายค่าประกันที่ไม่เคยเคลม

ข้อสอง และสำคัญกว่า: การที่ผู้ขายเขียนเองว่า “รุ่นแพงกว่าให้ผลเท่ากัน” เป็นเรื่องที่หาได้ยาก อุตสาหกรรมนี้เดินมาทางตรงข้ามมาตลอดสองปี — แข่งกันประกาศตัวเลขคอนเท็กซ์ให้ใหญ่ขึ้นเรื่อย ๆ เป็นตัวชี้วัดความก้าวหน้า ทั้งที่เอาเข้าจริงมันคือสเปกที่ผู้ใช้ส่วนใหญ่ไม่ได้ใช้ การที่ Moonshot เลือกจะแยกรุ่นถูกออกมาและบอกตรง ๆ ว่าให้ใช้ตัวนี้เถอะ เป็นสัญญาณว่าตลาดโมเดลกำลังโตพอที่จะเริ่มแข่งกันที่ “ราคาต่อผลลัพธ์” แทน “ตัวเลขบนสเปกชีต”

สิ่งที่อยากให้จับตาต่อคือผู้ให้บริการรายอื่นจะทำตามไหม ตอนนี้การกำหนดราคาตามหน้าต่างคอนเท็กซ์ยังเป็นเรื่องที่ผู้ใช้ต้องไปคำนวณเองแทบทั้งหมด ถ้าเจ้าใหญ่เริ่มแยกรุ่นตามคอนเท็กซ์แบบนี้อย่างชัดเจน คนที่ได้ประโยชน์ที่สุดคือทีมในภูมิภาคที่ต้นทุน API เป็นสัดส่วนใหญ่ของงบพัฒนา ซึ่งรวมถึงบ้านเราด้วย

แหล่งข่าว

• Kimi Code — Models (เอกสารทางการ)
• Kimi K3-256k — การพูดคุยบน Hacker News (29 ก.ค. 2026)