40만 달러 랙을 24GB 그래픽카드로? ktransformers의 ‘28배’를 직접 재현해봤습니다

이 글은 MoE 모델을 자체 서빙할지 고민하는 엔지니어, 그리고 “GPU 한 장으로 거대 모델을 돌린다”는 요즘 트윗들을 어디까지 믿어야 할지 판단해야 하는 인프라 담당자를 위해 썼습니다. 결론부터 말하면, ktransformers의 트릭은 실재하고 작동합니다. 다만 화제가 된 “28배”와 “40만 달러 랙을 24GB 한 장으로”라는 문구는 각각 숨은 전제 위에 서 있습니다. 그 전제가 무엇인지, RunPod에서 GPU를 두 번 빌려 직접 측정한 기록을 공유합니다.

무엇이 화제였나

칭화대 MADSYS 연구실이 공개한 ktransformers(kvcache-ai/ktransformers, Apache 2.0, 별 1.7만 개)의 아이디어는 한 문장으로 요약됩니다. MoE 모델에서 실제로 호출되는 전문가(expert)만 GPU 근처에 두고, 대부분의 시간 놀고 있는 전문가는 CPU 메모리에 앉혀 두었다가 필요할 때 부릅니다. 이 배치로 24GB VRAM에서 DeepSeek-V3와 R1을 139K 컨텍스트로 돌리고, 표준 설정 대비 최대 28배 빠르다는 이야기가 퍼졌습니다.

트릭 자체는 거의 허무할 정도로 단순합니다. 그래서 오히려 의심스러웠습니다. 정말 공짜 점심인지, 아니면 어딘가에 청구서가 숨어 있는지 확인하려면 숫자를 직접 뽑아보는 수밖에 없었습니다.

실험 설계: 작은 모델로 메커니즘을 분리한다

DeepSeek-V3는 671B라 24GB 카드에 실을 수 없습니다. 그래서 같은 계열(MLA + fine-grained MoE)의 축소판인 Qwen3-30B-A3B(총 30B, 활성 3.3B)를 대리 모델로 삼았습니다. 목적은 벤더의 671B 숫자를 재현하는 게 아니라, “전문가를 CPU에 내려놓는다”는 메커니즘이 실제로 이득을 주는지, 준다면 그 이득이 어디서 오는지를 분해하는 것이었습니다.

측정은 두 단계로 나눴습니다. 첫째, 상용 AMD 박스에서 메커니즘 자체의 효과를 봅니다. 둘째, ktransformers가 성능의 원천이라 주장하는 Intel AMX 커널을 별도로 측정합니다.

1차: 상용 4090 + AMD에서 메커니즘을 측정하다

RunPod에서 RTX 4090(24GB)에 AMD Ryzen 9 7950X, 188GB RAM 구성을 빌렸습니다. 여기서 첫 번째 숨은 전제가 바로 드러났습니다. ktransformers의 CPU 전문가 커널은 Intel AMX 명령어에 최적화되어 있는데, 이 AMD CPU에는 AMX가 없었습니다. 그래서 ktransformers 고유 커널 대신, 완전히 같은 트릭을 구현한 llama.cpp의 --n-cpu-moe(전문가를 CPU에, 어텐션과 KV 캐시를 GPU에)로 메커니즘만 깨끗하게 쟀습니다.

Qwen3-30B-A3B를 Q4로 양자화해 세 가지 배치로 디코딩 속도를 비교했습니다.

배치	디코드 속도
모델 전체를 GPU에 (full-GPU)	261.5 tok/s
전문가는 CPU, 어텐션은 GPU (메커니즘)	12.0 tok/s
전부 CPU (CPU-only)	7.4 tok/s

여기서 두 가지가 보입니다. 메커니즘은 순수 CPU보다 1.62배 빠릅니다. 어텐션을 GPU로 올린 대가로 실제로 이득을 봤습니다. 그런데 모델이 VRAM에 통째로 들어가는 경우(Q4는 18GB라 24GB에 들어갑니다) full-GPU가 메커니즘을 22배 앞섰습니다. 다시 말해, 모델이 GPU에 들어가기만 하면 전문가를 CPU로 내려보내는 선택은 손해입니다. 이 트릭이 의미를 갖는 순간은 오직 모델이 VRAM을 넘칠 때입니다. 그때는 “12 tok/s로라도 돈다”가 가치이지, 속도 자체가 목적이 아닙니다.

2차: Intel AMX 커널의 진짜 배수를 재다

28배의 근거라는 AMX 커널을 정면으로 보려면 Sapphire Rapids 세대 Xeon이 필요했습니다. RunPod에서 H100 파드를 몇 번 띄워 CPU를 확인한 끝에, Intel Xeon Platinum 8470(AMX bf16/int8/tile 지원), 208 vCPU, 1TB RAM이 걸린 호스트를 잡았습니다.

kt_kernel 패키지는 백엔드별 커널을 모두 담고 있어서, 같은 프로세스 안에서 AMX 커널과 AVX2 커널을 동일한 BF16 가중치로 나란히 돌릴 수 있었습니다. DeepSeek-V3 규모(전문가 256개, 히든 7168)의 MoE 순전파를 두 커널로 측정했습니다.

커널 (동일 BF16, 디코드)	속도
AMX (AMXBF16_MOE)	145.5 tok/s
AVX2 (AVX2BF16_MOE)	105.5 tok/s

AMX 커널은 AVX2보다 1.38배 빨랐습니다. 분명한 이득이지만, 28배와는 거리가 멉니다. INT8 전용 타일 연산까지 쓰면 이 배수는 더 벌어질 여지가 있으나(비용 때문에 이번엔 BF16 동일 정밀도 비교까지만 했습니다) 커널 하나가 28배를 만들어내지는 않습니다.

“28배”를 분해하면

두 실험을 합치면 벤더의 28배가 어떻게 구성되는지가 보입니다. 그 숫자는 커널의 마법이 아니라, 시스템 전체를 llama.cpp의 순수 CPU 실행과 비교한 값입니다. 분해하면 이렇게 나뉩니다.

어텐션과 KV 캐시를 GPU로 올린 것이 가장 큰 지렛대입니다. 상용 AMD에서도 이 배치만으로 순수 CPU 대비 1.62배가 났고, 모델이 GPU에 들어가면 35배까지 벌어졌습니다. 그 위에 AMX 전문가 커널이 AVX2 대비 약 1.4배를 더합니다. 여기에 INT8/INT4 양자화와 파이프라인 최적화가 얹힙니다. 각 요소는 소박한 배수지만, 특정 조건에서 이것들이 곱해지면 두 자릿수 배수가 만들어집니다. 그 조건이란 모델이 VRAM을 넘치고, CPU가 AMX를 지원하며, 비교 대상이 순수 CPU llama.cpp일 때입니다.

“40만 달러를 24GB로”의 진실

이 문구는 메모리를 없앤 게 아니라 옮긴 것입니다. 우리 파드는 각각 188GB와 1TB의 시스템 RAM을 갖고 있었습니다. DeepSeek-V3를 Q4로 돌리려면 CPU 쪽에 약 380GB의 DRAM이 필요합니다. 전문가 가중치는 사라지지 않고 VRAM에서 시스템 RAM으로 자리를 옮길 뿐입니다. 그러니 정확한 표현은 “24GB GPU 한 장 + 대용량 RAM 서버”입니다. 비싸진 GPU를 값싼 RAM으로 바꾼 것이지, 총 메모리 소요가 준 것은 아닙니다. 소비자용 24GB 카드 한 장이 데이터센터 랙을 대체한다는 그림과는 결이 다릅니다.

그래서 실제로 몇 tok/s이고, 얼마인가

앞의 실험들은 메커니즘을 분해했지만, 정작 실무자가 궁금한 두 숫자를 빠뜨렸습니다. 24GB에 안 들어가는 진짜 대형 모델이 얼마나 빠르고, 돈은 얼마나 아끼는가. 그래서 24GB에도 80GB 한 장에도 안 들어가는 Qwen3-235B-A22B(Q4, 약 130GB)로 다시 쟀습니다. 오프로드가 선택이 아니라 필수인 케이스입니다.

먼저 속도입니다. 2×A100 80GB에 모델을 통째로 올리면 디코딩이 51.5 tok/s 나옵니다. 사람이 읽는 속도의 다섯 배가 넘으니 실시간 대화에 넉넉합니다. 그런데 같은 모델을 전문가만 CPU로 내리면 GPU가 쓰는 메모리는 11GB로 줄어듭니다. 235B짜리 모델이 GPU 11GB만 먹는다는 뜻입니다. 24GB는 물론이고 12GB 카드에도 올라갑니다. “24GB 한 장으로 되냐”는 질문의 답은 여기서 분명해집니다. 됩니다, 그것도 여유롭게.

문제는 그 오프로드 상태의 디코딩 속도입니다. 우리 측정 환경(RunPod 네트워크 스토리지에 130GB를 둔 구성)에서는 토큰마다 원격 저장소를 읽느라 값이 무너져서, 이 수치는 정직하게 공표하지 않습니다. 로컬 NVMe를 쓰는 실제 배포에서는 생기지 않는 병목이기 때문입니다. 대신 1차 실험에서 깨끗하게 잰 30B 오프로드가 12 tok/s였고, 활성 파라미터가 훨씬 큰 235B는 그보다 낮은 한 자릿수 초중반으로 떨어집니다. AMX 서버면 여기에 1.4배쯤 붙습니다. 정리하면 오프로드 디코딩은 실시간 대화에는 빠듯하고, 배치 처리나 에이전트처럼 지연에 덜 민감한 작업에 맞습니다.

이제 비용입니다. RunPod 실가 기준으로 토큰 100만 개당 비용을 계산하면 이렇습니다.

구성	하드웨어	시간당	디코딩	100만 토큰당
Full-GPU	2×A100 80GB	$2.98	51.5 tok/s	약 $16
Offload	4090 24GB + 대용량 RAM	$0.69	약 5~12 tok/s	약 $16~38

여기서 반직관적인 결론이 나옵니다. 오프로드는 토큰당 비용으로는 거의 아끼지 못하고, 경우에 따라 오히려 비쌉니다. 하드웨어가 다섯 배 싸지만 그만큼 느려서 토큰당으로 환산하면 상쇄되기 때문입니다. 그러니 “비용을 얼마나 세이브하느냐”에 대한 솔직한 답은, 운영비로는 별로 아끼지 못한다는 것입니다.

진짜 절약은 다른 곳에 있습니다. 초기 투자와 접근성입니다. 대당 1만 5천 달러짜리 A100 두 장을 사거나 시간당 3달러에 빌리지 못하는 팀이, 커모디티 24GB 카드 한 장과 램 넉넉한 서버 한 대로 671B급 모델을 아예 돌릴 수 있게 됩니다. 운영비를 깎아주는 도구가 아니라, “돌아가느냐 안 돌아가느냐”의 경계를 바꾸는 도구입니다.

그래서 도입해야 하나

세 가지 조건을 먼저 확인하길 권합니다. 서빙 CPU가 Intel Sapphire Rapids 이상(AMX 지원)인가. 돌리려는 모델이 GPU VRAM을 실제로 넘치는 대형 MoE(V3, R1 급)인가. 그리고 그 대형 모델을 담을 대용량 시스템 RAM이 있는가. 세 조건이 모두 맞으면 ktransformers는 값비싼 다중 GPU 없이 대형 MoE를 서빙하는 현실적인 길을 열어줍니다. 하나라도 빠지면 이득은 빠르게 줄어듭니다. 특히 모델이 GPU에 들어간다면 고민할 필요도 없이 그냥 GPU에 통째로 올리는 편이 22배 빠릅니다.

우리 관점에서 ktransformers의 진짜 가치는 “28배”라는 헤드라인이 아닙니다. 다중 GPU를 사거나 빌릴 수 없는 팀이, 대용량 RAM을 갖춘 Intel 서버 한 대와 GPU 한 장으로 671B급 MoE를 아예 돌릴 수 있게 된다는 접근성에 있습니다. 속도 챔피언이 아니라 진입 장벽을 낮추는 도구로 읽어야 맞습니다.

재현 정보

두 실험 모두 RunPod에서 진행했고, GPU 총 사용 비용은 약 5달러였습니다. 벤치 하네스(llama.cpp --n-cpu-moe, kt_kernel MoE 커널 비교)와 원시 결과 JSON은 전부 공개했습니다. 직접 재현하거나 숫자를 검증하고 싶다면 github.com/sylvanus4/ktransformers-moe-offload-bench(Apache-2.0)를 보시면 됩니다. 다음 검증 후보는 AMX INT8 서빙 경로의 실제 종단 디코딩 속도와, 진짜 ktransformers balance_serve 스택을 Sapphire Rapids 위에서 끝까지 세워보는 것입니다.