멀쩡한 V100은 왜 vLLM을 거부할까: GPU의 진짜 수명

Mr. Latte ∙ 소프트웨어 개발 전문가

연구실이나 회사 서버실 구석, 여전히 팬이 쌩쌩 돌아가는 V100 GPU를 본 적이 있을 것이다. 2017년에 나온 카드지만 물리적으로는 멀쩡하고 전기도 잘 먹는다. 그런데 여기에 요즘 널리 쓰이는 LLM 서빙 스택인 vLLM을 올려보려고 설치 명령어를 치면 단칼에 거절당한다. vLLM이 요구하는 최소 Compute Capability(연산 능력 버전)가 7.5인데, V100은 7.0이기 때문이다[1]. 비디오 카드 장비 자체의 고장이 아니라, 그 위에 올라가는 소프트웨어가 거부하는 문제다.

이 글의 핵심은 단순하다. 가속기를 몇 년 더 쓸 수 있느냐를 결정하는 것은 하드웨어의 물리적 수명이 아니라, 업스트림 오픈소스 프로젝트들이 정한 소프트웨어 지원 종료(EOL) 시점이다.

지금 이 이야기가 중요한 이유는 비용 때문이다. 2026년 8월 블룸버그 보도에 따르면 엔비디아 칩을 탑재한 서버 가격이 주요 고객 기준 15% 넘게 오를 예정이다[2]. 주원인은 연산 칩이 아닌 HBM 등 메모리 반도체 가격의 급등이다. 서버를 사기 위한 돈값(금리)도 같이 올랐다. 마이크로소프트 데이터센터용으로 발행된 39억 달러 규모의 5년물 채권 금리가 연 7.228%로 매겨졌을 정도다[3][4].

새 장비와 자금 조달 비용이 모두 치솟자 기업들의 대응은 명확하다. “가지고 있는 장비를 최대한 오래 굴린다.” 마이크로소프트의 2026 회계연도 연차보고서를 보면 서버와 네트워크 장비의 추정 내용연수를 최대 6년까지 늘려 잡았다[5]. 취득가를 6년에 나눠 비용으로 적겠다는 뜻이다. 하지만 문제는 기업 장부가 6년을 적어두었어도, 소프트웨어 생태계는 그 6년을 약속한 적이 없다는 사실이다.

버전 번호 하나가 가르는 GPU의 운명

엔비디아는 GPU 세대마다 Compute Capability라는 버전 번호를 붙인다. 라이브러리들은 이 번호를 기준으로 “이 버전 미만은 지원하지 않는다"며 거부한다[6].

세대	Compute Capability	대표 카드	현주소 및 제약 사항
Pascal	6.x	P100	CUDA 13.0부터 오프라인 빌드 대상에서 제외
Volta	7.0	V100	vLLM 최소 요구사항 미달, 신규 빌드 불가
Turing	7.5	T4	FlashAttention 메인 저장소 지원 제외, bf16 미지원
Ampere	8.0	A100	FP8 연산 하드웨어 미지원 (가중치만 FP8 적용 가능)
Ada / Hopper	8.9 / 9.0	L40S / H100	FP8 연산 지원, FlashAttention-3는 Hopper부터 지원
Blackwell	10.x	B200	FlashAttention-4가 겨냥하는 최신 아키텍처

지원이 끊기는 세 가지 계단

하드웨어 지원 중단은 단번에 일어나지 않고 세 단계에 걸쳐 계단식으로 진행된다.

컴파일러 단계 (CUDA Toolkit): CUDA 13.0은 Compute Capability 7.5 미만(Turing 이전) GPU에 대한 오프라인 컴파일 지원을 뺐다. 이 세대를 계속 빌드해야 한다면 CUDA 12.9 이하에 머물러야 하며, 드라이버 지원(R580 브랜치) 역시 2028년 중반이면 끝난다[7][8]. 2022년에 들여온 Volta 장비를 6년 채워 쓰겠다고 장부에 적어둔 곳이라면, 마지막 해에는 벤더가 보장하지 않는 조합을 사용해야 한다.
프레임워크 단계 (PyTorch): PyTorch 2.8은 배포 바이너리 크기를 줄이기 위해 Maxwell과 Pascal 지원을 배포 빌드에서 제외했다. 흥미로운 점은 Volta는 오히려 되살렸다는 것이다[9]. 이처럼 프레임워크마다 자체적인 기준을 적용하므로 “내 카드를 언제까지 쓸 수 있는가"에 대한 답은 프로젝트마다 다르다.
커널 라이브러리 단계 (FlashAttention 등): LLM 처리량을 결정짓는 핵심 부품인 어텐션 커널의 파편화가 가장 심하다. FlashAttention-2는 Ampere 이상, 3은 Hopper 전용, 4는 Hopper와 Blackwell을 겨냥한다. Turing은 별도 분기(repo)로 밀려났고 bf16 연산조차 지원하지 않는다[10]. 카드가 도는 것과 쓸 만한 속도가 나오는 것은 별개의 문제다.

“기존 바이너리는 돈다"는 말의 착시

지원 제거가 당장 “실행조차 불가능함"을 의미하진 않는다. 예전 툴킷으로 빌드해 둔 바이너리는 드라이버가 허용하는 한 전과 똑같이 작동한다. 문제는 우리가 쓰는 대부분의 서빙 스택이 남이 빌드해 둔 패키지를 가져와 쓴다는 점이다.

배포자가 바이너리 크기를 이유로 특정 아키텍처를 빼버리면, 결국 직접 소스 빌드를 해야 한다. 그 순간 툴킷·드라이버 버전을 고정하고 전용 CI 환경을 유지보수하는 부담이 온전히 우리 팀의 짐이 된다.

물론 구형 카드가 무조건 고물이 되는 것은 아니다. 최신 어텐션 커널이나 저정밀도 연산이 필요 없는 임베딩 생성, 리랭킹, 야간 배치 추론 등에서는 T4나 V100도 여전히 밥값을 한다. 핵심은 카드의 폐기 여부가 아니라 클러스터의 작업 큐를 어떻게 효율적으로 분리하느냐다.

토큰당 단가를 낮추는 힘은 새 실리콘에 있다

장비를 오래 쓰는 것이 비용 절감처럼 보이지만, 실제로는 추론 단가 인하의 기회를 놓치는 것일 수 있다. 최근 추론 비용을 대폭 낮춘 핵심 기술들이 최신 하드웨어에 묶여 있기 때문이다.

vLLM 기준 FP8 연산(Ada/Hopper 이상)은 모델 메모리 요구량을 절반으로 줄이고 처리량을 최대 1.6배 높여준다[11]. Ampere나 Turing은 가중치만 FP8로 변환하고 계산은 16비트로 처리하는 방식(W8A16)을 써야 해서 실제 연산 속도가 비례해서 빨라지진 않는다. 서버 메모리 가격이 급등한 지금, 메모리 소모를 반으로 줄여주는 기술이 최신 GPU에만 온전히 존재한다는 것은 묘한 역설이다.

GPU 한 장 없이도 직접 해볼 수 있는 것

무료 Google Colab(T4 제공)만으로도 다음 작업들을 직접 구축해 볼 수 있다.

의존성 CC 스캐너 작성: requirements.txt나 락 파일을 읽어 각 라이브러리가 요구하는 최소 Compute Capability를 모아 보여주는 스크립트다. 자산 대장 옆에 이 표를 붙여두면 GPU의 진짜 소프트웨어 수명을 한눈에 볼 수 있다.
클러스터 인벤토리 대조기: 노드별로 torch.cuda.get_device_capability()를 수집해 위 표와 대조함으로써, 어떤 노드가 어떤 라이브러리 업데이트에서 먼저 탈락할지 보여주는 도구다.
PTX 폴백 성능 실측: 구형 카드에서 예전 툴킷 빌드가 작동할 때, 최신 환경 대비 성능 손실(Latency, Throughput)이 얼마나 발생하는지 동일 프롬프트로 측정한다. (단, 드라이버 지원 종료 시 보안 패치가 중단되므로 프로덕션 적용엔 주의해야 한다.)
세대별 큐 분리 실험: 임베딩/리랭킹 작업은 구형 노드로 몰고 생성(Generation) 작업만 최신 노드에 남겼을 때의 전체 지연 시간과 비용 효율을 측정한다.

첫 번째(의존성 스캐너)와 네 번째(큐 분리 실험)는 당장 시도해 볼 가치가 크다. 다양한 세대가 섞인 클러스터에서 작업 큐를 효율적으로 분할했을 때의 실제 운영 데이터는 여전히 희귀하다. 구형 GPU를 무작정 버리거나 억지로 최신 모델을 얹기보다, 소프트웨어가 그어놓은 선을 정확히 파악하고 적재적소에 배치하는 실무적 지혜가 필요한 때다.