vLLM 서빙 스택을 C++20으로 포팅함: 66 MiB 바이너리, 추론 시 파이썬 없음, vLLM과 토큰 단위로 동일한 출력 확인

내가 만든 거니까 적당히 걸러 들어. vLLM 프로젝트랑은 아무 상관 없는 커뮤니티 포트고, vLLM 쪽에서 공식 인증해 준 것도 아님. 그냥 vLLM 코드를 참고해서 정확도 검증용으로 쓴 것뿐이야.

이걸 왜 시작했냐면, 난 vLLM을 진짜 좋아하는데 vLLM을 설치하려면 virtualenv만 9.1 GiB를 잡아먹거든. 근데 난 다른 소프트웨어 안에 추론 기능을 넣고 싶었고, 프로세스 안에 인터프리터가 돌아가는 게 문제가 되는 환경들이 있었어. 솔직히 파이썬 의존성 문제는 보안(공급망 공격)이나 파이썬 자체의 덩치 문제도 있고 해서, vllm.cpp는 vLLM의 서빙 스택을 C++20으로 밑바닥부터 다시 짠 거야. 이름은 아직 정하는 중인데, 더 좋은 이름 나오기 전까진 그냥 vllm.cpp라고 부를게.

Continuous batching, block-paged KV, 자동 prefix 캐싱, speculative decoding, OpenAI 호환 서버까지 다 돼. 파이썬이나 PyTorch 없이 빌드하면 66 MiB짜리 바이너리 하나로 끝남.

나한테는 크기보다 검증 과정이 훨씬 중요해. 모든 아키텍처는 같은 워크로드에서 vLLM 오라클이랑 토큰 단위로 일일이 대조하고, 업스트림의 테스트 모듈도 코드 커밋할 때 같이 포팅해. ID 값이 무조건 똑같이 나와야 함. 지금까지 한 25개 정도 아키텍처 작업했어. 맞음, 이 프로젝트 만들 때 AI를 엄청나게 굴렸어. 어떻게 설계했는지(이건 포트 버전이라 MLX나 Radix Attention 지원 같은 부분에서 좀 다름)는 나중에 따로 정리해서 올릴게.

다들 제일 궁금해하는 속도 얘기 좀 할게. 이미지 보면 알겠지만 고부하 상황에서 vLLM이랑 거의 비등해. DGX Spark, Thor, AGX Orin에서만 테스트해 봤어. DGX Spark(GB10)에서 Qwen3.6-27B NVFP4 모델 돌렸고, vLLM은 프로덕션용 그래프 설정으로 잡고 3번씩 인터리브해서 중앙값 냈어. 1024 입력 / 128 출력 기준이야:

concurrency	vllm.cpp	vLLM	ratio
1	86.05	82.32	1.045x
2	159.68	158.03	1.011x
4	292.34	290.31	1.007x
8	508.77	505.46	1.007x
16	801.76	789.16	1.016x
32	1095.01	1076.25	1.017x

전반적으로 살짝 앞서긴 하는데, 우리 쪽 실행 오차가 0.5% 정도고 6개 중 5개가 1.7% 이내에 들어와. 사실상 c1에서 한 번 이기고 나머지는 다 비긴 셈이지. 댓글에서 누가 계산해 보라고 하기 전에 내가 먼저 말하는 게 나을 것 같아서 적어. 출력값은 모든 지점에서 완전히 똑같아. 메모리 쪽은 확실히 차이가 나는데, GPU 피크 메모리가 vLLM은 70,531 MiB인데 우리는 40,996 MiB야. vLLM은 처음에 고정된 비율을 미리 예약해 두는 방식이고, 우리는 워크로드에 필요한 만큼만 할당하는 방식이라서 KV 캐시가 더 효율적이라기보다는 그냥 점유하는 메모리 차이라고 보면 돼.