로컬 LLM을 위해 96GB VRAM을 최적화하는 데 2주를 보냈습니다. 하지만 유료 API가 여전히 승리했습니다.

불편한 진실과, 그럼에도 불구하고 최적화를 진행할 가치가 있었던 부분들에 대해 말씀드리겠습니다.

설정 (The setup)

• 4× RTX 3090 (Ampere — 네이티브 BF16 미지원), 총 96 GB VRAM, 44 코어
• 모델: Qwen3.6-35B-A3B (Q8_0, MoE) 및 Qwen3-Coder-Next (Q6_K, hybrid)
• llama.cpp 라우터 모드 + OpenWebUI
• 도달한 한계치: 초당 약 105 토큰 (tokens/second)

6%의 문제

장벽은 연산 능력이 아니었습니다. GPU 사용률(GPU utilization)이 6%에 머물렀습니다. 병목 현상은 CPU 오케스트레이션(orchestration)이었습니다. llama.cpp는 여러 GPU에 순차적으로 작업을 할당하기 때문에, 그래픽 카드들은 서로를 기다리며 시간의 94%를 유휴 상태(idle)로 보냈습니다. 여기에 VRAM을 더 추가하는 것은 이 문제에 아무런 도움이 되지 않습니다.

실제로 효과가 있었던 것들

변경 사항	효과
--ubatch-size 512	처리량(throughput) 40% 증가
KV 캐시 양자화 (KV cache quantization, Q4_0)	VRAM 4배 절약
추측적 디코딩 (Speculative decoding, n-gram)	반복적인 작업에서 2.5배 속도 향상
YaRN 로프 스케일링 (YaRN rope scaling)	컨텍스트(context)를 1M 토큰까지 확장

두 가지 사실이 저를 놀라게 했습니다:

• MoE 모델은 밀집형(dense) 모델보다 공격적인 양자화(quantization)를 훨씬 더 잘 견딥니다 — 비활성 전문가(inactive experts)는 대역폭(bandwidth)을 소모하지 않기 때문에, 양자화로 인한 타격이 덜합니다.
• 3B 활성(active)-파라미터 모델은 로컬 의사결정에는 훌륭했지만, 코드 300~400줄을 넘어가는 시점부터 일관성(coherence)이 무너졌습니다 — 단일 함수에는 적합하지만, 파일 간의 일관성을 유지하기에는 부족합니다.

원치 않았던 결론

하루 약 11 kWh의 전력 소비와 하드웨어 감가상각을 현재의 API 가격과 비교했을 때, 대화형 작업(interactive work)을 위해 로컬을 사용하는 것은 경제적으로 유리하지 않습니다. 제 일상적인 AI 워크플로우에서 가장 큰 개선은 API를 결제한 것이었습니다. 로컬은 개인정보 보호, 대량의 배치 작업(batch jobs), 또는 검열 없는 실험에는 여전히 우위에 있지만, 일반적인 클라우드 대체재로서는 그렇지 않습니다. 이것은 성능의 문제가 아니라 경제성의 문제입니다.

전체 비용 분석과 정확한 llama.cpp 라우터 설정(router configs)은 aipster.com에 정리해 두었습니다.

만약 로컬 장비(local rig) 구축을 고민 중이시라면, GLM 5.2의 오픈 웨이트 (open weights)에 대한 벤치마크 결과도 확인해 보세요. 이 결과는 집에서 어떤 모델을 돌리는 것이 가치 있는지에 대한 제 관점을 바꾸어 놓았습니다.

여러분의 GPU 사용률(GPU utilization)은 실제로 어느 정도인가요? 혹시 순차적 디스패치(sequential-dispatch) 문제를 해결하신 분이 계신지 궁금합니다.