Kimi K3-256k

• Kimi K3-256k เป็นโมเดลสำหรับงานเขียนโค้ดประจำวัน ที่รักษาคุณภาพผลลัพธ์ของ K3 ไว้ในคอนเท็กซ์ 256k ขณะเดียวกันใช้ โควตาประมาณครึ่งเดียว เมื่อเทียบกับ k3 ที่มีคอนเท็กซ์ 1M
• Kimi Code ให้บริการ K3 และ K2.7 Code ผ่าน model ID 4 รายการ โดย k3 มีพารามิเตอร์ 2.8T และรองรับคอนเท็กซ์สูงสุด 1M ส่วน kimi-for-coding-highspeed ให้เอาต์พุตเร็วขึ้นประมาณ 5–6 เท่า แต่ใช้โควตา 3 เท่า
• เมื่อเปลี่ยนจาก k3 เป็น k3-256k หากคอนเท็กซ์เดิมเกิน 256k หรือมีวิดีโอรวมอยู่ ต้องรัน compact ก่อน เพื่อรักษาข้อมูลสำคัญไว้พร้อมคงความเข้ากันได้
• เมื่อเปลี่ยนโมเดลหรือ reasoning_effort แคชคอนเท็กซ์เดิมจะใช้ไม่ได้ และต้องพรีฟิลใหม่ ทำให้การใช้งานเพิ่มขึ้นได้ จึงแนะนำให้เปลี่ยนในเซสชันใหม่
• โมเดลและคอนเท็กซ์ที่ใช้งานได้แตกต่างกันตามแพ็กเกจ หากเกินสิทธิ์จะได้ 401 ในเครื่องมือ third-party ต้องตั้งค่า model ID ที่ถูกต้อง รวมถึงขนาดคอนเท็กซ์และระดับการอนุมานด้วยตนเอง

---

โครงสร้างโมเดลของ Kimi Code

• Kimi Code ให้บริการ Kimi K3 และ Kimi K2.7 Code ผ่าน model ID 4 รายการ
  • k3: โมเดลเขียนโค้ดเรือธงที่มีพารามิเตอร์ 2.8T และรองรับคอนเท็กซ์สูงสุด 1M ในแพ็กเกจระดับสูง
  • k3-256k: เวอร์ชันคอนเท็กซ์ 256k ของ Kimi K3 ที่เน้นลดการใช้งาน
  • kimi-for-coding: Kimi K2.7 Code ที่เหมาะกับ code completion และงานพัฒนาทั่วไป
  • kimi-for-coding-highspeed: K2.7 Code HighSpeed ที่ให้เอาต์พุตเร็วขึ้นประมาณ 5–6 เท่า ด้วยความสามารถด้านโค้ดเท่ากัน
• สเปกและเงื่อนไขการใช้งานของแต่ละโมเดลมีดังนี้
  • k3
    • ทำงานที่ความเร็วปกติ และให้ คอนเท็กซ์สูงสุด 1M แก่สมาชิกระดับสูง
    • reasoning_effort รองรับ low, high, max และค่าเริ่มต้นคือ high
    • ใช้งานได้ตั้งแต่ Moderato ขึ้นไป และคอนเท็กซ์ 1M ให้บริการตั้งแต่ Allegretto ขึ้นไป
    • รับอินพุตเป็นรูปภาพและวิดีโอได้
  • k3-256k
    • ทำงานที่ความเร็วปกติ และคอนเท็กซ์ถูก ตรึงไว้ที่ 256k
    • reasoning_effort รองรับ low, high, max และค่าเริ่มต้นคือ high
    • สมาชิกตั้งแต่ Moderato ขึ้นไปใช้งานได้
    • รับอินพุตได้เฉพาะรูปภาพ ไม่รองรับวิดีโอ
  • kimi-for-coding
    • ให้ความเร็วปกติและคอนเท็กซ์ 256k สมาชิกทุกระดับใช้งานได้
    • ทำงานด้วย Thinking:ON และรองรับรูปภาพกับวิดีโอ
  • kimi-for-coding-highspeed
    • สร้างเอาต์พุตเร็วขึ้นประมาณ 6 เท่าในคอนเท็กซ์ 256k แต่ ใช้โควตา 3 เท่า
    • ใช้งานได้ตั้งแต่ Allegretto ขึ้นไป และรองรับ Thinking:ON รวมถึงอินพุตรูปภาพ·วิดีโอ

การใช้งาน K3-256k และการสลับโมเดล

• k3-256k ให้ผลลัพธ์เช่นเดียวกับ k3 ภายในช่วงคอนเท็กซ์ 256k ขณะเดียวกันใช้โควตาประมาณครึ่งเดียวเมื่อเทียบกับเวอร์ชัน 1M
• เหมาะกับถามตอบทั่วไป, code completion, การพัฒนาฟีเจอร์ทั่วไป, การแก้ไขไฟล์เดี่ยวหรือไฟล์ขนาดเล็ก แต่ ไม่รองรับอินพุตวิดีโอ

• เปลี่ยนจาก K3 เป็น K3-256k

  • หากคอนเท็กซ์เซสชันปัจจุบันเกิน 256k เครื่องมือบางตัว เช่น Kimi Code CLI และ Claude Code จะทำ compact เอง
  • เพราะเครื่องมือเอเจนต์แต่ละตัวจัดการต่างกัน จึงแนะนำให้รัน compact ด้วยตนเองหนึ่งครั้งก่อนเปลี่ยน เพื่อบีบอัดคอนเท็กซ์ให้อยู่ภายใน 256k
  • วิธีนี้ช่วยคงเซสชันไว้พร้อมรักษาเนื้อหาสำคัญของงาน
  • หลังเปลี่ยนแล้วจะใช้โควตาได้นานขึ้น
  • หากประวัติการสนทนามีไฟล์วิดีโอ จะไม่สามารถเปลี่ยนเป็น k3-256k โดยตรงได้ จึงต้องรัน compact ก่อน

• เปลี่ยนจาก K3-256k เป็น K3

  • หาก k3-256k ใกล้ถึงขีดจำกัด 256k และต้องการหลีกเลี่ยงการสูญเสียข้อมูลจาก compact สามารถเปลี่ยนเป็น k3 1M ได้โดยตรง
  • ในเวอร์ชันปัจจุบัน การเปลี่ยนจาก 256k เป็น 1M ไม่มีผลต่อแคช

การจัดการแคชและการใช้งาน

• เมื่อเปลี่ยนโมเดล แคชคอนเท็กซ์ที่สร้างไว้ในโมเดลก่อนหน้าจะไม่ hit จึงต้องพรีฟิลคอนเท็กซ์นั้นใหม่
• ด้วยเหตุนี้ หลังเปลี่ยนทันทีอาจดูเหมือนการใช้งานเพิ่มขึ้น เมื่อใช้โมเดลใหม่ การเริ่มเซสชันใหม่มักให้ผลลัพธ์ดีกว่าและใช้ทรัพยากรน้อยกว่า

• ต้นทุนของการเปลี่ยนระดับการอนุมาน

  • แม้เปลี่ยน reasoning_effort แคชคอนเท็กซ์เดิมก็จะใช้ไม่ได้ และต้องพรีฟิลใหม่
  • แนะนำให้เลือกระดับการอนุมานที่เหมาะกับงาน แล้วคงไว้ให้สม่ำเสมอภายในเซสชันเดียว
  • หากจำเป็นต้องใช้ระดับการอนุมานอื่นจริง ๆ ควร เริ่มเซสชันใหม่ แทนการสลับไปมาซ้ำ ๆ ในเซสชันยาว

สิทธิ์ตามแพ็กเกจและข้อผิดพลาด 401

• แม้ใช้ model ID ถูกต้อง แต่หากฟีเจอร์ที่ร้องขอเกินสิทธิ์ของแพ็กเกจ เซิร์ฟเวอร์จะส่ง 401 กลับมา
  • ไม่มีสิทธิ์เข้าถึง K3: แพ็กเกจต่ำกว่า Moderato ไม่สามารถเรียก k3 และ k3-256k ได้
  • ไม่มีสิทธิ์เข้าถึง 1M: ใน Moderato k3 รองรับได้สูงสุด 256k ส่วนสูงสุด 1M ใช้ได้ตั้งแต่ Allegretto ขึ้นไป
  • ขีดจำกัดคอนเท็กซ์ของ k3-256k ถูกตรึงไว้ที่ 256k ไม่ขึ้นกับแพ็กเกจ
  • ไม่มีสิทธิ์เข้าถึง HighSpeed: kimi-for-coding-highspeed ต้องใช้ Allegretto ขึ้นไป
• ดูข้อความผิดพลาดแบบเต็มและวิธีจัดการได้ที่ Error Reference

เหตุผลที่ HighSpeed อาจไม่รู้สึกว่าเร็ว

• model ID ของ HighSpeed ต้องเป็น kimi-for-coding-highspeed อย่างถูกต้อง
  • หากป้อนผิด อาจถูกแทนด้วย kimi-for-coding มาตรฐานโดยไม่มีข้อผิดพลาด ทำให้ไม่เห็นความเร็วเพิ่มขึ้น
• HighSpeed เร่งเฉพาะเอาต์พุตของโมเดล
  • การอ่าน·เขียนไฟล์, การเรียกคำสั่ง และการรันสคริปต์จะไม่เร็วขึ้น
  • หากในงานหนึ่งรอบมีสัดส่วนการใช้เครื่องมือหรือรันสคริปต์สูง ความเร็วโดยรวมที่เพิ่มขึ้นอาจรู้สึกได้น้อย

การเปลี่ยนโมเดลในไคลเอนต์

• เมื่อเปลี่ยน model ID แคชคอนเท็กซ์จะใช้ไม่ได้ เพื่อหลีกเลี่ยงการใช้โทเค็นเพิ่มและให้ได้ประสบการณ์ใช้งานที่ดีที่สุด แนะนำให้ เริ่มเซสชันใหม่
• ตอนเรียกใช้งาน ต้องป้อน model ID หนึ่งในรายการต่อไปนี้ ไม่ใช่ชื่อเวอร์ชันโมเดล
  • k3
  • k3-256k
  • kimi-for-coding
  • kimi-for-coding-highspeed
• หากป้อนชื่อเวอร์ชันอย่าง Kimi K3 หรือ K2.7 Code การเรียกใช้งานจะล้มเหลว
• หากปิด Thinking ใน K3 หรือ K2.7 คำขอจะถูก route ไปยัง K2.6 ดังนั้นหากต้องการใช้ K3 หรือ K2.7 Code ต้องเปิด Thinking

• ไคลเอนต์ทางการ

  • ใน Kimi Code CLI สามารถพิมพ์ /model เพื่อเปลี่ยนโมเดลโดยไม่ต้องแก้การตั้งค่า
  • หากไม่มีโมเดลล่าสุดในรายการ ให้ /logout แล้ว /login เพื่อเข้าสู่ระบบใหม่
  • ใน Kimi Code for VS Code ให้เลือกโมเดลจากเมนูดรอปดาวน์ในช่องป้อนข้อความ
  • หากไม่แสดงโมเดล ให้รีสตาร์ต VS Code หรือติดตั้งส่วนขยายใหม่

การตั้งค่าเครื่องมือ third-party

• สร้าง API Key ใน Kimi Code Console แล้วป้อน Base URL และ model ID ลงในเครื่องมือ
• Kimi Code API รองรับทั้ง โปรโตคอลที่เข้ากันได้กับ OpenAI และ โปรโตคอลที่เข้ากันได้กับ Anthropic
  • OpenAI compatible Base URL: https://api.kimi.com/coding/v1
  • Anthropic compatible Base URL: https://api.kimi.com/coding/
• วิธีตั้งค่าสำหรับแต่ละเครื่องมือดูได้จากเอกสารต่อไปนี้
  • Claude Code: ผู้ช่วยเขียนโค้ดแบบ command-line ของ Anthropic
  • OpenCode: เอเจนต์เขียนโค้ดบนเทอร์มินัล
  • Codex: เอเจนต์เขียนโค้ดของ OpenAI

• การตั้งค่าคอนเท็กซ์ของ K3

  • คอนเท็กซ์เริ่มต้นของเครื่องมือ third-party บางตัวเล็กกว่าค่าสูงสุด 1M ของ K3
  • หากต้องการใช้คอนเท็กซ์สูงสุด 1M ต้องตั้งค่าฟิลด์ context-window เป็น 1048576 ด้วยตนเอง

• การแมประดับการอนุมานของ K3

  • K3 รองรับ low, high, max และค่าที่เครื่องมือส่งมาจะถูกแมปดังนี้
  • null หรือ undefined: ค่าเริ่มต้น high
  • ค่าอื่นที่ไม่รู้จัก: ข้อผิดพลาด HTTP 400
  • ultra, max, xhigh: max
  • high, medium: ระดับที่แนะนำคือ high
  • low, minimum, light: low
  • none: ปิดใช้งาน thinking.type

[GN⁺]

ความคิดเห็นบน Hacker News

• Codex ใช้ประโยชน์จาก คอนเท็กซ์ 256k ได้ดีมาก 1M นั้นเหลือเฟือ แต่ยังแพงและดูไม่จำเป็นในฐานะค่าเริ่มต้น

• LLM กำลังกลายเป็น สินค้าโภคภัณฑ์ทั่วไป อย่างรวดเร็ว และคูเมืองของแล็บวิจัย AI ในสหรัฐฯ อย่าง OpenAI กำลังอ่อนแอลง สุดท้ายผู้ที่มีแนวโน้มจะชนะคือไฮเปอร์สเกลเลอร์และเจ้าของดาต้าเซ็นเตอร์ที่ขายโทเค็นราคาถูกได้

  • ยังไม่ได้ลองผลิตภัณฑ์อื่นมากนัก แต่ Codex harness น่าดึงดูดจนยากจะเปลี่ยนไปใช้อย่างอื่น อยากรู้ว่ามีที่ไหนอีกไหมที่ให้ harness คุณภาพระดับนี้
  • รู้สึกขอบคุณอย่างยิ่งต่อ บริษัท Frontier AI ที่ทุ่มทุนมหาศาลและงานวิจัยพัฒนาที่ซับซ้อนให้กับโมเดลแต่ละตัว ถึงขั้นที่ตอนนี้เริ่มลืมได้ง่ายแล้วว่าต้องใช้ต้นทุนมากแค่ไหนกว่าจะมาถึงจุดนี้

• k3-256k เปิดตัวแล้ว และให้ ผลลัพธ์เหมือนกันภายในคอนเท็กซ์ 256k ส่วน k3 (1M) ใช้โควตาประมาณสองเท่าของ k3-256k

• เป็นการเปลี่ยนแปลงที่โอเค ปกติพยายามคงคอนเท็กซ์ไว้ ไม่เกิน 200k

  • ในเธรด Reddit ของข่าวนี้ ประโยคเดียวกันนี้ก็เป็นคอมเมนต์อันดับบนสุดเช่นกัน
    https://www.reddit.com/r/kimi/s/BFa1TR9vNg
  • ขึ้นอยู่กับขอบเขตงาน แต่คิดว่าจุดที่เหมาะสมคือ ไม่เกิน 500k ใน Claude โทเค็น 500,000 ก็เพียงพอให้รักษาบริบททั้งหมดตั้งแต่ต้นจนถึงปัจจุบัน พร้อมกับสร้างโปรเจกต์ขนาดค่อนข้างใหญ่ได้
  • “256k ก็น่าจะพอสำหรับทุกคนแล้ว”

• ถ้าอย่างนั้นก็สงสัยว่าผู้ใช้ทุกคนจะได้ใช้ Kimi ในราคา ครึ่งหนึ่งอย่างกะทันหัน จนกว่าคอนเท็กซ์จะถึง 256k หรือไม่ ถ้าจริงก็นับว่าเป็นการเปลี่ยนแปลงครั้งใหญ่

  • เพราะเป็นโมเดลแยกกัน จึงเคยคิดว่าถ้าใช้ k3-256k แล้วเปลี่ยนไปใช้โมเดล 1M เมื่อถึง 256k แคชจะถูกทำให้ใช้ไม่ได้ และต้องจ่ายค่าโทเค็น 256k เดิมซ้ำในราคาของโมเดล 1M
    แต่ความเข้าใจนี้ผิด และสามารถเปลี่ยนไปใช้โมเดล 1M เมื่อใกล้ถึงขีดจำกัดคอนเท็กซ์ได้ โดยไม่ทำให้แคชใช้ไม่ได้ ในเวอร์ชันปัจจุบัน การเปลี่ยนจาก k3-256k ไปเป็น k3 (1M) ไม่กระทบแคช
  • เข้าใจว่าไม่ใช่อย่างนั้น น่าจะหมายถึงเมื่อหน้าต่างคอนเท็กซ์เล็กลง โทเค็นอินพุตที่สะสมตามเวลาจะลดลง จึงโดยรวมถูกลงมากกว่า

• โพสต์นี้ขึ้นมาได้ 38 นาทีแล้ว และตั้งแต่ 20 นาทีที่แล้ว บริการหลายตัวของ Anthropic ถูกแสดงว่าอยู่ในสถานะ ล่มครั้งใหญ่ คงไม่เกี่ยวกันหรอก แต่ก็แอบขำ

• ดูเหมือนว่าตัวโมเดลเองจะเหมือนเดิม และเป็นเพียง การเปลี่ยนแปลงในระดับ API เท่านั้น

• ในเชิงฟังก์ชันคล้ายกับวิธีของ OpenAI ที่เปลี่ยนระดับราคาเมื่อเกินความยาวคอนเท็กซ์ระดับหนึ่ง เกณฑ์ก็อยู่แถว 272k หรือประมาณ 2^18 หรือ 256k
  เมื่อคอนเท็กซ์ที่ใช้งานอยู่ใหญ่ขึ้น ปริมาณการคำนวณต่อโทเค็นเอาต์พุตและจำนวนไบต์ที่ต้องอ่านก็เพิ่มขึ้น ดังนั้นการผลักต้นทุนให้ผู้ใช้จึงสมเหตุสมผล แต่ที่น่าแปลกคือเลือกใช้ เกณฑ์แบบขั้นบันได แทนที่จะเป็นเส้นโค้งราคาที่ค่อย ๆ เปลี่ยน

  • มีแนวโน้มสูงว่าจะรัน โครงสร้างพื้นฐานสองแบบ ตามความยาวลำดับสูงสุด ดังนั้นเกณฑ์แบบขั้นบันไดจึงไม่น่าแปลกใจ
    คอนฟิกคอนเท็กซ์สั้นต้องใช้โหนดเฉพาะสำหรับ prefill ต่ออินสแตนซ์น้อยกว่า และไม่จำเป็นต้องรองรับ KV cache ขนาดใหญ่ จึงลดจำนวนโหนดโดยรวมได้ด้วย หากใช้การอนุมานแบบแยกส่วน ก็สามารถปรับสัดส่วนการคำนวณที่จัดสรรให้ prefill และ decoding แยกกันได้

• หวังว่าการเปลี่ยนแปลงนี้จะช่วยลดภาระโครงสร้างพื้นฐานได้ ช่วงหลังโมเดลทั้งหมดช้าลงอย่างเห็นได้ชัด แต่ทีมซัพพอร์ตไม่ตอบสนอง สงสัยว่าคำขอจำนวนไม่น้อยอาจถูกประมวลผลด้วย โมเดลแบบ quantized

  • ทฤษฎีสมคบคิด ที่ไม่มีหลักฐานอาจเหมาะกับ Reddit แต่ไม่เหมาะกับ HN

• สงสัยว่าไม่ได้เป็นโมเดลที่ quantized แต่แค่ลด หน้าต่างคอนเท็กซ์เหลือ 256k เท่านั้นหรือเปล่า

  • หน้าต่างคอนเท็กซ์ 256k กับ การ quantize หรือไม่ เป็นคนละเรื่องกัน เนื่องจากตรวจสอบจากภายนอกโดยตรงได้ยาก จึงตัดความเป็นไปได้ที่จริง ๆ แล้วจะถูก quantize ออกไปไม่ได้