Kimi K3가 이틀 전에 출시되었고, 타임라인은 파라미터 수(parameter counts)로 가득 차 있습니다. 저는 다른 수치를 알고 싶었습니다. 대안 모델들과 비교했을 때, 실제 작업을 수행하는 데 비용이 실제로 얼마나 드는가 하는 점입니다.

그래서 저는 다섯 가지 모델에 대해 동일한 코딩 작업을 실행하고 비용을 측정했습니다. 결과는 제 예상과 달랐으며, 그 과정에서 그 자체로 기록할 가치가 있는 측정 문제(measurement problem)가 드러났습니다.

측정 문제 (이것은 벤치마크보다 더 중요합니다)

저의 첫 번째 시도는 게이트웨이의 가격 책정 엔드포인트(pricing endpoint)에서 가격을 도출하는 것이었습니다. 이 엔드포인트는 모델당 model_ratio와 completion_ratio를 노출합니다. 일반적인 관례는 $/M = model_ratio * 2이므로, 저는 그것을 사용했습니다.

그 다음, 제가 이미 실제 가격을 알고 있는 모델들을 대상으로 정당성 검사(sanity-check)를 수행했습니다:

둘 다 틀렸으며, 방향도 반대였습니다. 그 공식은 쓸모없는 것이었습니다.

그래서 저는 공식을 버리고 대신 실제 데이터(ground truth)로부터 측정했습니다. 계정의 누적 사용량(cumulative usage)을 읽고, 한 번의 호출을 수행한 뒤, 다시 읽어서 그 차이를 구하는 방식입니다.

usage() {
  curl -s https://<gateway>/dashboard/billing/usage \
    -H "Authorization: Bearer $KEY" | jq -r .total_usage
...

양쪽의 알려진 토큰 수(token counts)를 이용하면 실제 100만 토큰당(per-million) 요율을 구할 수 있습니다. 두 개의 독립적인 모델이 유효숫자 세 자리까지 동일한 계수(coefficient)로 수렴했는데, 이것이 우연이 아니라는 것을 알 수 있는 방법입니다:

$/M input  = model_ratio * 1.60
$/M output = model_ratio * completion_ratio * 1.60

* 2가 아니었습니다. 그리고 claude-sonnet-5는 이 공식을 전혀 따르지 않습니다. 이 모델의 model_ratio 항목(37.5)은 다른 척도(scale)를 사용하므로 직접 측정해야 합니다.

부수적인 효과로, 제가 가진 가격표에 deepseek의 가격이 거의 3배나 높게 책정되어 있다는 것을 발견했습니다. 사용자에게 호출당 비용을 표시한다면, 청구 차액(billing deltas)을 통해 가격표를 검증하십시오. 제 것은 틀렸고, 며칠 동안이나 그렇게 표시해 왔었습니다.

벤치마크

다섯 모델 모두에 동일한 프롬프트를 사용하였으며, 각각 한 번씩 실행하였고, 스트리밍(non-streaming)을 사용하지 않았으며, max_tokens 제한도 두지 않았습니다:

순서를 유지하면서 배열의 중복을 제거하는 JavaScript 함수를 작성하고, 3가지 예외 케이스에 대한 단언(assertion)을 추가하세요. 코드만 작성하세요.

예상하지 못했던 세 가지

1. K3는 여기서 가장 비싼 옵션이며, 가장 저렴한 모델보다 12배나 비쌉니다. 측정된 출력 속도는 약 $12/M 수준입니다. 단 한 번의 호출에서는 노이즈 수준일 수 있습니다. 하지만 수천 번의 호출이 포함된 배치 작업(batch job)에서는 $2와 $25의 차이를 만들어냅니다.

2. 또한 가장 느립니다. claude-sonnet-5의 9.3s와 비교했을 때 35.8s를 기록했습니다. K3는 추론 모델(reasoning model)이므로, 답변하기 전에 생각하는 데 토큰을 소비합니다. 편차(variance)가 큽니다. 유사한 프롬프트가 다른 실행에서는 11.9s 만에 돌아오기도 했습니다. 추론 예산(reasoning budget)은 유동적입니다.

3. codex 변형 모델이 실제로는 가성비가 좋습니다. 기본 K3와 동일한 리스트 가격이지만, 코딩 작업에서는 훨씬 적게 생각합니다: $0.0067 대 $0.0171, 9.4s 대 35.8s. 비용은 절반이고, 속도는 대략 4배 더 빠릅니다. 코드를 작성하기 위해 K3를 사용하려 한다면, 대신 Kimi-K3-codex를 선택하세요.

max_tokens를 제한할 때 빠질 수 있는 함정

테스트 중에 max_tokens를 200으로 설정했더니 완전히 비어 있는 응답이 돌아왔고, 그럼에도 200 토큰에 대한 비용을 지불했습니다. 모든 토큰이 추론 토큰(reasoning_tokens)으로 사용되었고, 가시적인 출력(visible output)을 위한 토큰이 남지 않았기 때문입니다.

600으로 설정했을 때는 추론에 57 토큰이 사용되었고 답변이 정상적으로 나왔습니다. 2048로 설정했을 때는 229 토큰이 사용되었습니다.

이것은 K3의 결함이 아니라, 추론 모델에 자원을 제한했을 때 나타나는 동작 방식입니다. 하지만 여러분의 애플리케이션이 모든 모델에 대해 엄격한 max_tokens 상한선을 적용하고 있다면(제 경우 2048이었습니다), 이를 점검하십시오. 사용자는 빈 답변을 받게 되지만, 여러분은 여전히 비용을 청구받게 됩니다.

주의 사항

모델당 단 한 번의 실행 결과입니다. 이는 규모(order-of-magnitude)를 파악하기 위한 읽기 자료이며, 통계적으로 유의미한 결과는 아닙니다. 특히 지연 시간(latency)은 실행마다 차이가 매우 큽니다. 핵심은 정확한 소수점 수치가 아니라, 순위가 출시 당일의 담론이 시사했던 것과 정반대였다는 점이며, 이는 오직 계측(metering)을 통해서만 알 수 있다는 것입니다.

재현하기

다섯 가지 모델 모두 https://ainetcafe.com/?utm_source=devto&utm_medium=article&utm_campaign=kimi-k3에서 실행되고 있습니다. 이곳은 설치나 API 키 없이도 바로 사용할 수 있도록 호스팅된 오픈 소스 (open-source) AI 앱들입니다. 모든 호출 시 측정된 비용이 표시됩니다.

만약 에이전트 (agent)가 직접 비교를 수행하도록 하고 싶다면 MCP 서버도 있습니다:

claude mcp add --transport http ai-netcafe https://ainetcafe.com/mcp

그 다음, 실제로 관심 있는 어떤 프롬프트(prompt)에 대해서든 compare_models를 요청하십시오. 이것이 제가 위의 표를 만드는 데 사용한 도구입니다.

전체 데이터 및 방법론: https://ainetcafe.com/lab/kimi-k3?utm_source=devto&utm_medium=article&utm_campaign=kimi-k3