Fable 5·GPT-5.6 Sol·Kimi K3, 단가 3.3배 차이는 실제 비용 3.3배 차이인가?

토큰과 단가표를 먼저 읽는 법

AI 모델의 요금은 글자 수나 요청 횟수가 아니라 토큰 수로 매겨진다. 토큰은 글을 처리 단위로 잘게 쪼갠 조각이다. Kimi의 공식 문서는 일반적인 영어 텍스트에서 1토큰이 대략 영문 3~4글자에 해당한다고 설명한다. 한국어는 이보다 잘게 쪼개지는 편이라 같은 의미의 문장이 영어보다 토큰을 더 먹는다.

요금표는 이 토큰 100만 개(1M)당 얼마인지를 적어 둔 표이고, 항목은 보통 셋으로 나뉜다. 입력은 내가 모델에 밀어 넣는 프롬프트와 첨부 문서, 출력은 모델이 생성해 돌려주는 글, 캐시 히트는 앞서 보낸 것과 똑같은 앞부분을 다시 보낼 때 적용되는 할인가다. 에이전트처럼 같은 지시문과 같은 코드베이스를 반복해서 넣는 작업일수록 캐시 히트가 차지하는 비중이 커진다.

여기서 헷갈리기 쉬운 지점이 하나 있다. 표의 단가는 100만 토큰당 가격이지 한 번 호출할 때 내는 돈이 아니다. 실제 결제액은 언제나 단가 곱하기 수량이고, 이 글이 다루는 것은 그 수량 쪽에서 벌어지는 일이다.

세 모델의 공식 단가는 얼마나 다른가

2026년 7월 26일 기준으로 각사 공식 문서에 적힌 값은 다음과 같다. 세 모델 모두 100만 토큰 안팎의 컨텍스트 창을 갖고 있어 다루는 작업의 크기 자체는 비슷하다.

단가만 보면 순서가 명확하다. Fable 5는 Kimi K3의 3.3배인데, 입력과 출력에 같은 배수가 걸린다는 점이 정확하다. Sol과 비교하면 입력은 2배지만 출력은 1.7배로 조금 좁다. 눈여겨볼 것은 캐시 히트 열이다. 세 곳 모두 입력가의 정확히 10%로 맞춰져 있다. 즉 캐싱은 세 모델의 절대 비용을 다 같이 낮출 뿐, 어느 하나를 상대적으로 유리하게 만들지 않는다. 비용 때문에 모델을 고민하는 사람이 캐싱을 먼저 떠올리는 경우가 많은데, 이 비교에서는 답이 되지 않는다.

같은 글인데 왜 토큰 수가 달라지는가

토크나이저는 글을 토큰으로 쪼개는 규칙이다. 이 규칙이 바뀌면 같은 문장이라도 토큰 개수가 달라진다. 앤스로픽은 공식 요금 문서에서 Claude 4.7 이후 모델과 Mythos Preview가 새 토크나이저를 쓰며, 이 토크나이저가 같은 텍스트에 대해 약 30% 많은 토큰을 만들어 낸다고 명시했다. 성능 향상과 맞바꾼 선택이라는 설명도 함께 붙어 있다.

이 30%가 무엇과 비교한 값인지는 정확히 짚어야 한다. 앤스로픽 자신의 이전 세대 토크나이저와 비교한 수치이고, 다른 회사 모델과 토큰 수를 직접 비교한 공식 수치는 공개돼 있지 않다. 그러니 이 값을 가져다 회사 간 비용 차이를 곱셈으로 계산하면 안 된다.

그래도 실무적으로 남는 결론은 분명하다. 단가표의 배수는 실제 지출 격차의 하한이지 상한이 아니다. 같은 문서를 넣어도 모델마다 청구되는 토큰 수량이 다를 수 있으므로, 진짜 비교는 같은 작업을 양쪽에 한 번씩 돌려 보고 각 콘솔에 찍힌 사용량을 확인하는 것이다. 세 회사 모두 응답에 사용 토큰 수를 함께 돌려주므로 이 확인은 어렵지 않다.

길어지면 단가 자체가 바뀌는 구간이 있다

OpenAI는 Sol에 길이 기반 할증을 두고 있다. 입력이 27만 2천 토큰을 넘어가면 그 요청 전체가 입력 2배, 출력 1.5배로 계산된다. 100만 토큰당으로 환산하면 입력 10달러, 출력 45달러다. 초과분만 비싸지는 것이 아니라 그 요청 전부에 적용된다는 점이 중요하다.

이 구간은 생각보다 쉽게 닿는다. 저장소 전체를 읽혀 리팩터링을 시키거나, 긴 회의록과 계약서 묶음을 통째로 넣는 작업이 여기 해당한다. 반대로 Fable 5와 Kimi K3의 요금표에는 길이 구간이 없다. 앤스로픽은 1M 컨텍스트 전 구간을 표준 단가로 청구한다고 명시했고, Kimi K3 요금표도 104만 8576 토큰 컨텍스트에 단일 행만 두고 있다.

그래서 같은 세 모델이라도 작업 성격에 따라 순위가 흔들린다. 짧은 요청을 대량으로 돌리는 작업에서는 단가표 순서가 그대로 유지되지만, 한 번에 수십만 토큰을 밀어 넣는 에이전트 작업에서는 Sol의 실효 단가가 Fable 5 쪽으로 올라붙는다.

한 번에 제대로 나오는가 — 재시도는 단가에 곱해진다

세 모델에 같은 프롬프트를 한 번씩만 주고 결과물을 비교한 리뷰가 있다. 사람이 중간에 개입하면 모델의 실력이 아니게 되므로 단일 프롬프트로 통제한 방식이다. 도시 교통 시뮬레이터, 에이전트 UI, 웹 격투 게임 세 과제를 같은 조건으로 시켰다.

결과는 갈렸다. 교통 시뮬레이터에서 Fable은 차량이 교차로를 통과하는 물리 처리와 신호 표현까지 만들어 냈고, Sol은 차량을 사각 박스로 그린 데다 충돌 처리가 없어 차들이 겹쳐 쌓였다. Kimi는 그 사이였다. 도로 표현은 Sol보다 낫고 겹침 문제는 Sol과 비슷했다. 에이전트 UI에서는 Fable이 가장 나았고 Kimi가 다음, Sol은 연결선이 엉뚱한 지점에 붙었다. 리뷰어는 Sol에 대해 완성도를 스스로 확인하고 다시 고치는 반복이 부족해 보인다고 평했다.

이 대목이 비용 이야기와 이어진다. 결과가 한 번에 나오지 않으면 같은 작업을 다시 시켜야 하고, 그때마다 입력과 출력이 다시 청구된다. 같은 작업을 한 번 더 시키면 싼 모델의 실효 단가는 두 배가 된다. 3.3배 차이는 첫 시도에서 세 번 다시 시켜야 겨우 뒤집히는 크기이므로 여전히 싼 쪽이 유리한 구간이 넓지만, 단가표만 보고 계산한 절감액이 그대로 실현되지는 않는다는 뜻이다.

하나 덧붙이면, 리뷰어는 같은 모델이라도 어떤 실행 도구로 돌렸느냐에 따라 결과물의 완성도가 눈에 띄게 달랐다고 했다. 모델을 바꾸기 전에 지금 쓰는 실행 환경부터 점검할 이유가 여기에 있다.

그래서 어떻게 고르는가

먼저 자기 작업이 어느 항목에 걸리는지부터 확인한다. 한 번에 넣는 입력이 27만 토큰을 넘나드는가, 같은 지시문을 반복해 넣어 캐시 비중이 큰가, 결과를 받아 그대로 쓰는가 아니면 두세 번 고쳐 쓰는가. 이 세 답이 정해지면 어느 모델이 유리한지는 계산으로 나온다.

간단한 예를 보자. 입력 20만 토큰, 출력 2만 토큰짜리 작업 한 번을 캐시 없이 돌리면 Fable 5는 2달러에 1달러를 더해 3달러, Sol은 1달러에 0.6달러를 더해 1.6달러, Kimi K3는 0.6달러에 0.3달러를 더해 0.9달러다. 여기까지는 표의 3.3배가 그대로 나온다. 그런데 입력을 30만 토큰으로 늘리는 순간 Sol만 할증 구간에 들어가 3달러에 0.9달러를 더한 3.9달러가 된다. 같은 작업에서 Fable 5는 4달러이므로 둘의 차이가 사실상 사라진다. 20만 토큰에서 1.9배였던 Sol의 가격 우위가 여기서는 1.03배로 줄고, 같은 조건에 1.2달러인 Kimi K3와의 격차는 1.8배에서 3.3배로 벌어진다. 순위가 뒤집히지는 않지만, 표를 보고 계산한 절감액은 이 구간에서 증발한다.

구독 요금제를 쓰는 개인이라면 판단 기준이 하나 더 있다. 지금 쓰는 모델로 사용량이 남는다면 굳이 바꿀 이유가 없다. 반대로 한도가 자주 마르고 그때마다 몇 시간씩 기다린다면, 마르는 구간을 더 싼 모델로 메우는 조합이 실익이 크다. 어느 쪽이든 결정의 근거는 단가표가 아니라 자기 사용 기록이다.

조직이라면 여기에 한 가지를 더 본다. 결과물을 다시 시키는 횟수는 모델만의 문제가 아니라 지시를 얼마나 정확히 주는지, 결과를 검증하는 절차가 있는지에 함께 달려 있다. 같은 모델로도 재시도를 절반으로 줄이면 단가를 3분의 1로 낮춘 것과 같은 효과가 난다. 모델 교체보다 이쪽이 대개 더 싸고 빠르다.