{"id":"IL-0413","org":"Microsoft","date":"2025-10-17","docs":[],"title":{"en":"LLM inference engines timed out or ran out of resources under load in about 60% of 156 severe incidents at Microsoft","ko":"Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다"},"domain":["ai-infra","kubernetes"],"impact":{"scope":"94 of 156 high-severity incidents (April to June 2025) of Microsoft's cloud LLM inference service were inference engine failures","users":"Customers of the LLM inference service; ≈96% of all incidents affected a single endpoint","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Hotfixes restore correctness but lengthen time to mitigate, while traffic routing and node rebalancing mitigate faster under overload and timeout patterns. Even with AIOps tooling a meaningful share of incidents still needs manual detection or judgement, so health-probe-driven traffic routing, restarts and capacity increases are the decisions to automate first.","ko":"논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2511.07424","kind":"paper","archived":"https://web.archive.org/web/20261023113022/https://arxiv.org/abs/2511.07424"}],"summary":{"en":"Three Microsoft engineers studied the 156 high-severity incidents (129 at severity 2 and 27 at severity 2.5, on an internal scale where 0 is most critical) of Microsoft's cloud LLM inference service from April to June 2025, using the incident management system, postmortem reports, runtime logs and dashboards, and Designated Responsible Individual (DRI) playbooks and tools. Each incident was labelled by hand with one of four root cause categories, and the labelling agreement reached a Cohen's kappa of 0.89. In the service, an API gateway receives REST or gRPC requests, an endpoint load balancer applies health probes, GPU capacity-aware routing, request batching and token caps, and inference engines on GPU clusters managed by Kubernetes load model weights, run requests and manage the KV cache and sampling parameters.\n\nInference engine failures were the largest category, about 60% of incidents, and were mostly driven by latency and GPU capacity: timeouts on long-running requests and resource exhaustion under load. Capacity increases, traffic routing and node restarts were applied mostly to these failures. For Case A the team enabled dynamic pushback at the load balancer with caps on pending tokens and requests, tuned request batching and GPU/CPU replica counts, improved gRPC backoff and error mapping, and limited sampling parameters with per-client throttling; availability stabilised, HTTP 429s fell and timeout-driven HTTP 5xx decreased under stress. Against timeouts on long-running requests the team used connection liveness strategies such as streaming, request batching and pending token caps, together with GPU capacity-aware routing, which correlated with fewer HTTP 408s and better SLA; for one customer the normalised HTTP 408 rate fell from 2.72% to 0.47% between February and March 2025, before the study window, which the paper reads as a directional association with the connection liveness mitigation. Across all 156 incidents ≈74% were auto-detected and ≈28% needed a hotfix, and hotfix-driven periods lengthened time to mitigate: P75 time to mitigate was ≈32 hours in April and ≈49 hours in May.","ko":"Microsoft Redmond 의 엔지니어 세 명이 자사 클라우드 LLM 추론 서비스의 높은 심각도 장애를 분석한 논문이다. 분류 체계는 한 해 동안 서비스를 운영한 경험에서 만들었고, 정량 분석은 2025년 4월부터 6월까지의 심각도 2 장애 129건과 심각도 2.5 장애 27건, 모두 156건에 집중했다. 심각도는 0 이 가장 심각하고 4 가 가장 가벼우며, 2.5 는 심각도 2 만큼 영향이 컸지만 업무 시간 안에 해결된 장애에 붙이는 내부 등급이다. 데이터는 장애 관리 시스템 ICM, 포스트모템 보고서, 런타임 로그와 대시보드, 장애를 맡는 지정 책임자인 DRI 의 플레이북과 도구에서 손으로 모았다. 장애마다 사람이 원인 범주 네 가지 가운데 하나를 붙였고, 원인이 여럿이면 장애 요약에 가장 먼저 나온 것을 골랐다. 표본을 다시 분류해 처음 분류와 비교한 Cohen's kappa 는 0.89 였다. Cohen's kappa 는 우연히 일치할 확률을 보정한 일치도다.\n\n서비스는 API gateway, 엔드포인트 로드 밸런서, 추론 엔진으로 이루어진다. API gateway 는 REST 나 gRPC 로 요청을 받는다. 엔드포인트 로드 밸런서는 헬스 프로브와 GPU 용량 인지 정책으로 트래픽을 보내고, request batching 과 토큰 상한을 맡는다. 추론 엔진은 모델 가중치를 올리고 요청을 실행하며 KV cache 와 샘플링 파라미터를 관리하고, Kubernetes 가 관리하는 GPU 클러스터에서 돈다. 156건 가운데 94건, 약 60% 가 추론 엔진 장애로 가장 많았고, 그 안에서 타임아웃이 약 40%, 자원 고갈이 약 29% 였다. 엔진 장애는 대부분 오래 걸리는 요청의 타임아웃과 부하 속 자원 고갈처럼 지연과 GPU 용량에서 나왔다.\n\n사례 A 에서는 트래픽이 몰리자 이미지 인코더와 모델 컨테이너가 포화돼 GPU 와 CPU 의 균형이 무너지고 KV cache 압박이 생겼다. 샘플링 파라미터가 유난히 높은 트래픽까지 서빙을 압도해 HTTP 429, 5xx 와 타임아웃이 났다. 팀은 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켜고, request batching 과 GPU·CPU 레플리카 수를 조정하고, gRPC backoff 와 오류 매핑을 고치고, 샘플링 파라미터에 제한을 두며 클라이언트별 throttling 을 걸었다. 그 뒤 가용성이 안정되고 HTTP 429 가 줄었으며, 부하 속 타임아웃으로 인한 HTTP 5xx 도 줄었다. 오래 걸리는 요청에는 스트리밍 같은 connection liveness 방법과 GPU 용량 인지 라우팅을 썼고, 이와 함께 HTTP 408 이 줄고 SLA 가 나아졌다. 영향을 받은 고객 한 곳에서는 전체 요청 대비 HTTP 408 비율이 2025년 2월 2.72% 에서 3월 0.47% 로 내려갔다. 용량 증설, 트래픽 라우팅, 재시작은 주로 추론 엔진 장애에 썼다. 전체 156건의 조치는 모니터링만 한 경우가 75건으로 약 48.08%, 핫픽스가 44건으로 약 28.21%, 용량 증설 15건, 노드 재시작 14건, 트래픽 라우팅 7건, 배포 삭제 1건이었다."},"trigger":{"en":"Bursty load, traffic with unusually high sampling parameters and long-running requests pushed the inference engines into resource exhaustion and timeouts.","ko":"몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다."},"severity":"unknown","symptoms":["intermittent-timeouts","high-error-rate","high-latency"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Across the 156 incidents, 115 (≈74%) were auto-detected, meaning health probes or DRI pipelines alerted before customers reported the problem; the others were not.","ko":"논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다."},"components":["inference-server"],"root_cause":"capacity","remediation":[{"text":{"en":"Enabled dynamic pushback at the load balancer with caps on pending tokens and requests","ko":"로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켰다."}},{"text":{"en":"Tuned request batching and GPU/CPU replica counts","ko":"request batching 과 GPU·CPU 레플리카 수를 조정했다."}},{"text":{"en":"Improved gRPC backoff and error mapping","ko":"gRPC backoff 와 오류 매핑을 고쳤다."}},{"text":{"en":"Limited sampling parameters and throttled per client","ko":"샘플링 파라미터에 제한을 두고 클라이언트별 throttling 을 걸었다."}},{"text":{"en":"Enabled streaming, tuned request batching and capped pending tokens against engine connection timeouts on long-running requests","ko":"오래 걸리는 요청에서 엔진 연결이 타임아웃 나는 문제에는 스트리밍을 켜고, request batching 을 조정하고, 대기 토큰에 상한을 뒀다. 그 결과 HTTP 408 이 줄고 성공률이 높아졌다."}},{"text":{"en":"Increased capacity, routed traffic to healthy endpoints and restarted nodes, the actions applied mostly to inference engine failures","ko":"용량 증설, 트래픽 라우팅, 재시작을 주로 추론 엔진 장애를 완화하는 데 썼다."}}],"action_items":[{"text":{"en":"Optimise serving for long-running requests and high sampling regimes, with connection liveness and GPU capacity-aware routing as the main levers","ko":"오래 걸리는 요청과 높은 샘플링 조건에 맞게 서빙을 최적화해 타임아웃과 자원 고갈을 줄인다."}},{"text":{"en":"Expand health-probe-driven failover and GPU capacity-aware routing so traffic moves off degraded endpoints on its own","ko":"헬스 프로브 기반 failover 와 GPU 용량 인지 라우팅을 넓혀, 상태가 나빠진 엔드포인트에서 트래픽이 스스로 빠져나가게 한다."}},{"text":{"en":"Forecast token and throughput growth and automate capacity increase decisions","ko":"토큰과 처리량 증가를 예측하고 용량 증설 결정을 자동화해, 완화 시간을 늘리는 수동 핫픽스와 수동 증설을 피한다."}},{"text":{"en":"Deploy adaptive alerting and expand engine-level telemetry to close detection gaps","ko":"적응형 알림을 배포하고 엔진 수준 텔레메트리를 늘려, 트래픽이 적은 엔드포인트에서, 그리고 오류가 모호하게 변환되는 곳에서 생기는 감지 빈틈을 메운다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"In Microsoft's cloud LLM inference service, the inference engines themselves failed in 94 of the 156 high-severity incidents from April to June 2025 (≈60%). Requests timed out or ran into resource exhaustion under load, and callers got HTTP 408, 429 and 5xx errors.\n\nWithin the engine failures the paper's breakdown is timeouts ≈40%, resource exhaustion ≈29%, crashes ≈12%, latency spikes ≈6%, input fetch ≈6%, KV cache ≈5%, constraint sampling ≈1% and memory leaks ≈1%. Across all 156 incidents the error code was HTTP 500 in 115 (≈74%), HTTP 408 in 16 (≈10%), HTTP 503 in 14 (≈9%), HTTP 429 and HTTP 424 in 5 each (≈3%) and HTTP 504 in 1 (≈1%). The paper reads the dominance of HTTP 500 as monitoring gaps that let requests be routed to engines that could not serve them.\n\nIn the paper's Case A, bursty load saturated the image encoders and model containers of vision and reasoning models, with GPU/CPU imbalance and KV cache pressure, and traffic with unusually high sampling parameters overwhelmed serving, which gave HTTP 429/5xx and timeouts. In the timeout pattern, long-running requests hit frontend HTTP 408 timeouts even though the backends eventually returned HTTP 200.\n\nOver the study window token generation grew by ≈1.27× from April to June, P75 time to first token (TTFT) rose by ≈60 ms and P75 time to last token (TTLT) by ≈80 ms, which the paper connects to emerging engine saturation, KV cache inefficiencies or architectural bottlenecks under the higher load.","ko":"Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.\n\n추론 엔진 장애 안에서는 타임아웃이 약 40% 로 가장 많았다. 그다음은 자원 고갈 약 29%, 크래시 약 12%, 지연 급증 약 6%, 입력 가져오기 약 6%, KV cache 약 5%, 제약 샘플링 약 1%, 메모리 누수 약 1% 였다. 엔진 장애는 대부분 지연과 GPU 용량에서 나왔고, 오래 걸리는 요청의 타임아웃과 부하 속 자원 고갈이 많았다.\n\n전체 장애 156건의 오류 코드는 서버 쪽 HTTP 5xx 가 주를 이뤘다. HTTP 500 이 115건으로 약 74%, HTTP 408 이 16건으로 약 10%, HTTP 503 이 14건으로 약 9%, HTTP 429 와 HTTP 424 가 각각 5건으로 약 3%, HTTP 504 가 1건으로 약 1% 였다. 논문은 500 오류가 이렇게 많은 것을 엔진이 요청을 처리할 수 없는데도 요청이 그 엔진으로 라우팅되게 둔 모니터링 빈틈이 있다는 뜻으로 봤다. 장애의 약 96% 는 엔드포인트 하나에만 영향을 줬다.\n\n사례 A 에서는 트래픽이 몰리자 이미지 인코더와 모델 컨테이너가 포화됐다. GPU 와 CPU 의 균형이 무너지고 KV cache 압박이 생겼으며, 샘플링 파라미터가 유난히 높은 트래픽이 서빙을 압도했다. 그 결과 HTTP 429, 5xx 와 타임아웃이 났다.\n\n사례 B 에서는 오래 걸리는 요청이 프런트엔드에서 HTTP 408 타임아웃을 냈다. 백엔드는 결국 HTTP 200 으로 응답했지만, 프런트엔드는 그 전에 이미 타임아웃을 냈다.\n\n부하가 늘면서 서빙 지표도 나빠졌다. 2025년 4월부터 6월까지 토큰 생성량이 약 1.27배 늘었고, 같은 기간 P75 TTFT 는 약 60 ms, P75 TTLT 는 약 80 ms 늘었다. 논문은 이 변화가 엔진 포화가 시작되거나 KV cache 가 비효율적이거나 아키텍처 병목이 생긴 것과 들어맞는다고 봤다."},"updated_at":"2026-11-14T12:34:06.389394Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0413","org_slug":"microsoft"}