---
title: "동시성이 왕이다 — vLLM을 돌리는 사람들의 점수와 잔고"
date: 2026-10-10
model: qwen3.6-plus
author_type: human
category: reviews
summary: "vLLM은 병렬 서빙의 기준점이다. 단일 요청에서는 llama.cpp보다 느리고, 동시 요청에서는 압도적이다. shm 브로드캐스트 장애·OOM·FP8 KV 정확도·노드당 5K tok/s 실측까지 프로덕션 사용자 기록으로 정리했다."
tags: vLLM, 추론 서버, 동시성, FP8, 텐서 병렬, 프로덕션, 사용자 리뷰, 실사용자 리뷰, AI 에이전트
---

## 동시성이 왕이다 — vLLM을 돌리는 사람들의 점수와 잔고

r/Vllm의 짧은 확인 글 하나가 vLLM의 본질을 말한다. "Qwen3.5 9B FP8로 단일 요청 약 50 t/s. 원래 vLLM이 llama.cpp보다 빠르다고理解했는데, 확실히 아니다."

답글: **"미친 게 아니다. vLLM은 동시 요청에 빠르다. 단일 요청에서는 거의 항상 llama.cpp보다 느리다."**

반대쪽의 실측도 있다. "B200 8장 노드에서 Qwen 3.5 27B FP8: **95,317 tok/s.** 12 노드: **1.1M tok/s.** 커스텀 커널 없음."

이 글은 vLLM을 **동시 서빙 엔진**으로만 평가하고, 그 안에서의 점수와 잔고를 정리한다.

---

### 1. 무엇이 점수인가

**동시성.** paged attention·배치 서빙이 설계의 핵심이다. 위 B200 실측이 보여주듯, 노드 규모로 갈수록 토큰 처리량이 선형에 가깝게 커진다.

**실측 플래그.** 커뮤니티가 공유한 최적화 조합: `--data--parallel-size 8`(TP 대신 DP로 22K→75K), `--num-speculative-tokens 1`+ngram, `--kv-cache-dtype fp8_e4m3`(959K vs 288K 토큰/엔진), `--enable-chunked-prefill`, `--enable-prefix-caching`.

**프로덕션 엔드포인트.** RTX 6000 Ada 한 장에서 Qwen3.6-27B FP8: "빠른 TTFT, 피크 668 tok/s." `--tool-call-parser qwen3_coder`·`--reasoning-parser qwen3`로 툴·추론 파싱까지 담는 형태.

---

### 2. 무엇이 잔고인가

**단일 요청의 체감.** 위 "느리다" 체험. 개인 사용자·로컬 대화의 기본값이 llama.cpp·Ollama인 이유다. vLLM의 승리는 **대기열**의 승리다.

**공유 메모리 장애.** "vLLM 0.25.1은 잘 돌아가지만 **상시 깨진다.** Sometimes 10 hours fine, sometimes 1~2 hours." `shm_broadcast.py:705 No available shared memory broadcast block found`. 사용자의 해결책: "재시작 프로세스를 걸어 두었다. 이건 프로페셔널하지 않다."

**하드웨어·양자화 매핑.** Threadripper·RTX 4000 Ada 조합에서 "2일 동안 트러블슈팅. nvidia/Qwen3.6-35b-a10b-nvfp4만 올라간다. 다른 FP8 모델은 shm 부족으로 컨테이너가 꺼진다." SWAP 8GB 고갈 흔적까지 기록된다.

**OOM의 여백.** 위 B200 실패 사례: `gpu-memory-utilization 0.95`에서 MTP 드래프트+베이스+KV+CUDA graphs가 OOM, **908개 요청 실패.** 0.90이면 성공.

**추론적 정확도.** FP8 KV 캐시는 "known accuracy issue"라는 주석과 함께 사용된다. 처리량의 대가를 수치로 적어 두어야 한다.

**추측 디코딩의 한계.** MTP-5는 두 번째 런에서 `cudaErrorIllegalAddress`. MTP-1로 안전하게 유지. 수용률이 위치별로 84.7%에서 급락하는 패턴도 기록된다.

---

### 3. 언제 vLLM인가

| 상황 | 선택 |
| --- | --- |
| 동시 요청·API 서빙, 노드 이상 | **vLLM** |
| 혼자·소수, 로컬 대화 | llama.cpp·Ollama |
| GPU 1장·WSL·컨테이너 환경 | shm·드라이버 이슈를 감수할 의지 |
| 지속 고부하, 정확도 민감 | FP8 KV 대신 안전한 dtype 검증 |

실무 처방: **버전을 핀하고, shm/컨테이너 환경을 먼저 검증하고, 재시작 전략을 엔지니어링으로 받아들여라.** "rock solid"한 단일 플래그 조합은 커뮤니티에도 아직 없다.

---

### 4. 결론 — 서버의 물리

vLLM의 사용자 기록은 한 문장으로 압축된다. **동시성이 곧 성능이고, 그 성능은 하드웨어·버전·공유 메모리의 물리에 매여 있다.**

95K tok/s의 노드와 shm 브로드캐스트로 죽는 두 시간은 같은 프레임워크의 다른 얼굴이다. 전자는 "엔진이 무엇을 할 수 있는가", 후자는 "운영이 무엇을 감수하는가"를 말한다.

vLLM을 선택할 팀: ① 동시성 요구가 확실한지, ② GPU·양자화·KV dtype을 측정으로 고를 사람, ③ 장애 시 재시작·관측을 담당할 인프라. 그 세 가지가 있으면, 오픈소스 서빙 엔진의 기준점은 여전히 vLLM이다.

관련 글: [llama.cpp 사용자 리뷰](/reviews/2026-10-10-llama-cpp-user-reviews/) · [Hugging Face 사용자 리뷰](/reviews/2026-10-10-hugging-face-user-reviews/) · [vLLM 에이전트 허브 항목](/agents/vllm/)

---

### 출처

- shm 장애: [Safest way to run vllm for production? (r/Vllm, 2026-08)](https://www.reddit.com/r/Vllm/comments/1vkts1w/)
- 단일 vs 동시: [Understanding vLLM Performance (r/Vllm, 2026-03)](https://www.reddit.com/r/Vllm/comments/1s8pdja/)
- 노드 실측: [5K tok/s per node with vLLM v0.18.0 on B200 (r/Vllm, 2026-03)](https://www.reddit.com/r/Vllm/comments/1s4hueq/)
- 하드웨어 트러블: [Advice needed please (r/Vllm, 2026-07)](https://www.reddit.com/r/Vllm/comments/1ula7dj/)
- 엔드포인트 실측: [Qwen3.6-27B-FP8 on One RTX 6000 Ada (r/Vllm, 2026-07)](https://www.reddit.com/r/Vllm/comments/1uodq4c/)