Kimi Vendor Verifier - inference providers की accuracy का सत्यापन

• Kimi Vendor Verifier(KVV) एक सार्वजनिक टूल है, जो ओपन सोर्स मॉडल डिप्लॉयमेंट के बाद अलग-अलग infrastructure में होने वाले inference implementation drift को सत्यापित करता है, ताकि मॉडल की अपनी सीमाओं और engineering errors में फर्क किया जा सके
• आधिकारिक API के आधार पर OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8 प्रस्तुत किए गए हैं, और हर evaluation के Temperature, TopP, MaxTokens settings के साथ K2VV evaluation result files भी सार्वजनिक किए गए हैं
• कम्युनिटी में रिपोर्ट किए गए benchmark anomalies की जांच में पता चला कि उनमें से काफी मामले decoding parameters के गलत उपयोग से आए थे, और Thinking mode में Temperature 1.0 तथा TopP 0.95 को अनिवार्य किया गया है, साथ ही content retransmission verification भी लागू किया गया है
• verification procedure में parameter constraints की पुष्टि के लिए pre-verification के बाद OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench आदि का उपयोग कर Vision preprocessing, long-form output, tool calling, और agentic coding तक जांच की जाती है
• पूरा workflow NVIDIA H20 8-GPU सर्वर की दो मशीनों पर sequential execution के आधार पर लगभग 15 घंटे लेता है, और सार्वजनिक leaderboard तथा early access के जरिए accuracy-first verification को फैलाने की कोशिश की जा रही है

---

भरोसे की शृंखला(Chain of Trust) का पुनर्निर्माण

• Kimi Vendor Verifier(KVV) स्रोत को सार्वजनिक करने के साथ इसे इस तरह डिज़ाइन किया गया है कि ओपन सोर्स मॉडल उपयोगकर्ता inference implementation accuracy को सत्यापित कर सकें
• इसे Kimi K2.6 मॉडल की रिलीज़ के साथ ही वितरित किया गया, क्योंकि सिर्फ मॉडल को सार्वजनिक करना पर्याप्त नहीं है; यह भी जरूरी है कि वह अलग-अलग environments में सही तरह काम करता है या नहीं इसकी जांच हो
• जैसे-जैसे ओपन सोर्स मॉडल ecosystem में weights public किए जा रहे हैं और deployment paths विविध हो रहे हैं, quality control की क्षमता कम होने वाली संरचना सामने आ रही है
• यदि उपयोगकर्ता मॉडल की वास्तविक performance limitations और engineering implementation drift में फर्क नहीं कर पाते, तो ओपन सोर्स ecosystem पर भरोसा टूट सकता है

समाधान का तरीका

• व्यक्तिगत anomalies से structural issue तक विस्तार

  • K2 Thinking के सार्वजनिक होने के बाद, कम्युनिटी से benchmark score anomalies पर फीडबैक बार-बार मिला
  • जांच में पुष्टि हुई कि काफी मामले decoding parameters के गलत उपयोग से जुड़े थे
  • तत्काल mitigation के रूप में API स्तर पर पहली defense line बनाई गई
    • Thinking mode में Temperature=1.0, TopP=0.95 अनिवार्य
    • thinking content सही तरह से दोबारा भेजा जा रहा है या नहीं, इसके लिए अनिवार्य verification लागू
  • कुछ खास LiveBenchmark evaluations में third-party API और आधिकारिक API के बीच बड़ा अंतर देखा गया
  • कई infrastructure providers पर व्यापक परीक्षण के बाद पुष्टि हुई कि यह अंतर काफी व्यापक रूप से मौजूद है

• verification procedure और operations

  • आधिकारिक API आधारित benchmark metrics सार्वजनिक
    • OCRBench accuracy 91.0
    • AIME2025 avg@32 98.4
    • MMMU Pro Vision accuracy 78.8
  • evaluation settings भी साथ में स्पष्ट की गईं
    • तीनों में Temperature 1.0, TopP 0.95 का उपयोग
    • MaxTokens: OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
  • Kimi API K2VV evaluation result file link उपलब्ध कराया गया, और बताया गया कि इसका उपयोग F1 score calculation के लिए है
  • Pre-Verification चरण संचालित
    • temperature, top_p जैसे API parameter constraints सही तरह से enforce हो रहे हैं या नहीं, इसकी जांच
    • सभी tests पास होने के बाद ही benchmark evaluation आगे बढ़ती है
  • OCRBench का उपयोग
    • multimodal pipeline के लिए 5 मिनट का smoke test
  • MMMU Pro का उपयोग
    • विविध visual inputs की जांच के जरिए Vision input preprocessing का सत्यापन
  • AIME2025 का उपयोग
    • long-form output stress test की भूमिका
    • छोटे benchmarks में न दिखने वाले KV cache bugs और quantization performance degradation को पकड़ना
  • K2VV ToolCall का उपयोग
    • trigger consistency(F1) और JSON Schema accuracy को मापना
    • agents में tool errors के जमा होने से पहले शुरुआती पहचान
  • SWE-Bench का उपयोग
    • पूर्ण agentic coding test की भूमिका
    • sandbox dependency के कारण इसे open source नहीं किया गया
  • vLLM, SGLang, KTransformers कम्युनिटी के साथ मिलकर काम
  • केवल symptoms detection पर नहीं, बल्कि root cause fixes पर जोर
  • deployment के बाद शिकायतों का इंतजार करने के बजाय infrastructure providers को early access दिया गया
  • इसे इस तरह बनाया गया कि उपयोगकर्ताओं को समस्या होने से पहले हर provider अपने stack को सत्यापित कर सके
  • vendors के results के लिए सार्वजनिक leaderboard लगातार चलाया जाएगा
  • इसे इस तरह डिज़ाइन किया गया है कि ऐसी transparency vendors में accuracy prioritization को बढ़ाए
  • पूरे evaluation workflow का verification पूरा
    • NVIDIA H20 8-GPU सर्वर की दो मशीनें इस्तेमाल की गईं
    • sequential execution के आधार पर लगभग 15 घंटे लगे
  • लंबे inference scenarios के लिए scripts optimization लागू
    • streaming inference
    • automatic retry
    • checkpoint resume mechanism शामिल
  • यह सिद्धांत स्पष्ट किया गया कि जब weights सार्वजनिक हैं, तो उन्हें सही ढंग से चलाने का ज्ञान भी सार्वजनिक होना चाहिए
  • vendor coverage बढ़ाने और अधिक हल्के agentic tests की खोज जारी है

[ng0301]

उम्मीद है यह प्रोजेक्ट सच में बहुत अच्छा बनेगा।

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे यह आइडिया पसंद आया। ऐसा लगता है कि यह reasoning providers पर पुराने मुद्दे ठीक करवाने के लिए काफी असरदार सामाजिक दबाव बना सकता है। उदाहरण के लिए, AWS Bedrock में Kimi के K2 और K2.5 model serving stack में एक गंभीर खामी है, जिसकी वजह से 20%~30% प्रयासों में, जहाँ tool call निकलनी चाहिए, बातचीत बिना कोई token output दिए चुपचाप खत्म हो जाती है। इसलिए AWS, Kimi के लिए एक गंभीर reasoning provider के रूप में लगभग बेकार हो जाता है, और ऐसा लगता है कि यह users को समान agent task performance के लिए अधिक महंगे Anthropic models की ओर धकेलता है
  • यह कोई नई बात नहीं है; मेरी समझ से Kimi यह काम पहले से कई महीनों से कर रहा है। K2 Vendor Verifier, Kimi Vendor Verifier भी पहले से मौजूद थे, और यह K2.5 तथा K2.6 रिलीज़ से भी पहले का है
• मेरी समझ में threat model का फोकस गलती से होने वाली performance degradation को रोकना है, न कि malicious actors तक को cover करना। उदाहरण के लिए, अगर कोई संदिग्ध provider कहे कि वह सबसे नया top model चला रहा है, लेकिन वास्तव में सस्ता और कम performant model इस्तेमाल करके मार्जिन रख रहा हो, तो ऐसे tests बहुत मददगार नहीं हो सकते। क्योंकि यदि उसे पता चल जाए कि testing चल रही है, तो वह Volkswagen emissions scandal की तरह उसी समय सही तरह से behave करने का दिखावा कर सकता है
  • OpenRouter जैसे providers मूल रूप से सबसे सस्ता provider चुनते हैं, और कई बार वह सस्ता इसलिए होता है क्योंकि quality की जगह throughput के लिए अत्यधिक quantization और tuning की गई होती है। इसलिए यह Kimi की ऐसी कोशिश लगती है कि सस्ते providers model performance को सही तरह represent न करके उसके brand को नुकसान न पहुँचाएँ
  • सिर्फ accidental drift पकड़ लेना भी बहुत मूल्यवान है। यह लगभग CI के performance regression tests जैसा ही विचार है, और इसका उद्देश्य यह मानकर चलना नहीं है कि कोई जानबूझकर चीज़ें तोड़ेगा। आम तौर पर इसका उपयोग ऐसे साधारण मुद्दे पकड़ने के लिए होता है जैसे किसी dependency को upgrade करने पर throughput 15% गिर जाना। अगर कोई जानबूझकर checks को bypass करता है, तो वह बस चुपचाप सस्ती quantization push करने से कानूनी रूप से भी काफी अलग स्थिति बन जाती है
  • मेरे हिसाब से यह बात सही भी है और नहीं भी। यदि actor वास्तव में malicious हो, तो चिंता जायज़ है। लेकिन यह व्यवस्था स्थिति को "model को quantize करके भी न बताना स्पष्ट fraud नहीं है" से बदलकर "verification एक model से pass कराना और वास्तविक customer requests किसी दूसरे model से process करना जानबूझकर किया गया fraud है" में बदल देती है। मुझे लगता है कि ऐसे काफी अर्ध-दुराशयी खिलाड़ी होंगे जो पहले वाली हद तक तो जाने को तैयार हों, पर दूसरी तक नहीं
  • यह ऐसे systems के लिए काफी अच्छी चुनौती लगती है। उदाहरण के लिए, यह fromtier labs के high-load परिस्थितियों में quantized models serve करने के मामलों की याद दिलाता है
• यह हमारे benchmarks में भी एक वास्तविक समस्या थी। OpenRouter providers में जो quantization level स्पष्ट नहीं बताते, या अपेक्षा से भी निचला स्तर इस्तेमाल करते हैं, उनसे सावधान रहना चाहिए। OpenRouter इसके लिए संबंधित config options देता है, लेकिन ऐसा करने पर अक्सर विकल्प बहुत कम रह जाते हैं। उससे अलग, सबसे अच्छे provider के साथ भी Kimi-K2-thinking हमारे benchmarks में कुछ निराशाजनक और धीमा था, लेकिन temperature और variation के लिहाज़ से रोचक और उपयोगी था। दूसरी ओर, Kimi K2.6 अभी तक नया open source leader लगता है। Agent evaluations भी चल रहे हैं, और one-shot coding reasoning benchmark पहले से तैयार है
  • OpenRouter में exacto option है, जो किसी खास model के लिए higher-quality providers को prefer करने देता है। जानना चाहूँगा कि क्या आपने उसे इस्तेमाल करके कोई फायदा देखा है। साथ ही, Kimi K2 training और inference दोनों में int4 का उपयोग करता है, इसलिए संबंधित चर्चा देखकर लगता है कि अलग-अलग gguf creators अलग तरह से conversion करते होंगे, जिससे quality प्रभावित हो सकती है
• मेरा मानना है कि high-performance hardware पर 15 घंटे चलने वाला test पुनरुत्पादित करना या scale करना आसान नहीं है। फिर भी, यह कई cloud services में फैली एक व्यापक चिंता को ठीक से छूता है। मुख्य बात यह है कि जिसे मैं ping कर रहा हूँ वह वास्तव में वही न हो जो मुझे मिल रहा है
  • मेरी व्याख्या में इस test का पहला target user नहीं, बल्कि vendor खुद है। Test लंबा और व्यापक होने का कारण भी यही है; मेरी समझ में इसका उद्देश्य vendor को अपनी self-hosting quality पर भरोसा देना है
  • मेरा मानना है कि पहले हर vendor पर पूरा suite एक बार चलाया जाए, फिर हर 2 या 4 हफ्ते में उसके हिस्सों को घुमाकर चलाया जाए ताकि सामान्य usage patterns की नकल हो सके। इससे समय के साथ evaluation up-to-date रखा जा सकता है
• यह देखकर अच्छा लगा कि ऐसी चीज़ मौजूद है। Reasoning providers अक्सर quantization level चुपचाप बदल देते हैं, और ज़्यादातर users जाँच तक नहीं करते। Model creators द्वारा जारी standard verifier सबसे सही दिशा लगती है, और अच्छा होगा अगर दूसरी labs भी ऐसा कुछ जारी करें
• Open-weights models चलाने में ऐसे verifier की ज़रूरत क्यों पड़ती है, इस पर fireworks.ai की संबंधित पोस्ट भी देखने लायक है। यह है quality-first with kimi k2p5
• यह ध्यान देने योग्य है कि Anthropic के बाद Moonshot भी ऐसा model provider है जो sampling parameters को adjust करने की क्षमता सीमित करता है। फिर भी, vendor verifier का आइडिया मुझे पसंद है
  • यहाँ "sampling parameters को adjust करने की क्षमता सीमित करता है" से आपका क्या मतलब है, यह जानने की जिज्ञासा है
  • अगर post-training किसी खास sampling parameters के साथ हुई है, तो मेरा मानना है कि वास्तविक उपयोग को भी trained parameters के अनुरूप रखना तर्कसंगत है
• यह सचमुच शानदार विचार लगता है। मैं AI gateway Glama चलाता हूँ, और मैंने देखा है कि कुछ third-party providers quantization के बारे में खुलेआम झूठ बोलते हैं, इसलिए मैंने उन्हें पूरी तरह list से हटा दिया था। यदि providers को verify किया जा सके, तो मैं अधिक आत्मविश्वास से providers के अधिक विविध संयोजन दे पाऊँगा, जो बड़ा सुधार होगा
• मुझे चिंता है कि अगर vendors इन 6 KVV benchmarks के लिए optimize करना शुरू कर दें, तो अंततः हम model fidelity नहीं बल्कि सिर्फ KVV compliance ही मापेंगे। इसे रोकने के लिए क्या कोई rotation strategy तैयार की गई है?