llm-d 1.0 릴리스, Kubernetes 추론을 프로덕션 운영으로 확장
llm-d 1.0 릴리스가 10월 20일 공개되면서, 이 오픈 소스 추론 프로젝트는 경쟁하는 워크로드와 지속적인 유지보수가 필요한 공유 프로덕션 서비스로 한 걸음 더 나아갔다. PyTorch Conference North America에서 발표된 이 릴리스는 학습된 모델을 실행해 답변을 생성하는 과정인 추론을 겨냥한다. 핵심 과제는 운영에 있다. 서로 다른 사용자가 인프라를 공유하고 운영자가 그 아래 시스템을 변경하는 상황에서도 모델의 속도를 유지해야 한다.
IBM, Red Hat, Google Cloud의 기여자들이 주도하는 llm-d는 여러 머신에 걸쳐 컨테이너화된 애플리케이션을 관리하는 플랫폼인 Kubernetes를 기반으로 한다. llm-d의 주된 상대는 느슨하게 조율된 모델 플릿이다. 즉, 컨텍스트, 우선순위, 유지보수에 대한 공통된 이해 없이 요청에 응답하는 개별 서버들이다. 이 차이는 단순한 오픈 소스 대 독점 소프트웨어 구도보다 더 중요하다.
엔터프라이즈 플랫폼 팀에게 이번 발표는 평가의 기준을 바꾼다. 빠른 데모는 유용하지만, 공유 서비스에는 과부하, 업그레이드, 장애 상황에서도 예측 가능한 동작이 필요하다. NVIDIA Dynamo는 또 다른 분산 서빙 선택지를 제공하며, 관리형 서비스는 운영 책임을 다르게 나눈다. llm-d의 주장은 오픈 서빙 스택을 실질적으로 운영 가능하게 만드는 데 기반을 둔다.
llm-d 1.0 릴리스가 실제로 바꾸는 것
이번 릴리스의 중심은 모든 성능 기법을 처음부터 도입하는 것이 아니라, 배포 이후 공유 추론 서비스를 운영하는 데 있다.
IBM의 프로덕션 추론 발표는 워크로드 우선순위, 업데이트 중 연속성, 에이전트 인지형 서빙을 핵심 주제로 제시한다. 이는 서비스 초기 출시 후 유지하기 위해 필요한 업무인 데이 투 운영에 속한다.
이 구분은 발표를 오해하는 일을 막아 준다. 여러 머신에 걸쳐 모델 실행과 서빙을 조율하는 분산 추론은 이번 이정표 이전에도 존재했다. 버전 1.0은 그 기반 위에 운영 관점의 제안을 담았다.
엔터프라이즈 구매자에게 기능 목록과 운영 모델은 서로 다른 질문에 답한다. 기능 목록은 소프트웨어가 무엇을 시도할 수 있는지 설명한다. 운영 모델은 누가 구성을 변경하고, 누가 사고에 대응하며, 수요가 가용 용량을 초과할 때 무엇이 일어나는지를 결정한다.
이번 릴리스를 평가하는 유용한 방법은 일반적인 유지보수 시간을 상상해 보는 것이다. 서비스에는 여전히 활성 사용자가 있다. 어떤 요청은 짧고, 어떤 요청은 더 긴 대화를 포함하며, 백그라운드 작업도 계속 들어온다.
운영자는 이 모든 활동을 일괄 폐기 가능한 것으로 취급하지 않고 소프트웨어를 교체해야 한다. 여기서 중요한 질문은 서빙 시스템이 트래픽과 구성 요소 변경을 충분히 잘 조율해 허용 가능한 서비스를 유지할 수 있는지다.
같은 구분은 공유 인프라에도 적용된다. 모델 서버를 설치하면 애플리케이션이 요청을 보낼 곳이 생긴다. 공유 플랫폼을 구축하려면 애플리케이션들의 총수요가 용량을 초과할 때 그 경쟁을 해결할 규칙이 필요하다.
그 규칙은 제품 경험의 일부가 된다. 백그라운드 처리 중에도 일관되게 응답하는 코딩 어시스턴트는 예측할 수 없이 느려지는 어시스턴트와 다르게 느껴진다. 사용자는 어떤 서빙 프레임워크가 그 아래에 있는지 몰라도 그 차이를 경험한다.
따라서 이번 발표는 인프라 이정표로서 주목할 만하다. 이는 새 모델, 범용 하드웨어 호환성 보장, 또는 모든 엔터프라이즈 워크로드에 대한 포괄적 결과를 발표하는 것은 아니다.
IBM은 여러 모델, 가속기, 클라우드에 걸친 배포를 프로젝트의 방향으로 설명한다. 구매자는 이를 특정 통합을 통해 뒷받침되는 아키텍처적 목표로 읽어야 한다. 실제 배포는 여전히 모델 엔진, 하드웨어 지원, 네트워크, 구성에 따라 달라진다.
실질적인 변화는 이러한 지속적인 책임을 중심으로 구성된 릴리스를 사용할 수 있게 됐다는 점이다. 도입 결정은 버전 번호가 모든 운영상의 질문을 해결한다고 가정하기보다, 검증된 배포 경로를 따라야 한다.
그다음 책임은 플랫폼 팀에 있다. 단순히 예제가 성공적으로 시작되는지 확인하는 데 그치지 말고, 자체 서비스 요구사항 아래에서 구성 요소들이 함께 어떻게 동작하는지 평가해야 한다.
공유 플릿이 플랫폼 팀에 가하는 압박
즉각적인 압박은 동일한 인프라에서 대화형 애플리케이션과 자동화 작업을 함께 제공해야 하는 팀에 가해진다.
IBM의 분산 추론 분석은 길이, 긴급성, 리소스 요구가 서로 다른 요청을 설명한다. 또한 에이전트가 도구를 사용한 뒤 관련 컨텍스트로 돌아오는 상황도 설명한다.
작업을 완료하기 위해 모델과 도구를 반복적으로 호출하는 소프트웨어인 AI 에이전트는 개별 채팅 교환을 넘어선 스케줄링 결정을 도입한다. 다음 요청은 모델 외부에서 수행된 작업에 따라 달라질 수 있다.
플랫폼 소유자에게 이는 애플리케이션 경계와 인프라 경계가 더 이상 깔끔하게 일치하지 않는다는 의미다. 백그라운드 워크플로와 직원용 어시스턴트는 비즈니스 우선순위가 달라도 동일한 리소스를 두고 경쟁할 수 있다.
대화형 코딩 어시스턴트와 자동화된 리포지터리 검토 프로세스를 갖춘 가상의 엔터프라이즈 배포를 생각해 보자. 어시스턴트에는 반응성 있는 대화가 필요하다. 검토 프로세스에는 허용 가능한 시간 안에 작업을 완료할 충분한 용량이 필요하다.
들어오는 모든 요청을 동일하게 처리하는 방식은 중립적으로 들린다. 그러나 실제로는 백그라운드 활동의 급증이 큐를 지배하게 할 수 있다. 별도 인프라를 할당하면 일부 경합은 피할 수 있지만, 사용되지 않는 용량이라는 또 다른 문제가 생긴다.
이것이 공유 플릿 제어가 해결하려는 운영상의 압박이다. 팀은 리소스 풀링의 경제적 이점을 원하지만, 모든 애플리케이션이 다른 모든 애플리케이션의 트래픽에 똑같이 취약해지는 것은 원하지 않는다.
워크로드가 리소스를 받는 방식을 규율하는 정책인 서비스 품질은 이러한 선택을 명시적으로 만든다. 이는 추가 용량을 만들어 내지 않는다. 부족한 리소스를 시스템이 어떻게 배분할지 결정한다.
공정성에 관한 주장을 읽는 구매자에게 이 구분은 중요하다. 공정성은 서비스에 연결된 정의가 필요하다. 동일한 요청 수, 동일한 처리 시간, 긴급 작업에 대한 보호는 서로 다른 정책을 의미한다.
플랫폼 팀은 구현을 평가하기 전에 어떤 결과가 중요한지 결정해야 한다. 그렇지 않으면 겉보기에 성공적인 처리량 결과가 즉각적인 응답이 필요한 사용자의 받아들일 수 없는 경험을 감출 수 있다.
압박은 애플리케이션 개발자에게도 미친다. 공유 서비스가 바빠질 때 거부, 재시도, 대기 동작을 이해해야 한다. 인프라 정책이 애플리케이션 동작의 일부가 된다.
엔터프라이즈 구매자는 관련 조달 문제에 직면한다. 플랫폼 제안은 이를 운영할 책임과 함께 경합 상황에서 예상되는 서비스 동작을 명시해야 한다. 하드웨어 용량만으로는 이 질문에 답할 수 없다.
이 때문에 llm-d는 인프라 전문가를 넘어선 영역에서도 의미가 있다. 제품 소유자는 예측 가능한 응답 시간에 의존하고, 재무 팀은 지출과 유용한 작업 간의 신뢰할 수 있는 관계가 필요하다.
이번 릴리스는 그 관계에 주목하게 한다. 풀링된 용량이 애플리케이션 우선순위를 보존하면서 더 많은 유용한 작업을 처리할 때 비즈니스 사례는 강해진다. 튜닝과 사고 대응이 예상한 이점을 소진하면 약해진다.
이는 먼 산업 전망이 아니라 즉각적인 운영 질문이다. 공유 추론을 평가하는 조직은 의존 애플리케이션을 확장하기 전에 답을 얻어야 한다.
에이전트 인지형 라우팅은 재사용을 스케줄링 결정으로 만든다
이 기술적 메커니즘은 트래픽 배치를 재사용 가능한 모델 컨텍스트와 연결한 뒤, 그 기회를 현재 수요와 균형 있게 조정한다.
프리픽스 캐시는 모델 입력의 시작 부분에 대한 재사용 가능한 연산을 저장한다. 캐시 인지형 라우팅은 관련 요청을 해당 작업을 보유한 서버로 보낸다.
프로젝트의 릴리스 추적은 연속된 에이전트 턴 전반의 스케줄링과 세션 인지형 배치를 연결한다. 또한 승인되는 작업을 조절하는 플로우 제어를 공유 서비스 설계의 일부로 지목한다.
이는 요청을 균등하게 분배하는 것보다 더 구체적인 문제를 만든다. 유용한 캐시 컨텍스트를 보유한 서버는 이점을 제공할 수 있지만, 동시에 바쁠 수도 있다. 라우팅은 재사용의 가치와 대기 비용을 함께 고려해야 한다.
요청 수를 고르게 분배한다고 해서 연산 작업이 반드시 고르게 분배되는 것은 아니다. 프롬프트마다 필요한 처리량이 다르다. 관련 요청도 이전 작업이 어디에 남아 있는지에 따라 비용이 달라질 수 있다.
이로써 주된 상대가 분명해진다. 느슨하게 조율된 플릿은 사용 가능한 목적지를 본다. 컨텍스트 인지형 서빙 시스템은 각 목적지가 이미 무엇을 알고 있는지와 현재 얼마나 많은 작업을 처리하는지를 고려하려 한다.
유용한 단위는 단지 다음에 들어오는 메시지가 아니라 지속되는 워크로드다. 리포지터리를 다시 살피는 에이전트의 경우, 반복된 지시와 소스 자료가 별개의 요청처럼 보이는 것들을 연결할 수 있다.
캐시 재사용에도 한계는 있다. 변경된 입력, 누락된 캐시 상태, 다른 실행 경로는 기회를 줄일 수 있다. 라우팅 인텔리전스는 사용할 수 없거나 호환되지 않는 연산을 재사용할 수 없다.
모델이 텍스트를 처리하고 생성하는 동안 사용되는 저장된 어텐션 상태인 KV 캐시는 또 다른 리소스 결정을 만든다. 오프로딩은 그 상태를 가속기 메모리 밖으로 옮겨 다른 곳에 보존한다.
보존과 즉각적인 접근은 서로 다른 이점이다. 더 많은 상태를 유지하면 재연산을 피할 수 있지만, 이를 가져오는 작업도 필요하다. 적절한 균형은 실제 워크로드와 인프라에 따라 달라진다.
생성 전에 입력을 처리하는 프리필과 출력을 점진적으로 생성하는 디코드도 시스템에 서로 다른 요구를 제시한다. 이 단계를 분리하면 서빙 구성 요소 간에 필요한 조율이 늘어난다.
이 때문에 운영 통합이 중요하다. 로컬 최적화는 매력적으로 보일 수 있지만, 라우팅, 메모리, 스케줄링과의 상호작용은 다른 시스템 수준의 결과를 만들 수 있다.
llm-d의 작동 방식을 묻는 독자에게 중요한 메커니즘은 이러한 관계를 둘러싼 조율된 의사결정이다. 이 프레임워크는 모든 목적지를 상호 교환 가능한 것으로 취급하는 대신, 라우팅이 컨텍스트와 서비스 우선순위를 반영하도록 한다.
이 메커니즘은 단일 성능 수치로 전체 가치를 포착할 수 없는 이유도 설명한다. 어떤 배포는 재사용을 개선하는 대신 혼잡 상황에서 반응성을 약화시킬 수 있다. 다른 배포는 백그라운드 작업을 미뤄 대화형 성능을 유지할 수 있다.
두 결과 모두 의도한 서비스에 비추어 해석해야 한다. 문제는 조율이 플릿을 공유하는 애플리케이션의 유용한 결과를 개선하는지다.
이번 릴리스의 의미는 이러한 결정을 운영 프레임워크 안으로 가져온 데서 비롯된다. 이는 팀이 그렇지 않았다면 애플리케이션 코드와 분리된 인프라 구성 요소에 나눠 두었을 트레이드오프를 관리할 공통된 장소를 제공한다.
클라우드 통합이 서빙 선택지의 중첩 방식을 보여준다
llm-d는 조율 계층을 두고 경쟁하는 한편, 각자의 역할을 이미 갖춘 모델 엔진과 클라우드 서비스와 함께 작동한다.
Google의 분산 추론 스택 발표는 관리형 Kubernetes 플랫폼인 Google Kubernetes Engine과의 통합을 설명한다. Google은 또한 vLLM, SGLang 및 혼합 가속기 인프라 전반에서 1,000개의 에이전트를 활용한 컨퍼런스 시연을 보고했다.
vLLM과 SGLang은 모델을 실행하고 그 출력을 제공하는 소프트웨어인 추론 엔진이다. 이들의 존재는 llm-d를 애플리케이션 하위의 모든 구성 요소를 대체하는 수단으로 평가해서는 안 되는 이유를 보여준다.
Google은 자사 플랫폼이 프로덕션 환경에서 관련 라우팅 기능을 사용한다고 말한다. 이러한 설명은 배포 맥락을 제공하지만, 독립적인 검증이 아닌 공급업체가 보고한 근거라는 점은 변하지 않는다.
경쟁 구도 역시 여러 층위로 이루어져 있다. IBM의 오픈 추론 출시 발표에서 CoreWeave는 고객이 자사의 Kubernetes 서비스에서 NVIDIA Dynamo와 함께 llm-d를 사용할 수 있다고 밝혔다.
이는 단순한 공급업체 간 대결 구도에 대한 유용한 반론이다. 조직은 대체 서빙 경로를 제공하면서도 오픈 프로젝트에 기여할 수 있다. 구매자는 이름이 언급된 모든 참여자가 배타적인 선택지를 의미한다고 가정하기보다 구성과 책임을 비교해야 한다.
NVIDIA Dynamo 역시 또 다른 분산 추론 프레임워크로 비교 대상에 포함된다. 관리형 모델 서비스는 더 많은 인프라 운영을 제공업체에 맡기는 또 하나의 선택지다.
실질적인 차이는 기능 제공 여부를 넘어선다. 자체 관리형 스택은 배포와 튜닝에 대해 고객이 더 직접적인 책임을 지게 한다. 관리형 서비스는 제공업체의 서비스 계약과 지원되는 인터페이스를 통해 그 책임 구조를 바꾼다.
어느 쪽도 자동으로 더 낫지는 않다. 이미 인프라 운영 체계를 갖춘 팀은 배치와 스케줄링에 대한 제어권을 중시할 수 있다. 규모가 작은 애플리케이션 팀은 그러한 책임을 피하는 가치를 더 크게 볼 수 있다.
오픈소스의 사례는 조직이 엔진, 배포 환경 또는 인프라 제공업체 전반에서 선택지를 필요로 할 때 더 설득력을 얻는다. 그 가치는 시스템에 유지보수가 필요할 때에도 이러한 선택지가 실질적으로 유지되는지에 달려 있다.
따라서 이식성은 실제 마이그레이션 시나리오를 통해 평가해야 한다. 구매자는 모델을 옮기거나, 하드웨어를 교체하거나, 다른 엔진을 도입할 때 무엇이 달라지는지 물어야 한다.
일부 변경 사항은 서빙 계층에 속한다. 다른 사항은 모델, 엔진 또는 가속기에 특화되어 남는다. 이러한 모든 종속성을 하나의 이식성 주장으로 취급하면 평가의 정확성이 떨어진다.
엔지니어링 조직에는 이것이 문서화 과제도 만든다. 구성 결정, 지원되는 조합, 장애 대응 과정에서 얻은 결과는 구성 요소가 진화하더라도 계속 접근할 수 있어야 한다.
검색 가능한 지식 베이스는 팀이 로컬 기술 문서 전반에서 이러한 운영 맥락을 보존하는 데 도움이 될 수 있다. 이전 결정을 더 쉽게 찾을 수 있게 하여 배포 프로세스를 보완한다.
궁극적으로 경쟁에 관한 질문은 구체적이다. 어떤 방식이 특정 팀에 허용 가능한 운영 부담으로 필요한 서비스 동작을 제공하는가? llm-d는 그 결정에 개방형 조정이라는 선택지를 추가한다.
프로덕션 준비 상태에는 벤치마크 이상이 필요하다
프로덕션 지향 릴리스는 평가 기준선을 제공하지만, 모든 배포 환경에서 동일한 신뢰성이나 경제성을 보장하지는 않는다.
프로젝트의 v1.0 릴리스 노트는 안정적인 라우터 구성 인터페이스와 조정된 유지보수 기능을 설명한다. 또한 모든 릴리스 추적 목표가 달성된 것은 아니라고 언급한다.
그 단서는 비난으로 바꾸지 않으면서도 주목할 가치가 있다. 릴리스 추적 항목에는 실제 출시 범위를 넘어서는 작업이 포함될 수 있다. 평가자는 자신이 선택한 구성에 실제로 어떤 기능이 포함되는지 확인해야 한다.
프로덕션 준비 상태는 조건이 수반되는 주장으로 이해하는 것이 가장 좋다. 이러한 조건에는 지원되는 소프트웨어 조합, 예상 트래픽, 운영 절차, 그리고 동작이 예상과 달라질 때 대응할 책임자가 포함된다.
가용성 주장에도 비슷한 정밀함이 필요하다. 고가용성은 특정 장애에도 서비스를 계속 제공하도록 구성 요소를 설계한다는 뜻이다. 가능한 모든 장애가 진행 중인 모든 요청에 영향을 주지 않는다는 의미는 아니다.
엔터프라이즈 평가는 계획된 유지보수와 갑작스러운 중단을 구분해야 한다. 통제된 조건에서 구성 요소를 교체하는 일과 예기치 않게 머신을 잃는 일은 복구 요구 사항이 서로 다른 사건이다.
컨텍스트 보존은 또 다른 차원을 더한다. 요청은 정상 서버에 도달할 수 있지만 이전 대화에서 기대했던 재사용 이점을 잃을 수 있다. 애플리케이션은 계속 접근 가능하지만 성능 특성은 달라진다.
이 때문에 고립된 구성 요소 상태보다 서비스 결과가 더 유용하다. 구매자는 전환 중에도 사용자가 의도한 응답 시간 안에 허용 가능한 답변을 받는지 알아야 한다.
경제성 주장에도 같은 수준의 주의가 필요하다. 더 나은 인프라 활용도는 서빙 경제성을 개선할 수 있지만, 구매 결정은 전체 운영 체계를 고려해야 한다.
관련 고려 사항에는 인력, 예약 용량, 미사용 리소스, 네트워킹, 스토리지, 장애 복구가 포함된다. 여러 가정을 동시에 바꾸는 비교는 서빙 프레임워크의 기여도를 분리해낼 수 없다.
워크로드 유사성 역시 중요하다. 반복되는 컨텍스트를 다룬 결과는 구매자의 애플리케이션이 비슷한 재사용을 제공할 때 가장 관련성이 높다. 서로 무관한 입력으로 구성된 워크로드는 다른 질문을 던진다.
이는 긍정적인 시연을 무효화하지 않는다. 다만 그러한 시연이 뒷받침할 수 있는 결론의 범위를 제한한다. 작성자가 워크로드, 기준선, 구성 및 서비스 요구 사항을 공개할수록 근거는 더 유용해진다.
따라서 회의적인 관점은 이념적이라기보다 방법론적이다. 문제는 오픈 인프라가 본질적으로 적합한지 여부가 아니라, 배포 근거가 구매자에게 필요한 특정 주장을 뒷받침하는지 여부다.
팀은 기술적 이식성과 운영 준비 상태의 차이도 유지해야 한다. 성공적으로 실행되는 조합이라도 조직이 이를 지원할 준비를 갖추기 전에는 상당한 작업이 필요할 수 있다.
가장 강력한 도입 사례는 성능 결과를 지속적인 서비스 동작 및 신뢰할 수 있는 운영 모델과 연결할 것이다. 이것이 릴리스의 프로덕션 중심이 시사하는 기준이다.
릴리스 이후 주목할 점
가장 유익한 다음 신호는 업그레이드 중에도 유지되는 서비스, 독립적인 혼합 워크로드 결과, 그리고 지원 환경 전반에서 지속되는 배포다.
첫 번째 신호는 활성 트래픽 환경에서의 업그레이드 근거다. 앞으로 몇 달 동안 배포 환경이 요청이 계속 유입되는 가운데 어떻게 구성 요소를 교체하는지 보여주는 상세한 사례가 나와야 한다.
유용한 근거는 초기 구성, 수행된 변경, 사용자에게 보인 결과를 설명할 것이다. 단순히 롤아웃이 완료되었다고 보고하는 대신 중단, 재시도 및 복구 동작을 포함해야 한다.
일관된 결과는 이 프로젝트가 지속적인 운영 작업을 줄인다는 주장을 강화할 것이다. 특히 문서화되지 않은 전문 지식에 의존하는 반복적인 수동 개입은 그 주장을 약화시킬 것이다.
두 번째 신호는 혼합 워크로드를 활용한 재현 가능한 테스트다. 대화형 요청과 백그라운드 에이전트가 같은 평가에 포함되고, 그 결과는 별도로 보고되어야 한다.
공유 플릿은 가장 긴급한 워크로드를 부실하게 처리하면서도 매력적인 총합 결과를 낼 수 있다. 별도 보고는 이러한 절충 관계를 드러낸다.
독립 테스트는 프로젝트 기여자가 선택한 범위를 넘어서는 배포 가정을 도입하기 때문에 가치를 더한다. 신중한 재현은 어떤 이점이 이전 가능한지, 어떤 이점이 특정 설정에 의존하는지를 명확히 할 수 있다.
응답성을 유지하면서 유용하게 완료된 작업량을 늘리는 결과는 조정이라는 논지를 뒷받침할 것이다. 덜 유리한 트래픽에서 사라지는 개선은 적용 가능 범위를 좁힐 것이다.
세 번째 신호는 지원되는 엔진과 인프라 환경 전반에서의 지속적인 운영이다. 초기 호환성은 유용하지만, 지속적인 유지보수는 배포 경로가 계속 실용적인지를 보여준다.
명확한 지원 경계, 문서화된 마이그레이션, 그리고 팀이 구성 요소 변경을 어떻게 처리하는지 설명하는 보고서를 살펴봐야 한다. 이러한 세부 사항은 통합 로고 목록의 확대보다 더 많은 정보를 제공한다.
조직이 광범위한 맞춤형 수정 없이 서로 다른 구성을 유지할 수 있다는 근거는 이식성 주장을 강화할 것이다. 지속적인 구성 차이는 더 큰 운영 부담을 시사할 것이다.
이러한 신호는 llm-d 1.0 릴리스를 명시된 목적에 맞게 평가하게 해 준다. 이 프로젝트는 조직에 시간이 지나도 유지하고, 공유하고, 변경할 수 있는 인프라로서 오픈 추론을 고려해 달라고 요청한다.
엔터프라이즈 구매자에게 이는 헤드라인 벤치마크만 보고 프레임워크를 선택하는 것보다 더 나은 평가 근거를 제공한다. 개발자에게는 서비스 동작과 애플리케이션 기대치를 같은 논의 안에 놓는다.
공유 워크로드를 확정하기 전에 애플리케이션에 부합하는 배포 근거를 파악해야 한다. 즉 트래픽 패턴, 컨텍스트 재사용, 응답 기대치 및 유지보수 요구 사항이다. 그러한 가정이 바뀔 때 어떤 일이 일어나는지 공급업체나 내부 팀에 설명을 요청하라. 긍정적인 시연은 그 한계와 함께 보존하고, 자체 평가가 실제로 재현한 조건을 기록하라. llm-d 1.0 릴리스는 이러한 비교를 위한 구체적인 출발점을 제공한다. 이를 활용해 조정된 서빙이 사용자가 받는 경험을 개선하는지, 팀이 수행해야 하는 지속적인 작업이 얼마나 되는지, 출시 후에도 어떤 책임이 남는지를 검토하라. 그런 다음 운영상의 이점이 이 스택을 도입할 만큼 타당한지 결정하라.
