H200 두 장 2500TPS, 실제 대화 26TPS 차이의 정체

클코단에서 Gemma4를 TP=2, 병렬 8개, 최대 토큰 64k로 맞추고 H200 GPU 두 장에 올리면 초당 2500토큰(TPS)이 나온다는 벤치마크 구성이 공유됐다. 같은 자리에서 실제 대화 체감 속도는 초당 25~26토큰이라는 이야기도 나왔다. GPU 요금과 API 단가가 함께 오르는 요즘 이런 간극은 그냥 넘기기 어렵다. 100배 가까운 차이지만 둘 중 하나가 틀린 숫자는 아니다. 이 기사는 그 간극이 어디서 오는지, 이 숫자들이 개인 개발자에게 어떤 의미인지를 짚는다.

2500 TPS는 서버 전체의 합산 처리량이다

TP=2는 각 레이어의 텐서 연산을 GPU 두 장에 나눠 처리하는 방식이다. 한 장짜리 메모리에 다 안 들어가는 모델을 여러 GPU로 쪼개 돌릴 때 쓰는 표준 기법이다. vLLM 프로젝트가 최근 공개한 벤치마크에서 H200 한 장당 초당 2200토큰까지 뽑아낸 사례가 보고됐다. DeepSeek-R1처럼 671B 파라미터 중 37B만 활성화하는 희소 모델을 넓은 전문가 병렬화 방식으로 돌린 결과다. 방에서 공유된 2500 TPS도 개별 사용자 속도가 아니라 합산 처리량으로 제시된 숫자다.

병렬 8개라는 설정은 GPU 두 장으로 구성된 서버가 여덟 개의 요청을 동시에 처리하며 쌓아 올린 합산치라는 뜻이다. vLLM이나 TensorRT-LLM 같은 서빙 엔진은 여러 사용자의 요청을 하나의 배치로 묶어 GPU 연산을 최대한 채운다. 이 값은 서버 전체의 처리 능력이지 한 사람이 채팅창에서 느끼는 속도가 아니다.

26 TPS는 한 사람이 채팅창에서 받는 속도다

같은 GPU, 같은 모델이라도 배치 크기를 키우면 전체 처리량은 오르고 개별 응답은 느려진다. 처리량과 지연시간(TPOT) 사이엔 이런 트레이드오프가 있다는 게 vLLM 진영에서 오래전부터 나온 이야기다. 채팅 UX를 다룬 최근 분석은 첫 토큰이 나오기까지 걸리는 시간(TTFT)이 초당 토큰 수보다 체감에 더 크게 작용한다고 짚는다. 첫 토큰이 빨리 뜨는 응답이, 이후 생성 속도만 높은 응답보다 빠르게 느껴질 수 있다는 것이다.

방에서 나온 25~26 TPS는 딱 이 지점, 대화창에서 한 사람이 받는 스트리밍 속도에 해당한다. 사람이 읽기에 30 TPS 안팎이면 충분하다는 기준이 업계에서 흔히 쓰인다. 숫자만 보면 100배지만 재는 대상이 다르다.

벤치마크의 합산 처리량 숫자만 보고 장비부터 들였다가 정작 대화창 체감 속도가 기대에 못 미쳐 당황했다는 반응도 있다. 서버 전체 처리량과 개인이 받는 속도를 같은 눈금으로 재는 데서 오는 착시라는 것이다.

밀집 모델이 느리다는 의견, 구조상 근거가 있다

Gemma4는 올해 4월 공개됐고 최대 256K 토큰까지 문맥을 지원한다. 방에서 잡은 64k 설정은 그중 일부만 쓴 값이다. 현재 E2B, E4B, 12B, 26B, 31B 다섯 가지 크기로 나오고 26B는 전체 파라미터 중 3.8B만 활성화하는 MoE(전문가 혼합) 구조다. 실측 비교에서 MoE 26B가 밀집 구조인 31B보다 빠르게 응답했다.

밀집 모델은 토큰 하나를 만들 때마다 파라미터 전체를 계산에 끌어온다. MoE는 필요한 전문가 조각만 골라 쓴다. 품질 차이는 크지 않다는 비교도 있다. 방에서 "밀집 모델은 특정 하드웨어에서 느릴 수 있다"고 한 의견은 이 구조 차이를 가리킨다.

MLX 이야기는 다른 하드웨어 계열의 이야기다

방에서는 MLX 최적화가 덜 됐을 수 있다는 말도 나왔다. MLX는 애플이 자사 실리콘(M 시리즈 칩)에 맞춰 만든 프레임워크다. CUDA 기반인 H200 서버와는 애초에 다른 스택이다. 로컬에서 통합 메모리를 쓰는 맥북·맥 스튜디오 환경에서 강점을 보이는 도구다. H200처럼 데이터센터에서 최대 처리량과 다중 GPU 확장을 노릴 땐 vLLM·TensorRT-LLM 같은 CUDA 계열 서빙 엔진이 표준으로 쓰인다.

맥으로 로컬에서 돌린 경험과 서버에서 H200으로 돌린 경험이 한 대화 안에서 섞이면, 속도 차이의 원인을 잘못 짚기 쉽다. 장비군을 먼저 구분하는 게 원인 진단의 출발점이다.

장비값과 전력, 그리고 렌탈 사업의 손익분기

H200은 한 장에 141GB 메모리를 얹고 700W를 쓴다. 구매가는 대당 3만~4만 달러 선이다. 클라우드 렌탈은 시간당 3.5~13달러 사이에서 업체마다 갈린다. 두 장을 상시로 돌리면 GPU 렌탈비만 하루 168~624달러, 30일이면 5040~1만8720달러 선이다. GPU 자체의 최대 TDP 합계는 두 장 기준 1.4kW다.

후속 세대인 B200과 B300은 메모리를 192~288GB까지 늘린다. 처리량도 H200 대비 3배 이상 올라간다는 벤치마크가 나와 있다. 다만 렌탈가도 그만큼 높다. 방에서 나온 vLLM 기반 운영 솔루션 사업화 아이디어는 방향 자체는 틀리지 않다.

개인 개발자가 GPU를 빌려 자체 추론 API를 운영해 기존 API 서비스보다 싸게 먹히려면 꾸준한 트래픽과 높은 GPU 활용률이 있어야 손익분기를 넘는다. 운영·모니터링에 시간이 들어간다는 점도 빠지기 쉬운 비용이다.

직접 서버를 굴려본 사람들 사이에서는 트래픽이 꾸준하지 않으면 시간 단위로 돈이 나가는 렌탈이 API 종량제보다 오히려 손해라는 반응이 많다. 트래픽이 크지 않다면 자체 서버보다 관리형 추론 서비스 쪽이 절감 효과의 상당 부분을 운영 부담 없이 가져간다는 의견은 이런 반응과 방향이 같다.

2500 TPS와 26 TPS는 거짓말도 모순도 아니었다. 서버 전체가 감당하는 합산량과 한 사람이 받는 스트리밍 속도, 다른 저울에 올라간 숫자였을 뿐이다. 그 차이에는 무엇을 재고 있었는지가 크게 작용했다.