Kimi K3.1 Pro의 65.7%: 숫자보다 먼저 벤치마크의 하네스를 확인해야 하는 이유

Kimi K3.1 Pro의 Terminal-Bench 4.0 점수 65.7%는 Claude Code 하네스로 측정됐습니다. 그런데 나란히 제시된 경쟁 모델 점수는 같은 조건의 재실행 결과가 아닙니다. 모델을 바꾸려는 개발자에게는 순위보다 이 비교 조건이 먼저입니다.

Kimi의 공식 각주는 경쟁 결과를 각 발표나 리더보드의 최고 기록에서 가져왔다고 밝힙니다. 66.4%와의 차이는 0.7%포인트지만, 반복별 결과와 동일 조건 비교 없이 그 차이를 동급 성능이나 유의미한 열세로 판정할 수 없습니다.

공식 글에는 게시일이 보이지 않습니다. 브리핑이 주목한 시점은 10월 23일 전후, 기존 아티클 발행일은 10월 24일이며 이 보강을 위해 원문을 다시 확인한 날짜는 10월 26일입니다. 모델/API를 직접 실행하지 않았습니다.

공개된 사실과 아직 공개되지 않은 것

Kimi의 기술 블로그와 K3 문서를 기준으로 확인한 내용입니다.

여기서 "3T급"과 "2.8T"를 구분할 필요가 있습니다. K3 문서는 2.8T 파라미터와 896개 expert 중 16개 활성화라는 구조를 밝혔습니다. K3.1 Pro는 그 K3를 사후학습한 모델이므로 같은 규모대로 보는 것이 합리적이지만, K3.1 문서가 총 파라미터 수나 활성 파라미터 수를 다시 적지는 않았습니다. 발표에 없는 숫자를 확정된 사실처럼 쓰면 안 됩니다.

65.7%의 전제: 하네스와 채점

Terminal-Bench 4.0은 현실적인 터미널 작업을 에이전트에게 주고, 작업별 테스트로 통과 여부를 채점합니다. 모델은 도구를 고르고, 명령을 실행하고, 실패를 읽고, 다시 시도합니다. 점수에는 모델 외에 다음이 함께 들어갑니다.

• 어떤 도구를 몇 개까지 쓸 수 있는지
• 컨텍스트가 얼마나 차면 압축하는지
• 실패 후 몇 번까지 재시도하는지
• 추론 예산과 타임아웃이 얼마인지
• 채점기가 어떤 출력을 실패로 보는지

Kimi의 각주는 이 점을 분명히 합니다. K3.1 Pro는 Claude Code 하네스로 평가했고, 나머지 모델 점수는 각자의 블로그나 공식 Terminal-Bench 리더보드에 보고된 최댓값을 가져왔습니다. 즉 같은 하네스에서 같은 조건으로 다시 돌린 비교가 아닙니다. 벤더가 서로 다른 하네스에서 낸 최고 점수를 한 표에 놓은 것입니다.

BenchCAD도 비슷합니다. 공개 표는 "도구 사용" 점수를 강조하지만, 같은 모델의 도구 미사용 점수는 72.8%입니다. 도구 사용 시 92.7%와 20점 가까이 차이 납니다. 차이는 19.9%포인트입니다. 다만 도구 사용 하네스와 단발 생성이라는 실행 방식도 함께 달라지므로, 이를 도구 하나의 인과 효과로 분리할 수는 없습니다. 여러분의 에이전트에 Blender나 CAD 스크립트를 실행할 도구가 없고, 뷰를 렌더링해 되먹이는 루프가 없다면 92.7%는 다른 제품의 숫자입니다.

평가 환경도 확인해야 합니다. 표의 BenchCAD 수치는 17,900개 Vision2Code 사례에서 무작위로 고른 1,000개 하위 집합, Voxel IoU 기준입니다. 하위 집합 구성이 바뀌면 점수가 흔들릴 수 있고, 이 선택은 제조사가 했습니다. 또한 Voxel IoU는 두 형상의 겹침을 재는 지표입니다. 92.7%를 “1,000개 중 927개 CAD 제작 성공”으로 바꾸어 읽으면 안 됩니다. 표본별 점수와 반복 실행 결과 없이는 신뢰구간도 이 글에서 계산할 수 없습니다.

같은 하네스에서 비교하려면

모델을 바꿀지 결정하는 실험은 벤치마크 재현이 아니라 통제된 비교여야 합니다. 최소한 다음 항목을 고정하세요.

특히 추론 예산을 봐야 합니다. Kimi는 별도 명시가 없는 결과의 기본 설정을 reasoning effort "max", temperature 1.0, top-p 0.95로 밝혔습니다. 비용을 줄이려고 effort를 낮추면 같은 모델도 다른 점수가 나옵니다. 반대로 경쟁 모델의 "max" 점수와 내 워크로드의 기본 설정을 비교하면 실제 운영 비용과 성능을 오해하게 됩니다.

30개 작업으로 시작하는 비교 설계

벤치마크 전체를 재현할 필요는 없습니다. 여러분의 저장소에서 실패가 반복되는 작업 30개를 고르고, 숨은 테스트를 붙이면 됩니다. 핵심은 "통과율" 하나가 아니라 "성공당 비용"과 "대기 시간"을 같이 보는 것입니다.

아래는 실제 모델을 호출하지 않는 교육용 집계 예제입니다. compare-runs.mjs로 저장하고 node compare-runs.mjs로 실행하세요. Node 18 이상 외에는 설치가 필요 없으며, 아래 출력은 로컬 실행으로 확인했습니다. A/B와 가격·시간은 모두 가상 데이터입니다.

// compare-runs.mjs — Node 18+, no dependencies or network calls
const runs = [
  { model: "A", task: "parser", passed: true, usd: 0.12, ms: 1000 },
  { model: "A", task: "timeout", passed: false, usd: 0.18, ms: 5000 },
  { model: "B", task: "parser", passed: true, usd: 0.20, ms: 800 },
  { model: "B", task: "timeout", passed: true, usd: 0.20, ms: 1200 }
];
for (const model of ["A", "B"]) {
  const group = runs.filter(r => r.model === model);
  const passes = group.filter(r => r.passed).length;
  const total = group.reduce((sum, r) => sum + r.usd, 0);
  const times = group.map(r => r.ms).sort((a, b) => a - b);
  const p95 = times[Math.ceil(0.95 * times.length) - 1];
  const perPass = passes ? (total / passes).toFixed(2) : "NA";
  console.log(`${model}: pass=${passes}/${group.length} usd/pass=${perPass} p95_ms=${p95}`);
}

A: pass=1/2 usd/pass=0.30 p95_ms=5000
B: pass=2/2 usd/pass=0.20 p95_ms=1200

A는 실행 한 번의 가격이 더 낮아 보이지만 실패 비용까지 포함하면 성공당 0.30달러입니다. B는 0.20달러입니다. 이는 집계 방식의 차이를 보여주며 Kimi나 경쟁 모델의 실제 가격·성능이 아닙니다. 두 표본으로 계산한 nearest-rank p95는 최댓값일 뿐, 안정적인 지연 추정도 아닙니다. 성공이 0개이면 나눗셈 대신 NA를 냅니다.

실제 로그에는 정확한 모델 ID, 하네스 커밋, 초기 저장소 커밋, 예산, 작업·반복 ID와 독립 채점 결과를 남기세요. 각 실행은 같은 초기 커밋의 격리된 작업 디렉터리에서 시작해야 앞 실행의 수정이 다음 모델에 넘어가지 않습니다. API 오류와 타임아웃도 실패 행과 비용에 포함해야 합니다. 에이전트 종료 코드 0만으로 성공을 판정하지 마세요.

측정할 지표는 네 개면 충분합니다.

1. pass@1: 한 번 실행에서 숨은 테스트를 통과한 비율
2. 성공당 비용: (입력 토큰 × 단가 + 출력 토큰 × 단가 + 도구 호출 비용) ÷ 성공 수
3. p50/p95 완료 시간: 평균이 아니라 꼬리 지연
4. 사람 개입 횟수: 승인, 재지시, 수동 수정을 몇 번 했는지

성공당 비용은 실패한 실행의 비용도 포함해야 합니다. 통과율이 높아도 재시도가 많으면 실제 비용은 더 큽니다. 가격표가 바뀌었을 수 있으므로 이 글에서는 K3.1 Pro의 단가를 인용하지 않습니다. 청구서나 API 콘솔에서 확인한 값을 공식에 넣으세요.

100만 토큰과 Highspeed를 읽는 법

100만 토큰 컨텍스트는 큰 저장소를 한 번에 넣을 수 있다는 뜻이지, 100만 토큰을 균등하게 이해한다는 뜻이 아닙니다. 긴 컨텍스트에서는 중간 정보 검색, 지시 유지, 코드 일관성이 떨어질 수 있습니다. 확인할 테스트는 두 가지입니다.

• 문서 중간에만 있는 함수명이나 제약을 찾아내는가
• 30만 토큰을 넘긴 뒤에도 초반의 아키텍처 규칙을 지키는가

컨텍스트 압축 방식도 함께 봐야 합니다. 하네스가 오래된 대화를 요약하면 100만 토큰을 다 쓰지 않을 수 있고, 요약에서 요구사항이 사라질 수 있습니다.

Highspeed의 "2~3배 빠르다"는 발표는 처리량과 지연 중 무엇을 뜻하는지 불명확합니다. 에이전트에서는 평균보다 p95가 중요합니다. 동일 작업 20개를 세 번씩 돌려 p50과 p95, 재시도율을 비교하세요. 속도가 2배여도 재시도가 두 배면 체감 이득은 사라집니다.

가중치 공개도 "내 노트북에서 돌릴 수 있다"와 다릅니다. K3 문서는 896개 expert 중 16개를 활성화하는 구조와 64개 이상 가속기 구성을 권장했습니다. 3T급 모델을 직접 서빙하려면 클러스터와 추론 스택이 필요합니다. 11월 4일 이후 확인할 것은 파일 크기와 라이선스, 그리고 실제 서빙 비용이지 "로컬 실행 가능"이 아닙니다.

선택하지 말아야 할 경우

• 재현 가능한 벤치마크 순위가 필요한 경우: 독립 리더보드와 하네스별 결과가 나올 때까지 기다리는 편이 낫습니다.
• 세션 중간에 모델을 바꾸는 워크플로: K3 문서는 보존된 사고 이력이 필요하고, 세션 도중 모델을 바꾸면 품질이 불안정해질 수 있다고 경고합니다. K3.1에 그대로 적용된다고 단정할 수는 없지만, 하네스 호환성을 먼저 확인하세요.
• 지연이 곧 비용인 대화형 제품: 1M 컨텍스트와 긴 추론은 첫 토큰 지연을 키웁니다. p95를 보기 전에는 도입하지 마세요.
• 11월 4일 이전에 자체 호스팅이 필요한 경우: 가중치가 아직 공개되지 않았습니다.

결론: 0.7점은 실험을 대체하지 못한다

65.7%라는 숫자는 "Claude Code 하네스에서, max 추론 예산으로, 제조사가 채점한 결과"입니다. 경쟁 모델 점수는 각자의 최고 기록에서 가져왔습니다. 이 조건을 떼고 "Opus와 거의 같다"고 말하면, 여러분의 하네스에서는 재현되지 않을 수 있습니다.

결정은 리더보드가 아니라 2주짜리 실험으로 하세요. 작업 30개, 숨은 테스트, 3회 반복, 성공당 비용과 p95. 이 네 가지가 있으면 0.7점 차이보다 훨씬 유용한 답이 나옵니다.

이 글 끝의 유료 강의 홍보는 Claude Code 하네스의 규칙·검증 흐름을 학습하는 과정입니다. Kimi 사용법이나 이 벤치마크 재현을 가르치는 과정으로 소개하는 것은 아닙니다.

함께 읽으면 좋은 글

• Kimi K3의 2.8조 파라미터보다 더 중요한 것
• 오픈 웨이트 모델의 가격과 성능을 같이 보는 법

참고 자료

• Kimi: Introducing Kimi K3.1 Pro
• Kimi: Kimi K3: Open Frontier Intelligence
• Terminal-Bench