현우 이
V100 LLM 추론, 아직 가능할까요? 2017년에 나온 Tesla V100으로 2026년 최신 LLM인 Qwen3.8-Flash-Next와 DeepSeek-V4-Flash를 돌릴 수 있을까요? 공식 vLLM으로는 불가능합니다. 이 글은 V100 전용 vLLM 포크인 1Cat-vLLM으로 V100 PCIe 32GB 8장 서버에서 두 모델을 직접 띄우고, 최대 컨텍스트와 속도, 동시 처리량을 측정한 기록입니다.
왜 공식 vLLM으로는 V100에서 안 될까
최신 모델용 추론 커널은 대부분 V100 이후 세대 GPU 기능을 전제로 만들어집니다.
| 필요 기능 | 요구 GPU | V100 (SM70) |
|---|---|---|
| FlashAttention 2/3 | Ampere(SM80) 이상 | 미지원 |
| AWQ/GPTQ Marlin 커널 | SM75 이상 | 미지원 |
| FP8 Tensor Core 연산 | Ada/Hopper 이상 | 미지원 |
| NVFP4/MXFP4 연산 | Blackwell 이상 | 미지원 |
| deep_gemm (DeepSeek-V4) | Hopper 이상 | 미지원 |
그래서 공식 vLLM으로는 V100에서 구형 FP16 모델 정도만 돌아가고, 4비트 양자화된 최신 MoE 모델은 커널 단계에서 막힙니다.
1Cat-vLLM이란
1Cat-vLLM은 vLLM을 포크해서 V100(SM70)에서 최신 모델이 돌아가도록 커널을 새로 만들어 넣은 프로젝트입니다. API와 CLI는 vLLM과 같아서 vllm serve로 띄우고 OpenAI 호환 API로 쓰면 됩니다.
- FLASH_ATTN_V100: V100 Tensor Core에 맞춰 다시 짠 FlashAttention
- TurboMind SM70 양자화 커널: NVFP4, MXFP4, AWQ, GPTQ 가중치를 FP16으로 풀어 계산 (메모리는 아끼고 연산은 FP16)
- FP8 KV 캐시: 저장만 FP8, 계산은 변환해서 처리
- 모델별 전용 커널: Qwen의 GDN/QSA, DeepSeek의 sparse MLA 등
프로젝트 배경도 알아둘 만합니다.
| 항목 | 내용 |
|---|---|
| 개발 주체 | 중국 개발자 커뮤니티로 보임 (중국어 문서, 위챗 커뮤니티, 빌리빌리 데모) |
| 공개 시기 | 2026년 4월경 v1.0.0, 2026년 10월 3일 v1.5.1 |
| 라이선스 | Apache-2.0 |
| 성격 | 커뮤니티 프로젝트, 기술 지원이나 SLA 없음 |
V100 LLM 테스트 환경
| 항목 | 내용 |
|---|---|
| CPU / RAM | Intel Ice Lake 2소켓 / 251GB |
| GPU | Tesla V100-PCIE-32GB × 8 (NVLink 없음, PCIe만 사용) |
| 드라이버 | nvidia-driver-580-server (V100을 지원하는 마지막 브랜치) |
| CUDA | 12.8 툴킷 (CUDA 13은 SM70 컴파일 미지원) |
| 엔진 | 1Cat-vLLM v1.5.1, Python 3.12, PyTorch 2.10 cu128 |
| 드라이버: 580이 V100 마지막 지원 브랜치 # apt install -y nvidia-driver-580-server # apt-mark hold nvidia-driver-580-serverCUDA 12.8 툴킷 (13.0은 V100 컴파일 불가) # apt install -y cuda-toolkit-12-8Triton JIT 컴파일에 필요 (빠뜨리면 Python.h 에러) # apt install -y python3.12-dev build-essential ninja-build1Cat-vLLM # uv venv –python 3.12 .venv # uv pip install –python .venv/bin/python ./1cat_vllm-1.5.1-cp312-cp312-linux_x86_64.whl |
V100 LLM 테스트 결과 요약
| 항목 | Qwen3.8-Flash-Next | DeepSeek-V4-Flash |
|---|---|---|
| 체크포인트 | RadixArk NVFP4 (126GB) | 원본 FP8 + MXFP4 (155GB) |
| 필요 GPU | 4장 | 8장 |
| 최대 컨텍스트 | 1M | 1M |
| decode (1K) | 62~64 tok/s | 14 tok/s |
| decode (840K) | 36 tok/s | 1.5 tok/s |
| 840K 프롬프트 TTFT | 6분 25초 | 41분 |
| 동시 처리량 | 371 tok/s (8장, 4장 × 2개, 동시 16) | 10 tok/s (8장, 동시 2) |
동시 처리량은 입력 4K, 출력 512 기준입니다. 결론부터 말하면, 이 서버에서는 Qwen3.8-Flash-Next가 GPU를 절반만 쓰면서 훨씬 빠릅니다.
Qwen3.8-Flash-Next: 4장으로 1M까지
125B MoE(활성 6B) 모델인데 V100 4장에 올라갑니다. 비결은 세 가지입니다.
- NVFP4 4비트 압축으로 가중치가 원본의 약 1/4
- 51B N-gram 임베딩(PLE)을 호스트 RAM으로 오프로드 (약 48GB)
- GDN 선형 어텐션 + QSA 희소 어텐션 구조라 KV 캐시가 작음
| 구성 | 최대 컨텍스트 | decode (1K / 120K) |
|---|---|---|
| FP16 KV, MTP ON (런처 기본값) | 186,742 | 37 / 31 tok/s |
| FP16 KV, MTP OFF | 288,802 (네이티브 262K 전체) | 64 / 57 tok/s |
| FP8 KV, MTP OFF, mem 0.95, MBT 4096 | 1,105,100 (1M) | 62 / 55 tok/s |
1M 구성에서 needle-in-a-haystack 테스트(120K, 478K, 840K × 앞·중간·끝)를 9/9 통과했습니다.
DeepSeek-V4-Flash: 돌아가지만 느리다
8장 PP2×TP4로 1M 기동까지는 성공했습니다. 하지만 1K 입력에서도 첫 응답까지 8초, 생성 속도는 14 tok/s였고, 동시 요청을 늘려도 처리량이 늘지 않았습니다.
측정 중 GPU 사용률은 100%인데 전력은 45W(한도 250W) 수준이었습니다. 계산이 아니라 GPU 간 통신을 기다리는 상태라는 뜻입니다. 온도와 클럭은 정상이었고, 1Cat 기준치(NVLink 환경 약 73 tok/s)와의 차이는 PCIe 전용 환경의 통신 병목으로 봅니다.
삽질 기록: 미리 알았으면 좋았을 것들
| 증상 | 원인 | 해결 |
|---|---|---|
Python.h: No such file or directory |
Triton JIT에 Python 헤더 필요 | python3.12-dev 설치 |
| MTP 켜면 오히려 느림 | PCIe 3장 이상이면 custom all-reduce가 꺼져 추측 디코딩 통신 비용이 이득보다 큼 | MTP OFF, 런처 대신 vllm serve 직접 실행 |
QSA E4M3 phase 1 requires MTP0 |
Qwen에서 FP8 KV와 MTP 동시 사용 불가 | FP8 KV 쓸 땐 MTP OFF |
CSA+linear ... cache geometry |
Qwen은 PP 분할 불가 | TP4 사용 |
supports tensor parallel sizes (1, 2, 4) |
NVFP4 MoE 커널이 TP8 미지원 (EP, DP도 불가) | 8장은 TP4 인스턴스 2개로 운영 |
DeepseekV4 only supports fp8 kv-cache |
DeepSeek는 FP8 KV 필수 | --kv-cache-dtype fp8 |
| CUDA Graph 캡처 중 OOM | Graph 메모리 예약을 해제하면 KV가 공간을 전부 가져감 | 예약은 유지하고 mem·MBT·SEQS로 조정 |
| 동시 8에서 서버 다운 | 1M 구성은 GPU 메모리 여유가 거의 없음 | 1M 구성은 SEQS 4 이하 |
운영 시 주의할 점
- 버전 고정: 생긴 지 6개월 된 빠르게 변하는 프로젝트라, 검증한 버전을 고정하고 업데이트 때마다 재검증합니다.
- 포트 노출: vLLM은 기본으로 API 키 없이
0.0.0.0에 열립니다. 테스트 중에도 외부 스캔이 바로 들어왔습니다. 방화벽과--api-key는 필수입니다. - RAM: Qwen 인스턴스 2개를 띄우면 PLE 때문에 RAM을 약 156GB 씁니다.
- 드라이버: 580 브랜치가 V100 지원의 마지막이므로 자동 업데이트를 막아 둡니다.
참고 링크
- 1Cat-vLLM GitHub 저장소
- Qwen3.8-Flash-Next (Hugging Face)
- Qwen3.8-Flash-Next vLLM 레시피
- DeepSeek-V4-Flash-0731 (Hugging Face)
마치며
V100은 공식 소프트웨어 지원에서는 밀려났지만, 1Cat-vLLM 덕분에 최신 MoE 모델을 1M 컨텍스트로 돌리는 게 가능해졌습니다. 특히 Qwen3.8-Flash-Next는 4장으로 1M, 8장으로 동시 371 tok/s까지 나와서 실사용을 검토할 만한 수준입니다. 반면 DeepSeek-V4-Flash처럼 GPU 간 통신이 많은 모델은 NVLink 없는 PCIe 서버에서는 한계가 뚜렷했습니다.
남는 V100이 있다면, 모델 선택만 잘하면 V100 LLM 서버로 아직 충분히 쓸모가 있습니다.
본 글의 데이터는 2026년 11월 1Cat-vLLM v1.5.1 기준으로 직접 테스트하여 얻은 결과이며, 글 작성은 AI의 도움을 받았습니다.