API ของ Kimi K3 ดูเหมือนจะมีราคาถูกเมื่อดูจากตัวเลขเบื้องต้น แต่ค่าธรรมเนียมแฝงและรายละเอียดทางเทคนิคที่ขาดหายไปอาจทำให้มันมีราคาแพงกว่าที่ตัวเลขพาดหัวระบุไว้มาก

สิ่งที่กระแสความตื่นเต้นไม่ได้บอกคุณ

ข้อมูลเปิดตัวของ Moonshot AI อ้างว่ามีโมเดลขนาด 2.8 ล้านล้านพารามิเตอร์ (2.8 trillion-parameter) ที่ "ราคาถูก" และ "เปิดกว้าง" นอกจากนี้ในข่าวประชาสัมพันธ์ยังสัญญาว่าจะมีการปล่อย weights ให้ดาวน์โหลดในเร็วๆ นี้ แต่ทั้งสองคำกล่าวอ้างนี้ยังไม่มีอะไรยืนยันได้จริง

  • ยังไม่มีการปล่อย weights – Moonshot กำหนดเส้นตายวันที่ 27 กรกฎาคม 2026 สำหรับการปล่อย public checkpoint ซึ่งจนกว่าจะถึงเวลานั้น ผู้ใช้ต้องเรียกใช้งานผ่าน hosted API เท่านั้น ดังนั้นคำสัญญาเรื่อง "open-source" จึงยังไม่มีอะไรที่นำมาใช้งานได้จริง
  • พารามิเตอร์ 2.8 T ไม่ได้ถูกใช้งานทั้งหมด – ตัวเลขนี้อธิบายถึงความจุรวมของสถาปัตยกรรมเท่านั้น การออกแบบแบบ Mixture-of-Experts ของ K3 จะส่งแต่ละ token ผ่านเครือข่ายย่อยผู้เชี่ยวชาญ (expert sub-networks) เพียง 16 จาก 896 เครือข่าย ซึ่ง Moonshot ยังไม่ได้ระบุว่ามีพารามิเตอร์จำนวนเท่าใดที่ทำงานต่อหนึ่งคำขอ (request) ทำให้ไม่สามารถประเมินการใช้หน่วยความจำ (memory) และการประมวลผล (compute) ได้

ราคาที่ดูดี – จนกว่าคุณจะเริ่มนับจำนวนคำ

อัตราค่าบริการที่ประกาศไว้:

  • Input แบบ Cache-hit: $0.30 ต่อ 1 ล้าน tokens
  • Input แบบ Uncached: $3.00 ต่อ 1 ล้าน tokens
  • Output: $15.00 ต่อ 1 ล้าน tokens

อัตราเหล่านั้นดูเหมือนจะไม่แพง แต่พวกมันไม่ได้คำนึงถึงปริมาณ token

จากการทดสอบล่าสุดพบว่า K3 สร้าง output ออกมาถึง 130 ล้าน tokens ซึ่งมากกว่า 63 ล้าน tokens ที่โมเดลชั้นนำอื่นๆ ผลิตได้ในงานเดียวกันถึงกว่าสองเท่า ความเยิ่นเย้อของโมเดลส่งผลโดยตรงต่อค่าใช้จ่าย output ที่เพิ่มขึ้น—คำที่มากขึ้นสองเท่าหมายถึงค่าใช้จ่ายที่เพิ่มขึ้นสองเท่า สำหรับการเขียนโค้ด การเขียนเรียงความ หรือแชทบอท อัตรา $15 ต่อล้าน tokens อาจกลายเป็นค่าใช้จ่ายหลักที่สูงมาก

สิ่งนี้หมายความว่าอย่างไรสำหรับผู้ใช้กลุ่มต่างๆ

นักพัฒนาและนักวิจัย

หากคุณทดสอบ K3 เพื่อช่วยเขียนโค้ดหรือการวิจัยที่ขับเคลื่อนด้วยข้อมูล ควรมีการกำหนดเพดาน (hard caps) ของ token output ไว้ด้วย การทำ A/B test โดยเปรียบเทียบ K3 กับโมเดลมาตรฐาน (baseline model) ที่มีการจำกัด output เท่ากัน จะช่วยให้เห็นว่าการใช้ token ที่สูงขึ้นนั้นมาจากตัวโมเดลเองหรือมาจากการออกแบบ prompt

ทีมที่เน้นการควบคุมงบประมาณ

ส่วนลดแบบ cache-hit จะใช้ได้ก็ต่อเมื่อมีการใช้ input เดิมซ้ำๆ เท่านั้น ควรสร้าง prompt prefix ที่คงที่เพื่อให้ได้ input string ที่เหมือนกัน เพื่อผลักดันให้คำขอส่วนใหญ่ไปอยู่ในระดับราคา $0.30 ซึ่งวิธีนี้จะได้ผลเฉพาะกับงานที่มีรูปแบบซ้ำๆ กันสูงเท่านั้น (เช่น การใช้ query แบบเทมเพลต) ส่วน input ที่มีความหลากหลายส่วนใหญ่จะกลับไปใช้อัตรา uncached ที่ $3.00

บริษัทที่กำลังพิจารณาการทำ self-hosting

การรอให้มีการปล่อย checkpoint ออกมาเป็นทางเลือกที่ฉลาด การทำ self-hosting โมเดลจะช่วยตัดค่าธรรมเนียมต่อ token ออกไป แต่จะเพิ่มค่าใช้จ่ายด้านลิขสิทธิ์และโครงสร้างพื้นฐานที่ยังไม่เปิดเผย จนกว่า weights จะถูกปล่อยสู่สาธารณะ การใช้ hosted API ยังคงเป็นทางเลือกเดียวที่เป็นไปได้จริงในขณะนี้

สภาพแวดล้อมการใช้งานจริง (Production environments)

อย่าเพิ่งเปลี่ยนมาใช้เพียงเพราะราคาพาดหัวดูต่ำกว่าคู่แข่ง ควรทำการทดสอบนำร่อง (pilot) ที่วัด ต้นทุนต่อหนึ่งงานที่เสร็จสมบูรณ์ (cost per completed task) ซึ่งรวมถึงค่าใช้จ่ายแฝงจากคำตอบที่ยาวขึ้น แทนที่จะวัดแค่ต้นทุนต่อ token เท่านั้น เมื่อทำเช่นนี้แล้วคุณจึงจะตัดสินใจได้ว่า K3 ช่วยประหยัดเงินได้จริงหรือไม่

สิ่งที่ต้องจับตามองต่อไป

  • การปล่อย checkpoint ในวันที่ 27 กรกฎาคม 2026 – มีกำหนดการปล่อย weights ในวันดังกล่าว
  • การเปิดเผยจำนวน active-parameter – การทราบว่ามีพารามิเตอร์กี่ตัวจาก 2.8 T ที่ทำงานต่อหนึ่ง token จะช่วยให้ผู้ใช้สามารถเลือกขนาดฮาร์ดแวร์ได้อย่างแม่นยำ

บทสรุป

ราคา output ที่โฆษณาไว้ที่ $15 ต่อล้าน tokens ของ K3 บอกความจริงเพียงครึ่งเดียว แนวโน้มที่โมเดลจะสร้าง token ออกมามากกว่าคู่แข่งถึงสองเท่าสามารถล้างความประหยัดที่เห็นจากราคาพาดหัวไปจนหมด โดยเฉพาะอย่างยิ่งสำหรับงานที่ต้องตอบยาวๆ จนกว่าจะมีการปล่อย weights และมีความชัดเจนเรื่องจำนวน active-parameter ให้ปฏิบัติกับ K3 ในฐานะบริการระดับพรีเมียมที่อาจจะเยิ่นเย้อ มากกว่าที่จะมองว่าเป็นทางเลือกราคาถูก ควรทำการทดสอบงบประมาณ token กำหนดขีดจำกัด output และเปลี่ยนมาใช้ก็ต่อเมื่อคุณได้วัดต้นทุนที่แท้จริงต่อหนึ่งงานที่เสร็จสิ้นแล้วเท่านั้น