최근 저는 제 AI Werewolf에 화제의 중심에 있는 모델들을 대거 추가했습니다:

• Kimi K3
• Qwen 3.8 Max, Qwen 3.7 Plus, Qwen 3.7 Flash
• MiniMax M3

그리고 이미 한동안 사용해 온 모델들도 있습니다:

• DeepSeek V4 Pro 및 Flash
• GLM-5.2
• Sakana Fugu base 및 Ultra

마지막 모델은 중국이 아닌 일본 모델이지만, 한두 달 전 뉴스에 나왔기에 이 이야기에 포함시켰습니다.

저는 중국 모델들이 얼마나 느린지에 대해 글을 쓰기 위해 자리에 앉았습니다. 왜냐하면 이 모델들은 컨텍스트 (Context)가 적음에도 불구하고 모두 짜증 날 정도로 느리기 때문입니다. 수치 데이터도 있었고, 논지도 저절로 세워졌습니다. 그런데... 예상치 못한 무언가를 발견했습니다.

좋습니다, 바로 문제로 들어가죠

모든 중국 공식 API들은 극도로 느립니다. DeepSeek는 v4로 개선되었지만, 나머지는 그저 끔찍합니다. 텍스트 게임에서 거의 사용할 수 없을 정도로 느립니다. 아니, 진심입니다. 한번 확인해 보세요.

네 문장으로 된 투표 하나를 생성하는 데 걸리는 시간:

• Kimi K3: 29~34초
• MiniMax M3: 25~30초
• Qwen 3.8 Max: 25~27초 (생각하기 (Thinking) 제한을 두었기에 가능한 수치입니다. 제한을 풀면 100초에 달합니다.)
• DeepSeek V4 Pro: 14~22초, 이 그룹 중에서는 가장 좋습니다.

동일한 프롬프트(Prompt), 동일한 오후 시간대: Claude 5 Opus는 5.9초 만에 답변합니다.

저는 게임의 하루가 끝날 때 투표를 시뮬레이션하는 테스트를 가지고 있습니다. 약간의 대화가 오갔고, 일부 플레이어는 이미 투표를 마친 상태이며, 이제 테스트 대상 모델이 동일한 작업을 수행해야 합니다. 프롬프트에는 이 모든 내용이 포함되어 있습니다: 36,000자이며, 모델의 토크나이저 (Tokenizer)에 따라 8,000~13,000 토큰(Tokens) 정도로 계산됩니다. 해당 모델들이 1M 컨텍스트를 지원한다고 가정하면 그리 많은 양은 아닙니다.

다른 미국/유럽 모델들:

입력 컬럼을 잠시 유심히 살펴볼 가치가 있습니다. 동일한 36,000자는 Gemini에게는 7,979 토큰, Mistral에게는 8,175 토큰, OpenAI에게는 12,124 토큰, 그리고 Claude에게는 13,027 토큰입니다. Claude는 아무도 무언가를 생각하기도 전에, 동일한 텍스트에 대해 Google보다 63% 더 많은 프롬프트 비용을 저에게 청구하고 있습니다.

Frontier models (최첨단 모델)은 3~7초 범위에 있습니다. Grok은 뒤처져 있습니다. Mistral은 이상합니다. 그들의 Large 모델은 최신인 Medium 모델보다 훨씬 빠릅니다. Gemini Pro 또한 별로입니다. Google, 당신들의 TPU는 어디에 있나요?

Mistral Medium은 별도로 언급할 가치가 있습니다. 하루 동안 동일한 프롬프트를 일곱 번 실행한 결과: 3.3초, 3.6초, 24.1초, 35.0초, 27.9초, 11.1초, 2.9초였습니다. 출력값은 매번 57에서 109 토큰 사이였습니다. 이는 그들의 인프라가 불안정한 날이었다는 뜻입니다. 제가 어떤 단일 측정값을 취했더라도, 이 모델에 대해서는 틀린 결과가 나왔을 것입니다.

이제 다른 그룹을 보겠습니다.

• Qwen 행은 이미 1,024개의 추론 (reasoning) 토큰으로 제한되어 있습니다. 제한되지 않은 수치는 더 아래에 있으며, 결과는 더 좋지 않습니다.

15초 미만인 유일한 모델은 그 수치에 도달하기 위해 '생각하는 모자(thinking cap)'가 필요했습니다. 나머지는 네 문장의 투표를 생성하는 데 13초에서 34초가 필요합니다. 제 게임에서는 12개의 봇이 차례대로 대화를 나눕니다. 한 차례당 30초가 걸린다면, 한 라운드의 토론을 보는 데는 6분 동안 로딩 스피너를 지켜봐야 합니다.

그것이 원래 쓰려던 기사의 내용이었습니다.

하지만 한 가지 예외가 있습니다

Claude 4.5 Haiku는 느렸습니다.

매우 느립니다. 왜일까요? 가장 작고, 가장 저렴하며, 따라서 가장 빠른 모델 아닌가요? 분명히, 이 라인업에서 가장 느린 모델 중 하나입니다.

도대체 무슨 일이 일어나고 있는 걸까요?

파이프라인은 괜찮습니다

저의 첫 번째 추측은 하드웨어였습니다. 미국이 더 나은 하드웨어를 가지고 있지 않나요? 그리고 서버도 더 가까워서 네트워크 지연 시간 (latency)이 적을 것이고요.

글쎄요, 꼭 그렇지는 않습니다. 출력 토큰을 초 단위로 나누면, 제가 각 모델에 대해 수행한 모든 실행에 대해 프리필 (prefill)을 포함한 호출당 대략적인 처리량 (throughput)을 얻을 수 있습니다:

• Qwen3.7 Flash: 104-145 tokens/s
• Claude 4.5 Haiku: 90-98 tokens/s
• DeepSeek V4 Flash: 73-76 tokens/s
• Gemini 3.1 Pro: 70-78 tokens/s
• GLM-5.2: 57-74 tokens/s
• MiniMax M3: 48-78 tokens/s
• Claude 5 Opus: 37-49 tokens/s
• Qwen3.8 Max: 42-44 tokens/s
• Kimi K3: 26-35 tokens/s

DeepSeek V4 Flash를 보십시오. 세 번의 실행에서 각각 990, 1,415, 2,275개의 출력 토큰 (output tokens)을 생성했는데, 생성 속도 (generation rate)는 73-76 tokens/s에서 전혀 벗어나지 않았습니다. 연결은 안정적이었습니다. 모델은 단지 세 번째 실행에서 두 배 더 많은 내용을 쓰기로 결정했을 뿐이며, 실제 경과 시간 (wall clock)은 13.3초에서 30.1초로 늘어났습니다.

DeepSeek와 MiniMax는 Google이 실행하는 그 어떤 모델만큼이나 빠르게 생성합니다. 이들이 다섯 배 더 오래 걸리는 이유는 여덟 배 더 많은 내용을 쓰기 때문입니다. 오직 Kimi와 Qwen Max만이 토큰당 속도 자체가 느리며, 이들조차도 토큰 수 자체가 대부분의 성능 저하를 야기합니다.

재미있게도, Haiku는 Qwen 3.7 Flash를 제외한 여기 있는 모든 모델보다 더 빠르게 타이핑하며, 이는 제가 가진 모델 중 가장 느린 모델입니다. 초당 90 토큰을 생성하며, 답변하는 데 42초가 걸립니다. 텍스트를 생성하는 데 어려움을 겪는 것이 아닙니다. 단 네 문장을 말하기 위해 4,000개의 토큰을 생성하고 있는 것입니다.

따라서 전체 표는 하나의 숫자로 귀결됩니다: 네 문장이 필요한 질문에 답하기 전에 모델이 얼마나 많은 토큰을 쓰기로 결정하는가? Opus는 220에서 387개를 썼습니다. Haiku는 1,769에서 4,095개를 썼습니다.

그들은 다르게 생각합니다

최신 Anthropic 모델들은 모두 적응형 추론 (adaptive reasoning)을 지원합니다. 모델이 요청을 읽고 스스로 얼마나 많은 사고 (thinking)가 필요한지 결정하는 방식입니다. Haiku는 너무 오래되어 이를 지원하지 않습니다. Opus 5는 이 프롬프트에 대해 220에서 387개의 토큰을 출력하며, 여기에는 답변과 추론 (reasoning)이 모두 포함됩니다. GPT 모델들도 마찬가지이며, Sol은 훨씬 더 적게 (~150 토큰) 출력합니다. Gemini 3 역시 이를 수행하지만, 더 큰 수치에 도달합니다. Google은 이를 동적 사고 (dynamic thinking)라고 부르며, 해당 세대에서는 기존의 사고 예산 (thinking budget) 방식이 폐기되었습니다. Grok은 이를 전혀 수행하지 않고 고정된 높은 노력 (fixed high effort)으로 실행되며, 이것이 10-15초가 걸리는 이유입니다.

제 목록에 있는 모든 중국산 모델은 요청이 무엇이든 상관없이 모든 요청에 대해 거의 최대 출력 (full tilt)으로 추론을 수행합니다:

• Kimi K3는 항상 최대 출력 (max effort)으로 작동합니다. 이를 낮출 수 있는 지원되는 방법이 없습니다. 출력 토큰의 대략 85~90%가 추론 (reasoning)에 사용됩니다.
• Qwen은 사전에 설정하는 thinking_budget을 제공합니다. 기본값은 4096이며, 아래에서 100초가 소요된 실행 결과는 바로 이 기본값 때문에 발생했습니다.
• DeepSeek 및 GLM은 제가 제어할 수 있는 깊이 조절 (depth control) 기능 없이 추론 전용 (thinking-only) 엔트리를 제공합니다.
• MiniMax M3는 적응형 추론 (adaptive thinking)을 광고하며, 이 모델이 흥미롭습니다. 이름에 해당 기능을 명시하고 있음에도 불구하고, 누구에게 투표할지 결정하는 데 1,216에서 2,381개의 토큰을 사용했습니다.

코딩 에이전트 (coding agent)를 구축하거나 어려운 질문에 답하는 상황이라면 이 모든 방식이 정당화될 수 있습니다. 추론 모델 (reasoning model)은 더 오래 생각할수록 거의 항상 더 높은 점수를 받는 벤치마크 (benchmarks)를 기준으로 평가되며, 토큰 사용에 대해 비용을 청구하지도 않기 때문입니다. 그대로 두면 모든 것에 대해 깊이 생각하는 것이 기본 동작이며, 이는 제가 운영하지 않는 리더보드 (leaderboard)에서 승리하는 방식이기도 합니다.

하지만 제 게임은 성격이 다릅니다. 봇이 투표를 하기 위해 30초를 기다리는 것은 치명적입니다. 세상의 나머지 사람들이 중국 AI가 경주에서 승리하는 것을 축하하고 있는 동안, 기본적인 채팅에서 이런 느린 속도를 마주하며 느끼는 제 좌절감을 상상해 보십시오.

복권

아, 그리고 이 성능은 매우 불규칙합니다. Qwen 3.8 Max가 이를 가장 잘 보여줍니다. 제가 제한을 걸기 전, 동일한 프롬프트로 네 번 실행했을 때의 결과는 다음과 같습니다: 26.3초, 30.6초, 81.9초, 100.5초. 출력 토큰 수도 이에 따라 1,068, 1,149, 3,363, 4,169개로 변했습니다.

이 수치들을 나열해 보면 생성 속도 (generation rate)는 초당 40.6, 37.5, 41.1, 41.5 토큰입니다. 거의 일정합니다. 모델은 내내 동일한 속도로 작동하고 있었습니다. 단지 두 번의 경우에, 이 질문이 세 배 더 많은 생각을 할 가치가 있다고 판단했을 뿐입니다.

해당 실행들 사이에는 아무것도 변하지 않았습니다. 동일한 프롬프트, 동일한 날짜, 동일한 서버, 모든 것이 동일했습니다. 움직이는 것은 사고 사슬 (Chain of Thought) 그 자체이며, 사고 사슬은 모델이 온도 (Temperature) 설정이 적용된 상태에서 한 번에 하나의 토큰씩 작성하는 시퀀스입니다. 저는 Qwen을 0.7의 온도로 실행했습니다. 추적 (Trace) 초기 단계에서 모델이 "첫째 날 Kenji가 말한 내용을 다시 읽어보자"라고 판단하느냐 아니냐에 따라 갈리며, 이 하나의 분기점이 1,100개의 토큰을 얻을지 아니면 4,100개의 토큰을 얻을지를 결정합니다.

따라서 이는 어떤 전형적인 값 주변에 퍼져 있는 것이 아니라, 두 가지 결과에 더 가깝습니다. Max의 네 번의 실행 결과는 1,068, 1,149, 그리고 3,363, 4,169였습니다. 두 번은 짧고, 두 번은 길었으며, 그 중간은 없었습니다. Qwen Flash도 마찬가지였습니다. 1,831, 1,897, 1,912였고, 그 후 한 번의 실행이 3,035였습니다. Haiku는 1,769, 2,635, 4,095로 나타났습니다.

이런 현상은 예측하여 대비할 수 없습니다. 전형적인 경우에 27초가 걸리고 최악의 경우에 100초가 걸리는 모델은 최악의 경우를 대비한 타임아웃 (Timeout) 설정이 필요하며, 사용자는 그 시간을 견뎌내야 합니다.

낮은 사고 예산 (Low thinking budget)

Qwen의 API는 thinking_budget을 사용합니다. 저는 세 가지 Qwen 모델 모두의 추론 토큰 (Reasoning tokens)을 1,024개로 제한했고, Max는 25.4~27.3초 사이에 안착했습니다. 추론 능력은 떨어지지만, 견딜 만한 지연 시간 (Latency)을 갖게 된 것입니다. 사람이 앉아서 기다려야 하는 게임이라면 저는 기꺼이 이 거래를 수용할 것입니다.

이 제한은 제한치를 초과했던 모델들에게만 도움이 되었습니다. Flash는 제한이 없을 때 1,831에서 3,035개의 토큰을 작성했으므로, 제한을 두자 8.4~10.5초로 줄어들었습니다. Plus는 이미 대부분의 경우 제한 범위 내인 760에서 1,262개의 토큰을 선택하고 있었기에, 제한을 두어도 아무것도 변하지 않았고 여전히 31초의 실행 시간을 기록했습니다.

비교를 위해 말씀드리자면, Gemini 1.5 Pro는 제한된 Qwen Max와 거의 비슷한 양인 821940개의 토큰을 작성하며, 매 실행마다 11.612.1초 안에 결과를 돌려줍니다. 유사한 출력물을 내면서 대기 시간은 절반 미만이며, 편차도 전혀 없습니다. 또한 아무도 예산을 설정하지 않았습니다. 높은 노력(High effort) 수준으로 작동하며 스스로 그 수치를 결정합니다.

MiniMax M3는 예산 파라미터 (Budget parameter)가 아예 없습니다. 적응형 설정 (Adaptive setting)이 유일한 조절 장치이며, 더 강력한 제어 수단은 사고 기능을 완전히 끄는 것뿐입니다. Kimi K3는 문서화되지 않은 K2 시대의 thinking: disabled 토글이 있는데, 저는 이를 기반으로 구축하고 싶지 않습니다. 이 두 모델의 경우, 측정되는 값이 곧 얻게 되는 결과입니다.

돈(비용) 측면에서는 좋은 소식입니다

저렴한 모델들은 정말로 저렴합니다:

• Qwen3.7 Flash: 투표당 $0.0004
• DeepSeek V4 Flash: $0.0005
• DeepSeek V4 Pro: $0.0009

DeepSeek V4 Flash는 Mistral Large가 73134개의 출력 토큰 (output tokens)을 생성할 때 9902,275개를 생성했지만, 비용은 여전히 8배 더 저렴했습니다.

다음은 Kimi K3입니다. 이 모델은 입력(in) $3, 출력(out) $15로 청구되는데, 이는 Claude 5 Sonnet과 동일한 요금 체계입니다. K3의 세 번의 실행 중 한 번이 따뜻한 캐시 (warm cache)를 포착했으므로 표의 평균값은 잠시 무시하십시오. 차가운 실행 (cold runs) 시 K3는 $0.036 및 $0.041이 들었고, Sonnet은 $0.043 및 $0.045가 들었습니다. 답변 시간이 4배 더 걸렸음에도 비용은 거의 비슷했으며, K3 출력 토큰의 85~90%는 아무도 볼 수 없는 추론 (reasoning) 과정이었습니다. 또한 Sonnet은 동일한 텍스트에 대해 13,027개의 입력 토큰 (input tokens)을 청구받는 반면, K3는 8,192개의 입력 토큰에 대해 청구된다는 점도 주목하십시오.

여기서 Qwen의 캡 (cap) 제한도 도움이 되었습니다. Max의 제어되지 않은 4,169개 토큰의 사고 (think) 비용은 $0.0415였으나, 일반적인 실행 시에는 $0.0229~$0.0235였습니다. 이 로또는 지연 시간 (latency)뿐만 아니라 청구 비용 측면에서도 로또이며, 사고 (thinking) 과정을 제한함으로써 두 가지 모두를 제한했습니다.

캐싱 (Caching)은 모든 모델에서 작동하며, 이는 매 턴마다 점점 길어지는 대화 내용을 다시 보낼 때 중요합니다. 표에 나타난 넓은 비용 범위는 바로 이 효과 때문입니다. 저는 9분 간격으로 두 번의 전수 조사를 실시했는데, 두 번째 실행에서 Kimi는 $0.0411에서 $0.0163으로, GLM은 $0.0167에서 $0.0083으로 감소했습니다. 이때 프롬프트 (prompt)는 동일했으며 출력 토큰은 첫 번째 실행보다 더 많았습니다.

MiniMax는 제가 의도적인 조치를 취하기도 전인 첫 번째 탐색 호출에서 캐시 히트 (cache hits)를 보고했습니다. Qwen의 암시적 캐시 (implicit cache)는 두 실행 사이에서 실제 호출 비용을 $0.0229에서 $0.0115로 절감했습니다. DeepSeek는 캐시된 입력을 일반 요율의 2%로 읽어들이는데, 이는 제가 조사한 전체 목록 중 가장 큰 할인율입니다.

그리고 Fugu가 있습니다

Sakana의 Fugu Ultra는 일본 모델이며, 두 번째 표에 있는 가장 느린 모델보다 7배 더 느립니다.

이 모델은 너무 느려서 응답을 기다린 지 3분이 지나자 제 테스트가 타임아웃 (timing out) 되었습니다.

성공적인 투표 한 번에 발생한 비용은 $0.585였습니다. 그중 약 65%는 저에게 전달되지 않는 내부 초안 및 재독(re-reads) 과정인 orchestration_input_tokens와 orchestration_output_tokens였습니다. 이것이 무엇을 오케스트레이션 (orchestrating) 하는지는 모르겠지만, 저에게는 전혀 사용 불가능한 수준입니다. Fable보다 4배나 비싸면서 대기 시간은 영원히 느껴질 정도입니다.

몇 분 전에 보낸 바이트 단위로 동일한 (byte-identical) 프롬프트에 대한 캐시 히트율 (Cache hit rate)은 0이었습니다. 낮은 것이 아니라, 0이었습니다.

결론

• 중국 모델들은 더 많이 추론 (reason) 합니다 - 이것이 속도가 느린 주요 원인입니다.
• 토큰당 속도도 더 느리지만, 그 차이는 약 20-40% 정도입니다. Kimi K3와 Qwen 3.8 Max는 약 2배 정도 느려 예외적이며, Qwen 3.7 Flash는 전체 라인업 중 가장 빠른 생성기 (generator)입니다. 처리량 (throughput)보다는 토큰 수 (token count)가 대부분의 문제를 일으킵니다.
• 일부 중국 모델들은 저렴합니다. 하지만 Kimi K3와 Qwen 3.8 Max는 그리 저렴하지 않습니다.

이것이 제가 벤치마크 (benchmarks)를 싫어하는 이유입니다.

뒤늦게 추가하자면: 이 글을 쓰는 동안 DeepSeek에서 결제 조정 (billing adjustment)에 관한 이메일을 보냈습니다. 서비스를 계속 사용하면 새로운 약관에 동의하게 됩니다. 따라서 제 표에서 가장 저렴한 열 (column)은 유효 기간이 있지만, 순위를 바꿀 만큼 크게 변동될지는 의문입니다.