Tesla V100 16GB 로컬 LLM 성능: 단일 및 듀얼 NVLink 벤치마크

로컬 모델을 실행하고 Claude Code를 완전히 오프라인으로 구동하기 위해 얼마 전 Tesla V100-SXM2-16GB 모듈을 몇 개 구매했습니다. 실제 수치와 주의해야 할 함정들을 공유하면 다른 분들의 시행착오를 줄여줄 수 있을 것 같아 정리해 봅니다. 가격이 많이 내려갔고, ~900 GB/s 속도의 16GB HBM2는 추론 (Inference) 용도로 여전히 놀라울 정도로 성능이 좋습니다. 토큰 생성 (Token generation)에는 대역폭 (Bandwidth)이 가장 중요한데, V100은 대역폭이 매우 풍부합니다.

사양 복습: GV100, Volta, sm_70, 16GB HBM2 ~900 GB/s, fp16 전용. bf16 미지원, int8 텐서 연산 (Tensor ops) 미지원하므로, bf16을 가정하는 모든 것은 fp16 경로를 사용해야 합니다. 두 개의 모듈을 NVLink 브리지로 연결하면 32GB 용량과 대략 두 배의 대역폭을 얻을 수 있습니다. 단일 모듈 구성과 브리지로 연결된 구성 두 가지 방식으로 모두 테스트해 보았으며, 각 결과는 아래와 같습니다.

단일 모듈
단일 16GB 모듈은 26B급 모델을 완전히 GPU 상에서 실행할 수 있습니다 (Gemma 4 26B는 KV 캐시를 위한 여유 공간과 함께 들어갑니다). 이는 로컬 코딩/에이전트 작업이나 일반적인 채팅을 수행하는 한 명의 사용자에게 충분한 수준입니다. 하지만 Qwen3 35B와 같은 더 큰 MoE (Mixture of Experts) 모델은 16GB에 들어가지 않습니다. 따라서 단일 모듈에서는 일부 전문가 (Experts) 모델이 CPU RAM으로 넘어가게(spill out) 되는데, 실행은 되지만 CPU/RAM 속도가 중요해지며 완전히 들어가는 모델보다 느려집니다. Windows를 사용 중이라면 가장 큰 무료 성능 향상 방법은 WSL2 / MCDM을 거치는 대신 모듈을 TCC 모드 (데이터 센터 드라이버 모드)로 실행하는 것입니다. 동일한 모듈, 동일한 모델이지만 드라이버 모드만 다릅니다:

[IMG:1]

모델 (단일 V100) | WSL2 / MCDM | TCC 차이

Gemma 4 26B-A4B (Q4_0 QAT) | 56.8 tok/s | 99.8 tok/s | +76%
Qwen3 35B-A3B (IQ4_XS) | 37.7 tok/s | 54.5 tok/s | +45%

Qwen3 35B 행은 16GB에 들어가지 않아 전문가 모델이 CPU로 오프로드(Offloaded)된 결과이므로, 해당 수치는 RAM 속도에 따라 달라집니다. Gemma 4는 모듈에 완전히 들어가므로 CPU 성능과 무관합니다.

참고할 점은 SXM2 모듈과 캐리어(Carrier)에는 디스플레이 출력 포트가 전혀 없다는 것입니다. 이는 하드웨어 자체의 특성이지 드라이버 모드와는 무관하므로, 비디오 출력을 위해서는 별도의 장치가 필요합니다.

이 카드들은 제 데일리 드라이버 데스크톱에 장착되었습니다. 기존에 있던 오래된 4GB GPU를 뽑아내고 디스플레이는 Ryzen iGPU(내장 그래픽)로 출력하도록 설정했습니다. V100은 오직 연산(compute) 전용으로만 사용합니다. 오래된 모듈 단일 구성으로 초당 약 100 토큰(tok/s)을 생성하는 것은 코딩 에이전트(coding agent)를 구동하거나 로컬 모델을 오프라인으로 실행하기에 충분합니다.

듀얼 모듈, 멀티 에이전트 동시성 (Q4)
이것들은 SXM2 모듈이므로 직접적으로 꽂을 수 있는 곳이 없으며, 이를 실행하려면 캐리어 보드(carrier board)가 필요합니다. 저는 두 모듈을 모두 수용하면서 NVLink를 지원하는 커스텀 듀얼-SXM2 PCIe 캐리어 보드를 찾아냈는데, 이는 데스크톱의 연산 능력을 크게 향상시켜 줍니다! 이 모듈들은 자체 팬이 없는 서버에서 추출된 것이므로 직접 냉각 장치를 장착해야 합니다. 기본 방식은 어댑터에 고회전(high-rpm) 블로워 팬을 다는 것이지만, 저는 반대로 기존의 9cm 높이 라디에이터를 커스텀 팬 마운트와 함께 다시 장착하여 책상 위에 두어도 충분히 조용하게 유지되도록 했습니다. 공간을 많이 차지하지만 전체 시스템을 독립적으로 유지할 수 있습니다.

어쨌든, 제가 가장 궁금했던 부분은 이것이 여러 에이전트를 동시에 얼마나 잘 서비스하는가 하는 점이었습니다. 설정: Qwen2.5-35B-A3B IQ4_XS (4.19 bpw), 전체 메모리 상주(fully resident), 두 모듈에 걸친 텐서 분할(tensor-split, -sm tensor -ts 1/1), q8_0 KV 캐시(KV cache), TCC. 256 토큰 생성 기준입니다.

첫 번째 표는 요청당 짧고 구별되는 프롬프트를 사용하므로 디코딩(decode) 중심이며, 기본적으로 상한선(upper bound)을 나타냅니다:

에이전트 수	총합 tok/s	에이전트당 tok/s	p50 지연 시간 (256 tok)
1	62.7	62.7	4.3 s
4	125.1	31.3	6.4 s
8	211.4	26.4	8.0 s
16	338.1	21.1	13.0 s

하지만 중요한 주의 사항이 있습니다. 위 수치는 짧은 프롬프트를 사용했을 때의 디코딩 한계치입니다. 실제 Claude Code 트래픽은 약 24k 토큰의 시스템 프롬프트를 포함하므로 프리필(prefill) 비중이 높으며, 실제 수치는 더 낮습니다. 동일한 하드웨어에서 요청당 약 24k의 프롬프트를 사용하는 NCCL + NVLink 환경의 결과입니다:

에이전트 수	총합 tok/s	에이전트당 tok/s
1	47	47
4	122	30
8	155	19
16	174	11

따라서 816개의 동시 실행 시, 실제 에이전트가 체감하게 될 정직한 수치는 총합 약 150175 tok/s 정도입니다.

성능 저하나 공유 메모리 (shared-memory, smem) 실행 실패 없이 16개까지 깔끔하게 확장되었습니다. 이는 높은 동시성 (concurrency) 상황에서 Volta의 더 작은 SM당 공유 메모리 예산이 문제를 일으킬 수 있는 부분입니다. 솔직히 말씀드리자면, 이 결과는 Q4 가중치 (weights) 기준입니다. Q4는 멀티 턴 에이전트 작업 (multi-turn agentic work)에서 취약한 지점으로 알려져 있습니다. 많은 작업에서 잘 버텨주지만, 에이전트 체인이 길어지면 그 한계가 느껴집니다. 참고하시기 바랍니다.

더 나은 품질을 원한다면, 32GB 모델은 동일 모델의 Q6_K를 완전히 상주(resident)시킬 수 있으며, 단일 스트림 (single-stream) 기준 약 80 tok/s (-sm 레이어)를 기록합니다. 따라서 동시성 여유분을 일부 포기하고 더 강력한 양자화 (quant) 모델을 선택할 수 있습니다. 단일 16GB 모듈로는 이를 수용할 수 없습니다.

주의사항 (실제로 유용한 부분)

드라이버 지원 기간 (Driver window). Volta는 드라이버 지원이 종료되어 가는 단계입니다. CUDA 12.8 바이너리를 로드하려면 최소 R570 (Windows의 경우 570.65) 버전이 필요하며, 그보다 낮은 버전은 "device kernel image is invalid" 오류를 발생시킵니다. 최상단 기준으로 Volta 지원은 R580에서 종료되며, CUDA 13.3 / R595에서는 완전히 제외됩니다. 따라서 사용 가능한 기간은 R570에서 R580 사이이며, 저는 573.96 버전을 사용 중입니다. 확인 없이 최신 드라이버를 설치했다가는 왜 아무것도 실행되지 않는지 의아해할 수 있습니다.

PSU 과도 응답 (PSU transient response). 이 문제로 며칠을 허비했습니다. 듀얼 GPU 동시 부하 상황에서 시스템이 계속 강제 재부팅되었고, nvlddmkm을 가리키는 0x133 DPC_WATCHDOG_VIOLATION 오류가 발생했습니다. 두 가지 드라이버 브랜치를 추적하고, 온도(60도 중반으로 양호)를 확인하고, NVLink P2P를 비활성화하고, ECC 오류도 확인했지만 아무것도 해결되지 않았습니다. 결국 원인은 전력 공급이었습니다. 부하가 걸릴 때 두 모듈이 동시에 전류를 급격히 끌어올리는데, 구형 파워 서플라이 (PSU)가 이 과도 응답 (transient)을 감당하지 못해 전압 저하 (brownout)가 발생한 것이었습니다. Corsair RM850으로 교체한 이후로는 안정적입니다. 따라서 듀얼 구성을 한다면 GPU 온도가 아니라 PSU를 제대로 갖추는 것이 핵심입니다.

듀얼 구성 참고 사항. 캐리어 (carrier)는 BIOS에서 Above 4G Decoding이 활성화된 상태로 슬롯이 x8/x8 분할 (bifurcation) 설정되어 있어야 합니다. 두 모듈 사이의 NVLink P2P 측정값은 약 33 GB/s였습니다. 멀티 에이전트 서빙 (multi-agent serving)의 경우, NVLink / NCCL all-reduce는 Windows 기본 내부 경로에 비해 주로 프리필 (prefill) 단계에서 완만한 총합 이득만을 제공하므로, NVLink가 처리량 (throughput)을 획기적으로 변화시킬 것이라고 기대해서는 안 됩니다.

전체 기술 문서, 벤치마크, 그리고 유용하게 사용할 수 있는 사전 빌드된 바이너리(binaries) / 서빙 스크립트(serve scripts)는 여기에서 확인할 수 있습니다:

gitub: github.com/andrewleech/v100-llm-kit
blog: notes.alelec.net/posts/datacentre-under-the-desk

이와 관련된 어떤 질문이든 기꺼이 답변해 드리겠습니다. 특히 드라이버(driver)와 PSU(전원 공급 장치) 관련 문제는 원인을 파악하는 데 시간이 꽤 걸렸으므로, 이 장치를 구축 중이라면 무엇이든 물어봐 주세요.
제출자: /u/coronafire
[link] [comments]