Kimi K3 ในการใช้งานจริง: ประสบการณ์ภาคปฏิบัติและการเปรียบเทียบกับ Claude Code

การทดลองของผู้เขียนจบลงอย่างไร#

Kimi K3 เปิดตัวเมื่อวันที่ 16 กรกฎาคม 2026 มีพารามิเตอร์ 2.8 ล้านล้านตัว หน้าต่างบริบทหนึ่งล้านโทเค็น น้ำหนักโมเดลแบบเปิด และได้อันดับหนึ่งในการเปรียบเทียบงาน frontend แบบปกปิดชื่อ ผมรวบรวมรายละเอียดทั้งหมดเกี่ยวกับสถาปัตยกรรม ผลการทดสอบประสิทธิภาพ และราคาไว้ในรีวิวฉบับเต็มของ Kimi K3 เทียบกับ Claude Code จึงจะไม่กล่าวซ้ำที่นี่

ท้ายรีวิวนั้น ผมเขียนไว้ว่า ความเสี่ยงคือเสียเวลาหนึ่งวันกับการตั้งค่า ส่วนผลตอบแทนคือบิลที่ลดลงตั้งแต่สัปดาห์ที่สองเป็นต้นไป ผมทดลองกับงานของตัวเอง

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

สุดท้ายผมย้อนกลับไปใช้แบบเดิม นี่คือสิ่งที่ทำให้ผมตัดสินใจเช่นนั้น พร้อมตัวเลขและลิงก์ไปยังแหล่งข้อมูลปฐมภูมิ เพื่อให้คุณตรวจสอบทุกอย่างได้ด้วยตัวเอง

ทำไมผลการทดสอบประสิทธิภาพจึงแสดงว่า Kimi K3 เอาชนะ Claude ได้?#

นี่คือการทดสอบประสิทธิภาพที่ Kimi K3 เอาชนะ Claude Fable 5:

llm-stats รวบรวมผลการทดสอบไว้ โดยทุกรายการเปรียบเทียบกับ Claude Fable 5

ตัวเลขเหล่านี้เป็นข้อมูลจริง เมื่อดูการทดสอบทั้ง 35 รายการในสรุปเดียวกัน Claude Fable 5 ชนะ 22 รายการ Kimi K3 ชนะ 12 รายการ และเสมอหนึ่งรายการ

สิ่งที่น่าสนใจกว่าคือจุดที่ Kimi K3 ทำได้ไม่ดีนัก คะแนนที่ตามหลังในการทดสอบด้านการเขียนโค้ดมีไม่มาก อยู่ที่ 4–5 คะแนน แต่ทำคะแนนด้านความรู้และการให้เหตุผลได้ลดลง: ใน HLE Claude นำเกือบ 10 คะแนน นี่แหละคือจุดที่งานยาว ๆ ไปต่อไม่ไหว เพราะต้องทำความเข้าใจให้ได้ก่อน แล้วถึงจะเขียนได้

Moonshot เขียนไว้ในส่วนหลักของโพสต์เปิดตัวว่า:

ทำไม Kimi K3 จึงรู้สึกช้าลงสองเท่าเมื่อใช้งานจริง?#

การเปรียบเทียบนี้ใช้ Claude Opus 4.8 ซึ่งเป็นเวอร์ชันของ Claude ที่มีผลการทดสอบความเร็วครบถ้วน

Kimi K3 ตอบกลับเร็วกว่า จึงให้ความรู้สึกว่าเร็วกว่าในการคุยสั้น ๆ แต่ในการทำงาน เวลาส่วนใหญ่หมดไปกับเรื่องอื่น: การรอคำตอบฉบับเต็ม ที่จุดนี้มันช้ากว่าเกือบครึ่งหนึ่ง และเมื่อเป็นคำตอบยาว ๆ ส่วนต่างก็สะสมจนกลายเป็นหลายนาที

Kimi Code โฆษณาความเร็ว 180–260 โทเค็นต่อวินาที ซึ่งดูน่าเชื่อถือเมื่อเทียบกับ 34.7 ของผม ตัวเลขนั้นหมายถึงรุ่นเพิ่มความเร็วของรุ่นก่อนหน้า คือ K2.7 Code HighSpeed แต่ Kimi K3 ไม่มีรุ่นดังกล่าวเลย และการทดสอบอิสระวัด Kimi K3 โดยตรง

โทเค็นหายไปไหน หากปิดการให้เหตุผลไม่ได้?#

คุณลดระดับความพยายามได้ โดยเอกสารระบุไว้สามระดับ: ต่ำ สูง และสูงสุด แต่ไม่สามารถปิดการให้เหตุผลทั้งหมดได้ เพราะเอกสารระบุชัดเจนว่าการให้เหตุผลและการจัดเก็บประวัติการให้เหตุผลเปิดใช้งานอยู่เสมอสำหรับ Kimi K3 หากเรียก API โดยตรง ระดับสูงสุดจะเป็นค่าเริ่มต้น และโปรแกรม wrapper ส่วนใหญ่ไม่ได้เปลี่ยนค่านี้

แต่ละเทิร์นเพิ่มโทเค็นเอาต์พุตหลายพันโทเค็น ในราคา $15 ต่อหนึ่งล้านโทเค็น นอกจากนี้ Moonshot กำหนดให้คุณส่งข้อความทั้งหมดของ assistant กลับไป รวมถึงประวัติการให้เหตุผลด้วย และโทเค็นเอาต์พุตเหล่านั้นจะกลายเป็นโทเค็นอินพุตอีกครั้งในเทิร์นถัดไป

นั่นหมายความว่าคุณจ่ายสองครั้งสำหรับการให้เหตุผลเดียวกัน: ครั้งแรกเมื่อโมเดลเขียนมัน และครั้งที่สองเมื่อคุณส่งมันกลับไปให้โมเดล

เมื่อดูดัชนีโดยรวม Kimi K3 ใช้โทเค็นเอาต์พุตน้อยกว่ารุ่นก่อน K2.6 อยู่ 21% โมเดลประหยัดขึ้นเมื่อเทียบกับรุ่นก่อนหน้าของตัวเอง แต่ Claude ยังคงใช้โทเค็นน้อยกว่าในงานเดียวกัน

พรอมป์ต์ “hi” คิดค่าใช้จ่ายเท่ากับ 86 โทเค็น เบื้องหลังมีพรอมป์ต์ระบบที่ซ่อนอยู่ประมาณ 85 โทเค็น และคุณต้องจ่ายสำหรับส่วนนี้ในทุกคำขอ

ผมมีรีวิวอีกชิ้นหนึ่งเกี่ยวกับวิธีคำนวณการใช้งานและตรวจสอบยอดคงเหลือที่เหลือ: Claude Pro และ Max ให้โทเค็นคุณเท่าไร หลักการคำนวณเหมือนกัน มีเพียงราคาที่เปลี่ยนไป

เกิดอะไรขึ้นเมื่อโมเดลติดอยู่กับการให้เหตุผล?#

ลักษณะเป็นแบบนี้ โมเดลเริ่มคิด แต่แทนที่จะขยายความคิด ข้อความกลับวนซ้ำ: คำเดิมคำเดิม แล้วตามด้วยเศษพยางค์ไม่รู้จบ งานหยุดชะงัก แต่มาตรวัดโทเค็นยังหมุนต่อไป

รายงานวันที่ 28 กรกฎาคมในรายการปัญหาที่ทราบของ Moonshot อธิบายว่า Kimi K3 พยายามอ่านไฟล์เดิมหกครั้งติดต่อกัน ได้รับข้อความปฏิเสธ “no-op call, file hasn’t changed since the previous read” เจ็ดครั้ง แล้วจบเทิร์นราวกับไม่มีอะไรเกิดขึ้น ในตัวติดตามปัญหา Kimi CLI ผู้เขียนแจกแจงอาการค้างแบบเดียวกันสี่ชนิด ได้แก่ การอ่าน การแทนที่ การทดสอบ และการวิเคราะห์ ก่อนสรุปไว้ในประโยคเดียว:

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

ผู้เขียนบทวิเคราะห์ในเราเตอร์คำขอของบุคคลที่สาม ให้การวินิจฉัยแบบเดียวกัน: Kimi เข้มงวดถึงขั้นปฏิเสธคำขอที่มีประวัติการให้เหตุผลไม่ครบ wrapper ภายนอกไม่รู้ถึงความเข้มงวดนี้ จึงตัดทอนประวัติ

ทำไมการตั้งค่าแบบหลายเอเจนต์จึงพังเมื่อใช้ Kimi K3?#

เอกสารอย่างเป็นทางการของ Moonshot ระบุเรื่องนี้อย่างชัดเจน: API ของพวกเขายังไม่รองรับ WebFetch กล่าวอีกอย่างคือ Claude Code ซึ่งปกติจะออนไลน์ไปดึงหน้าเว็บมา ไม่สามารถทำเช่นนั้นกับ Kimi K3 ได้ วิธีเลี่ยงคือวางเนื้อหาด้วยตนเองหรือเชื่อมต่อเครื่องมือของบุคคลที่สาม

Claude Code โหลดเครื่องมือตามต้องการได้ และใส่บล็อกบริการประเภท tool_reference ลงในประวัติ Kimi ไม่ยอมรับประเภทนี้และส่งข้อผิดพลาด 400 กลับมา โดยไม่แจ้งทั้งชื่อฟิลด์หรือสาเหตุ:

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

เพื่อเปรียบเทียบ นี่คือลักษณะของความล้มเหลวแบบเดียวกันบน API ดั้งเดิมของ Anthropic ซึ่งเซิร์ฟเวอร์อย่างน้อยก็ระบุชื่อฟิลด์และแสดงประเภทที่ยอมรับ:

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

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

ผลที่ตามมาอธิบายไว้ในรายงานอีกฉบับที่เปิดเมื่อวันที่ 17 กรกฎาคมและยังไม่มีคำตอบ ผู้เขียนพบข้อผิดพลาดนี้เจ็ดครั้งในเซสชันเดียว เซสชันยังอยู่รอดหลังหกครั้งแรก แต่ครั้งที่เจ็ดทำให้พังถาวร: หลังจากนั้น แม้แต่การพิมพ์ข้อความธรรมดา “continue” ก็ทำให้ระบบล่ม ผู้เขียนยังระบุแยกต่างหากว่าไม่ได้เข้าใกล้ขีดจำกัดบริบทเลย ดังนั้นคำอธิบายว่า “ประวัติยาวเกินไป” จึงฟังไม่ขึ้น

ต่อไปนี้คือสรุปประเภทบล็อกที่ Moonshot API ยอมรับและปฏิเสธ:

คำว่า “เข้ากันได้” ในที่นี้อธิบายเฉพาะรูปแบบคำขอเท่านั้น ส่วนอื่นต่างกันทั้งหมด ทั้งประเภทบล็อกที่ยอมรับ เนื้อหาที่ประวัติต้องมี และเครื่องมือที่ใช้งานได้

อะไรบ้างที่ใช้ต่อกับ Kimi K3 ไม่ได้?#

ส่วนข้อจำกัดของโพสต์เปิดตัวเขียนไว้ตรงตัวดังนี้:

สิ่งที่ผู้พัฒนาโมเดลกำลังบอกคือ: ใช้ไคลเอนต์ของเรา เราไม่รับประกันพฤติกรรมของไคลเอนต์อื่น

ประเด็นที่สองในส่วนเดียวกันอธิบายอีกเรื่องหนึ่งที่ผมเคยคิดว่าเป็นความดื้อของโมเดล:

ไฟล์ CLAUDE.md ของผมเขียนขึ้นเพื่อให้ทำตรงกันข้าม: ถาม แสดงแผน แล้วรอการยืนยัน คำสั่งยังอยู่ครบ แต่ตอนนี้กำลังถูกอ่านโดยโมเดลที่มีนิสัยต่างออกไป

หากต้องการใช้ไฟล์กฎเพียงไฟล์เดียวร่วมกันกับหลายเอเจนต์ ผมอธิบายการตั้งค่านั้นไว้ต่างหากแล้ว: ไฟล์คำสั่งเดียวสำหรับ Claude Code, Codex และ Cursor

Kimi K3 มีค่าใช้จ่ายจริงเท่าไร?#

ก่อนอื่น มาดูราคาที่เป็นประโยชน์ต่อ Kimi K3:

ราคา Kimi มาจากเอกสารการแคชบริบท ส่วนคอลัมน์ขวาแสดงราคา Claude Opus 5 ณ วันที่ 30 กรกฎาคม 2026

แคชของ Kimi ทำงานอัตโนมัติ ปิดไม่ได้ และระบุด้วยค่าแฮชที่จุดเริ่มต้นของคำขอ การแก้ไขพรอมป์ต์ระบบหรือรายการเครื่องมือแม้เพียงครั้งเดียวจะล้างแคชข้อความทั้งหมด

นี่คือสิ่งที่ Claude Code ทำในวันทำงานปกติ:

1. เชื่อมต่อและยกเลิกการเชื่อมต่อเครื่องมือภายนอกตามความคืบหน้าของงาน
2. โหลดเครื่องมือเมื่อจำเป็น
3. เปิดใช้งานเอเจนต์ย่อยที่มีชุดเครื่องมือแตกต่างกัน
4. เพิ่มไฟล์คำสั่งลงในพรอมป์ต์ระบบ
5. สร้างประวัติขึ้นใหม่เมื่อบีบอัดบริบท

แต่ละรายการในลิสต์นี้รีเซ็ตจุดเริ่มต้นของคำขอ และจึงรีเซ็ตแคชด้วย โทเค็นอินพุตจึงกลับไปมีราคา $3 ต่อหนึ่งล้าน แทนที่จะเป็น 30 เซนต์—แพงขึ้นสิบเท่า นอกจากนี้ยังมีการให้เหตุผลอย่างต่อเนื่องในราคา $15 ต่อหนึ่งล้านโทเค็นเอาต์พุต และโทเค็นเดิมเหล่านั้นก็กลับมาเป็นอินพุตในเทิร์นถัดไป นี่คือเหตุผลที่โมเดลซึ่งมีราคาประกาศต่ำอาจทำให้คุณได้บิลที่ไม่คาดคิด

จากข้อมูลรวมของ OpenCode เซสชัน Kimi K3 โดยเฉลี่ยมีค่าใช้จ่าย $1.86 และใช้โทเค็นเฉลี่ย 3.1 ล้านโทเค็น จากเซสชันจริงเกือบ 280,000 เซสชัน ตัวเลขนี้ตั้งอยู่บนสมมติฐานว่าโทเค็นอินพุต 93% เข้าถึงแคช หากเปลี่ยนจุดเริ่มต้นของคำขอ ตัวเลขนี้ก็ใช้กับคุณไม่ได้อีกต่อไป

แพ็กเกจ Kimi ราคา $19, $39, $99 และ $199 โควตามาจากพูลร่วมกันสำหรับสมาชิกทั้งหมด รีเซ็ตรายสัปดาห์โดยไม่นำยอดที่ไม่ได้ใช้ไปทบ และใช้หน้าต่างเวลาแบบเลื่อนห้าชั่วโมง รีวิวแพ็กเกจ อธิบายไว้ว่า เทอร์มินัลสี่ตัวที่รัน Kimi K3 ซึ่งให้เหตุผลอยู่ตลอด จะใช้โควตาห้าชั่วโมงหมดอย่างรวดเร็ว

โควตาการเขียนโค้ดของแพ็กเกจ $99 ใกล้เคียงกับแพ็กเกจ $200 ของ Anthropic ซึ่งขัดกับจุดยืนของผมเอง Kimi ราคาถูกกว่าต่อโทเค็น แต่ตอนเย็นคุณจะมองไม่เห็นความแตกต่างนั้นในบิลแล้ว

Kimi K3 เก่งเรื่องอะไรอย่างชัดเจน?#

1. Frontend. อันดับหนึ่งในการเปรียบเทียบแบบปกปิดชื่อโดยนักพัฒนาที่ทำงานจริง สร้างเลย์เอาต์อย่างเป็นระเบียบและมีรสนิยมพอสมควร
2. ปริมาณ. หน้าต่างบริบทหนึ่งล้านโทเค็น และไม่หวั่นกับไฟล์ยาว ๆ การวิเคราะห์คลังโค้ดขนาดใหญ่และทำแผนผังคือประเภทงานที่เหมาะกับมัน
3. การตอบสนองครั้งแรก. เวลาจนถึงโทเค็นแรกใช้เวลาเพียงครึ่งหนึ่งของ Claude สังเกตเห็นได้และให้ความรู้สึกดีในการสนทนาสั้น ๆ
4. ราคาต่อโทเค็น. ประมาณ 60% ของราคาของ Claude Opus 5 หากจุดเริ่มต้นของคำขอไม่เปลี่ยน ก็ช่วยประหยัดได้จริงในงานปริมาณมากที่ทำซ้ำ ๆ
5. น้ำหนักโมเดลแบบเปิด. โมเดลไม่ได้ผูกติดอยู่กับผู้ให้บริการรายเดียว

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

วิธีทดสอบทั้งหมดนี้ด้วยตัวเองภายในเย็นวันเดียว#

1. ตั้งค่าการเข้าถึงตามคำแนะนำ ผมอธิบายตัวแปรสภาพแวดล้อมสามตัวและการแทนที่โมเดลตามระดับไว้ในรีวิว Kimi K3 เทียบกับ Claude Code ตรวจสอบการตั้งค่าด้วยคำสั่ง /status: Kimi จะไม่ปรากฏในเมนูเลือกโมเดล เพราะมีรายการชื่อแทนที่ติดตั้งมาในตัว และคุณไม่จำเป็นต้องแก้ไขรายการนั้น
2. ลบคีย์เก่าออก หากเคยตั้งค่า ANTHROPIC_API_KEY ไว้ ให้ลบออก เมื่อใช้ร่วมกับ ANTHROPIC_AUTH_TOKEN จะทำให้เกิดข้อขัดแย้ง และคุณจะได้รับข้อผิดพลาดด้านการอนุญาตโดยไม่มีเหตุผลที่สมควร
3. ปิดการโหลดเครื่องมือแบบเลื่อนเวลาไว้ทันที ทำก่อนการรันครั้งแรก อย่ารอจนเซสชันแรกพัง
4. อย่าเปลี่ยนโมเดลกลางงาน หากเริ่มต้นด้วย Kimi K3 ก็ให้ทำงานจนจบด้วย Kimi K3 เช่นเดียวกันในทางกลับกัน นี่เป็นข้อกำหนดโดยตรงของ Moonshot ซึ่งผมอ้างไว้ข้างต้นแล้ว
5. ใช้ชิ้นงานจริงของตัวเอง เลือกงานที่คุณทำเมื่อวาน พร้อมความยุ่งเหยิงและหัวข้อที่ยังทำไม่เสร็จ เกมงูจะแสดงความแตกต่างไม่ได้ เพราะความแตกต่างจะปรากฏเมื่อใช้งานเป็นเวลานานเท่านั้น
6. จดตัวเลขสองอย่าง ใช้เวลากี่นาที และเย็นวันนั้นเสียเงินไปเท่าไร แล้วเปรียบเทียบกับเย็นวันปกติที่ใช้ Claude
7. ติดตามเวลาที่ไม่ได้ทำงานแยกต่างหาก เมื่อเอเจนต์ค้าง อ่านไฟล์เดิมวนซ้ำ หรือตอบกลับด้วยข้อผิดพลาด สิ่งเหล่านี้ก็เป็นส่วนหนึ่งของต้นทุนด้วย

หากบิลตอนเย็นสูงกว่าที่คาดไว้ เกือบทุกครั้งเป็นเรื่องของแคช: ลองนับดูว่าจุดเริ่มต้นของคำขอถูกรีเซ็ตกี่ครั้งในเย็นวันนั้น ราคาต่อโทเค็นแทบไม่เกี่ยวกับเรื่องนี้

สิ่งที่ผมเลือกเก็บไว้ใช้#

ผู้อ่านในช่องที่ทดลองโมเดลร่วมกับผมต่างก็เลือกใช้การตั้งค่าแบบเดียวกันด้วยตัวเอง: ส่ง Kimi K3 ไปตรวจสอบคลังโค้ดและให้ความเห็นอีกทางหนึ่ง ส่วนงานหลักยังให้เอเจนต์ที่คุ้นเคยทำ การตั้งค่าแบบนี้ได้ผลเพราะไม่จำเป็นต้องย้าย wrapper หรือทำลายสิ่งที่ทำงานได้ดีอยู่แล้ว

พูดได้ว่า งานหนึ่งชิ้นที่ครบถ้วนส่งให้ Kimi K3 ส่วนสายงานยาวที่มีเครื่องมือและเอเจนต์ย่อยส่งให้ Claude Code ยิ่งงานต้องสลับใช้เครื่องมือบ่อยเท่าไร ค่าใช้จ่ายบน Kimi K3 ก็ยิ่งสูงขึ้น และโอกาสที่เซสชันจะพังก็ยิ่งมากขึ้น

ผมมีรีวิวแยกต่างหากเกี่ยวกับการแบ่งบทบาทให้เอเจนต์สองตัวโดยไม่ทำให้สับสน: สามวิธีทำงานร่วมกับเอเจนต์สองตัว

ผลการทดสอบประสิทธิภาพตอบคำถามว่า “ใครเก่งกว่าในสภาพแวดล้อมห้องทดลอง?” บิลตอนเย็นและรายการงานที่ทำเสร็จตอบคำถามว่า “ใครเก่งกว่าสำหรับคุณ?” เมื่อคำตอบทั้งสองต่างกัน ให้เชื่อคำตอบที่สอง เพราะคุณเป็นคนคำนวณเอง ไม่ใช่ฝ่ายการตลาด

หลังจากพิจารณาทั้งหมดนี้ ผมตัดสินใจด้วยตัวเองว่า ไม่ว่าใครจะพูดอย่างไรเกี่ยวกับโมเดลใหม่ ผู้นำก็ยังเป็นผู้นำ Claude Code ยังคงเป็นเครื่องยนต์หลักของผม