llm-d 1.0은 2026년 10월 20일 북미 PyTorch Conference에서 공식 공개됐고, IBM Research가 공식 블로그를 통해 발표했다. Kubernetes 네이티브 분산 추론 프로젝트인 llm-d는 Red Hat, IBM, Google이 주도적으로 유지보수하며, 세 회사는 2025년 CoreWeave, NVIDIA와 함께 프로젝트를 공동 설립했다. AMD, Cisco, Hugging Face, Intel, Lambda, Mistral AI 등도 이후 기여자로 합류했다. 1.0의 핵심은 벤치마크 숫자가 아니라, 추론을 돌릴 수 있는 단계에서 장기 운영이 가능한 단계로 넘어갔다는 점이다.
보완된 것은 단일 성능이 아니라 운영 역량
llm-d로 알려진 다섯 가지 기술, 즉 접두사 캐시 인식 라우팅, KV 캐시 오프로딩, 배치 추론 최적화, 프리필과 디코드의 분리, 와이드 전문가 병렬은 1.0에서도 그대로다. 달라진 것은 그 위의 운영 계층으로, 안정적인 API, 멀티테넌트 서비스 품질 관리, 무중단 업그레이드, 우선순위가 다른 워크로드가 같은 인프라를 공유해도 서로 발목을 잡지 않게 하는 흐름 제어가 더해졌다. 공동 창립자이자 IBM Research 수석 엔지니어인 Carlos Costa는 1.0이 llm-d를 다른 핵심 서비스처럼 운영할 수 있게 만드는 데 목적이 있다고 설명했다.
같은 진입점이라도 사람과 에이전트의 요청은 구분해서 처리
기업용 추론 서비스의 트래픽 형태가 바뀌고 있다. 하나의 엔드포인트 뒤에는 코딩 도우미의 즉각적인 답변을 기다리는 사용자와, 요청을 한꺼번에 보내고 도구 사용을 위해 멈췄다가 다시 돌아오는 에이전트가 함께 있다. 1.0의 흐름 제어와 공정 스케줄링은 수요가 몰릴 때 누가 자원을 먼저 받을지를 명확히 정하고, 다중 턴 요청을 같은 복제본에 고정해 접두사 캐시를 따뜻하게 유지한다. IBM의 테스트에서 접두사 인식 라우터는 에이전트 코딩 워크로드에서 재사용 가능한 캐시의 97%를 활용했고, 또 다른 자체 호스팅 시연에서는 소프트웨어 엔지니어링 에이전트 3,000개를 동시에 실행하는 비용이 동등한 호스팅 서비스의 5분의 1에서 10분의 1 수준이었다.
직접 추론을 운영하는 팀을 위한 중립적 선택지
llm-d는 vLLM이나 SGLang 같은 추론 엔진을 대체하지 않는다. 그 위에 분산 라우팅과 운영 기능을 더하는 역할을 하며, 프로젝트는 CNCF 샌드박스로 호스팅되고 있다. 자체 Kubernetes 클러스터에서 모델을 서빙하는 팀에게 1.0은 오픈 웨이트 모델을 프로덕션 서비스로 만드는 공학적 문턱을 낮추고, 연산 자원이 어디에 쓰이는지와 캐시 적중 수준을 관리할 수 있게 한다. 한계도 분명하다. Kubernetes 운영 역량은 여전히 전제이며, 클라우드 사업자의 관리형 추론으로 충분한 소규모 팀이 직접 운영으로 비용을 회수할 수 있다고 장담할 수는 없다.
