LLM 엔드포인트 때문에 99.9% 가동 시간 SLA(Service Level Agreement)를 놓친 적이 있습니다.

제공업체가 다운되어서도, DDoS 공격을 받아서도 아니었습니다. 그들의 p99 지연 시간(latency)이 우리가 엔터프라이즈 고객에게 약속한 800ms 임계값을 조용히 넘어섰는데, 우리의 합성 모니터(synthetic monitors)는 평균 지연 시간(mean latency)을 기준으로 작동하고 있었기 때문입니다. 평균값은 괜찮아 보였습니다. 하지만 p99는 재앙이었습니다. 우리는 새벽 2시에 호출을 받았고, 백업 모델을 가동했으며, 이제 제 뇌 어딘가에 문신처럼 새겨둔 교훈을 얻었습니다. 사용자 대상 AI의 경우, 편안한 평균이 아니라 최악의 1%를 대비하여 프로비저닝(provision)해야 한다는 것입니다.

그래서 한 고객이 2026년에 여러 리전(multi-region) 환경에서 실행할 수 있는 가장 빠른 AI API를 설계해 달라고 요청했을 때, 저는 이를 다른 운영 시스템과 동일하게 취급했습니다. SLA, p99, 오토스케일링(Auto-scaling), 페일오버(Failover). 제가 발견한 것들을 안내해 드리겠습니다.

실제 운영 환경에서 속도를 측정하는 방법

4만 명의 동시 접속 사용자를 지원하는 채팅 제품의 추론(inference) 규모를 산정할 때, 저는 단 하나의 숫자를 신뢰하지 않습니다. 저는 분포(distributions)를 원합니다. 백분위수(percentiles)를 원합니다. 하루 중 서로 다른 세 가지 시간대에 세 가지 다른 리전에서 동일한 모델을 호출해 보기를 원합니다.

이번 테스트를 위한 설정은 다음과 같습니다:

• 테스트 날짜: 2026년 5월 20일
• 리전(Regions): US East (Ohio), Asia (Singapore)
• 프롬프트(Prompt): "재귀(recursion)에 대해 200단어로 설명해줘"
• 출력(Output): 실행당 약 150 토큰(tokens)
• 실행 횟수: 리전당 모델별 10회 실행, 평균 기록
• 스트리밍(Streaming): 서버 전송 이벤트(Server-sent events), 완전한 엔드 투 엔드(end-to-end)
• 엔드포인트(Endpoint): https://global-apis.com/v1의 글로벌 API

150토큰을 목표로 잡은 이유는 이것이 실제 채팅 트래픽의 약 80%(짧은 답변, 인라인 제안, 도구 설명 등)를 커버하기 때문입니다. 이보다 길어지면 모델의 서빙 처리량(serving throughput)이 아니라 모델의 일관성(coherence) 한계를 벤치마킹하게 됩니다.

나의 "운영 적합(Production OK)" 테스트 기준에 따른 순위별 원시 데이터

저는 단순히 원시 데이터 순서대로 나열하는 것을 선호하지 않습니다. 저는 고객에게 거짓말을 하지 않고 실제로 로드 밸런서(Load Balancer) 뒤에 배치할 수 있는 것을 기준으로 순위를 매깁니다. TTFT(Time To First Token)가 400ms 미만이면 "대화형(interactive)"으로 간주합니다. 400~800ms 사이는 "폴백 전략(fallback strategy)이 필요한" 수준으로 간주합니다. 800ms를 초과하면 채팅용으로는 배포하지 않습니다.

다음은 초당 토큰 수(tokens/second) 기준으로 가장 빠른 것부터 느린 순서로 정리한 전체 목록입니다. 스트리밍(streaming)이 시작되면 초당 토큰 수가 사용자 인식을 실제로 변화시키는 지표가 됩니다.

• Step-3.5-Flash (StepFun) — 120ms TTFT, 80 tok/s, $0.15/M output. 순수 속도의 챔피언.
• DeepSeek V4 Flash (DeepSeek) — 180ms TTFT, 60 tok/s, $0.25/M output. 제가 실제로 배포하는 모델.
• Hunyuan-TurboS (Tencent) — 200ms TTFT, 55 tok/s, $0.28/M output. 저렴하고 빠름.
• Qwen3-8B (Qwen) — 150ms TTFT, 70 tok/s, $0.01/M output. 엄청나게 저렴하고 놀라울 정도로 빠름.
• Qwen3-32B (Qwen) — 250ms TTFT, 45 tok/s, $0.28/M output.
• Doubao-Seed-Lite (ByteDance) — 220ms TTFT, 50 tok/s, $0.40/M output.
• Hunyuan-Turbo (Tencent) — 280ms TTFT, 42 tok/s, $0.57/M output.
• GLM-4-32B (Zhipu) — 300ms TTFT, 38 tok/s, $0.56/M output.
• Qwen3.5-27B (Qwen) — 350ms TTFT, 35 tok/s, $0.19/M output.
• DeepSeek V4 Pro (DeepSeek) — 400ms TTFT, 30 tok/s, $0.78/M output.
• MiniMax M2.5 (MiniMax) — 450ms TTFT, 28 tok/s, $1.15/M output.
• GLM-5 (Zhipu) — 500ms TTFT, 25 tok/s, $1.92/M output.
• Kimi K2.5 (Moonshot) — 600ms TTFT, 20 tok/s, $3.00/M output.
• DeepSeek-R1 (DeepSeek) — 800ms TTFT, 15 tok/s, $2.50/M output. 추론(Reasoning) 모델 — 생각하는 과정 때문에 느림.
• Qwen3.5-397B (Qwen) — 1200ms TTFT, 10 tok/s, $2.34/M output. 세트 중 가장 큼.

제가 보고서에 항상 적어두는 각주가 하나 있습니다: R1, K2.5, K2-Thinking과 같은 사고/추론(reasoning) 모델들은 가시적인 토큰을 하나 내보내기 전에 내부적으로 시간을 소비합니다. 해당 추론 능력이 반드시 필요하고 첫 번째 토큰 생성 비용(cold first-token cost)을 고려하는 것이 아니라면, 이들을 Flash 계열 모델과 일대일로 비교하지 마십시오.

멀티 리전(Multi-Region) 시나리오 (SLA가 성패를 가르는 곳)

이 부분이 더 많은 블로그 포스트에서 다뤄졌으면 좋겠습니다. 어디서 서비스를 제공하느냐는 무엇을 서비스하느냐만큼 중요합니다.

US East와 Asia에서 동일한 모델에 접근하여 네트워크 지연 시간(network delta)을 계산해 보았습니다:

• DeepSeek V4 Flash — US East에서 180ms, Asia에서 150ms. 차이 -30ms.
• Qwen3-32B — US East에서 250ms, Asia에서 210ms. 차이 -40ms.
• GLM-5 — US East에서 500ms, Asia에서 420ms. 차이 -80ms.
• Kimi K2.5 — US East에서 600ms, Asia에서 480ms. 차이 -120ms.

패턴은 일관적입니다: 아시아에서 학습된 모델(Qwen, GLM, Kimi)의 경우 근본적인 추론 클러스터가 물리적으로 더 가깝기 때문에 아시아에서 약 16~20% 낮은 지연 시간을 보였습니다. DeepSeek은 예외입니다. 전 세계적으로 충분히 분산되어 있어 특정 지역을 선택했다고 해서 불이익을 받지 않습니다.

저의 멀티 리전 배포에서는 사용자 위치와 추론 기능을 함께 배치합니다. EU 트래픽은 Frankfurt에서 서비스되는 모델로, APAC 트래픽은 Singapore에서 서비스되는 모델로 처리합니다. 단순히 '단일 엔드포인트, 글로벌 DNS' 방식을 사용하는 것은 제가 고객들에게 계속 경고하는 p99 함정입니다. 엣지 라우팅(Edge routing)이 생각보다 훨씬 중요합니다.

팀에게 제공하는 계층형 자동 스케일링 지도

제가

이곳은 제가 고객 워크로드의 70%를 배치하는 곳입니다. DeepSeek V4 Flash는 저의 주력 모델입니다. GPT-4o급 품질을 유지하면서도 60 tokens/second의 속도와 $0.25/M의 비용을 제공합니다. 덕분에 고객에게 저하된 UX(사용자 경험)에 대해 설명할 필요 없이 요청당 비용(cost-per-request)을 통제할 수 있습니다. Hunyuan-TurboS는 다양성을 위해 교체하며 사용하는 백업 모델입니다.

Tier 3: $0.30-$0.80/M 출력 (속도보다 품질이 중요해지기 시작할 때)

• Doubao-Seed-Lite: 50 tok/s, $0.40/M
• GLM-4-32B: 38 tok/s, $0.56/M
• Hunyuan-Turbo: 42 tok/s, $0.57/M
• DeepSeek V4 Pro: 30 tok/s, $0.78/M

파라미터 수(parameter count)가 증가함에 따라 이곳에서는 처리량(throughput)이 떨어집니다. 30 tok/s의 V4 Pro는 유의미하게 느리지만, 답변 품질이 충분히 뛰어나기 때문에 정확성을 중시하는 B2B SaaS 고객들을 위해 계속 옵션으로 유지합니다.

Tier 4: $0.80+/M 출력 (프리미엄 계층)

• MiniMax M2.5: 28 tok/s, $1.15/M
• GLM-5: 25 tok/s, $1.92/M
• Kimi K2.5: 20 tok/s, $3.00/M

작업이 사용 가능한 최상의 모델을 요구하고 지연 시간(latency)이 부차적인 문제가 될 때 이 모델들을 배포합니다. 저는 GLM-5를 수동 에스컬레이션 토글(manual escalation toggle) 뒤에 배치하며, 절대 핫 패스(hot path)에 두지 않습니다.

약간의 Python (표준이 중요하니까요)

스트리밍 처리량(streaming throughput)과 함께 백분위수 추적(percentile tracking)을 직접 수행하고 싶을 때, Python으로 벤치마크 엔드포인트를 몰아붙이는 방법은 다음과 같습니다. 제가 실행했던 스크립트는 대략 다음과 같습니다:

import time, statistics, requests

ENDPOINT = "https://global-apis.com/v1/chat/completions"
...

동일한 스크립트에서 모델 이름만 바꾸면 위와 같은 표를 얻을 수 있습니다. deepseek-v4-flash를 step-3.5-flash나 hunyuan-turbos로 교체하면 전체 스윕(sweep)을 재현할 수 있습니다.

이것이 실제 채팅 제품에 의미하는 바

저는 TTFT(첫 토큰 시간)를 사용자 인지(user perception)와 매핑하는 암기용 표를 가지고 있습니다. 완벽하지는 않지만, 과도한 약속을 하는 실수를 방지해 주었습니다:

• 200ms 미만 — "즉각적(Instant)." 훌륭한 사용자 경험(UX). 사용자는 이를 의식하지 못합니다.
• 200-400ms — "빠름(Fast)." 수용 가능함. 대부분의 사용자는 눈치채지 못합니다.
• 400-800ms — "지연이 느껴짐(Noticeable delay)." 일부 사용자가 이탈합니다. 저는 이 단계에서는 타이핑 인디케이터(typed indicator)를 함께 사용합니다.
• 800ms 이상 — "느림(Slow)." 사용자가 떠납니다. 대화형 인터페이스(interactive surfaces)에는 이를 배포하지 마세요.

채팅의 경우, 저는 첫 토큰 생성 시간(TTFT, Time To First Token)이 400ms 미만인 모델로 배포를 유지합니다. DeepSeek V4 Flash는 180ms, Qwen3-32B는 250ms, Hunyuan-TurboS는 200ms입니다. 그 외의 모든 작업은 비대화형 워크로드(batch summarization, 비동기 문서 Q&A, 야간 보고서 생성)로 라우팅됩니다.

아무도 슬라이드에 넣지 않는 SLA 및 확장(Scaling) 관련 참고 사항

표에 깔끔하게 들어맞지 않지만 제가 강조하고 싶은 몇 가지 사항이 있습니다:

1. 스트리밍(Streaming)은 TTFT의 고통을 가려줍니다. 첫 토큰을 200ms 안에 가져올 수 있다면, 600ms 후에 응답을 반환하는 비스트리밍(non-streaming) 모델보다 체감 속도가 훨씬 더 좋습니다. 항상 스트리밍을 사용하세요.
2. 콜드 스타트(Cold starts)는 실재합니다. 스케일 투 제로(scale-to-zero) 기능이 있는 오토스케일링(auto-scaling) 뒤에 배치된 모든 모델은 유휴 상태 이후 첫 요청 시 1~3초의 페널티를 받게 됩니다. 예측 가능한 부하의 경우, 최소 복제본(min replicas)을 1 이상으로 설정하여 프리웜(pre-warm)하세요.
3. 추론 모델(Reasoning models)은 숨겨진 시간이 있습니다. TTFT가 800ms인 R1은 느린 것이 아니라 "생각 중(thinking)"인 것입니다. 제품의 UX가 이를 고려한다면(예: Cursor의 "thinking" 패널), 괜찮습니다. 그렇지 않다면 사용자를 잃게 될 것입니다.
4. 공급업체 장애 위험(Provider outage risk). 저는 모든 티어 1(tier-1) 인터페이스에 대해 최소 두 개의 벤더를 운영 환경에 유지합니다. 다각화는 이론적인 것이 아니라 운영적인 문제입니다.

제가 실제로 내일 당장 이를 배포한다면

만약 오늘 고객이 찾아와서 "99.9% SLA 목표를 가진, 프로덕션 준비가 완료된, 멀티 리전(multi-region)의 빠른 AI 채팅 백엔드를 만들어 달라"고 한다면, 저는 다음과 같이 구축할 것입니다:

• 기본(Primary, US East): DeepSeek V4 Flash. 오토스케일링 그룹(Auto-scaling group), 최소 3개 복제본, 큐 깊이(queue depth)에 따른 스케일링.
• 보조(Secondary, US East): Hunyuan-TurboS. 웜 스페어(Warm spare), 기본 서버의 상태 확인(health-check) 실패 시 트래픽 수용.
• APAC 리전: 싱가포르의 Qwen3-32B. 동일한 오토스케일링 규칙 적용, 더 낮은 하한선.
• APAC 페일오버(failover): DeepSeek V4 Flash APAC 변체.
• **비동기 워크로드(Async workloads)