vLLM 0.28, 추론 엔진은 이제 운영체제 경쟁이다

0.28 릴리스의 핵심은 기능 수가 아니라 범위다

vLLM v0.28.0 릴리스 노트는 한 문장으로 요약하기 어렵다. 공개 노트 기준으로 584개 커밋, 270명 기여자, 76명 신규 기여자가 들어갔고, 저장소 자체도 GitHub에서 9만 개가 넘는 스타를 가진 LLM 서빙 표준 후보가 됐다. 눈에 띄는 항목은 Kimi-K3 최적화, DeepSeek V4 지원, speculative decoding 개선, Model Runner V2 성숙, 계층형 KV 캐시 오프로딩, 러스트 프런트엔드, 보안 수정이다.

이 릴리스가 중요한 이유는 vLLM이 단순한 모델 실행기가 아니라 추론 운영체제처럼 움직이고 있기 때문이다. GPU 커널, 스케줄러, 캐시 레이아웃, API 호환성, 멀티모달 전처리, 보안 경계가 한 릴리스 안에서 동시에 바뀐다. vLLM 문서가 강조하는 고처리량 서빙의 약속도 이제 단일 최적화가 아니라 전체 경로의 합으로 결정된다.

모델보다 경로 최적화가 비싸진다

Kimi-K3와 DeepSeek V4 항목을 보면 방향이 선명하다. 릴리스 노트는 Kimi-K3에 대해 DCP, fused FlashKDA decode and prefill kernel, adaptive speculative token budget, shared-expert sharding을 언급한다. DeepSeek V4 쪽은 sparse MLA, MTP, DSpark speculative decoding, ROCm enablement가 묶였다. 이런 변화는 모델 파일 하나를 내려받는 문제와 다르다. 같은 모델도 어느 추론 엔진, 어느 커널, 어느 캐시 정책 위에서 돌리느냐에 따라 제품 응답 시간과 GPU 비용이 달라진다.

BTB, 예측형 KV 복제가 LLM 추론의 새 병목을 겨냥하다는 KV 계층이 제품 비용의 중심으로 이동한다고 봤다. 이번 vLLM 릴리스도 같은 방향이다.

하드웨어 중립성은 말보다 빌드 매트릭스다

vLLM 0.28은 NVIDIA, AMD ROCm, Intel XPU, CPU 경로를 모두 다룬다. NVIDIA 쪽은 FlashInfer XQA, SM100/SM90 최적화가 보이고, AMD는 torch 2.12와 triton 3.7 스택, gfx11과 gfx950 지원이 들어갔다. Intel XPU 휠도 릴리스 파이프라인에 추가됐다. AMD ROCm과 Intel Extension for PyTorch 생태계가 추론 프레임워크의 실전 선택지로 들어오는 흐름이다.

한국 클라우드와 대기업 입장에서는 이것이 더 현실적이다. 모든 워크로드를 특정 GPU 한 종류에 맞출 수 없고, 조달 상황도 바뀐다. 오픈소스 추론 엔진이 여러 하드웨어 백엔드를 실제 릴리스 단위로 챙긴다면, 기업은 벤더 종속을 늦추는 협상력을 얻는다. 다만 중립성은 문서의 선언이 아니라 장애 대응과 성능 회귀 테스트로 검증된다.

보안 항목은 사소하지 않다

릴리스 노트의 보안 섹션은 sample-rate forgery로 오디오 디코드 시간 제한을 우회하는 DoS 수정, DeepStream 픽셀 제한, trust_remote_code 해석 가드, --api-key가 모든 엔드포인트를 막지 않는다는 문서 경고를 포함한다. LLM 서버는 이제 텍스트 API가 아니라 파일, 이미지, 오디오, 원격 코드, 플러그인, 구조화 출력이 모두 지나가는 입구다. 보안 경계가 얇으면 추론 비용 폭탄이나 내부 데이터 노출로 이어진다.

LLM 추론 엔진 호스트 장악 리스크, 로컬 AI의 새 공격면는 추론 런타임 자체가 공격면이 된다고 짚었다. vLLM의 보안 수정은 이 경고가 과장이 아니라 운영 이슈라는 사실을 보여준다. OpenAI 호환 API를 붙여 내부 도구를 여는 팀일수록 엔드포인트별 인증과 입력 제한을 별도로 점검해야 한다.

한국 팀의 체크리스트

첫째, 모델 벤치마크와 서빙 벤치마크를 분리해야 한다. 같은 프롬프트 정확도를 내는 모델이라도 초당 토큰, 첫 토큰 지연, 배치 안정성, 피크 메모리, 장애 복구 시간이 다르다. 둘째, 엔진 업그레이드를 라이브러리 패치가 아니라 인프라 릴리스로 취급해야 한다. 584개 커밋 규모의 변화는 성능 개선과 회귀를 동시에 가져온다. 셋째, 비용 계측은 모델 API 가격표가 아니라 실제 GPU 점유율과 캐시 적중률에서 시작해야 한다.

vLLM inference and serving guide와 Hugging Face Text Generation Inference 같은 대안을 함께 비교하면 특정 프레임워크 종교전에서 벗어날 수 있다. 로컬 LLM 품질, 모델보다 실행 스택이 흔든다도 같은 결론에 닿는다. 모델을 고르는 일은 끝이 아니라 운영 실험의 시작이다.

자주 묻는 질문

Q1: vLLM 0.28은 바로 프로덕션에 올려도 되나요?

A: 새 기능이 많아 바로 전면 적용하기보다 대표 워크로드로 회귀 테스트를 먼저 돌리는 편이 안전하다.

Q2: 가장 중요한 변화는 무엇인가요?

A: Kimi-K3, DeepSeek V4 같은 최신 모델 최적화보다 KV 캐시, 스케줄링, 하드웨어 백엔드가 함께 성숙했다는 점이다.

Q3: 한국 스타트업도 직접 운영해야 하나요?

A: 트래픽이 작으면 관리형 API가 빠르다. 다만 지연 시간, 데이터 위치, 대량 비용이 중요해지면 자체 서빙 검토가 필요하다.

Q4: 보안 항목을 왜 봐야 하나요?

A: 추론 서버는 멀티모달 파일과 원격 모델 코드를 다룬다. 인증과 입력 제한이 약하면 일반 웹 API보다 큰 비용 피해가 생길 수 있다.

Q5: 다음 액션은 무엇인가요?

A: 현재 모델 후보를 vLLM, TGI, 관리형 API에서 같은 프롬프트와 같은 동시성으로 비교하고, TTFT와 총 비용을 함께 기록하는 것이다.