Kimi 벤더 검증기 - 추론 제공자의 정확성 검증
(kimi.com)- 오픈소스 모델 배포 이후 서로 다른 인프라에서 발생하는 추론 구현 편차를 검증해, 모델 자체 한계와 엔지니어링 오류를 구분할 수 있게 한 공개소스 도구
- 공식 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까지 점검하는 구조
- 전체 워크플로는 NVIDIA H20 8-GPU 서버 두 대에서 순차 실행 기준 약 15시간이 소요되며, 공개 리더보드와 조기 접근 제공을 통해 정확성 우선 검증 확산 추진
신뢰 사슬 재구축
- Kimi Vendor Verifier(KVV) 공개소스화와 함께, 오픈소스 모델 사용자가 추론 구현 정확성을 검증할 수 있도록 설계됨
- Kimi K2.6 모델 공개와 동시에 배포됐으며, 모델 공개만으로는 충분하지 않고 다양한 환경에서 올바르게 동작하는지 확인하는 과정이 필요함
- 오픈소스 모델 생태계에서 가중치 공개와 배포 경로 다양화가 진행될수록, 품질 통제 가능성이 낮아지는 구조 드러남
- 사용자가 모델 자체 성능 결함과 엔지니어링 구현 편차를 구분하지 못하면, 오픈소스 생태계에 대한 신뢰가 무너질 수 있음
해결 방식
-
개별 이상 징후에서 구조적 이슈로 확대
- K2 Thinking 공개 이후, 커뮤니티에서 벤치마크 점수 이상 현상 관련 피드백이 자주 접수됨
- 조사 결과 상당수 사례가 디코딩 파라미터 오용에서 비롯된 것으로 확인됨
- 즉각적 완화 조치로 API 수준 1차 방어선 구축
- Thinking 모드에서 Temperature=1.0, TopP=0.95 강제
- 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 단계 운영
- temperature, top_p 등 API 파라미터 제약이 올바르게 강제되는지 검증
- 모든 테스트 통과 후에만 벤치마크 평가 진행
- OCRBench 사용
- 멀티모달 파이프라인 대상 5분 스모크 테스트 역할
- MMMU Pro 사용
- 다양한 시각 입력 테스트를 통해 Vision 입력 전처리 검증
- AIME2025 사용
- 장문 출력 스트레스 테스트 역할
- 짧은 벤치마크로는 드러나지 않는 KV cache 버그와 양자화 성능 저하 포착
- K2VV ToolCall 사용
- 트리거 일관성(F1)과 JSON Schema 정확성 측정
- 에이전트에서 도구 오류 누적 전 조기 탐지
- SWE-Bench 사용
- 전체 agentic coding 테스트 역할
- sandbox 의존성 때문에 공개소스화하지 않음
- vLLM, SGLang, KTransformers 커뮤니티와 함께 작업
- 증상 탐지에 그치지 않고 근본 원인 수정 지향
- 배포 후 불만 접수를 기다리는 대신, 인프라 제공자에게 조기 접근 권한 제공
- 사용자가 문제를 겪기 전에 각 제공자가 자신의 스택을 검증할 수 있도록 구성
- 벤더 결과에 대한 공개 리더보드 지속 운영 예정
- 이런 투명성이 벤더의 정확성 우선순위 제고로 이어지도록 설계됨
- 전체 평가 워크플로 검증 완료
- NVIDIA H20 8-GPU 서버 두 대 사용
- 순차 실행 기준 약 15시간 소요
- 장시간 추론 시나리오에 맞춰 스크립트 최적화 적용
- 스트리밍 추론
- 자동 재시도
- 체크포인트 재개 메커니즘 포함
- 가중치가 공개된 만큼, 이를 올바르게 실행하는 지식 역시 공개돼야 한다는 원칙 명시
- 벤더 커버리지 확대와 더 가벼운 agentic 테스트 탐색 진행 중
- 연락처 contact-kvv@kimi.com 공개
- 공식 API 기준 벤치마크 수치 공개
Hacker News 의견들
- 이 아이디어가 마음에 듦. 추론 제공자들이 오래된 문제를 고치게 만드는 데 꽤 효과적인 사회적 압박이 될 수 있어 보임. 예를 들어 AWS Bedrock은 Kimi의 K2와 K2.5 모델 서빙 스택에 치명적인 결함이 있어서, 툴 호출을 내보내야 할 시도의 20%~30%가 토큰 출력 없이 대화를 조용히 끝내버림. 그래서 AWS는 Kimi를 위한 진지한 추론 제공자로서 사실상 의미가 없어지고, 비슷한 에이전트 작업 성능에 더 비싼 Anthropic 모델로 사용자를 밀어 넣는 셈으로 보임
- 이건 새 얘기가 아니라 Kimi가 이미 몇 달째 해오던 일이라고 봄. K2 Vendor Verifier, Kimi Vendor Verifier도 이미 있었고, 심지어 K2.5와 K2.6 출시 전부터였음
- 내가 이해한 위협 모델은 실수로 인한 성능 저하를 막는 쪽이지, 악의적인 행위자까지 커버하는 건 아닌 듯함. 예를 들어 어떤 수상한 제공자가 최신 최고 모델을 돌린다고 말해놓고 실제로는 더 싸고 성능 낮은 모델을 써서 차액을 챙긴다면, 이런 테스트는 큰 도움이 안 될 수 있음. 테스트 중임을 감지하면 Volkswagen 배출가스 스캔들처럼 그때만 제대로 동작하게 꾸밀 수 있기 때문임
- OpenRouter 같은 제공자는 기본적으로 가장 싼 제공자를 고르는데, 그게 싼 이유가 품질보다 처리량을 위해 과도한 양자화와 튜닝이 들어갔기 때문인 경우가 많음. 그래서 이건 kimi가 헐값 제공자들이 모델 성능을 제대로 대표하지 못해 브랜드를 해치는 걸 막으려는 시도로 보임
- 실수로 생기는 드리프트만 잡아도 가치가 크다고 봄. 이건 CI의 성능 회귀 테스트와 거의 같은 발상이고, 누군가가 일부러 망가뜨릴 걸 예상해서 쓰는 게 아님. 보통은 의존성 하나 올렸더니 처리량이 15% 떨어지는 식의 평범한 문제를 잡기 위한 용도임. 누군가가 의도적으로 검사를 우회한다면, 그냥 더 싼 양자화를 조용히 내보내는 것과는 법적으로도 꽤 다른 상황이 됨
- 맞기도 하고 아니기도 하다고 봄. 정말 악의적인 행위자라면 우려가 맞음. 하지만 이 장치는 상황을 "모델을 양자화하고도 안 알린다고 해서 명백한 사기는 아니다"에서 "검증은 한 모델로 통과시키고 실제 고객 요청은 다른 모델로 처리하는 의도적 사기"로 바꿔놓음. 전자까지만 기꺼이 하려는 반쯤 악의적인 플레이어가 꽤 많을 것 같음
- 이런 시스템들에겐 꽤 좋은 도전 과제처럼 보임. 예를 들어 fromtier labs가 고부하 상황에서 양자화 모델을 서빙하는 사례를 떠올리게 됨
- 이건 우리 벤치마크에서도 실제 문제였음. OpenRouter 제공자 중에 양자화 수준을 명시하지 않거나 기대보다 더 낮은 수준을 쓰는 곳은 조심해야 함. OpenRouter가 관련 설정 옵션을 제공하긴 하지만, 그러면 선택지가 크게 줄어드는 경우가 많음. 그와 별개로 최고의 제공자를 써도 Kimi-K2-thinking은 우리 벤치마크에서 다소 실망스럽고 느렸지만, 온도와 변주 측면에서는 흥미롭고 유용했음. 반면 Kimi K2.6은 현재까지는 새로운 오픈소스 리더로 보임. 에이전트 평가도 진행 중이고, 원샷 코딩 추론 벤치마크는 이미 준비되어 있음
- 고성능 장비에서 15시간이나 도는 테스트는 재현하거나 확장하기가 쉽지 않다고 봄. 그래도 이건 여러 클라우드 서비스 전반에 걸친 널리 퍼진 걱정을 잘 건드림. 내가 핑한 대상이 실제로 내가 받는 대상이 아닐 수 있다는 점이 핵심임
- 내 해석으로는 이 테스트의 첫 번째 대상은 사용자보다 벤더 자신임. 테스트가 길고 포괄적인 이유도, 자기 호스팅 품질에 대한 확신을 벤더에게 주기 위해서라고 이해했음
- 처음엔 벤더별로 전체 스위트를 한 번 돌리고, 그다음엔 2주나 4주 주기로 각 파트를 순환 실행하면서 일반 사용 패턴을 흉내 내면 된다고 봄. 그러면 평가를 시간에 따라 최신 상태로 유지할 수 있음
- 이런 게 존재해서 반가움. 추론 제공자들은 양자화 수준을 조용히 바꿔치기하곤 하고, 대부분의 사용자는 확인조차 안 함. 모델 제작사가 내놓는 표준 검증기가 정답에 가깝고, 다른 연구소들도 비슷한 걸 내줬으면 좋겠음
- 오픈 웨이트 모델을 운영할 때 왜 이런 검증기가 필요한지 설명하는 fireworks.ai의 관련 글도 참고할 만하다고 봄. quality-first with kimi k2p5임
- Anthropic에 이어 Moonshot도 샘플링 파라미터 조정을 제한하는 모델 제공자라는 점은 눈에 띔. 그래도 vendor verifier라는 아이디어 자체는 마음에 듦
- 여기서 "샘플링 파라미터 조정을 제한한다"는 게 무슨 뜻인지 궁금함
- 후처리 학습이 특정 샘플링 파라미터로 이뤄졌다면, 실제 사용도 학습된 파라미터에 맞추는 게 타당하다고 생각함
- 이건 정말 훌륭한 발상이라고 느낌. 나는 AI 게이트웨이 Glama를 운영하는데, 제3자 제공자들 중 일부가 양자화에 대해 노골적으로 거짓말하는 게 보여서 전부 목록에서 내린 적이 있음. 제공자를 검증할 수 있게 되면 더 다양한 제공자 구성을 자신 있게 제공할 수 있어서 큰 개선이 될 것 같음
- 벤더들이 6개의 KVV 벤치마크에 맞춰 최적화하기 시작하면, 결국 모델 충실도가 아니라 KVV 준수성만 측정하게 되는 것 아닌지 걱정됨. 이를 막는 순환 전략이 마련돼 있는지 궁금함