curl https://api.crazyrouter.com/v1/models \
-H 

연잎이 매일 면적을 2배로 늘려 48일째에 연못 전체를 덮습니다. 절반을 덮는 것은 며칠째입니까? 숫자만 출력해 주세요.

V4-Pro는 정답을 맞히고, `47`

을 반환했습니다. 그런데 사용량 영수증을 보니, **출력은 80 토큰이며, 그중 78 토큰이 추론(inference) 토큰**이었습니다. 원했던 두 자리 숫자는 과금 대상의 2.5%에 불과합니다.

작성하는 도중에 같은 문제를 재실행해 보니, 이번에는 62 토큰 중 60 토큰이 추론이었습니다. **같은 모델・같은 프롬프트라도 사고 과정의 길이(thought length)는 변동할 수 있으므로**, 단발적인 샘플은 자릿수 파악까지만 하시는 것이 좋습니다.

'숫자만', '단어 하나만'이라고 명시한 4문제를 정리합니다.

| 문제 | 지시 | K3의 추론 비율 | V4-Pro의 추론 비율 |
|---|---|---|---|
| 연잎 | 숫자만 | 78.0% | 97.5% |
| ... | 
*본 검증 기록을 바탕으로 작성. 2026년 10월 15일 측정.*

직관에 반하지만, **'답변만 해줘'라고 강하게 지시할수록 눈에 보이지 않는 비율(추론 토큰)은 높아집니다**. 답변이 짧기 때문에 전체 양 대비 사고 과정의 비중이 올라가기 때문입니다. 이 4문제에서 V4-Pro가 실제로 출력한 가시 콘텐츠는 총 10 토큰, 과금 대상 completion은 286 토큰이었습니다.

이 값은 usage의 한 단계 아래에 별도로 기록되어 있습니다. 실제 반환되는 객체를 그대로 붙입니다.

추출하는 코드입니다. 이번 측정에서도 이것을 사용했습니다.

이렇게 '1+1은 무엇입니까?'라고 물었더니, `2`

이 반환되었고, 출력은 `답변 2 토큰 / 사고 32 토큰`이었습니다. 산술 숫자 한 글자를 위해, 내부적으로 32 토큰을 생각하고 있습니다.

8문제에서 빨랐던 V4-Pro였지만, 코드 2문제에서는 역전되었습니다.

| 태스크 | Kimi K3 | DeepSeek V4-Pro |
|---|---|---|
| 구간 병합 함수 구현 | 15.4초 / 265 토큰 | 24.6초 / 1,677 토큰 |
| 코드의 버그 지적 | 28.0초 / 433 토큰 | 39.4초 / 2,100 토큰 |

*본 검증 기록을 바탕으로 작성. 코드 2문제를 다른 색상으로 표시했습니다.*

구간 병합 함수에서는 V4-Pro가 1,677 토큰을 소비했고, 그중 1,579이 추론이었습니다. K3는 총 265 토큰입니다. 버그 지적의 경우 2,100 토큰 중 96%가 추론이었는데, 들은 질문은 '이 코드의 버그는 무엇입니까?'뿐이었습니다.

두 답변 모두 정확하고 틀린 것은 아닙니다. 다만 **같은 정답에 대해 한쪽은 6배나 돌아가는 과정을 거쳐 도달했습니다**.

측정 자체에서 발견한 점을 남깁니다.

처음 집계 스크립트에서, 정렬 후의 N/2 요소를 그대로 중앙값으로 사용했습니다. 게다가 숫자형으로 변환하지 않았기 때문에 문자열 순서로 정렬되어 있었습니다.

잘못된 값으로는 K3가 41.1초, V4-Pro가 3.5초가 되어 '11.7배 빠르다'는 결론이 나왔습니다. 실제로는 14.95 대 4.75로 3.15배입니다. **소요 시간은 긴 꼬리를 가진 분포(최대 91.1초, 최소 2.6초)이기 때문에 통계량을 잘못 사용하면 결론이 한 자릿수 바뀝니다.** 평균값도 마찬가지로 사용할 수 없습니다.

PowerShell 이야기인데, 일본어를 포함한 문자열을 `-Body`에 그대로 전달하면 기본 인코딩으로 전송되어 서버 측에서 글자가 깨집니다. 

골치 아픈 점은 **오류가 나지 않는다**는 것입니다. 모델은 평소처럼 답변을 하지만, 보이는 질문문이 손상되었기 때문에 내용이 맞지 않습니다. 원인을 파악하기 어려운 종류의 결함이었습니다.

구세대 `kimi-k2`를 지정했을 때의 실제 응답입니다.

request id가 들어가 있으므로, 문의할 때는 삭제하는 것이 좋습니다.

다만 `deepseek-v3.2`

이러한 구식 식별자는 **404가 아니었습니다**. 오래된 이름이 라우팅에 남아 있을 수 있기 때문에, '통했다 = 예상대로의 버전을 호출하고 있다'라고 단정할 수는 없습니다. 목록을 기준으로 삼는 것이 안전합니다.

모델마다 10문제씩 순서대로 돌리면 서버 측 부하 변동이 '모델 차이'로 기록됩니다. 이번에는 문제별로 번갈아 발행하여, 두 모델이 비슷한 시간대에 수렴하도록 했습니다. 호출 간에는 400밀리초의 간격을 두었습니다.

잘못된 전제에 기반한 문제에서는 양쪽 모델 모두 걸리지 않았습니다. 질문 내용은 다음과 같습니다.

Python의

`sort`

메소드는 정렬된 새로운 리스트를 반환한다고 기억하고 `result = mylist.sort()`
라고 작성했는데, `result`가 항상 None이 됩니다. Python 버전의 버그일까요?

전제가 잘못되어, `sort`는 인플레이스(in-place) 정렬이기 때문에 `None`을 반환합니다. 양쪽 모델 모두 그 점을 지적했습니다. 다만 K3는 듣지 않은 내용을 한 단락 덧붙였습니다.

이것은 Python의 중요한 규약입니다. 객체 자체를 변경하는 것을 목적으로 하는 메소드(`sort`, `append`, `extend`, `reverse` 등)는 모두 None을 반환합니다.

단발적인 지식이 규약으로 정리되었습니다. V4-Pro의 답변은 더 간결하고, 마찬가지로 정확하며, 이 단락은 없습니다. K3는 여기에 91.1초와 1,951 토큰을 사용했고, V4-Pro는 11.0초 만에 끝냈습니다.

참고로 V4-Pro의 출력에서 한 번 코드 주석 안에 잘못된 값을 적었다가 같은 줄에서 수정한 경우가 있었는데, 양쪽이 모두 남아 있었습니다. 정확성에는 영향을 미치지 않지만, 출력을 그대로 문서에 붙여 넣는 운영 방식이라면 한번 훑어보는 것이 좋을 것 같습니다.

아키텍처는 공개 자료에 따르면, K3가 2.8조 파라미터에 KDA라는 혼합 선형 어텐션(mixed linear attention) 메커니즘을 통해 어텐션 계산량을 문장 길이의 제곱에서 선형으로 낮춘 것이고, V4-Pro가 총 파라미터 1.6조의 MoE로 한 번의 추론당 약 490억(약 3%)만 활성화하는 것으로 되어 있습니다. 한쪽은 상한을 높이고, 다른 쪽은 한 번의 계산량을 낮추는 설계입니다.

라이선스에는 차이가 있습니다. 둘 다 공개 웨이트이지만, DeepSeek이 MIT, Kimi K3가 귀속 조항이 붙은 수정 MIT입니다. 웨이트를 자체 제품에 통합하는 경우에는 이쪽(Kimi K3)이 순위표보다 중요하므로, 원문을 직접 확인해 주십시오 (본 기사의 요약 내용을 포함하여, 2차 정보를 맹신하지 않는 것이 좋습니다).

사용처로는, 일상적인 개발 및 대화형 기능은 DeepSeek V4-Pro, 출력을 그대로 사람에게 전달하는 상황은 Kimi K3, 코드 중심의 워크로드는 자신의 환경에서 양쪽을 모두 시험해 본다는 정리였습니다.

미검증 범위임을 명시합니다. 각 태스크가 1회만 진행되었기 때문에 실패율/안정성에는 언급하지 않았습니다. 롱 컨텍스트는 미측정입니다. 전부 단발적인 상호작용이었고, 툴 호출/다중 턴 수정/재시도 비용은 대상에서 제외되지만, 추론 토큰의 거동을 생각하면 그 영역이야말로 차이가 커질 것 같습니다. Flash Grade도 미측정입니다. 아키텍처와 파라미터는 공개 자료를 인용한 것이며, 독자적으로 검증한 것은 아닙니다.

마지막으로, 선정과는 별개로 남은 습관을 하나만 말씀드립니다.

**새로운 모델을 연결할 때는, 먼저 추론 토큰(inference token) 필드를 출력해 보세요.** 어느 쪽이 우수한지는 알 수 없지만, 그 호출이 실제로 무엇을 했는지는 알 수 있습니다.