TGI 유지보수 모드 소식, LocalLLaMA는 vLLM이 기본값이 되는 순간으로 읽었다

r/LocalLLaMA에서 이 글이 잡아낸 감정은 nostalgia가 아니라 정리 모드에 가까웠다. 글쓴이는 회사에서 AWS Sagemaker AI 위에 Hugging Face TGI를 기본 engine으로 쓰고 있지만, 집에서 돌리는 llama.cpp와 vLLM 경험이 더 낫다고 적었다. 그리고 Hugging Face TGI 쪽이 더 이상 활발한 신기능 개발 단계는 아니라는 신호를 보고, 이제는 갈아탈 시점이냐고 묻는다. 이 질문이 먹힌 이유는 community가 이미 비슷한 판단을 하고 있었기 때문이다. inference serving은 ideology보다 운영 편의와 migration cost가 더 크게 느껴지는 단계로 넘어갔다.

댓글에서 가장 많이 반복된 답은 vLLM 쪽이었다. continuous batching 처리 차이가 실제 throughput으로 체감됐고, OpenAI-compatible endpoint 덕분에 client code를 거의 다시 쓰지 않아도 migration이 가능했다는 경험담이 이어졌다. TGI가 speculative decoding 같은 영역에서 여전히 장점이 있었다는 의견도 있었지만, general inference serving의 default로는 vLLM이 더 obvious choice라는 말이 여럿 나왔다. sglang을 대안으로 언급하는 사람도 있었지만, 전체적인 흐름은 이미 한쪽으로 기울어 있었다.

흥미로운 건 Reddit 답변이 단순한 benchmark 자랑으로 흐르지 않았다는 점이다. 오히려 production 쪽에서 무엇이 migration friction을 줄이는지, risk department가 승인하는 데 얼마나 오래 걸리는지, legacy deployment를 언제까지 안고 가야 하는지 같은 현실적인 얘기가 많았다. 한 댓글은 이미 8개월째 AWS에서 vLLM을 돌리고 있고, TGI가 stale하게 느껴지기 시작한 뒤로 throughput 차이가 분명했다고 적었다. 반대로 글쓴이는 Llama 4는 옮겼지만, 예전 deployment는 승인 절차 때문에 쉽게 못 바꾼다고 답했다. LocalLLaMA답게 기술 논의가 바로 조직 운영 이야기로 붙는다.

이 스레드가 의미 있는 이유는 engine 교체가 이제 model hobby가 아니라 infrastructure 판단으로 읽히기 때문이다. 2024년쯤에는 TGI vs vLLM이 취향 논쟁처럼 보였다면, 지금은 API 호환성, batching 성능, deployment inertia, review cycle 같은 요소가 우선순위를 정한다. community energy도 거기에 맞춰 움직인다. 최신 모델이 무엇이냐보다, 어떤 serving stack이 가장 덜 아프게 production에 붙느냐가 더 중요한 질문이 된 것이다.

Sources: Reddit thread, Hugging Face TGI docs.