AI 서버를 늘려도 대화가 느려진다면…llm-d 1.0의 요청 배분

AI 서버를 더 붙였는데도 사용자가 몰리는 시간에는 답변이 늦어질 수 있습니다. 처리 능력만큼 중요한 것은 어떤 요청을 먼저 받고, 어디로 보내며, 업데이트 중인 서버에서 어떻게 빼내느냐입니다. 2026년 10월 20일 공개된 llm-d 1.0은 이 운영 문제를 다룹니다. 요청 우선순위와 공정성을 반영하는 흐름 제어, 대화 맥락을 고려한 배분, 서버 교체 과정의 조정이 주요 변화입니다. 다만 1.0이라는 버전이 모든 구성의 안정성이나 무중단 운영을 보증하지는 않습니다. 공식 릴리스

여러 팀이 같은 AI 서버를 쓸 때 생기는 문제

가령 고객 상담 도중의 짧은 질문과 사내 문서 수백 건을 처리하는 요청이 같은 서버에 들어온다고 생각해 보겠습니다. 둘 다 필요한 업무지만, 기다려도 되는 시간은 다릅니다. 그래서 요청 수만 고르게 나누는 것과 사용자가 체감하는 대기 시간을 관리하는 것은 다른 문제입니다. llm-d는 Kubernetes에서 모델 추론을 운영하는 오픈소스 구성 요소입니다. 직접 모델 서버를 운영하는 팀이 주요 독자이며, 외부 AI API만 호출하는 서비스에 이번 설정이 그대로 적용되는 것은 아닙니다. 프로젝트 소개

공식 운영 문서는 우선순위, 팀별 공정성, 서버 포화 상태를 기준으로 요청을 다루도록 안내합니다. 여기서 눈여겨볼 것은 모든 작업을 똑같이 빠르게 끝내겠다는 약속이 아닙니다. 업무 성격에 맞춰 대기 순서를 정할 수 있다는 점입니다. 상담 응답과 야간 문서 처리를 함께 운영한다면 먼저 보호할 업무를 정해야 합니다. 과부하 때 일부 요청을 제한하는 설정도 있으므로, 응답이 빨라졌는지만 보면 안 됩니다. 거절된 요청이 늘었는지, 특정 팀의 대기만 길어졌는지까지 함께 봐야 합니다. 운영 가이드

대화를 기억하는 것과 계산을 재사용하는 것은 다릅니다

여러 차례 이어지는 대화에서는 앞부분의 계산을 재사용할 여지가 있습니다. 정밀 캐시 라우팅 가이드는 각 모델 서버에 남아 있는 KV 캐시 정보를 보고 요청을 배분합니다. 대화가 이어질 때 이미 처리한 맥락을 활용할 수 있는 서버를 찾는 방식입니다. 다만 해당 가이드는 현재 라우터 한 개를 기준으로 하며, 여러 라우터가 동시에 처리하는 고가용성 구성에는 추가 조건과 실험 단계 옵션이 있습니다. 정밀 캐시 라우팅 가이드

이것을 대화 기록 저장과 혼동하면 설계가 어긋납니다. 별도의 Responses API 가이드에서는 previous_response_id로 이전 대화를 이어갈 수 있지만, 상태를 저장하는 주체는 라우터 자체가 아닙니다. 앞단의 vllm/agentic-api가 PostgreSQL에 응답을 저장하고 이전 대화를 복원합니다. 이 가이드는 실험 단계로 표시돼 있으며 vLLM 기반 참조 구성을 제시합니다. 에이전트 서비스를 검토하는 팀이라면 캐시 재사용 시험과 대화 기록의 저장·복구 시험을 분리해야 합니다. Responses API 가이드

서버 교체도 순서가 맞아야 합니다

긴 입력을 처리하는 단계와 답변을 생성하는 단계를 서로 다른 서버에 나누면, 업데이트 역시 두 서버의 관계를 함께 고려해야 합니다. 공식 안전 배포 가이드는 같은 버전의 서버끼리 요청을 처리하도록 묶고, 진행 중인 작업을 마칠 시간을 확보하는 방법을 설명합니다. 다만 여기에 쓰이는 배포 선별 플러그인은 Alpha 단계입니다. 필요한 역할의 서버가 모두 준비된 버전이 없으면 503 오류를 반환하도록 설계돼 있습니다. 안전 배포 가이드

‘업데이트 중에도 끊기지 않는다’고 읽기보다는, 끊김을 줄이기 위해 준비해야 할 조건이 문서화됐다고 이해하는 편이 정확합니다. 여유 서버가 있는지, 오래 실행되는 요청을 얼마나 기다릴지, 실패하면 이전 구성으로 어떻게 돌아갈지가 남습니다. 입력 처리와 생성 단계를 분리하는 배포 가이드는 LeaderWorkerSet v0.11.1 이상과 DisaggregatedSet API 활성화도 요구합니다. 이미 운영 중인 환경이라면 새 기능부터 켜기보다 이 의존성을 먼저 확인해야 합니다. 분리 배포의 사전 조건

도입 판단은 ‘응답 성공’ 다음부터 시작됩니다

작게 시험한다면 동일한 모델과 하드웨어에서 짧은 대화, 긴 문서 입력, 연속 대화를 나눠 비교하는 방법이 적절합니다. 각 유형의 첫 응답 대기 시간과 전체 처리 시간, 오류·거절 비율을 기록하고 동시에 들어오는 요청을 늘려 보세요. 이어 업데이트 상황에서도 진행 중인 대화가 유지되는지 확인해야 합니다. 이는 필자의 시험 제안이며, 이번에 직접 측정한 결과는 아닙니다.

HTTP 200 응답만으로 캐시 최적화가 작동했다고 판단해서는 안 됩니다. 정밀 캐시 가이드는 프롬프트 변환이 실패해 캐시 정보를 쓰지 못해도 요청이 성공할 수 있다고 설명합니다. 해당 처리의 성공·실패 지표와 실제 대기 시간을 함께 확인해야 합니다. 정밀 캐시 검증 방법

당장 영향을 받는 팀과 아직 지켜볼 팀

이번 발표의 직접적인 의미는 자체 모델 서버를 운영하면서 여러 업무의 요청이 겹치는 팀에 있습니다. 라우터 설정 API가 v1으로 올라간 점은 구성을 관리할 때 확인할 변화지만, 실험 단계인 세부 경로까지 안정화됐다는 뜻은 아닙니다. 릴리스의 변경 범위

그렇다면 서버를 늘리는 대신 요청 배분만 바꾸면 될까요? 저는 둘 중 하나를 고르는 문제로 보지 않습니다. 먼저 어디서 대기가 길어지는지 찾고, 배분을 바꾼 뒤에도 처리 능력이 부족한지 살펴보자는 제안입니다. 반복 대화가 많고 요청 간 우선순위가 뚜렷한 환경이라면 검토할 이유가 있습니다. 운영 인력과 검증 환경이 부족하다면 이번 버전만 보고 자체 추론 환경으로 옮길 근거는 부족합니다. 성능 개선 여부와 배포 관리 부담을 함께 따져야 합니다. 해당 상태 저장형 Responses 경로를 선택한다면 추가되는 데이터베이스 운영 부담까지 포함해 결정해야 합니다.

하드웨어를 바꾸는 문제는 AWS TorchNeuron 공개 베타를 다룬 글에서 이어서 보실 수 있습니다. 해당 글은 기존 코드와 새 칩의 호환성을 묻고, 이번에는 같은 추론 환경에 여러 업무가 몰렸을 때 무엇을 먼저 처리할지를 묻습니다. 두 선택 모두 실제 작업의 정확도와 대기 시간을 기준으로 비교해야 합니다.

자료 확인은 2026년 10월 20일입니다. 공식 릴리스와 공개 문서를 바탕으로 작성했으며, 직접 설치하거나 성능 시험을 한 후기는 아닙니다. 대표 이미지는 승인 VECTO를 활용한 AI 제작 개념 장면이며, 실제 제품 화면이나 장비 사진이 아닙니다.

수정: 2026년 10월 21일. 한국어 문장 윤문 후 중복 표현과 문단 연결을 다듬고 자기지칭을 ‘저는·필자’로 바꿨습니다. 사실관계·출처·적용 조건은 유지했습니다.