AI 추론을 직접 운영하려는 플랫폼 팀, GPU 메모리 계산이 관건이다
An Open Field Guide to Inference Engineering
AI를 적극 도입한 조직에서 플랫폼 팀은 자연스럽게 추론 팀이 된다. 소스 코드를 외부에 보낼 수 없고, 프런티어 모델 비용은 매달 늘어나며, 지원 도구는 호스팅 모델이 접근할 수 없는 내부 데이터를 필요로 하기 때문이다. Hugging Face에는 200만 개가 넘는 오픈 모델이 있고, 대량 트래픽에서는 자체 운영으로 비용을 약 80% 줄일 수 있다. 이 가이드는 vLLM·SGLang 같은 추론 엔진을 상태 저장 데이터베이스에 비유하며 가중치와 KV cache 크기 계산, prefill과 decode의 서로 다른 병목, TTFT·goodput·백만 토큰당 비용 같은 지표를 설명한다. Upbound의 실험에서는 vLLM과 스케줄링은 잘 작동했고, 시간은 TLS·IAM·관측성 같은 주변 작업에 쓰였다.
Upbound는 자사 모델을 직접 운영하면서 vLLM과 스케줄링은 잘 작동한다는 것을 확인했다. 시간은 TLS, 아이덴티티, 타임아웃, 스토리지, IAM, 관측성에 쓰였다.
- libraryofbabel
합리적인 요약이긴 한데, 몇 가지 기본적인 부분이 빠져 있다는 느낌이 듭니다. Attention 메커니즘과 그 최근 변형들 같은 transformer 아키텍처 내부 구조를 이미 아주 탄탄하게 이해하고 있지 않은 플랫폼 엔지니어에게 이 글이 얼마나 이해가 될지 궁금하네요. KV cache가 실제로 무엇이고, 어떻게 계속 커지는 prefix에 대한 반복적인 attention 연산에서 나오는지를 머릿속에 담고 있지 않고서는 이 내용을 정말 이해할 수 있을지 모르겠습니다. 행렬 곱셈, softmax 등으로 attention 가중치를 계산하는 세부 사항에 크게 의존하는 PagedAttention 같은 KV cache 최적화를 이해하는 건 말할 것도 없고요. Attention이 어떻게 작동하는지 꽤 탄탄하게 이해하지 않고서는 "그 히스토리를 다시 계산하는 대신, 엔진은 처리 중인 모든 토큰의 attention key와 value를 유지한다" 같은 문장을 도저히 이해할 수 없었는데, 그 이해는 다른 자료에서 얻어야 했습니다.
이건 Philip Kiely의 그 외에는 훌륭한 책 Inference Engineering의 단점이기도 합니다. transformer 아키텍처 세부 사항을 살짝 넘어가 버리는데, 그건 다른 데서 얻어야 하죠. Sebastian Raschka의 책들은 그 부분에 아주 좋지만, 그러고 나서 그걸 다시 효율적인 추론을 하는 방법과 연결해야 하는데, 그는 그 얘기를 그렇게 많이 하지는 않습니다.
- randbyte
꽤 일반적인 내용처럼 보이네요. 솔직히 말하면 저는 에이전트를 써서 vllm으로 클러스터 서빙 스택을 직접 만들 수 있었고, spec decode, kernel cache reuse까지 갖추고 엔진 버그를 고치거나 앞으로 포팅하는 것도 했습니다.
- d-ramdass
이 가이드는 추론이 처음인 플랫폼 엔지니어를 위한 것입니다. 모델과 GPU가 어떻게 함께 작동하는지, 그리고 프로덕션에서 추론을 어떻게 실행하는지 이해해야 한다면 이 가이드가 도움이 될 겁니다. 또한 어떤 도구를 사용해야 하는지, 그리고 추론 엔지니어링 역할로 어떻게 성장해 나갈지도 배우게 됩니다. 이 가이드는 오픈 소스 CNCF 샌드박스 프로젝트 Modelplane의 메인테이너들이 작성했습니다.