Kimi Vendor Verifier – Überprüfung der Genauigkeit von Inferenzanbietern

• Kimi Vendor Verifier (KVV) ist ein öffentliches Tool, das nach der Bereitstellung von Open-Source-Modellen Abweichungen in der Inferenzimplementierung zwischen unterschiedlichen Infrastrukturen überprüft, damit sich modellbedingte Grenzen von Engineering-Fehlern unterscheiden lassen
• Auf Basis der offiziellen API werden OCRBench 91.0, AIME2025 avg@32 98.4 und MMMU Pro Vision 78.8 angegeben; außerdem werden für jede Bewertung die Einstellungen für Temperature, TopP und MaxTokens sowie die Ergebnisdateien der K2VV-Bewertung offengelegt
• Die Untersuchung von in der Community gemeldeten Benchmark-Auffälligkeiten ergab, dass ein erheblicher Teil auf falsch verwendete Decoding-Parameter zurückzuführen war; im Thinking-Modus werden daher Temperature 1.0 und TopP 0.95 erzwungen und zusätzlich die korrekte Weitergabe der Inhalte geprüft
• Das Validierungsverfahren ist so aufgebaut, dass nach einer Vorabprüfung der Parameterbeschränkungen mit OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench usw. Vision-Preprocessing, lange Ausgaben, Tool-Aufrufe bis hin zu agentic coding überprüft werden
• Der gesamte Workflow benötigt bei sequenzieller Ausführung auf zwei NVIDIA-H20-8-GPU-Servern etwa 15 Stunden; mit einem öffentlichen Leaderboard und Early Access soll die Verbreitung einer Validierung mit Priorität auf Genauigkeit vorangetrieben werden

---

Wiederaufbau einer Vertrauenskette (Chain of Trust)

• Mit der Veröffentlichung des Kimi Vendor Verifier (KVV)-Quellcodes wurde das System so konzipiert, dass Nutzer von Open-Source-Modellen die Korrektheit der Inferenzimplementierung überprüfen können
• Es wurde zeitgleich mit dem Kimi-K2.6-Modell veröffentlicht; die bloße Veröffentlichung eines Modells reicht nicht aus, sondern es braucht auch einen Prozess zur Prüfung, ob es in unterschiedlichen Umgebungen korrekt funktioniert
• Je weiter im Open-Source-Modell-Ökosystem die Veröffentlichung von Gewichten und die Vielfalt der Bereitstellungspfade voranschreitet, desto deutlicher wird eine Struktur, in der die Möglichkeiten zur Qualitätskontrolle abnehmen
• Wenn Nutzer Leistungsdefizite des Modells selbst nicht von Abweichungen in der Engineering-Implementierung unterscheiden können, kann das Vertrauen in das Open-Source-Ökosystem zusammenbrechen

Lösungsansatz

• Von einzelnen Auffälligkeiten zu einem strukturellen Problem

  • Seit der Veröffentlichung von K2 Thinking gingen aus der Community häufig Rückmeldungen zu auffälligen Benchmark-Ergebnissen ein
  • Die Untersuchung zeigte, dass ein erheblicher Teil der Fälle auf falsch verwendete Decoding-Parameter zurückzuführen war
  • Als sofortige Gegenmaßnahme wurde auf API-Ebene eine erste Verteidigungslinie eingerichtet
    • Im Thinking-Modus werden Temperature=1.0 und TopP=0.95 erzwungen
    • Es wird eine verpflichtende Prüfung angewendet, ob Thinking-Inhalte korrekt erneut übermittelt werden
  • Bei bestimmten LiveBenchmark-Auswertungen wurde ein großer Unterschied zwischen Drittanbieter-APIs und der offiziellen API beobachtet
  • Umfangreiche Tests mit verschiedenen Infrastrukturanbietern bestätigten, dass diese Unterschiede breit verbreitet sind

• Validierungsverfahren und Betrieb

  • Veröffentlichung der Benchmark-Werte auf Basis der offiziellen API
    • OCRBench Genauigkeit 91.0
    • AIME2025 avg@32 98.4
    • MMMU Pro Vision Genauigkeit 78.8
  • Die Konfigurationswerte der Evaluierung werden ebenfalls angegeben
    • Für alle drei Punkte werden Temperature 1.0 und TopP 0.95 verwendet
    • MaxTokens beträgt bei OCRBench 16384, bei AIME2025 98304 und bei MMMU Pro Vision 65536
  • Es wird ein Link zur Datei mit den Kimi API K2VV Evaluation Results bereitgestellt; angegeben ist, dass sie zur Berechnung des F1-Scores dient
  • Betrieb einer Pre-Verification-Phase
    • Es wird überprüft, ob API-Parameterbeschränkungen wie temperature und top_p korrekt erzwungen werden
    • Erst wenn alle Tests bestanden sind, wird die Benchmark-Evaluierung durchgeführt
  • Einsatz von OCRBench
    • Dient als 5-minütiger Smoke-Test für multimodale Pipelines
  • Einsatz von MMMU Pro
    • Überprüft durch verschiedene visuelle Eingaben das Preprocessing von Vision-Eingaben
  • Einsatz von AIME2025
    • Dient als Stresstest für lange Ausgaben
    • Erkennt KV-Cache-Bugs und Leistungseinbußen durch Quantisierung, die in kurzen Benchmarks nicht sichtbar werden
  • Einsatz von K2VV ToolCall
    • Misst Trigger-Konsistenz (F1) und die Genauigkeit des JSON Schema
    • Dient der frühen Erkennung, bevor sich Tool-Fehler in Agenten aufschaukeln
  • Einsatz von SWE-Bench
    • Dient als vollständiger agentic coding test
    • Wird wegen Sandbox-Abhängigkeiten nicht als Open Source veröffentlicht
  • Zusammenarbeit mit den Communities von vLLM, SGLang und KTransformers
  • Ziel ist nicht nur die Erkennung von Symptomen, sondern die Behebung der Grundursachen
  • Statt nach der Bereitstellung auf Beschwerden zu warten, erhalten Infrastrukturanbieter frühen Zugang
  • So können Anbieter ihren eigenen Stack validieren, bevor Nutzer auf Probleme stoßen
  • Ein öffentliches Leaderboard für die Ergebnisse der Anbieter soll dauerhaft betrieben werden
  • Diese Transparenz ist darauf ausgelegt, bei Anbietern die Priorität für Genauigkeit zu erhöhen
  • Die Validierung des gesamten Evaluierungs-Workflows wurde abgeschlossen
    • Verwendet wurden zwei NVIDIA-H20-8-GPU-Server
    • Bei sequenzieller Ausführung beträgt die Laufzeit etwa 15 Stunden
  • Die Skripte wurden für langlaufende Inferenzszenarien optimiert
    • Streaming-Inferenz
    • automatische Wiederholungsversuche
    • einschließlich eines Mechanismus zum Fortsetzen per Checkpoint
  • Es wird der Grundsatz formuliert, dass mit der Veröffentlichung der Gewichte auch das Wissen über ihre korrekte Ausführung offengelegt werden sollte
  • Die Ausweitung der Vendor-Abdeckung und die Erkundung leichterer agentic tests laufen weiter

[ng0301]

Ich hoffe wirklich, dass dieses Projekt erfolgreich wird.

[GN⁺]

Hacker-News-Kommentare

• Mir gefällt diese Idee. Das könnte ziemlich wirksamer sozialer Druck sein, damit Inference-Anbieter alte Probleme beheben. Zum Beispiel hat AWS Bedrock einen kritischen Fehler im Serving-Stack für Kimis K2- und K2.5-Modelle, wodurch 20–30 % der Versuche, bei denen Tool-Calls ausgegeben werden müssten, die Unterhaltung stillschweigend ohne Token-Ausgabe beenden. Damit ist AWS als ernstzunehmender Inference-Anbieter für Kimi praktisch wertlos und scheint Nutzer stattdessen in teurere Anthropic-Modelle mit ähnlicher Agent-Task-Performance zu drängen
  • Das ist keine neue Geschichte, Kimi macht das meiner Ansicht nach schon seit Monaten. Es gab bereits den K2 Vendor Verifier und den Kimi Vendor Verifier, sogar schon vor dem Release von K2.5 und K2.6
• So wie ich das Bedrohungsmodell verstehe, geht es eher darum, versehentliche Performance-Verschlechterungen zu verhindern, nicht darum, auch böswillige Akteure abzudecken. Wenn zum Beispiel ein dubioser Anbieter behauptet, das neueste Spitzenmodell laufen zu lassen, tatsächlich aber ein billigeres und schwächeres Modell nutzt und die Differenz einstreicht, dann helfen solche Tests womöglich nicht viel. Wenn erkannt wird, dass gerade getestet wird, könnte man es wie beim Volkswagen-Abgasskandal genau dann korrekt funktionieren lassen
  • Anbieter wie OpenRouter wählen standardmäßig den billigsten Provider, und oft ist er deshalb billig, weil dort zugunsten des Durchsatzes übermäßige Quantisierung und Tuning eingesetzt werden statt Qualität. Daher wirkt das wie ein Versuch von Kimi, zu verhindern, dass Billiganbieter der Marke schaden, weil ihre Leistung die Modellqualität nicht angemessen repräsentiert
  • Schon versehentlich entstandenen Drift zu erkennen, ist meiner Meinung nach sehr wertvoll. Das ist fast dieselbe Idee wie Performance-Regressionstests in CI, und man setzt sie nicht ein, weil man erwartet, dass jemand absichtlich etwas kaputtmacht. Meist geht es darum, ganz normale Probleme zu finden, etwa wenn durch ein Dependency-Update der Durchsatz um 15 % sinkt. Wenn jemand die Prüfung absichtlich umgeht, ist das auch rechtlich eine ganz andere Lage, als einfach stillschweigend eine billigere Quantisierung auszuliefern
  • Ich würde sagen: teils ja, teils nein. Bei wirklich böswilligen Akteuren ist die Sorge berechtigt. Aber diese Vorrichtung verschiebt die Lage von „Ein Modell zu quantisieren und es nicht offenzulegen ist nicht eindeutig Betrug“ hin zu „Die Verifikation mit einem Modell zu bestehen und echte Kundenanfragen dann mit einem anderen Modell zu bedienen ist vorsätzlicher Betrug“. Es dürfte etliche halb böswillige Akteure geben, die nur Ersteres bereitwillig tun würden
  • Das wirkt wie eine ziemlich gute Herausforderung für solche Systeme. Es erinnert mich zum Beispiel an Fälle, in denen fromtier labs unter hoher Last quantisierte Modelle ausliefert
• Das war auch in unseren Benchmarks ein reales Problem. Bei OpenRouter-Anbietern sollte man vorsichtig sein, wenn sie den Quantisierungsgrad nicht angeben oder einen niedrigeren als erwartet verwenden. OpenRouter bietet dafür zwar entsprechende Konfigurationsoptionen, aber dann schrumpft die Auswahl oft stark. Unabhängig davon war Kimi-K2-thinking in unseren Benchmarks selbst beim besten Anbieter eher enttäuschend und langsam, aber in Bezug auf Temperatur und Varianz interessant und nützlich. Dagegen wirkt Kimi K2.6 bisher wie der neue Open-Source-Spitzenreiter. Agent-Evaluierungen laufen noch, und der One-Shot-Coding-Reasoning-Benchmark ist bereits verfügbar
  • Bei OpenRouter gibt es die Option exacto, mit der bei bestimmten Modellen Anbieter mit höherer Qualität bevorzugt werden. Mich würde interessieren, ob du damit schon Vorteile gesehen hast. Außerdem heißt es, dass Kimi K2 sowohl beim Training als auch bei der Inferenz int4 nutzt, und wenn man sich die Diskussion dazu ansieht, könnte es sein, dass verschiedene GGUF-Ersteller die Konvertierung unterschiedlich vornehmen und dadurch die Qualität beeinflussen
• Ich glaube nicht, dass ein Test, der auf leistungsstarker Hardware 15 Stunden läuft, leicht zu reproduzieren oder zu skalieren ist. Trotzdem trifft er eine weit verbreitete Sorge über viele Cloud-Dienste hinweg gut. Der Kern ist, dass das Ziel, das ich angepingt habe, womöglich nicht das ist, was ich tatsächlich bekomme
  • Meiner Interpretation nach ist das erste Ziel dieses Tests eher der Anbieter selbst als der Nutzer. Dass der Test lang und umfassend ist, verstehe ich so, dass er dem Anbieter Vertrauen in die Qualität seines Self-Hostings geben soll
  • Ich denke, man könnte pro Anbieter zunächst einmal die gesamte Suite laufen lassen und danach alle Teile in einem Rhythmus von zwei oder vier Wochen rotierend ausführen, um typische Nutzungsmuster nachzuahmen. So ließe sich die Bewertung über die Zeit aktuell halten
• Gut, dass es so etwas gibt. Inference-Anbieter tauschen stillschweigend gern den Quantisierungsgrad aus, und die meisten Nutzer prüfen das nicht einmal. Ein Standard-Validator vom Modellhersteller kommt der richtigen Antwort am nächsten, und es wäre gut, wenn auch andere Labs etwas Ähnliches herausgeben würden
• Lesenswert ist auch der zugehörige Beitrag von fireworks.ai, der erklärt, warum man beim Betrieb von Open-Weight-Modellen solche Validatoren braucht: quality-first with kimi k2p5
• Auffällig ist, dass Moonshot nach Anthropic ebenfalls ein Modellanbieter ist, der die Anpassung von Sampling-Parametern einschränkt. Trotzdem gefällt mir die Idee des Vendor Verifier an sich
  • Ich frage mich, was hier genau mit „die Anpassung von Sampling-Parametern einschränken“ gemeint ist
  • Wenn das Post-Training mit bestimmten Sampling-Parametern erfolgt ist, dann ist es meiner Meinung nach sinnvoll, die reale Nutzung ebenfalls an diesen trainierten Parametern auszurichten
• Das ist wirklich eine hervorragende Idee. Ich betreibe das AI-Gateway Glama und habe gesehen, dass einige Drittanbieter bei der Quantisierung ganz offen lügen, weshalb ich sie komplett aus dem Verzeichnis entfernt habe. Wenn man Anbieter verifizieren kann, wäre das eine große Verbesserung, weil man dann mit mehr Vertrauen vielfältigere Anbieter-Konfigurationen anbieten könnte
• Ich mache mir Sorgen, dass wir am Ende nur noch KVV-Konformität messen statt Modelltreue, wenn Anbieter anfangen, auf die 6 KVV-Benchmarks hin zu optimieren. Mich würde interessieren, ob es eine Rotationsstrategie gibt, um das zu verhindern