"LLM API"는 과거에 제공자당 기능적으로 한 가지를 의미했습니다: 하나의 모델, 하나의 가격, 하나의 기능 세트 말이죠. 하지만 이제는 더 이상 그렇지 않으며, Qwen의 현재 라인업은 왜 "LLM API 가격 책정"이라는 문구에 더 이상 단일한 정답이 없는지를 보여주는 명확한 사례입니다.

변화의 핵심: 제공자들은 릴리스당 하나의 플래그십 (flagship) 모델을 내놓는 대신, 명시적인 내부 계층 (internal tiers)을 출시하고 있습니다. Qwen이 3.5/3.6/3.7 버전 제품군에 걸쳐 flash/plus/max로 나누어 제공하는 것이 좋은 예시이며, DeepSeek의 Pro/Flash 분할이나 GLM의 번호가 매겨진 계층에서도 유사한 패턴이 나타납니다. 이는 단순한 명명 규칙의 특이점이 아닙니다. 이는 완전히 다른 애플리케이션이 아닌, 동일한 애플리케이션 내의 서로 다른 부분들을 겨냥하여 비용/성능 간의 절충안 (tradeoff)에 따라 동일한 기반 모델 제품군을 의도적으로 세분화한 것을 반영합니다.

구조적으로 변화하는 점: "어떤 LLM API를 사용해야 하는가"의 단위는 더 이상 제공자나 심지어 모델 제품군 자체가 아닙니다. 그것은 특정 작업(task)을 위한 특정 계층 (tier)입니다. 하나의 제품을 만드는 팀은 분류 (classification)를 위해 flash 계층의 Qwen을, 일반적인 채팅을 위해 plus 계층을, 그리고 복잡한 추론 (reasoning)을 위해 max 계층(또는 다른 제공자의 플래그십 모델)을 호출하는 것이 합리적일 수 있습니다. 이는 아키텍처 수준에서 한 번 결정하는 제공자의 선택이 아니라, 동일한 애플리케이션 내에서 이루어지는 선택입니다.

팀이 "LLM API 비용"을 어떻게 생각해야 하는지에 있어 이것이 중요한 이유: 의미 있는 비용 최적화 레버 (lever)는 더 이상 "어떤 제공자가 가장 저렴한가"가 아닙니다. 그것은 "각 호출을 해당 특정 작업에 대해 나의 품질 기준을 충족하면서도 가장 저렴한 계층으로 라우팅(routing)하고 있는가"입니다. 처음에 통합되었던 모델이라는 이유로 모든 호출을 기본적으로 플래그십 계층으로 설정하는 팀은, 어떤 제공자를 사용하든 상관없이 비용 절감 기회를 놓치고 있는 것이며, 이러한 절감액은 보통 동일한 계층 내에서 경쟁하는 제공자들 간의 격차보다 더 큽.

접근 계층(access-layer)의 함의: 이러한 분할은 티어 간 전환 비용이 저렴할 때만 실행 가능해집니다. 플래시 티어(flash-tier) Qwen이 분류 작업(classification task)을 플러스 티어(plus-tier)만큼 잘 처리하는지 테스트하는 것이 의미 있게 다른 통합 작업을 요구한다면, 대부분의 팀은 시도조차 하지 않을 것이며, 이 티어 분할은 실제로 비용을 절감하는 것보다는 이론적인 상태로 남게 됩니다. 이것이 바로 통일된, OpenAI와 호환되는 접근 계층(예: RouteAI)이 단순히 다중 제공업체 접근성을 넘어 구조적으로 중요해진 이유입니다. 이러한 접근 계층은 티어 간 내부 테스트를 프로젝트가 아닌 매개변수 변경으로 만들어주며, 이는 팀들이 실제로 이 분할을 활용하기 위한 전제 조건입니다.

주시해야 할 열린 질문: 이러한 티어링 패턴이 제공업체 전반에 걸쳐 표준화됨에 따라, '모델 선택'이라는 일회성 아키텍처 결정이 캐싱이 데이터베이스의 표준이 된 방식처럼 동적이고 호출(per-call) 단위의 티어 라우팅으로 대체되어 일반적인 인프라 계층이 될까요? 가격 구조는 이미 그 방향으로 나아가고 있습니다.

(위에서 언급된 Qwen 티어 비교를 실행하기 위해 RouteAI의 호환 엔드포인트를 사용했습니다. 이는 티어 전반에 걸친 테스트를 프로젝트가 아닌 설정 변경으로 만들었기 때문입니다. 권장 사항이 아니라 방법론 공개입니다.)