GPU를 더 사는 게 유일한 답일까. 환경변수 한 줄로 추론 속도가 2~4배 뛴 팀이 있고, 모델 아키텍처를 바꿔서 동시처리를 10배 늘린 팀이 있다. 1억원짜리 증설을 검토하다가 결국 안 한 팀도 있다.
-- 환경변수 한 줄, 모델 3번 교체, 그리고 1억원짜리 질문
GPU를 더 사는 게 유일한 답일까. 환경변수 한 줄로 추론 속도가 2~4배 뛴 팀이 있고, 모델 아키텍처를 바꿔서 동시처리를 10배 늘린 팀이 있다. 1억원짜리 증설을 검토하다가 결국 안 한 팀도 있다.
금융그룹 D사. vLLM으로 대규모 언어 모델을 서빙하는 환경이었다.
이상한 일이 하나 있었다. RTX 6000이 H200보다 빠르게 나온 것이다. H200은 141GB HBM3e를 탑재한 차세대 GPU다. RTX 6000 Ada는 48GB GDDR6 워크스테이션급이다. 스펙상으로는 비교 자체가 성립하지 않는다. 그런데 추론 벤치마크에서 RTX 6000이 앞섰다.
처음엔 측정 오류를 의심했고, 다음엔 드라이버를 봤다. 원인은 의외로 환경변수 쪽에 있었다.
범인은 deepgemm이었다.
vLLM 최신 릴리스에서 기본 활성화되는 GEMM 커널이다. Hopper/Blackwell GPU(SM90+)에서 FP8 연산을 최적화하도록 설계됐는데, 특정 하드웨어-모델 조합에서 오히려 병목이 됐다. deepgemm을 비활성화하자 triton 커널이 자동으로 활성화됐다.[1]
결과:
모델Before (deepgemm)After (triton)개선30B80 tok/s150 tok/s1.9배80B40 tok/s130 tok/s3.25배235B30 tok/s60 tok/s2배
내부 성능 검증 기록 기준. vLLM 환경변수 변경 외 하드웨어 및 모델 파라미터 동일 조건.
"deepgemm이 진짜 범인이었고 그거 제거하니 속도 2~4배 개선. 모델 로딩속도도 2배 빨라졌습니다."
PM 반응:
"헉 성공하신건가요..?!"
"rtx6000이 h200보다 빨랐던 이유가 그 장비는 처음부터 triton 활성화 되어서..."
H200에서는 deepgemm이 기본 활성화 상태로 돌아가고 있었고, RTX 6000에서는 아키텍처가 달라 triton이 처음부터 활성화돼 있었다. GPU 성능 차이가 아니라 커널 선택 차이였다.
환경변수 한 줄. 코드 수정 없음. 비용 0원.
추론 엔진 설정은 즉시 적용 가능하고 되돌리기도 쉽다. GPU 증설은 분기 단위다. GPU를 더 사기 전에, 지금 있는 GPU를 제대로 쓰고 있는지부터 확인해야 한다.
(이하 사례들은 실제 운영 환경에서 반복되는 패턴을 기반으로 구성했고, 고객사명과 담당자명은 익명이다. 기술적 수치는 당사 엔지니어링 팀의 내부 성능 검증 기록에 근거하며, 해당 고객사의 하드웨어 환경에 한정된 관측치다.)
제조사 E. H100 서버를 운영 중이었다. 비전-언어 모델과 텍스트 모델을 분리 서빙하는 구성이었는데, 텍스트 모델 쪽에 H100 2장을 할당하고 있었다.
신규 요구사항이 들어왔다. Qwen3.5-122B를 도입할 수 있느냐는 거다. 122B -- MoE 아키텍처로 전체 파라미터 122B, 활성 파라미터는 훨씬 적지만, GPU 메모리에는 전체 파라미터를 올려야 한다. MoE의 특성이다. 메모리 절약은 아니고, 연산 절약이다.
AI팀 답변이 올라왔다.
"122b 모델은 h100 2장엔 못 올라가거나 간신히 올라만 가는 정도일 것 같습니다."
H100 80GB 2장 = 160GB VRAM. 122B 모델을 FP16으로 올리면 약 244GB가 필요하다. FP8 양자화를 적용해도 122GB -- 160GB 안에 간신히 들어가지만, 서빙에 필요한 KV 캐시와 운영 오버헤드를 고려하면 사실상 불가다. 올라만 가는 것과 운영 가능한 것은 다르다.
매니저가 정리했다.
"우선 122b는 gpu 모자라서 더 작은 모델로 골라야할것 같다고 말하고 의견 들어볼까요?"
대안으로 나온 게 Qwen3.5-35B-A3B다. 전체 35B, 활성 3B의 MoE 모델이다. 이 모델은 뒤에서 다시 나온다.
문제는 비용이었다. GPU 단가만 H100 SXM5 기준 $27,000~$40,000. 2장이면 $54,000~$80,000(약 7,000만~1억원). 여기에 서버 본체(CPU, RAM, SSD, PSU) $15,000~$30,000, 인프라(네트워킹, 냉각, 랙) $17,000~$70,000이 붙는다. 총합 $86,000~$180,000. 원화로 약 1.1억~2.3억원.[2]
클라우드였으면 인스턴스를 하나 추가하면 된다. 온프레미스에서는 품의서 올리고, 견적 받고, 발주하고, 납기 기다리고, 설치하고, 테스트한다. 이 과정이 최소 수 주에서 수 개월이다. "일단 GPU 추가하지" -- 이 "일단"이 분기 단위다.
그래서 모델을 바꾸는 쪽으로 갔다.
금융사 C. 같은 H100 2장 환경에서 AI 에이전트를 운영하고 있었다. 이 고객사는 2편에서 PII 마스킹과 GPU 리소스가 충돌하던 곳이다. 이번에는 비용과 성능 쪽에서 이야기한다.
처음 올린 모델은 GPT-OSS-120B. 에이전트 성능(도구 호출, 추론 정확도)은 괜찮았다. 문제는 동시 처리였다.
"GPT-OSS-120B 모델 동시 처리 성능 분석 결과... 동시 처리 수는 1~3건 정도 밖에 안되네요."
P99 TTFT(Time To First Token)가 100건 동시 요청 기준 333초까지 올라갔다. 5분 넘게 기다려야 첫 글자가 나온다.
120B 모델이 H100 2장(160GB)을 거의 전부 점유하고, 동시 요청이 들어오면 KV 캐시가 비집고 들어갈 자리가 없다. 한 명이 쓸 때는 괜찮다. 두 명부터 줄 서기 시작한다. 사내 수십 명이 쓸 시스템에서 동시 처리 1~3건은 사실상 1인용이다.
크기를 줄이면 동시 처리가 늘어난다. 당연한 산술이다. Qwen2.5-72B를 FP8로 올리면 약 72GB -- 160GB 안에 여유가 생기고, 동시 배치를 늘릴 수 있다.
그런데 에이전트 성능 쪽에서 걸렸다.
"저희가 qwen2.5-72b 로 확정 하고 에이전트 구현을 깎아내려가는 방식으로 한다면?"
"그 모델은 이젠 옛날 모델이라 에이전트 성능 깎기가 쉽지 않을 것 같긴 합니다."
도구 호출(tool calling)이 약했다. 에이전트가 외부 도구를 불러야 하는 순간에 실패율이 올라간다. 벤치마크 점수에서는 드러나지 않는 부분이다. 2024년 말 기준으로 이미 Qwen2.5 시리즈는 에이전트 태스크에서 후속 모델에 밀리고 있었다.
Qwen3.5-35B-A3B. 제조사 E에서도 대안으로 나왔던 그 모델이다.
MoE(Mixture of Experts)를 비유하면 종합병원이다. 256명의 전문의가 상주하지만, 환자 한 명이 들어오면 접수 데스크(게이팅 네트워크)가 증상을 보고 해당 분야 전문의 8~9명에게만 배정한다. 나머지 전문의는 대기 상태다. Dense 모델은 모든 의사가 모든 환자를 함께 진료하는 구조다.[3]
Qwen3.5-35B-A3B -- 전체 파라미터 35B, 전문가 256개, 토큰당 활성화되는 전문가 8개 + 공유 전문가 1개. 활성 파라미터 3B. 전체의 약 1/10만 매 추론에 동원된다.[4]
GPU 메모리에는 35B 전체를 올려야 한다. FP16 기준 약 70GB. H100 2장(160GB) 안에 들어가고, KV 캐시 여유도 충분하다. 그런데 실제 연산은 3B 수준이다. 같은 GPU에서 훨씬 더 많은 동시 요청을 처리할 수 있다는 뜻이다.
모델H100 GPU동시 처리P99 TTFT (100건)GPT-OSS-120B2장1~3건333초Qwen3.5-35B-A3B2장25~50건 (SLO 기준)81초
내부 성능 검증 기록 기준. 동일 H100 2-GPU 환경, vLLM 서빙.
1~3건에서 25~50건. 동시 처리가 10배 넘게 뛰었다. P99 TTFT는 333초에서 81초로 -- 여전히 긴 편이지만, 100건 동시라는 극단적 부하 기준이고, 실 운영 범위(25~50건)에서는 SLO를 충족한다.
"에이전트 서비스 기준으로 안정적인 동시 처리는 SLO에 따라 25~50건 정도로 보는 게 적절할 것 같습니다."
성능은? Qwen3.5-35B-A3B는 MMLU-Pro 85.3으로 GPT-5-mini(83.7)를 앞서고, 도구 호출(BFCL-V4) 67.3 대 55.5, 에이전트 태스크(TAU2-Bench) 81.2 대 69.8로 격차를 보인다.[4] 활성 파라미터 3B짜리 모델이 GPT-5-mini와 대등하거나 앞서는 영역이 있다. MoE의 경제학이 여기서 드러난다.
vLLM 버전이 문제였다. 기존 환경은 vLLM 0.11.0. Qwen3.5 MoE를 서빙하려면 최소 0.17.1이 필요하다. 폐쇄망이다. pip install --upgrade 한 줄이면 끝나는 게 아니다. 의존성 패키지를 전부 오프라인으로 가져와야 한다.
모델 파일도 마찬가지다. 35GB짜리 모델 파일을 폐쇄망 안으로 물리적으로 반입해야 한다. USB, 외장 하드, 샤드 분할 zip -- 보안 절차를 거쳐서.
GPU 증설 대신 모델 전환을 택한 건데, 모델 전환에도 고유한 비용이 따른다. 추론 엔진 업그레이드, 파이프라인 재검증, 에이전트 동작 테스트, 폐쇄망 물리 반입. 돈이 안 드는 게 아니라, 돈 대신 엔지니어링 시간을 쓰는 것이다.
증설에 대한 논의도 있었다.
"혹시나 GPU 증설도 가능한지를 같이 문의하려고 하는데..."
"괜히 증설 이야기해서 실제로 증설됐을 때 성능에 대한 기대치가 좀 많이 높아지지 않을까 생각했습니다."
GPU를 증설하면 경영진은 "이제 됐지?"라고 기대한다. 그런데 GPU를 2배로 늘린다고 성능이 2배가 되는 건 아니다. 모델 병렬화의 통신 오버헤드, 배치 스케줄링의 비효율, 그리고 무엇보다 -- 모델 자체의 아키텍처 한계. 1억원짜리 증설 이후에 "그래서 뭐가 좋아졌어요?"라는 질문에 명확하게 답할 수 있어야 증설을 요청할 수 있다.
벤치마크를 보면 이런 숫자가 나온다. MMLU 90점, HumanEval 80점, BFCL 67점. 이건 "혼자 쓸 때" 성적이다.
현장에서 나오는 질문은 다르다. "25명이 동시에 쓸 때, 첫 응답이 10초 안에 나와?" 이 질문은 벤치마크 논문 어디에도 없다.
VRAM을 많이 먹을수록 KV 캐시 공간이 줄고, 동시 배치 수가 줄어든다. 120B가 H100 2장을 꽉 채우면, 사실상 한 명씩만 서빙할 수 있다.
MoE에서 핵심이다. 35B 전체를 메모리에 올리지만, 실제 연산은 3B만 한다. 연산이 가볍다는 건 다음 요청을 더 빨리 처리할 수 있다는 뜻이다. RTX 3090 1장 기준으로 MoE 모델은 168 tok/s, 같은 품질의 Dense 모델은 41 tok/s -- 4.1배 차이다.[5]
vLLM의 PagedAttention은 KV 캐시 메모리 단편화를 줄여서 유효 배치 크기를 높인다. 기존 구현 대비 2~4배 처리량 향상.[1] 여기에 HOOK에서 본 커널 선택(deepgemm vs triton)이 또 2~4배를 좌우한다.
이 세 축이 하나의 트레이드오프 매트릭스를 이룬다.
정확도 (모델 크기)
△
/ \
/ \
/ \
/ \
───────────
비용 동시처리
(GPU 수) (응답속도)
정확도를 올리려면 큰 모델이 필요하고, 큰 모델은 GPU를 더 먹고, GPU를 더 먹으면 동시처리가 줄어든다. 반대로 가면 비용은 아끼지만 정확도가 떨어진다. MoE처럼 아키텍처 자체를 바꾸면 이 고리를 끊을 수 있다.
금융사 C가 걸어온 경로를 이 매트릭스 위에 놓으면:
경로비용효과대가GPU 증설1억원+확실하지만 기대치 리스크경영진 기대치 관리 필요SW 최적화 (커널 전환)0원2~4배 개선하드웨어·모델 조합에 따라 효과 다름모델 다운사이징 (MoE 전환)엔지니어링 비용동시처리 1~3 → 25~50건vLLM 업그레이드, 폐쇄망 반입, 파이프라인 재검증
시작점을 못 잡겠으면:
- 동시 사용자 10명 미만이고 정확도가 최우선이면 → 큰 모델 유지 + GPU 증설 검토 - 동시 사용자 50명 이상이고 비용 제약이 있으면 → MoE 모델 전환 우선 - 어디서 시작할지 모르겠으면 → 먼저 추론 엔진 설정(커널, 배치, 캐시)을 점검. 0원이다.
여기서 놓치기 쉬운 숫자가 하나 있다. 모델 선택이 비용에 미치는 영향은 생각보다 크다. GPT-4급 대형 모델 API 호출 비용은 요청당 약 $0.09. 30B 이하 소형 모델은 $0.0004. 225배 차이다.[6] 온프레미스에서 MoE 모델을 자체 운영하면 이 격차가 곧 인프라 투자 회수 기간이 된다. 30B 미만 모델의 온프레 운영은 3개월 내 손익분기에 도달하는 경우가 많다는 분석도 있다.[7]
"어떤 모델이 가장 똑똑한가"는 두 번째 질문이다. 첫 번째 질문은 "우리 GPU에서 이 모델이 동시 몇 명을 SLO 안에 서빙할 수 있는가"다. 이 숫자가 나와야 모델 선택이 경영 판단이 된다.
세 가지 사례에서 반복적으로 돌아온 질문들이다. AI 플랫폼 벤더를 만나든, 내부 AI팀과 논의하든, 이 다섯 가지에 답이 있는지 확인해야 한다.
1. "이 모델, 우리 GPU에서 동시 N명 기준 p95 응답시간이 몇 초인가요?" PoC에서 1명이 쓸 때 빠른 모델이, 운영에서 50명이 쓸 때도 빠르다는 보장은 없다.
벤치마크 점수(MMLU, HumanEval)가 아니라 운영 성능이다. 동시 사용자 수와 SLO를 명시한 성능 데이터를 요구해야 한다. 없으면 PoC에서 직접 측정해야 한다. 제조사 E는 이 질문에서 시작해서 122B가 불가하다는 판단을 내렸다.
2. "GPU 증설 없이 소프트웨어 최적화만으로 개선 가능한 부분은?" GPU를 추가 구매하면 분기 단위가 걸린다. SW 최적화는 당장 다음 주에 가능하다.
금융그룹 D사는 환경변수 한 줄로 2~4배를 끌어냈다. 추론 엔진 커널 선택, PagedAttention 설정, 배치 스케줄링 튜닝 -- 하드웨어에 돈을 쓰기 전에 소프트웨어에서 짜낼 수 있는 여지가 있다. "없다"고 답하는 벤더는 의심해도 된다.
3. "모델 업그레이드 시 추론 엔진 호환성은?" 모델만 바꾸면 될 것 같지만, 추론 엔진·의존성·파이프라인 전체가 따라 움직인다.
금융사 C가 Qwen3.5-35B-A3B로 전환할 때, vLLM 0.11.0에서 0.17.1로 올려야 했다. 폐쇄망이면 이 각각을 오프라인으로 가져와야 한다.
4. "MoE 같은 경량화 아키텍처를 지원하나요?" 활성 파라미터 3B로 GPT-5-mini급 성능을 내는 모델이 이미 나오고 있다.[4] 에이전트 태스크(도구 호출, 다단계 추론)에서는 오히려 앞선다. 이런 모델을 서빙할 수 있는 추론 엔진과 파이프라인이 준비돼 있는지.
5. "폐쇄망에서 모델 업데이트 프로세스는?" 모델은 6개월마다 세대가 바뀐다. 업데이트를 못 하면 빠르게 뒤처진다.
35GB 모델 파일을 USB에 담아 보안 절차를 거쳐 물리 반입한다. 추론 엔진 업그레이드 패키지도 오프라인으로 가져온다. 이 프로세스가 정의돼 있고, 테스트된 적이 있는지.
이 다섯 가지 중 3개 이상에 명확한 답이 없으면, GPU를 얼마나 사든 운영에서 막힐 가능성이 높다.
GPU·모델·추론 엔진은 독립 변수가 아니다. 하나를 바꾸면 나머지 둘이 흔들린다.
당신의 GPU에서 지금 어떤 커널이 돌고 있는지, 몇 명이 동시에 쓸 때 SLO가 깨지는지 -- 이 숫자를 아는 팀과 모르는 팀 사이에 1억원 이상의 차이가 난다.
다음 편 예고 -- GPU와 모델 이야기는 결국 하나의 전제 위에 서 있다. 모델이 제대로 작동한다는 전제. 하지만 벡터 차원이 잘리면서 검색 품질이 무너지고, Reasoning 모델이 도구 호출을 방해하고, 다른 사용자의 문서가 검색 결과에 섞이는 일들이 현장에서 벌어진다. 다음 글에서는 RAG와 에이전트가 부딪히는 "눈에 보이지 않는 함정"을 다룬다.
온프레미스 AI 구축, 어디서부터 시작해야 할지 고민이신가요?
Allganize는 금융·공공·제조 등 다양한 산업에서 폐쇄망 AI 플랫폼을 구축하고 운영한 경험을 보유하고 있습니다. PoC부터 운영까지, 이 글에서 다룬 문제들을 함께 해결합니다.
→ 도입 상담 요청하기
이 글의 사례들은 온프레미스 AI 구축 엔지니어링 팀의 운영 경험에서 추출했습니다. 고객사명과 담당자명은 모두 익명입니다.
출처 - [1] vLLM Triton Attention Backend Deep Dive, vLLM Blog, 2026-03-04; vLLM DeepGEMM Benchmarks, GitHub vllm-project/vllm - [2] IntuitionLabs GPU Pricing Guide, 2025; Cyfuture H100 Server Price 2025; GMI Cloud H100 Cost Analysis, 2025 -- H100 SXM 2-GPU 시스템 $86K~$180K (환율 1,300원 기준 약 1.1억~2.3억원) - [3] IBM, "What is Mixture of Experts?"; NVIDIA MoE Glossary; Maximilian Schwarzmuller, "MoE vs Dense LLMs" - [4] Qwen Team, "Qwen3.5-35B-A3B", Hugging Face, 2025~2026 -- 전문가 256개, 활성 파라미터 3B, BFCL-V4 67.3 (GPT-5-mini 55.5), TAU2-Bench 81.2 (GPT-5-mini 69.8) - [5] Local LLM Bench: MoE vs Dense, ure.us -- RTX 3090 기준 MoE 168 tok/s vs Dense 41 tok/s (커뮤니티 벤치마크 기준, 비공식) - [6] Nebius, "Choosing Between Large and Small Models", 2024.10 -- GPT-4급 $0.09/req vs 소형 $0.0004/req (225배) (클라우드 서비스 업체 자체 분석, 2024년 GPT-4 기준 가격) - [7] "On-Premise LLM Cost-Benefit Analysis", arXiv:2509.18101, 2025 (프리프린트, 미피어리뷰)
📩 현장에서 실제로 마주친 AI 인프라 이야기, 다음 편도 받아보고 싶다면:
