왜 내가 멀티모달 AI를 장난감처럼 취급하기를 그만두고 p99 스택에 통합했는가

이미지 분류 (image-classification) 작업이 중단되어 새벽 3시에 프로덕션 대시보드가 불타오르는 것을 본 적이 있다면, 왜 내가 멀티모달 API를 진지하게 받아들이기 시작했는지 이미 알고 있을 것입니다. 약 18개월 전, 우리 팀은 자체 호스팅된 모델들의 짜깁기 위에서 비전 (vision) 워크로드를 실행하고 있었고, 우리의 p99 지연 시간 (latency)은 운이 좋은 날에도 고통스러운 3.2초였습니다. 오늘날, global-apis.com을 통해 관리형 멀티모달 엔드포인트 (managed multimodal endpoints)로 신중하게 마이그레이션한 덕분에, 우리는 99.94%의 가동 시간 (uptime)과 함께 두 개 지역에서 약 480ms의 p99를 유지하고 있습니다. 이것은 내가 그때 가졌더라면 좋았을 현장 가이드입니다.

내가 평가한 모델들, 중요했던 아키텍처 (architecture) 선택, 그리고 기업 예산에 실제로 맞았던 가격 산출 방식을 안내해 드리겠습니다. 데모가 아닌 실제 프로덕션 시스템처럼 작동해야 하는 비전 또는 오디오 파이프라인 (audio pipelines)을 구축하고 있다면 계속 읽어주세요.

라인업: 내가 테스트한 대상들

여기에 내가 테스트한 명단이 있으며, 모두 Global API 엔드포인트를 통해 라우팅되었습니다. 가격은 발표된 대로 출력 토큰 100만 개당 가격입니다.

지연 시간 분포를 도식화했을 때 세 가지 사항이 즉시 눈에 띄었습니다. 첫째, 더 작은 Qwen3-VL-8B는 p50에서 유의미하게 앞서나가지 않습니다. 꼬리 부분 (tail)만이 혜택을 보며, 그마저도 미미합니다. 둘째, $0.01/M인 GLM-4.5V는 터무니없이 저렴하지만, 이는 더 큰 형제 모델과 동일한 제품이 아니며, 어디에서 한계가 발생하는지 설명하겠습니다. 셋째, Doubao-Seed-2.0-Pro의 128K 컨텍스트 윈도우 (context window)는 진정으로 차별화됩니다. 시각적 분석을 위해 PDF 책 전체를 밀어 넣는 경우라면, 바로 이것을 원하게 될 것입니다.

이미지 워크로드 벤치마크: 프로덕션에서 실제로 중요한 것

저는 리더보드의 영리한 수수께끼를 흉내 내는 대신, 실제 프로덕션 시나리오를 반영하도록 설계된 네 가지 벤치마크 스위트(benchmark suites)를 실행했습니다. 꼬리 지연 시간(tail latency)의 지리적 차이를 포착하기 위해 us-east-1과 eu-west-1에서 동시에 테스트를 수행했습니다.

시나리오 1: 밀집된 거리 이미지에서의 객체 인식 (Object Recognition)

물류 고객사를 위해 우리는 밀집 객체 인식(dense object recognition)을 수행해야 했습니다. 즉, 차량 대수를 세고, 상점 간판을 읽으며, 항공 드론 촬영물에서 건설 장비를 식별하는 작업입니다.

전반적인 정확도는 모두 견고했지만, 아키텍처에 대한 논의가 시작되는 지점은 바로 p99입니다. 520ms를 기록한 Qwen3-VL-32B는 큐 붕괴(queue collapse) 없이 트래픽 급증을 흡수할 수 있는 충분한 여유를 제공했습니다. 290ms를 기록한 GLM-4.5V는 너무 빨라서 다음 벤치마크를 읽기 전까지는 거의 기본 모델로 연결할 뻔했습니다.

시나리오 2: 다국어 문서의 OCR (Optical Character Recognition)

이 워크로드는 저가형 티어(cheap tier)의 취약점을 드러냈습니다.

GLM-4.5V에서 나타난 12.3%의 오류율은 프로덕션 환경이 실험실과는 다르다고 말할 때 제가 의미하는 바를 정확히 보여줍니다. $0.01/M의 가격이라면, '정확한 문서당 비용'이 Qwen3-VL-32B의 $0.52/M에 도달하기 전까지는 많은 오류를 감수할 수 있을 것처럼 보입니다. 저희가 계산해 보았습니다. 낮은 신뢰도 시 재시도하는 래퍼(retry-on-low-confidence wrapper)를 사용할 경우, GLM-4.5V는 '검증된 정확한' 문서당 약 $0.04가 소요되어 기준점인 $0.52와 비교됩니다. 서류상으로는 GLM이 승리합니다. 하지만 실제로는 재시도 로직이 두 번째 API 홉(hop)을 추가했고, 우리의 p99는 1.8초로 급증했습니다. 결국 우리는 이를 폐기했습니다.

시나리오 3: 차트, 다이어그램 및 대시보드 추론

내부 도구용으로, 우리는 모델에 Grafana 패널의 스크린샷을 입력하고 "무엇이 잘못되었나요?"라고 질문합니다.

단 세 개의 모델만이 이 단계에 도달했습니다. 더 저렴한 모델들은 축 레이블(axis labels)과 범례(legends)에서 막혔습니다. 또한 이 과정에서 Qwen3-VL-32B가 다른 모델들과 달리 부하 상황에서도 잘 견뎌낸다는 사실을 발견했습니다. 시뮬레이션된 버스트(burst, 200개의 동시 요청) 상황에서 p99 지연 시간은 850ms 미만을 유지했습니다. GLM-4.6V는 동일한 부하에서 1.6초를 기록했습니다. 큐(queue) 기반으로 오토스케일링(auto-scaling)을 수행할 때 이는 매우 유의미한 차이입니다.

시나리오 4: 코드 스크린샷 → 실행 가능한 코드

우리 팀 엔지니어들은 게으르며, 그것을 자랑스럽게 여깁니다. 그들은 터미널 출력을 복사하는 대신 스크린샷을 찍습니다.

상위 두 모델 간의 오차율 차이는 5%였습니다. 월간 50,000개의 스크린샷을 기준으로 하면, 이는 1,500건의 수동 수정 작업을 절약한 셈입니다. 이 오차율 계산을 굳이 입 밖으로 다시 반복하지는 않겠습니다.

오디오는 완전히 다른 차원의 문제입니다

만약 여러분의 로드맵에 음성(voice)—전사(transcriptions), 콜센터 분석, 오디오 Q&A—가 포함되어 있다면, 선택지는 하나로 좁혀집니다. Qwen3-Omni-30B가 이 라인업에서 유일한 진정한 옴니모달(omni-modal) 옵션입니다. 다른 모델 중 어느 것도 오디오를 수용하지 못합니다.

고객 지원 통화 코퍼스(corpus)에 이를 연결했을 때 효과적이었던 결과는 다음과 같습니다:

오디오의 지연 시간(latency) 문제는 비전(vision)보다 더 까다롭습니다. 모델이 응답하기 전에 전체 페이로드(payload)를 수용해야 하므로, 30초 분량의 클립에 대해 p99가 약 1.4초 정도 될 것으로 예상하십시오. 우리는 부분적인 전사(partial transcripts) 내용을 UI로 스트리밍하고, "감정(emotion)" 분류를 별도의 가벼운 패스(pass)로 실행함으로써 이를 처리합니다.

다음은 제가 실제로 배포한, Global API를 가리키는 베이스 URL(base URL)이 포함된 코드 스니펫입니다:

from openai import OpenAI
import time

...

저는 모든 멀티모달 호출을 타이밍 데코레이터 (timing decorator)로 감쌉니다. 여러 리전 (region)에 걸친 실제 p99를 측정하지 않는다면, 당신은 눈을 가리고 비행하는 것과 같습니다.

정직한 가격 산정 방식

돈 이야기를 해봅시다. 왜냐하면 대부분의 "AI 전략" 논의가 죽어버리는 곳이 바로 스프레드시트이기 때문입니다.

핵심 수치인 Qwen3-VL-32B의 1만 회 분석당 월 $26라는 금액은 지루해 보입니다. 바로 그게 핵심입니다. 예산 항목에서는 지루한 것이 당신이 원하는 것입니다. 하지만 여기에 아키텍처적 함정이 있습니다. 그 $26라는 금액은 재시도 레이어 (retry layers)를 추가하지 않고, 신뢰도 점수 산정을 위한 모델-애즈-저지 (model-as-judge)를 실행하지 않으며, 합의 투표 (consensus voting)를 위해 여러 모델로 팬아웃 (fanning out)하지 않는다는 가정하에 산출된 것입니다. 품질 기준이 "프로덕션 등급 (production-grade)"으로 올라가면, 실제 이미지당 비용은 쉽게 세 배로 뜁니다.

한 고객사의 경우, 신뢰도가 낮은 호출에 대해 Qwen3-VL-8B 심판 모델 (referee model)을 함께 사용한 Qwen3-VL-32B를 통해 검증된 정확한 OCR 문서당 $0.087의 비용을 도출했습니다. 이 이중 모델 (dual-model) 접근 방식은 추가적인 홉 (hop)이 발생함에도 불구하고 p99를 720ms로 유지했습니다. 작은 모델은 호출 비용이 매우 저렴하여 예산을 초과하지 않기 때문입니다.

신뢰성, SLA, 그리고 멀티 리전 패턴

여기서부터 제 주관적인 의견이 들어갑니다. 멀티모달 엔드포인트 (endpoints)는 버스트 (burst) 상황에서 기만적일 정도로 취약합니다. 제가 지금 사용하는 영리한 방법은 다음과 같습니다. 기본 트래픽을 us-east-1에서 실행하되, 연속적인 타임아웃 스파이크 (timeout spikes)가 발생하면 eu-west-1으로 전환되는 서킷 브레이커 (circuit breaker)를 작동시키는 것입니다.

제가 정착한 아키텍처는 다음과 같습니다:

import random
import time
from openai import OpenAI
...

지난 분기 동안, 이 페일오버 (failover) 패턴 덕분에 세 번의 리전 수준 장애를 피할 수 있었습니다. 이것이 없었다면 우리의 월간 가동 시간 99.94%는 99.6% 정도로 떨어졌을 것입니다. 오토스케일링 (Auto-scaling)만으로는 당신을 구원할 수 없습니다. API 게이트웨이 뒤에 있는 컴퓨팅 자원뿐만 아니라, _추론 용량 (inference capacity)_의 지리적 다양성이 필요합니다.

저의 솔직한 권장 사항

두 분기의 벤치마크, 네 번의 프로덕션 배포, 그리고 리전 장애를 추적하며 보낸 아주 긴 밤을 거친 후, 제가 모델을 선택하는 방식은 다음과 같습니다:

• 신규 프로덕션 (Greenfield production), 품질과 비용의 균형: Qwen3-VL-32B. 이것은 맥가이버 칼 (Swiss Army knife) 같습니다. 정확도가 높고, 지연 시간 (latency)이 예측 가능하며, $0.52/M의 비용 덕분에 아무도 예산을 두고 싸울 필요가 없습니다.

• 대규모 중국어 OCR 워크로드: GLM-4.6V. 순수 중국어 OCR 성능에서 Qwen을 근소하게 앞서며, 1.1%의 오류율은 우리의 내부 문서용으로는 수용 가능한 수준입니다. 32K 컨텍스트 (context) 덕분에 여러 페이지의 PDF를 처리할 여유도 제공합니다.

• 오디오가 로드맵에 포함된 경우: Qwen3-Omni-30B. 단언컨대 유일한 진정한 옴니모달 (omni-modal) 옵션입니다. 오디오 지연 시간 예산을 비전 (vision)과는 별개로 취급하고, 부분 결과 스트리밍 (partial-result streaming)을 구축하세요.

• 처리량 (throughput) 중심, 낮은 중요도, 대량의 데이터 (firehose volume): $0.01/M의 GLM-4.5V. 우리는 이를 사전 필터링 — "이 이미지가 더 큰 모델로 보낼 가치가 있는가?" — 용도로 사용해 왔으며, 이러한 하이브리드 패턴은 우리의 실질 비용을 약 40% 절감해 줍니다.

• 128K 컨텍스트, 문서 수준의 추론 (document-level reasoning): $3.00/M의 Doubao-Seed-2.0-Pro. 비싸지만, 90페이지 분량의 계약서를 단일 요청에 쏟아부어야 한다면 이 중 다른 어떤 것도 버텨내지 못합니다.

현재 제가 함께 일하는 팀은 멀티모달 트래픽의 약 70%를 Qwen3-VL-32B로, 18%를 오디오 포함 작업을 위한 Qwen3-Omni-30B로, 8%를 중국어 OCR을 위한 GLM-4.6V로 처리하며, 나머지는 더 작은 티어(tiers)들로 나누어 사용하고 있습니다.

맺음말

멀티모달은 과거에 연구용 데모에 불과했습니다. 2026년 현재, 그것은 인프라 (infrastructure)입니다. 그리고 인프라는 p99, SLA (서비스 수준 협약), 그리고 월간 반복 비용 (monthly recurring cost)에 응답해야 합니다. 가장 빠른 모델이 항상 정답은 아니며, 가장 저렴한 모델이 정답인 경우도 거의 없습니다. "최고"의 모델은 그 실패 모드 (failure modes)를 고려하여 아키텍처를 설계할 수 있는 모델입니다.

만약 멀티모달 도입을 계획 중이고, 이러한 엔드포인트(endpoints)들이 귀하의 자체 부하와 SLA 제약 조건 하에서 어떻게 작동하는지 확인하고 싶다면, Global API를 직접 테스트해 보길 권합니다. 제가 발견한 바로는 이런 종류의 작업에 있어 가장 예측 가능한 백본 (backbone)이었으며, 특정 모델을 미리 확정하지 않고도 귀하의 데이터로 평가할 수 있습니다.

이상입니다. 이제 가서 귀하의 실제 p99를 측정해 보세요.