KTransformers: 거대 MoE 추론은 GPU만으로 풀 문제가 아니다

KTransformers · MoE 추론 · CPU-GPU 이기종 서빙 · SGLang

대형 오픈 모델을 실제 제품에 붙이려는 팀이 자주 놓치는 지점이 있다. 모델이 공개됐다는 사실과, 그 모델을 감당 가능한 비용·지연시간·하드웨어 조건에서 계속 돌릴 수 있다는 사실은 다르다. 특히 GLM-5.2, MiniMax-M3, DeepSeek-V3/R1, Kimi 계열처럼 sparse MoE 구조가 전면으로 오면 질문은 더 구체적으로 바뀐다. 모든 expert를 GPU에 올릴 것인가, 아니면 hot expert와 cold expert를 나눠 CPU·GPU·디스크 계층을 함께 쓸 것인가.

KTransformers가 보여주는 이기종 MoE 추론 계층

2026년 7월 21일 GitHub Trending 상위권에 오른 kvcache-ai/ktransformers는 이 질문을 꽤 노골적으로 드러낸다. README는 KTransformers를 “CPU-GPU heterogeneous computing”으로 대형 언어 모델의 효율적인 추론과 파인튜닝을 실험하는 연구 프로젝트라고 설명한다. 최신 문서 흐름도 단순한 실행 스크립트가 아니라 kt-kernel, SGLang 통합, MoE expert placement, prefix cache, LLaMA-Factory 기반 SFT까지 이어진다.

이 글의 결론은 단순하다. KTransformers를 “로컬에서 큰 모델 돌리는 도구” 정도로 보면 작게 읽는 것이다. 더 중요한 신호는 오픈 모델 경쟁이 모델 가중치 배포에서 추론 런타임·메모리 계층·expert 배치 전략 경쟁으로 이동하고 있다는 점이다.

검색 의도: KTransformers를 찾는 사람은 “설치법”보다 “큰 MoE를 어떻게 감당할까”를 묻는다

KTransformers, kt-kernel, SGLang KTransformers, GLM-5.2 inference, MiniMax-M3 local inference, MoE CPU offload 같은 검색어 뒤에는 대체로 네 가지 의도가 있다.

대형 MoE 모델을 제한된 GPU에서 돌리고 싶은 개발자
- 모든 expert를 GPU 메모리에 올릴 수 없다.
- CPU 메모리와 GPU를 섞어도 지연시간이 버틸지 알고 싶다.
SGLang/vLLM류 서빙 스택을 운영하는 인프라 팀
- OpenAI-compatible API는 유지하되, 내부 kernel·placement를 바꾸고 싶다.
- 모델별 튜토리얼과 launch parameter를 검증해야 한다.
오픈 모델을 사내 배포하려는 조직
- 외부 API로 보내기 어려운 코드·문서·업무 데이터를 내부에서 처리하고 싶다.
- GPU-only serving 비용이 너무 높다.
파인튜닝까지 고려하는 팀
- MoE LoRA SFT를 LLaMA-Factory 같은 기존 워크플로와 연결하고 싶다.

KTransformers가 흥미로운 이유는 이 네 의도를 한 번에 건드리기 때문이다. README는 2026년 6월 GLM-5.2 Day0 지원, MiniMax-M3 Day0 지원을 명시하고, kt-kernel 문서는 SGLang 통합과 CPU-optimized MoE kernels를 전면에 둔다. 즉 이 프로젝트의 핵심은 “새 모델 지원이 빠르다”가 아니라, 새 모델이 나올 때마다 추론 배치·메모리·kernel 정책을 같이 업데이트해야 한다는 현실을 보여주는 데 있다.

MoE의 병목은 “연산량”만이 아니라 “expert가 어디에 있느냐”다

Sparse MoE 모델의 매력은 모든 파라미터를 매 토큰마다 쓰지 않는다는 점이다. token은 router를 거쳐 일부 expert만 활성화한다. 이론적으로는 큰 모델 규모를 유지하면서 실제 계산량을 줄일 수 있다. 하지만 운영 관점에서는 곧바로 두 번째 문제가 생긴다.

선택된 expert가 어느 하드웨어 계층에 있느냐.

MoE expert routing과 CPU-GPU 배치

GPU 메모리가 충분하면 모든 expert를 GPU에 올리는 방식이 단순하다. 하지만 대형 MoE는 여기서 비용이 급격히 커진다. 반대로 CPU 메모리에 많은 expert를 두고, 자주 쓰는 expert만 GPU에 올리면 비용은 낮아질 수 있지만, 라우팅·전송·prefill/decode 스케줄링이 복잡해진다.

KTransformers의 kt-kernel README가 강조하는 지점이 바로 이쪽이다. 문서는 CPU-optimized MoE kernels, AVX512 native precision backend, AMX INT4/INT8 backend, llamafile CPU backend, NUMA-aware execution을 기능으로 내세운다. 쉽게 말하면 “GPU가 부족하면 느린 CPU로 대충 넘기자”가 아니다. CPU를 추론 계층의 적극적인 계산 자원으로 다루겠다는 방향이다.

이 차이는 한국 팀에게 실용적이다. 자체 GPU 클러스터가 제한적이거나, 클라우드 H100/H200 비용이 부담스럽거나, 고객 데이터를 외부 폐쇄형 API로 보내기 어려운 팀은 앞으로 이런 선택지를 보게 된다.

GPU-only serving: 단순하지만 비싸고 메모리 압박이 크다.
CPU offload: 싸질 수 있지만 kernel·NUMA·전송 병목을 관리해야 한다.
CPU-GPU heterogeneous serving: 복잡하지만 모델 선택 폭과 비용 구조가 달라진다.
Disk/CPU/GPU cache tiering: 반복 컨텍스트가 많은 workload에서만 의미가 커진다.

따라서 KTransformers의 의미는 “소비자 장비에서도 초거대 모델 가능?” 같은 낭만보다 더 운영적이다. MoE 모델을 하드웨어 계층에 맞춰 분해해서 배치하는 기술이 제품 차별화 요소가 된다는 신호다.

GLM-5.2와 MiniMax-M3 튜토리얼이 말하는 것: 모델 발표와 서빙 런타임은 분리할 수 없다

KTransformers README의 업데이트 로그에는 2026년 6월 17일 GLM-5.2 Day0 지원, 6월 21일 MiniMax-M3 Day0 지원이 올라와 있다. 이건 단순 버전 체크가 아니다. 각각의 튜토리얼을 보면 모델별 런타임 조건이 꽤 구체적이다.

GLM-5.2 튜토리얼은 SGLang과 KT-Kernel을 결합해 CPU-GPU heterogeneous inference를 실행하는 흐름을 제시한다. 예시 command에는 --kt-cpuinfer, --kt-threadpool-count, --kt-num-gpu-experts, --kt-method FP8, --kt-enable-dynamic-expert-update, --kt-expert-placement-strategy uniform, --tp-size 8, --kv-cache-dtype fp8_e4m3 같은 파라미터가 나온다. MiniMax-M3 튜토리얼도 MXFP8, 128 routed experts, Hopper 계열 GPU, CPU expert offload, OpenAI-compatible API, tool calling parser를 함께 다룬다.

SGLang과 KT-Kernel이 만나는 서빙 계층

여기서 중요한 건 parameter 이름 자체가 아니다. 모델을 “지원한다”는 말의 의미가 바뀌고 있다는 점이다.

예전에는 모델 지원이 대체로 다음을 뜻했다.

tokenizer와 model class가 로드된다.
weight format을 읽을 수 있다.
샘플 prompt에 답이 나온다.

이제 대형 MoE/agentic model에서는 부족하다. 실제 지원은 다음을 포함해야 한다.

어떤 precision으로 weight와 KV cache를 둘 것인가.
어떤 expert를 GPU에 둘 것인가.
CPU thread pool과 NUMA 정책을 어떻게 잡을 것인가.
SGLang/vLLM/Transformers 중 어떤 serving path가 안정적인가.
OpenAI-compatible API, tool calling, reasoning parser가 제품 요구와 맞는가.
prefill과 decode 단계에서 GPU/CPU 분담이 지연시간을 깨지 않는가.

KTransformers는 이 복잡성을 숨기지 않는다. 오히려 튜토리얼과 launch command로 드러낸다. 이 점이 좋다. 한국 개발팀이 오픈 모델을 검토할 때도 “모델 카드 성능”만 볼 게 아니라, 실제 서빙 command가 얼마나 구체적이고 재현 가능한가를 봐야 한다.

Prefix cache와 3계층 메모리: 반복 업무에서는 KV cache가 비용 구조를 바꾼다

KTransformers 문서에는 prefix cache 모드도 있다. 문서는 Balance serve가 GPU-CPU-Disk 3계층 구조로 KV cache를 저장하고 재사용한다고 설명한다. 설정 예시에는 GPU-only를 끄고, CPU memory size와 disk path를 지정하는 구성이 나온다.

이 기능을 과장해서 “모든 문제가 해결된다”고 말하면 안 된다. 문서에도 재컴파일, submodule 업데이트, cache 삭제 제한 같은 현실적인 제약이 보인다. 하지만 방향은 중요하다. 에이전트·RAG·코딩 작업에서는 같은 prefix가 반복된다.

시스템 프롬프트와 tool spec
조직 정책과 repository summary
제품 문서와 API 계약
긴 코드베이스 일부
반복되는 고객/업무 context

이 prefix를 매번 새로 prefill하면 GPU cycle과 TTFT가 낭비된다. 그래서 KV cache 재사용, prefix cache, 외부 cache management, engine-local prefix caching은 모두 같은 질문을 향한다. 긴 컨텍스트를 많이 쓰는 workload에서 무엇을 다시 계산하지 않을 것인가.

이전에 LMCache 같은 프로젝트가 KV cache management layer를 전면에 뒀다면, KTransformers의 prefix cache는 이기종 MoE 실행 환경 안에서 cache tiering을 다루는 쪽에 가깝다. 둘 다 결론은 비슷하다. LLM serving 비용은 모델 호출 횟수만으로 설명되지 않는다. prefill, cache hit rate, context 반복률, hardware tier가 비용을 좌우한다.

SFT까지 연결되는 이유: 추론 최적화와 학습 워크플로가 따로 놀 수 없다

KTransformers README는 inference와 함께 SFT 섹션도 분리해 보여준다. SFT Quick Start는 LLaMA-Factory 사용자가 KTransformers-backed MoE LoRA SFT를 실행하는 흐름을 제시하고, ktransformers[sft], kt-kernel, transformers-kt, accelerate-kt 같은 패키지 경계를 설명한다. 예시도 Qwen3/Qwen3.5 MoE LoRA SFT를 다룬다.

이건 단순히 “파인튜닝도 됩니다”가 아니다. 앞으로 오픈 MoE 모델을 사내에 맞추려는 팀은 세 층을 같이 봐야 한다.

모델 선택 — 어떤 base/open model을 쓸 것인가.
후처리·파인튜닝 — LoRA, DPO, domain data, tool-use data를 어떻게 넣을 것인가.
서빙 런타임 — fine-tuned checkpoint를 어떤 precision, 어떤 expert placement, 어떤 API shape로 제공할 것인가.

이 셋이 분리되면 실무에서 문제가 생긴다. 훈련은 됐는데 serving path가 불안정하거나, serving은 되는데 비용이 폭발하거나, 모델은 좋은데 tool calling parser가 제품 요구와 맞지 않을 수 있다.

KTransformers가 LLaMA-Factory와 SGLang 양쪽을 함께 언급하는 이유도 이 맥락에서 읽을 수 있다. 오픈 모델 운영은 “모델 파일 다운로드”가 아니라 훈련-추론-서빙-평가를 연결하는 내부 플랫폼 문제가 되고 있다.

한국 개발팀을 위한 실전 해석: 먼저 벤치마크할 workload를 정하라

이기종 추론 도입 판단 기준

KTransformers 같은 도구를 검토할 때 가장 나쁜 접근은 “우리도 큰 모델을 싸게 돌릴 수 있나?”라는 막연한 질문으로 시작하는 것이다. 대신 workload를 좁혀야 한다.

좋은 검토 순서는 이렇다.

대상 모델을 좁힌다
- GLM-5.2, MiniMax-M3, DeepSeek 계열, Qwen MoE 등 실제로 필요한 모델 후보를 정한다.
- 모델 카드의 benchmark보다 serving 문서와 runtime 지원 상태를 먼저 확인한다.
대표 workload 20~50개를 만든다
- 짧은 질의응답, 긴 문서 분석, tool calling, 코딩 에이전트 작업, RAG 질의처럼 제품 사용 패턴을 나눈다.
GPU-only baseline을 잡는다
- 현재 가능한 가장 단순한 vLLM/SGLang/Transformers serving path로 TTFT, tokens/s, 실패율, 비용을 측정한다.
이기종 경로를 비교한다
- GPU expert 수, CPU thread pool, precision, KV cache dtype, batch/concurrency를 바꿔본다.
운영 리스크를 따로 본다
- 설치 난이도, CUDA/driver dependency, crash recovery, observability, rollback, reproducibility를 체크한다.

KTransformers가 맞는 팀은 명확하다. GPU-only serving 비용이 너무 높고, 대형 MoE 모델을 자체 환경에서 돌려야 하며, kernel/NUMA/CUDA/serving parameter를 다룰 수 있는 인프라 역량이 있는 팀이다. 반대로 작은 모델, 낮은 트래픽, 단순 챗봇, 빠른 제품 검증 단계라면 managed API나 단순한 serving stack이 더 낫다.

리스크: 흥미로운 런타임일수록 운영 표면도 넓어진다

KTransformers류 프로젝트를 도입할 때 조심해야 할 점도 분명하다.

재현성: 모델 버전, SGLang fork, CUDA, driver, kt-kernel, Transformers 버전이 맞물린다.
하드웨어 민감도: AVX2/AVX512/AMX, Hopper, CUDA 12.x 같은 조건이 성능을 크게 바꾼다.
문서 최신성: Day0 지원은 빠르지만, 빠른 만큼 튜토리얼과 실제 wheel/version 조합이 흔들릴 수 있다.
관찰성: expert placement, CPU offload, cache hit rate, thread pool 병목을 보지 못하면 튜닝이 감으로 흐른다.
운영 책임: 자체 서빙은 데이터 통제권을 주지만 장애·보안·패치 책임도 같이 가져온다.

특히 한국 기업 환경에서는 “외부 API를 쓰지 않는다”는 장점만으로 내부 배포를 결정하면 위험하다. 내부 배포는 보안팀을 설득하기 쉽지만, 동시에 GPU 운영, 모델 업데이트, 장애 대응, 비용 추적, 사용량 제한을 모두 직접 책임져야 한다.

결론: 오픈 모델 시대의 승부처는 가중치보다 실행 계층이다

KTransformers가 지금 눈에 띄는 이유는 특정 모델 하나를 더 빠르게 돌린다는 주장 때문만은 아니다. 더 큰 의미는 대형 MoE 모델 운영의 질문을 제대로 바꾼다는 데 있다.

이제 “이 모델이 좋은가?”만 물어서는 부족하다.

이 모델은 어떤 serving runtime에서 안정적인가?
expert와 KV cache는 어떤 하드웨어 계층에 놓이는가?
긴 컨텍스트와 반복 prefix를 어떻게 재사용하는가?
GPU 비용을 낮추기 위해 CPU를 얼마나 적극적으로 쓸 수 있는가?
fine-tuning 결과물을 같은 운영 경로에 올릴 수 있는가?

KTransformers는 이 질문들에 대한 하나의 실험장이다. 한국 AI 빌더에게 실용적인 takeaway는 분명하다. 오픈 모델을 제품에 넣으려면 모델 이름보다 실행 계층의 설계 능력을 먼저 길러야 한다. 특히 MoE가 더 커지고 더 흔해질수록, 추론 인프라는 “GPU 몇 장을 샀는가”가 아니라 “계산·메모리·cache·expert를 어떻게 배치했는가”의 싸움이 된다.