Your Self-Hosted LLM Needs to Say No - Harshul Jain & Parv Khatri, Audible & SAP

한 줄 핵심

자체 호스팅 LLM에서 코딩 에이전트 트래픽을 안정적으로 받으려면, GPU에 요청을 넣기 전에 ingress에서 admission control로 먼저 거르고 그 정책을 실제 트래픽과 지표로 검증해야 한다.

시간별 요약

1. 0:05
   문제 정의와 발표 개요 자체 호스팅 LLM이 코딩 에이전트의 폭주 트래픽을 받는 환경에서, 요청을 언제 받아들일지 결정하는 admission control이 왜 필요한지와 전체 발표 흐름을 먼저 정리한다. inference 파이프라인, GPU 메모리, KV cache의 기본 개념을 바탕으로 이후 논의를 위한 공통 전제를 만든다.
2. 9:01
   왜 ingress에서 먼저 거부해야 하는가 admission은 GPU 메모리를 쓰기 전에 요청을 시작할지, 대기시킬지, 거부할지 결정하는 앞단의 분기점이다. 요청 하나가 prefill과 decode를 거치며 장시간 메모리를 점유하므로, 늦게 거절할수록 SLO 위반과 메모리 낭비가 함께 커진다.
3. 16:00
   의사결정에 필요한 신호와 응답 방식 좋은 admission 판단에는 요청 측 신호와 엔진 측 신호가 동시에 필요하며, 입력 길이·tenant·세션·deadline과 KV cache·queue age·replica load 같은 상태를 함께 봐야 한다. 응답은 admit, defer, reject 세 가지로 나뉘고, 200·503 Retry-After·429/529에 맞춰 클라이언트나 에이전트가 재시도·중단·부하 조절을 해야 한다.
4. 28:01
   정책 설계의 축과 연구 결과의 한계 단순한 요청 수 제한은 GPU 실제 부담을 반영하지 못하므로, 무엇을 단위로 admit할지, 어떤 신호를 볼지, 어떤 규칙으로 판단할지, 어떤 행동을 취할지를 분리해서 설계해야 한다. 기존 연구들은 threshold, dual gate, optimizer, formal bound 같은 방법을 제시하지만, 코딩 에이전트의 세션 단위·온라인 트래픽에는 딱 맞는 해법이 없어서 실제 환경에 맞는 정책을 새로 만들어야 한다.
5. 39:00
   벤치마킹과 검증 방법 정책의 성능은 실제 엔진, 실제 GPU, 실제 트래픽 trace를 기준으로 goodput under admission으로 평가해야 하며, 거절된 요청까지 분모에 포함해야 한다. admit perf 같은 도구로 정책과 엔진을 동일 조건에서 반복 실행하고, 신호 누락을 실패로 처리하며, 결정 당시의 상태와 결과를 남겨야 정책이 실제로 클러스터를 안정화하는지 검증할 수 있다.

실무 인사이트

• 코딩 에이전트처럼 짧은 시간에 다량의 호출을 만드는 워크로드는 요청 수보다 세션 단위와 deadline을 기준으로 제어해야 실제 병목을 줄일 수 있다.
• 정책이 볼 수 없는 신호에 의존하면 조용히 잘못된 결정을 내리므로, 신호 누락은 기본값으로 우회하지 말고 시작 시점에 실패시키는 방식이 안전하다.
• SLO가 핵심인 운영 환경에서는 admitted request만 보는 지표보다, 거절된 요청까지 포함한 goodput을 기준으로 admission 정책을 비교해야 한다.