LLM 서빙에서 CPU와 GPU를 분리해야 하는 이유
SMG는 Python GIL 병목을 없애기 위해 서빙 CPU 작업을 Rust 게이트웨이로 분리했다.
Shepherd Model Gateway(SMG)는 LLM 서빙에서 CPU와 GPU를 분리해야 한다는 주장을 실제 제품으로 증명한다. SGLang과 vLLM에서 토크나이징·디토크나이징이 Python GIL에 막혀 병목이 되자, SMG는 이를 전부 Rust 게이트웨이로 옮겼다.
핵심 구조는 Clients → Gateway → Router → Workers다. 게이트웨이는 토크나이징, reasoning과 tool call 파싱, 멀티모달 전처리, MCP 도구 오케스트레이션, 채팅 히스토리 관리, structured output 검증, stop sequence 감지까지 담당하고, GPU 엔진은 전처리된 토큰과 텐서만 받는다.
기술적으로는 native Rust gRPC data plane이 중심이다. 토크나이저는 Rust에서 두 단계 캐시(L0 exact-match, L1 prefix-aware)로 동작하고, reasoning 파싱은 스트리밍 중 실시간으로 이뤄진다. 멀티모달 전처리는 Hugging Face 이미지 프로세서를 Python에서 Rust로 다시 구현해 Llama 4 Vision, Qwen VL 등 주요 vision-language 모델을 지원하며, MCP와 WASM middleware도 게이트웨이에서 독립적으로 처리한다.
SMG는 오늘날에도 폭넓은 기능을 제공한다.
- 5개 네이티브 Agentic API 지원: Chat Completions, Responses API, Messages API, Interactions API, Realtime API
- SGLang, vLLM, TensorRT-LLM, MLX 및 외부 모델 공급자 연동
- 캐시 인지 라우팅 재구성으로 10~12배 빠른 삽입 속도와 99% 메모리 절감
- 8개 H100 모델, 2개 런타임, 5개 트래픽 시나리오, 9개 동시성에서 1,082개 비교 포인트로 검증
벤치마크에서는 동시성 256에서 gRPC가 HTTP 대비 약 8% 더 높은 처리량을 보였고, prefill-decode 분리 환경에서는 TTFT 평균 23% 감소, p99 28% 감소가 확인됐다. 결론은 분명하다. GPU를 최대한 바쁘게 만들려면, GPU 옆에 붙어 있던 CPU 작업을 과감히 떼어내 별도 서빙 계층으로 운영해야 한다는 것이다.
이 요약은 원문 이해를 돕기 위한 큐레이션입니다. 저작권은 원저작자에게 있으며, 정확한 내용과 맥락은 원문을 확인하세요.
요약 오류, 출처 표기 문제, 삭제 요청은 문의 · 건의로 알려주세요.