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

 (kimi.com)
3 पॉइंट द्वारा GN⁺ 8 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • 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 की खोज जारी है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.