"같은 모델인데 왜 답이 다르지?" – Kimi가 공개한 추론 제공자 검증 도구

같은 모델, 다른 답변의 미스터리

오픈소스 LLM을 API로 쓸 때 한 번쯤 겪어봤을 거예요. Llama 3.1 70B를 A 제공자에서 쓸 때랑, B 제공자에서 쓸 때랑 답이 미묘하게 달라지는 현상 말이에요. 때로는 답변 스타일이 달라지고, 때로는 특정 수학 문제를 한쪽은 맞추고 한쪽은 틀려요. "같은 모델 웨이트를 돌리는 건데 왜?"라는 의문이 드는데, 사실 그 뒤에는 숨은 변수가 꽤 많아요.

중국의 AI 스타트업 Moonshot AI가 만든 Kimi가 이번에 공개한 Kimi Vendor Verifier는 바로 이 문제를 정량적으로 드러내기 위한 도구예요. "Kimi K2 모델을 제공한다고 말하는 여러 벤더가 있는데, 실제로 그들이 돌리는 버전이 원본과 얼마나 일치하는가?"를 체계적으로 측정해요.

왜 같은 모델이 다르게 동작할까

이유는 생각보다 여러 가지예요. 가장 흔한 건 양자화(quantization)예요. 이게 뭐냐면, 원래 16비트나 32비트 실수로 저장되는 모델 가중치를 8비트, 4비트처럼 더 작은 숫자로 압축해서 GPU 메모리를 덜 쓰게 하는 기법이에요. 속도가 빨라지고 비용이 낮아지지만, 정확도가 조금 떨어지는 트레이드오프가 있죠. 어떤 제공자는 FP16으로 원본 그대로 돌리고, 어떤 제공자는 INT4로 공격적으로 양자화해요. 그런데 API 스펙에선 "Kimi-K2"라고 똑같이 표기하기 때문에 사용자는 그 차이를 모르고 써요.

그 외에도 몰래 붙는 시스템 프롬프트(벤더가 자기 지침을 추가하는 경우), 샘플링 구현 차이(softmax 정밀도, top-p 컷오프 구현 방식의 미묘한 차이), KV 캐시 최적화로 인한 누적 오차 같은 원인들이 있어요. 이런 것들이 쌓이면 같은 질문에도 답이 달라져요.

Kimi Vendor Verifier는 어떻게 동작하나

이 도구는 본질적으로 참조(reference) 출력과 벤더 출력을 비교하는 벤치마크예요. Moonshot은 자사 서버에서 Kimi K2 원본 모델로 수백~수천 개의 프롬프트에 대한 응답을 저장해둬요. 그 뒤에 동일한 프롬프트를 각종 API 제공자(OpenRouter, Together, Fireworks, Groq 등)에서 Kimi K2로 쿼리해서 응답을 받고, 원본 대비 유사도를 계산해요.

유사도 계산은 단순 문자열 비교가 아니라, 로그 확률 일치도, 토큰 일치율, 다운스트림 태스크 성능(수학 정답률, 코드 실행 성공률 등)을 종합해서 본다고 해요. 결과를 보면 제공자별로 "원본과 99% 유사", "90% 유사", "특정 태스크에서 15% 정확도 하락" 같은 식으로 점수가 매겨져요. 이게 공개되면 제공자들도 압박을 받게 돼서, 몰래 공격적으로 양자화하던 관행이 줄어들 수 있어요.

업계 맥락: 모델 제공자 생태계의 신뢰 문제

요즘 LLM API 시장은 모델 개발자(Meta, Mistral, DeepSeek, Moonshot, Alibaba)와 추론 제공자(Together, Fireworks, Groq, Cerebras, OpenRouter 등)가 분리된 구조예요. 개발자는 가중치를 공개하고, 제공자는 그걸 자기 인프라에서 돌려서 API로 판매하죠. 사용자는 가격과 속도로 제공자를 비교해요. 문제는 이 경쟁이 "누가 더 싸고 빠르게 돌리나"로 치닫다 보니, 은근슬쩍 양자화를 심하게 하거나 컨텍스트를 잘라내는 꼼수가 나오기 시작했다는 거예요.

이 문제에 대한 관심은 예전부터 있었어요. ArtificialAnalysis 같은 리더보드가 제공자별 속도·품질을 비교해왔고, 몇몇 독립 연구자들이 "이 벤더는 양자화한 버전을 쓴다"고 폭로하기도 했죠. 하지만 모델 개발자가 직접 "공식 인증 도구"를 내놓은 건 좀 새로워요. Moonshot의 이번 움직임은 "우리 모델은 원본 그대로 돌리는 벤더에서 써야 제값을 한다"라는 메시지를 시장에 던지는 거예요.

한국 개발자에게는

OpenRouter, Together, Fireworks 같은 글로벌 추론 제공자를 쓰는 국내 스타트업이라면 이 도구가 꽤 실용적이에요. 예컨대 챗봇 서비스의 답변 품질이 특정 시점부터 떨어졌을 때, "제공자가 조용히 양자화 버전으로 바꾼 건 아닐까?"를 검증할 수 있게 되거든요. 직접 Vendor Verifier를 돌려서 로그를 남겨두면, 나중에 SLA 협상이나 제공자 전환 근거로도 쓸 수 있어요.

오픈 웨이트 모델을 쓰는 팀이라면, 아예 자체 버전의 verifier를 만드는 것도 고려해볼 만해요. 사내 평가 셋 100~200개를 원본 모델로 먼저 돌려 답변을 저장해두고, 주기적으로 제공자 API와 비교하는 CI 파이프라인을 구성하는 거죠. 품질 드리프트(slow quality drift)를 조기에 잡는 데 큰 도움이 돼요.