PyTorch 콘퍼런스에서 프로덕션 추론 스택을 갖춘 llm-d 1.0 공개

llm-d 프로젝트 기여자들은 2026년 10월 20일 PyTorch Conference North America에서 Kubernetes 네이티브 분산 추론 서빙 스택인 llm-d 1.0을 발표했다고 IBM Research의 발표에서 밝혔다. IBM은 이번 릴리스로 llm-d가 개별 성능 기법을 시연하는 단계를 넘어섰으며, 추론 비용이 증가하는 가운데 조직들이 모델 배포를 사내에서 운영할 수 있도록 지원하는 것을 목표로 한다고 설명했다.

llm-d는 모든 모델을 모든 가속기에서, 어떤 클라우드에서든 배포할 수 있는 추론 스택을 구축하도록 설계됐다. Red Hat, IBM, Google은 이 프로젝트의 주요 유지관리자이며 CoreWeave, NVIDIA와 함께 llm-d를 공동 설립했다. AMD, Cisco, Hugging Face, Intel, Lambda, Mistral AI도 기여자로 참여했다. Cloud Native Computing Foundation(CNCF)은 llm-d를 샌드박스 프로젝트로 호스팅한다. IBM은 그 결과물을 단일 독점 모델 공급자나 클라우드, 하드웨어 플랫폼에 전적으로 의존하지 않으면서 자사가 말하는 최첨단급 추론 성능을 원하는 조직을 위한 공급업체 중립적 대안이라고 설명한다.

IBM Research의 Distinguished Engineer이자 llm-d 공동 설립자 겸 주요 유지관리자인 Carlos Costa는 버전 1.0을 통해 llm-d를 다른 핵심 서비스처럼 운영하는 데 필요한 성숙도가 갖춰졌다고 말했다. 그는 안정적인 API, 서로 우선순위가 다른 여러 테넌트가 동일한 인프라를 공유하는 기능, 운영 중단 없는 업그레이드를 그 근거로 들었다.

버전 1.0의 추가 기능

2026년 10월 20일 GitHub에 게시된 프로젝트의 v1.0.0 릴리스 노트는 서명 및 검증된 태그와 함께 멀티테넌트 서비스 품질을 주요 내용으로 제시한다. 여기에는 제어된 부하 차단 기능을 갖춘 우선순위 및 공정성 인식 흐름 제어가 포함되며, 확률적 요청 승인기, 프로그램 인식 공정성, 턴 우선순위 점수 산정도 제공한다. 이를 통해 지연 시간에 민감한 요청과 변동이 큰 에이전트 워크로드가 과부하 상황에서도 서로의 자원을 고갈시키지 않으면서 하나의 서버 풀을 공유할 수 있다. 흐름 제어 설정은 단일 flowControl 필드로 통합됐다.

다운타임 없는 운영을 위해 라우터에는 핫 스탠바이와 안전한 순차 업데이트를 지원하는 고가용성이 추가됐다. DisaggregatedSet 컨트롤러는 프리필 복제본과 디코드 복제본을 하나의 논리적 단위로 관리하며, 조율된 롤아웃, 동기화된 업그레이드, Pod 스냅샷을 기준으로 한 준비 상태 확인, 네이티브 리비전 라우팅을 제공한다. 라우터 구성 API는 v1로 정식 승격됐고, Responses API는 previous_response_id를 지원한다. 엔드포인트 선택기 요청 경로도 안정성, 성능, 확장성을 높이도록 강화됐다. DRA 및 DRANET용 토폴로지 인식 가속기 가이드도 포함됐다.

에이전트 인식 서빙에는 세션 상태 생성자 플러그인과 점진적으로 조정되는 세션 어피니티가 추가돼, 여러 차례에 걸친 대화가 캐시된 컨텍스트에 가깝게 유지된다. 턴 우선순위 스케줄링과 Responses API 상태도 제공해 에이전트가 대화의 각 턴에서 컨텍스트를 재사용하도록 돕는다. 이번 릴리스에서는 프로젝트 구성 요소를 v1.0.0으로 통일하고, 모델 가중치의 피어 투 피어 로딩을 위한 ai-dynamo/modelexpress 통합, llm-d-api-extensions 패키지, llm-d-pd-utils 진단 도구 등 생태계 구성 요소를 추가했다. 또한 프로젝트 자체의 llm-d-rocm 컨테이너 이미지 빌드는 더 이상 사용하지 않도록 했다. 모델 서버 이미지에는 다양한 가속기 대상용 vLLM 및 SGLang 빌드가 포함되며, 프리필/디코드 분리 가이드에서는 이제 DisaggregatedSet API를 활성화한 LeaderWorkerSet v0.11.1 이상을 요구한다.

핵심 기법과 흐름 제어

프로젝트는 출시 이후 추론 성능을 높이는 다섯 가지 접근법에 주력해 왔다. 공유 컨텍스트가 이미 있을 수 있는 인프라로 요청을 보내는 접두사 캐시 인식 라우팅, GPU·CPU·스토리지 리소스 간에 캐시된 정보를 옮기는 KV 캐시 오프로드, 배치 추론 최적화, 프롬프트를 읽는 작업과 응답을 생성하는 작업을 분리하는 프리필/디코드 분리, 대규모 전문가 혼합 모델을 여러 가속기에 분산하는 광범위한 전문가 병렬화가 이에 해당한다. 이러한 기법은 버전 1.0 이전부터 존재했다. IBM에 따르면 새롭게 추가된 것은 이 기법들을 둘러싼 통합과 운영 성숙도, 즉 트래픽이 변하거나 하드웨어에 장애가 발생하거나 소프트웨어가 업데이트되거나 서로 다른 사용자가 동일한 리소스를 두고 경쟁할 때도 성능을 유지하는 2일 차 운영 원칙이다.

버전 1.0의 흐름 제어, 공정성, 우선순위 지정은 워크로드가 동일한 하드웨어를 공유하든 여러 종류의 가속기에 걸쳐 있든, 변동이 큰 워크로드가 지연 시간에 민감한 서비스를 압도하지 않도록 하는 데 목적이 있다. 또한 접두사 캐시를 따뜻하게 유지하도록 여러 턴에 걸쳐 요청을 적절한 인프라에 계속 고정할 수 있다. llm-d는 vLLM이나 SGLang 같은 추론 엔진과 함께 작동하며, 그 위에 분산 라우팅과 운영 기능을 더한다. Red Hat 최고기술책임자실 부사장 Stephen Watt는 llm-d가 Kubernetes 네이티브 오케스트레이션을 vLLM 및 최신 추론 엔진에 직접 제공해 PyTorch와 CNCF 생태계를 통합한다고 말했다.

시연된 결과와 공개된 비용

2026년 7월 22일에 발표된 벤치마크 게시물에서 이 프로젝트는 GLM-5.2의 에이전트형 서빙을 측정했다. 해당 게시물은 GLM-5.2를 활성 매개변수 390억 개, 78개 레이어로 구성된 7,440억 개 매개변수 규모의 전문가 혼합 모델이라고 설명했다. 워크로드 분석은 실제 운영 환경의 Claude Code 세션 219개를 바탕으로 했으며, 여기서 주 에이전트 요청의 입력 토큰 수 중앙값은 19만 5,000개, 출력 토큰 수는 317개였고, 주 에이전트 턴의 96%에서 입력 토큰의 90% 이상이 재사용됐다. 게시물에 따르면 접두사 인식 라우팅은 워크로드에서 가능한 캐시 재사용의 96~97%를 포착했다. H200의 대여 비용을 GPU 시간당 2.71달러로 가정했을 때, 게시물은 64개 GPU 구성 두 가지를 사용한 자체 호스팅 서빙 비용을 입력 토큰 100만 개당 0.05~0.08달러, 출력 토큰 100만 개당 1.92~3.55달러로 산정했다. 저자들은 이 수치에 GPU 대여 비용만 포함되며 지속적인 부하를 가정한다고 밝혔다.

별도의 시연에서 IBM과 Red Hat은 NVIDIA H100 GPU 544개에서 GLM-5.2를 배포했다. IBM Research의 설명은 이 모델을 활성 매개변수가 약 390억 개인, 전체 매개변수 약 7,530억 개 규모의 오픈 웨이트 모델로 설명했다. IBM에 따르면 이 배포는 최대 부하 시 선점이 한 번도 발생하지 않는 상태로 코딩 에이전트 최대 3,000개를 동시에 처리하면서 분당 출력 토큰 660만 개 이상을 제공했으며, 에이전트 2,500개를 처리하는 운영 지점에서는 분당 요청 7,612건을 꾸준히 처리했다. IBM은 현재 클라우드 대여 요금을 기준으로 H100 GPU에서 llm-d를 사용해 GLM-5.2를 자체 호스팅하면 동등한 상용 API 요금보다 토큰당 비용이 5~10배 낮다고 밝혔다. Red Hat 추론 엔지니어링 팀의 수석 수석 머신러닝 엔지니어인 Maroon Ayoub은 “수천 개의 에이전트를 동시에 선점 없이 처리할 수 있으면 운영자는 벤치마크 결과를 실제 운영 환경의 배포로 이어갈 수 있는 믿을 만한 경로를 확보하게 됩니다”라고 말했다.

같은 설명에 따르면, 이러한 결과를 뒷받침하는 분리형 데이터 플레인은 전송당 평균 2.71GiB에 달하는 KV 캐시 전송 620만 건을 전송 실패 없이 완료했으며, 모든 벤치마크에서 서빙 오류가 한 건도 발생하지 않았다.