# Kimi 벤더 검증기 - 추론 제공자의 정확성 검증 > Clean Markdown view of GeekNews topic #28786. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28786](https://news.hada.io/topic?id=28786) - GeekNews Markdown: [https://news.hada.io/topic/28786.md](https://news.hada.io/topic/28786.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-23T03:34:06+09:00 - Updated: 2026-04-23T03:34:06+09:00 - Original source: [kimi.com](https://www.kimi.com/blog/kimi-vendor-verifier) - Points: 1 - Comments: 1 ## Topic Body - 오픈소스 모델 배포 이후 서로 다른 인프라에서 발생하는 **추론 구현 편차**를 검증해, 모델 자체 한계와 엔지니어링 오류를 구분할 수 있게 한 공개소스 도구 - 공식 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** 공개 ## Comments ### Comment 56089 - Author: neo - Created: 2026-04-23T03:34:07+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47838703) - 이 아이디어가 마음에 듦. 추론 제공자들이 오래된 문제를 고치게 만드는 데 꽤 효과적인 **사회적 압박**이 될 수 있어 보임. 예를 들어 AWS Bedrock은 Kimi의 K2와 K2.5 모델 서빙 스택에 치명적인 결함이 있어서, 툴 호출을 내보내야 할 시도의 20%~30%가 토큰 출력 없이 대화를 조용히 끝내버림. 그래서 AWS는 Kimi를 위한 진지한 추론 제공자로서 사실상 의미가 없어지고, 비슷한 에이전트 작업 성능에 더 비싼 Anthropic 모델로 사용자를 밀어 넣는 셈으로 보임 - 이건 새 얘기가 아니라 Kimi가 이미 몇 달째 해오던 일이라고 봄. [K2 Vendor Verifier](https://github.com/MoonshotAI/K2-Vendor-Verifier), [Kimi Vendor Verifier](https://github.com/MoonshotAI/Kimi-Vendor-Verifier)도 이미 있었고, 심지어 K2.5와 K2.6 출시 전부터였음 - 내가 이해한 위협 모델은 **실수로 인한 성능 저하**를 막는 쪽이지, 악의적인 행위자까지 커버하는 건 아닌 듯함. 예를 들어 어떤 수상한 제공자가 최신 최고 모델을 돌린다고 말해놓고 실제로는 더 싸고 성능 낮은 모델을 써서 차액을 챙긴다면, 이런 테스트는 큰 도움이 안 될 수 있음. 테스트 중임을 감지하면 Volkswagen 배출가스 스캔들처럼 그때만 제대로 동작하게 꾸밀 수 있기 때문임 - OpenRouter 같은 제공자는 기본적으로 가장 싼 제공자를 고르는데, 그게 싼 이유가 품질보다 처리량을 위해 **과도한 양자화**와 튜닝이 들어갔기 때문인 경우가 많음. 그래서 이건 kimi가 헐값 제공자들이 모델 성능을 제대로 대표하지 못해 브랜드를 해치는 걸 막으려는 시도로 보임 - 실수로 생기는 드리프트만 잡아도 가치가 크다고 봄. 이건 CI의 **성능 회귀 테스트**와 거의 같은 발상이고, 누군가가 일부러 망가뜨릴 걸 예상해서 쓰는 게 아님. 보통은 의존성 하나 올렸더니 처리량이 15% 떨어지는 식의 평범한 문제를 잡기 위한 용도임. 누군가가 의도적으로 검사를 우회한다면, 그냥 더 싼 양자화를 조용히 내보내는 것과는 법적으로도 꽤 다른 상황이 됨 - 맞기도 하고 아니기도 하다고 봄. 정말 악의적인 행위자라면 우려가 맞음. 하지만 이 장치는 상황을 "모델을 양자화하고도 안 알린다고 해서 명백한 사기는 아니다"에서 "검증은 한 모델로 통과시키고 실제 고객 요청은 다른 모델로 처리하는 **의도적 사기**"로 바꿔놓음. 전자까지만 기꺼이 하려는 반쯤 악의적인 플레이어가 꽤 많을 것 같음 - 이런 시스템들에겐 꽤 좋은 도전 과제처럼 보임. 예를 들어 fromtier labs가 **고부하** 상황에서 양자화 모델을 서빙하는 사례를 떠올리게 됨 - 이건 우리 벤치마크에서도 실제 문제였음. OpenRouter 제공자 중에 양자화 수준을 명시하지 않거나 기대보다 더 낮은 수준을 쓰는 곳은 조심해야 함. OpenRouter가 관련 설정 옵션을 제공하긴 하지만, 그러면 선택지가 크게 줄어드는 경우가 많음. 그와 별개로 최고의 제공자를 써도 Kimi-K2-thinking은 우리 벤치마크에서 다소 실망스럽고 느렸지만, 온도와 변주 측면에서는 흥미롭고 유용했음. 반면 Kimi K2.6은 현재까지는 새로운 **오픈소스 리더**로 보임. 에이전트 평가도 진행 중이고, 원샷 코딩 추론 벤치마크는 이미 [준비되어 있음](https://gertlabs.com/?mode=oneshot_coding) - OpenRouter에는 특정 모델에서 더 높은 품질의 제공자를 선호하게 하는 [**exacto** 옵션](https://openrouter.ai/docs/guides/routing/model-variants/exacto)이 있음. 그걸 써서 이점을 본 적이 있는지 궁금함. 또 Kimi K2는 학습과 추론 모두에서 int4를 사용한다고 하니, [관련 논의](https://www.reddit.com/r/LocalLLaMA/comments/1pzfuqg/why_kimi_k2_thinking_choose_int4_qat_from_infra/)를 보면 gguf 제작자들마다 변환을 다르게 해서 품질에 영향을 줄 수도 있겠다는 생각이 듦 - 고성능 장비에서 15시간이나 도는 테스트는 재현하거나 확장하기가 쉽지 않다고 봄. 그래도 이건 여러 클라우드 서비스 전반에 걸친 널리 퍼진 걱정을 잘 건드림. **내가 핑한 대상**이 실제로 내가 받는 대상이 아닐 수 있다는 점이 핵심임 - 내 해석으로는 이 테스트의 첫 번째 대상은 사용자보다 **벤더 자신**임. 테스트가 길고 포괄적인 이유도, 자기 호스팅 품질에 대한 확신을 벤더에게 주기 위해서라고 이해했음 - 처음엔 벤더별로 전체 스위트를 한 번 돌리고, 그다음엔 2주나 4주 주기로 각 파트를 순환 실행하면서 일반 사용 패턴을 흉내 내면 된다고 봄. 그러면 평가를 시간에 따라 **최신 상태**로 유지할 수 있음 - 이런 게 존재해서 반가움. 추론 제공자들은 양자화 수준을 조용히 바꿔치기하곤 하고, 대부분의 사용자는 확인조차 안 함. 모델 제작사가 내놓는 **표준 검증기**가 정답에 가깝고, 다른 연구소들도 비슷한 걸 내줬으면 좋겠음 - 오픈 웨이트 모델을 운영할 때 왜 이런 검증기가 필요한지 설명하는 fireworks.ai의 관련 글도 참고할 만하다고 봄. [quality-first with kimi k2p5](https://fireworks.ai/blog/quality-first-with-kimi-k2p5)임 - Anthropic에 이어 Moonshot도 샘플링 파라미터 조정을 제한하는 모델 제공자라는 점은 눈에 띔. 그래도 **vendor verifier**라는 아이디어 자체는 마음에 듦 - 여기서 "샘플링 파라미터 조정을 제한한다"는 게 무슨 뜻인지 궁금함 - 후처리 학습이 특정 샘플링 파라미터로 이뤄졌다면, 실제 사용도 **학습된 파라미터**에 맞추는 게 타당하다고 생각함 - 이건 정말 훌륭한 발상이라고 느낌. 나는 AI 게이트웨이 Glama를 운영하는데, 제3자 제공자들 중 일부가 양자화에 대해 **노골적으로 거짓말**하는 게 보여서 전부 목록에서 내린 적이 있음. 제공자를 검증할 수 있게 되면 더 다양한 제공자 구성을 자신 있게 제공할 수 있어서 큰 개선이 될 것 같음 - 벤더들이 6개의 KVV 벤치마크에 맞춰 최적화하기 시작하면, 결국 모델 충실도가 아니라 **KVV 준수성**만 측정하게 되는 것 아닌지 걱정됨. 이를 막는 순환 전략이 마련돼 있는지 궁금함