Kimi 팀이 오픈소스로 푼 'Vendor Verifier' — 추론 벤더가 모델을 제대로 돌리는지 검증하는 도구

• Kimi 팀이 K2.6 모델 공개와 함께 Kimi Vendor Verifier (KVV) 를 오픈소스로 풀었음 — 오픈소스 모델을 돌리는 각종 추론 벤더들이 "제대로 돌리고 있는지"를 검증하는 도구임
  • 핵심 문제의식은 단순함 — "가중치만 공개하는 건 절반에 불과하다. 나머지 절반은 아무 데서나 올바르게 돌아가게 만드는 일이다"
  • "Chain of Trust를 다시 세운다"는 게 프로젝트 슬로건

왜 만들었나 — 벤치마크 이상치가 일회성이 아니라 시스템 문제였음

• K2 Thinking 출시 후 커뮤니티에서 벤치마크 점수 이상치 제보가 반복적으로 들어옴
  • 조사해보니 상당수가 디코딩 파라미터 오용 때문 — 1차 방어선으로 Thinking 모드에서 Temperature=1.0, TopP=0.95 강제 + thinking content가 제대로 전달되는지 검증 의무화
• 그런데 더 미묘한 케이스가 등장 — LiveBenchmark 평가에서 3rd party API와 공식 API 간 점수 격차가 극심함
  • 여러 인프라 프로바이더를 테스트한 결과 이 현상이 특정 업체 문제가 아니라 광범위한 이슈로 드러남

여섯 개 벤치 — 각각이 특정 인프라 결함을 잡도록 설계됨

• Pre-Verification — API 파라미터 제약(temperature, top_p 등)이 제대로 강제되는지 사전 검증. 통과해야 나머지 벤치 진입
• OCRBench — 5분짜리 멀티모달 파이프라인 스모크 테스트
• MMMU Pro — 다양한 시각 입력으로 Vision input 전처리 검증
• AIME2025 — 긴 출력 스트레스 테스트
  • 짧은 벤치에서는 숨겨지는 KV cache 버그와 양자화(quantization) degradation을 잡는 용도
• K2VV ToolCall — 트리거 일관성(F1) + JSON Schema 정확도 측정
  • "에이전트에서 툴 에러는 복리로 불어나니 일찍 잡는다"
• SWE-Bench — 풀 에이전틱 코딩 테스트 (샌드박스 의존성 때문에 오픈소스화는 안 됨)

단순 "감지"를 넘어서 — 업스트림 직접 수정 + 사전 검증 + 공개 리더보드

• vLLM, SGLang, KTransformers 커뮤니티에 직접 들어가서 루트 원인을 고침 — 증상 감지가 아니라 원인 제거

• Pre-Release Validation — 배포 후 컴플레인을 기다리지 않고, 인프라 프로바이더에게 모델 사전 접근 권한을 줘서 스택을 미리 검증하게 함

• 공개 리더보드 유지 — 벤더별 결과가 공개되니 정확도 경쟁이 붙는 구조

• 테스트 비용은 NVIDIA H20 8-GPU 서버 2대로 순차 실행 시 약 15시간

  • 스트리밍 추론, 자동 재시도, 체크포인트 resume 기능이 스크립트에 내장

• 마무리 메시지도 명확함 — "가중치가 열려 있다면, 그걸 올바르게 돌리는 지식도 열려 있어야 한다"

---

기술 맥락

오픈소스 LLM 생태계가 직면한 진짜 고통은 "모델을 공개했는데 사람들이 똑같이 안 돌아간다"는 거예요. Kimi 팀이 KVV를 만든 이유도 여기에 있어요. 가중치 파일은 바이트 단위로 동일해도, 추론 서버가 quantization을 어떻게 적용하느냐, KV cache를 어떻게 관리하느냐, top_p 파라미터를 서버 단에서 강제하느냐에 따라 최종 출력 품질이 크게 갈리거든요.

특히 문제가 되는 구간이 long-output 시나리오예요. AIME 같은 수학 벤치는 긴 체인 오브 쏘트(CoT)를 생성하는데, 이 과정에서 KV cache의 메모리 관리 버그나 quantization에서 발생하는 누적 오차가 답을 틀리게 만들어요. 짧은 QA 벤치에서는 멀쩡하다가 긴 출력에서 무너지는 케이스를 AIME2025가 노려서 잡는 구조예요.

ToolCall 벤치를 별도로 둔 이유도 흥미로워요. 에이전트 워크플로우에서는 한 번의 툴 호출 실패가 다음 스텝 전체를 틀어버리는 복리 효과가 나거든요. 그래서 F1(트리거 일관성)과 JSON Schema 정확도를 같이 측정해서 "포맷이 맞는지" "타이밍이 맞는지"를 동시에 본다는 게 설계 포인트예요.

Kimi 팀이 vLLM, SGLang, KTransformers 같은 추론 엔진 업스트림에 직접 패치를 넣겠다고 한 대목도 중요해요. 단순히 "우리 벤더 정확도 점수가 낮네요"라고 리더보드에 박제하는 수준이 아니라, 근본 원인을 추론 엔진 단에서 해결하겠다는 거예요. 모델 개발사가 인프라 레이어까지 책임지는 형태라, 오픈소스 LLM의 품질 보증 책임이 어디까지 확장되는지 보여주는 사례예요.