Kimi Vendor Verifier - ตรวจสอบความถูกต้องของผู้ให้บริการ inference

 (kimi.com)
3 คะแนน โดย GN⁺ 2026-04-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Kimi Vendor Verifier (KVV) เป็นเครื่องมือสาธารณะที่ช่วยตรวจสอบ ความคลาดเคลื่อนของการติดตั้งใช้งาน inference ที่เกิดขึ้นบนโครงสร้างพื้นฐานที่แตกต่างกันหลังการเผยแพร่โมเดลโอเพนซอร์ส ทำให้สามารถ แยกข้อจำกัดของตัวโมเดลออกจากข้อผิดพลาดทางวิศวกรรม ได้
  • อ้างอิงตาม API อย่างเป็นทางการ มีการเผยแพร่ค่า OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8 พร้อมเปิดเผยค่าตั้ง Temperature, TopP, MaxTokens ของแต่ละการประเมิน รวมถึงไฟล์ผลการประเมิน K2VV
  • จากการตรวจสอบสัญญาณผิดปกติของเบนช์มาร์กที่ชุมชนรายงาน พบว่าหลายกรณีมีสาเหตุจาก การใช้พารามิเตอร์การถอดรหัสผิดวิธี และในโหมด Thinking มีการบังคับใช้ Temperature 1.0 และ TopP 0.95 รวมถึงการตรวจสอบการส่งต่อคอนเทนต์ซ้ำ
  • กระบวนการตรวจสอบมีโครงสร้างเป็นการตรวจล่วงหน้าเพื่อยืนยันข้อจำกัดของพารามิเตอร์ ก่อนประเมินด้วย OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench ฯลฯ เพื่อตรวจสอบตั้งแต่ การพรีโปรเซส Vision, เอาต์พุตยาว, การเรียกใช้เครื่องมือ ไปจนถึง agentic coding
  • เวิร์กโฟลว์ทั้งหมดใช้เวลาราว 15 ชั่วโมงเมื่อรันแบบลำดับบนเซิร์ฟเวอร์ NVIDIA H20 แบบ 8-GPU จำนวน 2 เครื่อง และผลักดันการขยายแนวทาง การตรวจสอบที่ให้ความสำคัญกับความถูกต้องเป็นอันดับแรก ผ่านลีดเดอร์บอร์ดสาธารณะและการให้สิทธิ์เข้าถึงล่วงหน้า

สร้าง Chain of Trust ขึ้นใหม่

  • ออกแบบมาพร้อมกับการเปิดเผยซอร์สของ Kimi Vendor Verifier (KVV) เพื่อให้ผู้ใช้โมเดลโอเพนซอร์สสามารถตรวจสอบ ความถูกต้องของการติดตั้งใช้งาน inference ได้
  • เปิดตัวพร้อมกับโมเดล Kimi K2.6 และชี้ว่าเพียงการเปิดเผยโมเดลอย่างเดียวไม่เพียงพอ แต่ยังต้องมีขั้นตอน ยืนยันว่าทำงานได้ถูกต้องในสภาพแวดล้อมที่หลากหลาย
  • ยิ่งระบบนิเวศของโมเดลโอเพนซอร์สเปิดเผยน้ำหนักโมเดลและกระจายเส้นทางการติดตั้งใช้งานมากขึ้นเท่าไร ก็ยิ่งเห็นชัดถึงโครงสร้างที่ ควบคุมคุณภาพได้ยากขึ้น
  • หากผู้ใช้ไม่สามารถแยกได้ว่าเป็น ข้อบกพร่องด้านประสิทธิภาพของตัวโมเดล หรือเป็น ความคลาดเคลื่อนจากการติดตั้งใช้งานทางวิศวกรรม ความเชื่อมั่นต่อระบบนิเวศโอเพนซอร์สก็อาจพังทลายได้

แนวทางแก้ไข

  • จากสัญญาณผิดปกติรายกรณีสู่ปัญหาเชิงโครงสร้าง

    • หลังการเปิดตัว K2 Thinking ชุมชนส่งฟีดแบ็กเกี่ยวกับ ความผิดปกติของคะแนนเบนช์มาร์ก เข้ามาบ่อยครั้ง
    • ผลการตรวจสอบยืนยันว่าหลายกรณีมีต้นตอมาจาก การใช้พารามิเตอร์การถอดรหัสผิดวิธี
    • จึงสร้างแนวป้องกันชั้นแรกในระดับ API ทันที
      • บังคับใช้ Temperature=1.0, TopP=0.95 ในโหมด Thinking
      • ใช้การตรวจสอบภาคบังคับว่า คอนเทนต์ thinking ถูกส่งต่อกลับอย่างถูกต้องหรือไม่
    • ในการประเมิน LiveBenchmark บางรายการ พบความแตกต่างขนาดใหญ่ระหว่าง API ของบุคคลที่สามกับ API อย่างเป็นทางการ
    • จากการทดสอบผู้ให้บริการโครงสร้างพื้นฐานจำนวนมากอย่างกว้างขวาง ยืนยันว่าความแตกต่างนี้ เกิดขึ้นอย่างแพร่หลาย

  • ขั้นตอนและการดำเนินงานตรวจสอบ

    • เปิดเผยค่าของเบนช์มาร์กอ้างอิงตาม API อย่างเป็นทางการ
      • ความแม่นยำของ OCRBench 91.0
      • AIME2025 avg@32 98.4
      • ความแม่นยำของ MMMU Pro Vision 78.8
      โฆษณา
    • ระบุค่าตั้งสำหรับการประเมินไว้ด้วย
      • ทั้งสามรายการใช้ Temperature 1.0, TopP 0.95
      • MaxTokens คือ OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
    • ให้ลิงก์ไฟล์ ผลการประเมิน Kimi API K2VV พร้อมระบุว่าใช้สำหรับคำนวณคะแนน F1
    • ดำเนินขั้นตอน Pre-Verification
      • ตรวจสอบว่า ข้อจำกัดของพารามิเตอร์ API เช่น temperature, top_p ถูกบังคับใช้อย่างถูกต้องหรือไม่
      • จะเริ่มประเมินเบนช์มาร์กก็ต่อเมื่อผ่านการทดสอบทั้งหมดแล้วเท่านั้น
    • ใช้ OCRBench
      • ทำหน้าที่เป็น smoke test 5 นาที สำหรับไปป์ไลน์มัลติโมดัล
    • ใช้ MMMU Pro
      • ตรวจสอบ การพรีโปรเซสอินพุต Vision ผ่านการทดสอบอินพุตภาพที่หลากหลาย
    • ใช้ AIME2025
      • ทำหน้าที่เป็น stress test ของเอาต์พุตแบบยาว
      • จับ บั๊กของ KV cache และ ประสิทธิภาพที่ลดลงจากการควอนไทซ์ ซึ่งเบนช์มาร์กสั้น ๆ อาจตรวจไม่พบ
    • ใช้ K2VV ToolCall
      • วัดความสม่ำเสมอของการทริกเกอร์ (F1) และ ความถูกต้องของ JSON Schema
      • ตรวจพบปัญหาได้ตั้งแต่เนิ่น ๆ ก่อนข้อผิดพลาดของเครื่องมือจะสะสมในเอเจนต์
      โฆษณา
    • ใช้ SWE-Bench
      • ทำหน้าที่เป็นการทดสอบ agentic coding แบบครบวงจร
      • ไม่เปิดซอร์สสาธารณะเนื่องจากมีการพึ่งพา sandbox
    • ทำงานร่วมกับชุมชน vLLM, SGLang, KTransformers
    • ไม่หยุดเพียงการตรวจพบอาการ แต่ตั้งเป้า แก้ไขที่ต้นเหตุ
    • แทนที่จะรอรับคำร้องเรียนหลังการติดตั้งใช้งาน มีการให้ สิทธิ์เข้าถึงล่วงหน้า แก่ผู้ให้บริการโครงสร้างพื้นฐาน
    • ออกแบบให้ผู้ให้บริการแต่ละรายสามารถตรวจสอบสแตกของตนเองได้ก่อนที่ผู้ใช้จะพบปัญหา
    • มีแผนดำเนิน ลีดเดอร์บอร์ดสาธารณะ สำหรับผลลัพธ์ของผู้ให้บริการอย่างต่อเนื่อง
    • ออกแบบให้ความโปร่งใสนี้ช่วยยกระดับ ลำดับความสำคัญด้านความถูกต้อง ของผู้ให้บริการ
    • การตรวจสอบเวิร์กโฟลว์การประเมินทั้งหมดเสร็จสมบูรณ์แล้ว
      • ใช้ เซิร์ฟเวอร์ NVIDIA H20 แบบ 8-GPU จำนวน 2 เครื่อง
      • หากรันแบบลำดับจะใช้เวลาประมาณ 15 ชั่วโมง
    • มีการปรับสคริปต์ให้เหมาะกับสถานการณ์ inference ที่ใช้เวลานาน
      • streaming inference
      • การลองใหม่อัตโนมัติ
      • มี กลไก resume จาก checkpoint
    • ระบุหลักการว่าเมื่อมีการเปิดเผยน้ำหนักโมเดลแล้ว ความรู้ในการรันมันอย่างถูกต้องก็ควร เปิดเผยเช่นกัน
    • กำลังขยายการครอบคลุมของผู้ให้บริการและสำรวจการทดสอบ agentic ที่เบากว่าเดิม

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
ng0301 2026-04-23

หวังว่าจะเป็นโปรเจกต์ที่ออกมาดีจริง ๆ นะ
 
GN⁺ 2026-04-23
ความคิดเห็นจาก Hacker News
  • ชอบไอเดียนี้ ดูน่าจะเป็น แรงกดดันทางสังคม ที่มีประสิทธิภาพพอสมควรในการบังคับให้ผู้ให้บริการ inference แก้ปัญหาเก่า ๆ ตัวอย่างเช่น AWS Bedrock มีข้อบกพร่องร้ายแรงในสแตกเสิร์ฟโมเดล K2 และ K2.5 ของ Kimi ทำให้ 20%~30% ของความพยายามที่ควรส่ง tool call กลับจบการสนทนาไปเงียบ ๆ โดยไม่มี token output เลย ดังนั้น AWS จึงแทบไม่มีความหมายในฐานะผู้ให้บริการ inference ที่จริงจังสำหรับ Kimi และดูเหมือนกำลังผลักผู้ใช้ไปใช้โมเดล Anthropic ที่แพงกว่าเพื่อให้ได้ประสิทธิภาพงาน agent คล้ายกัน
    • นี่ไม่ใช่เรื่องใหม่นะ คิดว่า Kimi ทำแบบนี้มาแล้วหลายเดือน K2 Vendor Verifier, Kimi Vendor Verifier ก็มีอยู่ก่อนแล้ว และมีมาตั้งแต่ก่อนเปิดตัว K2.5 กับ K2.6 เสียอีก
  • จากที่ผมเข้าใจ threat model นี้น่าจะมุ่งป้องกัน ประสิทธิภาพตกโดยไม่ตั้งใจ มากกว่า ไม่ได้ครอบคลุมถึงผู้ไม่หวังดีด้วย เช่น ถ้ามีผู้ให้บริการน่าสงสัยบอกว่าใช้โมเดลตัวท็อปล่าสุด แต่จริง ๆ ใช้โมเดลที่ถูกกว่าและแย่กว่าเพื่อกินส่วนต่าง การทดสอบแบบนี้อาจช่วยไม่ได้มากนัก เพราะถ้าพวกเขาตรวจจับได้ว่ากำลังถูกทดสอบ ก็อาจทำให้มันทำงานดีเฉพาะตอนนั้นได้ เหมือนคดีอื้อฉาวการปล่อยไอเสียของ Volkswagen
    • ผู้ให้บริการอย่าง OpenRouter จะเลือกผู้ให้บริการที่ถูกที่สุดเป็นค่าเริ่มต้น แต่ที่ถูกก็มักเป็นเพราะมี การ quantization และการจูนที่หนักเกินไปเพื่อเอา throughput มากกว่าคุณภาพ ดังนั้นนี่จึงดูเหมือนเป็นความพยายามของ kimi ที่จะหยุดผู้ให้บริการราคาถูกมากไม่ให้ทำลายแบรนด์ด้วยประสิทธิภาพที่ไม่สะท้อนโมเดลจริง
    • แค่จับ drift ที่เกิดขึ้นโดยไม่ตั้งใจก็มีคุณค่ามากแล้ว มันแทบจะเป็นแนวคิดเดียวกับ performance regression test ใน CI และไม่ได้มีไว้ใช้โดยตั้งต้นจากการคาดว่าคนจะจงใจทำพัง ปกติมันมีไว้จับปัญหาธรรมดา ๆ อย่างอัปเดต dependency ตัวหนึ่งแล้ว throughput ลดลง 15% ถ้าใครตั้งใจหลบการตรวจจริง ๆ มันก็เป็นสถานการณ์ที่ต่างออกไปมากทั้งในทางปฏิบัติและทางกฎหมายจากการแอบปล่อย quantization ที่ถูกกว่ามาเงียบ ๆ
    • คิดว่าทั้งใช่และไม่ใช่ ถ้าเป็นผู้ไม่หวังดีจริง ๆ ความกังวลนั้นก็ถูกต้อง แต่กลไกนี้เปลี่ยนสถานการณ์จาก "การ quantize โมเดลแล้วไม่บอกก็ยังไม่ใช่การฉ้อโกงแบบชัดเจน" ไปเป็น "ปล่อยให้ผ่านการตรวจด้วยโมเดลหนึ่ง แต่ประมวลผลคำขอลูกค้าจริงด้วยอีกโมเดลหนึ่ง" ซึ่งเป็น การฉ้อโกงโดยเจตนา น่าจะมีผู้เล่นกึ่งไม่หวังดีจำนวนมากที่ยอมทำแค่อย่างแรก แต่ไม่กล้าทำถึงขั้นหลัง
    • สำหรับระบบแบบนี้ มันดูเป็นโจทย์ท้าทายที่ดีทีเดียว เช่นทำให้นึกถึงกรณีที่ fromtier labs เสิร์ฟโมเดล quantized ภายใต้ภาวะ โหลดสูง
  • นี่ก็เป็นปัญหาจริงใน benchmark ของเราเหมือนกัน ควรระวังผู้ให้บริการ OpenRouter ที่ไม่ระบุระดับ quantization หรือใช้ระดับที่ต่ำกว่าที่คาดไว้ OpenRouter มีตัวเลือกการตั้งค่าที่เกี่ยวข้องก็จริง แต่พอใช้แล้วตัวเลือกที่เหลือมักลดลงมาก แยกจากประเด็นนั้น แม้จะใช้ผู้ให้บริการที่ดีที่สุด Kimi-K2-thinking ก็ยังค่อนข้างน่าผิดหวังและช้าใน benchmark ของเรา แต่ก็น่าสนใจและมีประโยชน์ในแง่ของอุณหภูมิและความหลากหลาย ส่วน Kimi K2.6 ตอนนี้ดูเหมือนจะเป็น ผู้นำโอเพนซอร์ส คนใหม่ การประเมินแบบ agent ก็กำลังทำอยู่ และ benchmark การให้เหตุผลด้านการเขียนโค้ดแบบ one-shot ก็ พร้อมแล้ว
    • ใน OpenRouter มีตัวเลือก exacto ที่ทำให้เอนเอียงไปเลือกผู้ให้บริการคุณภาพสูงกว่าสำหรับโมเดลบางตัว อยากรู้ว่าเคยได้ประโยชน์จากมันไหม อีกอย่าง Kimi K2 บอกว่าใช้ int4 ทั้งตอนฝึกและตอน inference ดังนั้นพอดูการพูดคุยนี้ ก็เลยคิดว่าผู้ทำ gguf แต่ละรายอาจแปลงต่างกันจนกระทบคุณภาพได้
  • การทดสอบที่รันนานถึง 15 ชั่วโมงบนฮาร์ดแวร์แรง ๆ แบบนี้คงไม่ง่ายที่จะทำซ้ำหรือขยายขนาด แต่ถึงอย่างนั้นมันก็แตะความกังวลที่แพร่หลายมากในหลายบริการคลาวด์ได้ตรงจุด ประเด็นสำคัญคือ สิ่งที่ผม ping ไป อาจไม่ใช่สิ่งเดียวกับที่ผมได้รับจริง ๆ
    • ในความเข้าใจของผม เป้าหมายแรกของการทดสอบนี้คือ ตัว vendor เอง มากกว่าผู้ใช้ เหตุผลที่การทดสอบยาวและครอบคลุมก็เพื่อให้ vendor มั่นใจในคุณภาพของการโฮสต์เอง
    • ตอนแรกอาจรันทั้งชุดหนึ่งรอบต่อ vendor แล้วหลังจากนั้นค่อยหมุนรันแต่ละส่วนทุก 2 สัปดาห์หรือ 4 สัปดาห์เพื่อเลียนแบบรูปแบบการใช้งานทั่วไป แบบนั้นก็จะรักษาผลการประเมินให้ อัปเดตอยู่เสมอ ตามเวลาได้
  • ดีใจที่มีสิ่งนี้อยู่ ผู้ให้บริการ inference มักแอบสลับระดับ quantization เงียบ ๆ และผู้ใช้ส่วนใหญ่ก็ไม่ตรวจด้วยซ้ำ ตัวตรวจสอบมาตรฐาน ที่ผู้สร้างโมเดลออกมาให้น่าจะใกล้เคียงคำตอบที่สุด และอยากให้แล็บอื่น ๆ ปล่อยอะไรคล้าย ๆ กันด้วย
  • คิดว่าบทความที่เกี่ยวข้องจาก fireworks.ai ซึ่งอธิบายว่าทำไมถึงต้องมีตัวตรวจสอบแบบนี้เมื่อรันโมเดล open-weight ก็น่าอ่านเหมือนกัน คือ quality-first with kimi k2p5
  • น่าสังเกตว่า ต่อจาก Anthropic แล้ว Moonshot ก็เป็นผู้ให้บริการโมเดลอีกรายที่จำกัดการปรับ sampling parameter ถึงอย่างนั้นก็ชอบไอเดียของ vendor verifier เอง
    • อยากรู้ว่าตรงนี้ที่ว่า "จำกัดการปรับ sampling parameter" หมายถึงอะไร
    • ถ้าการฝึกแบบ post-training ทำมาภายใต้ sampling parameter ชุดหนึ่ง ผมคิดว่าการใช้งานจริงก็ควรสอดคล้องกับ พารามิเตอร์ที่ใช้ฝึก
  • รู้สึกว่านี่เป็นแนวคิดที่ยอดเยี่ยมจริง ๆ ผมดูแล AI gateway ชื่อ Glama และเคยเห็นผู้ให้บริการภายนอกบางราย โกหกหน้าตาเฉย เรื่อง quantization จนต้องถอดออกจากรายการทั้งหมด ถ้าตรวจสอบผู้ให้บริการได้ ก็น่าจะปรับปรุงครั้งใหญ่เพราะทำให้เรากล้าเสนอชุดผู้ให้บริการที่หลากหลายมากขึ้น
  • กังวลว่าถ้า vendor เริ่มปรับแต่งให้เข้ากับ benchmark KVV ทั้ง 6 ชุด สุดท้ายเราจะวัดแค่ การทำตาม KVV แทนที่จะวัดความซื่อตรงของโมเดลหรือเปล่า เลยสงสัยว่ามีกลยุทธ์การหมุนเวียนเพื่อป้องกันเรื่องนี้หรือไม่