하이브리드 Mamba-Transformer 실측 — Qwen3.5-9B의 캐시는 Qwen3-8B의 4.4분의 1, 그리고 저희 속도 수치를 믿으면 안 되는 이유

하이브리드 Mamba-Transformer 실측 -- Qwen3.5-9B의 캐시는 Qwen3-8B의 4.4분의 1, 그리고 저희 속도 수치를 믿으면 안 되는 이유

하이브리드 Mamba-Transformer 첫 글은 논문 세 편을 근거로, 2026년의 수렴 -- 4분의 3은 linear 레이어, 4분의 1은 어텐션 -- 이 훨씬 작은 추론 캐시와 더 빠른 장문 디코딩을 산다고 주장했습니다. 논문에서 "full KV 캐시의 ~25%"와 "추론 속도 ~2~3배"를 인용했습니다. 이 글은 첫 번째 주장을 저희가 통제하는 하드웨어에서 검증하고, 두 번째 주장은 왜 *부분적으로만* 검증할 수 있는지 조심스럽게 설명합니다.

설정: Qwen3.5-9B(32 레이어: Gated DeltaNet 24 + full attention 8, full_attention_interval=4) 대 Qwen3-8B(36 레이어 전부 어텐션), 둘 다 bf16, A100 80GB 한 장, 배치 1, 컨텍스트 2K~64K 토큰, HuggingFace Transformers 5.16 + flash-linear-attention Triton 커널. 캐시 -- 어텐션 레이어의 키/값 텐서, linear 레이어의 순환·컨볼루션 상태 -- 는 GPU 메모리를 읽는 게 아니라(그러면 로짓이 섞입니다) 캐시 객체 안의 모든 텐서를 합산해서 잽니다.

1. 캐시: 64K에서 4.4배 작고, 4.6배로 수렴한다

숫자가 정확히 분해된다는 점이 기분 좋은 부분입니다.

트랜스포머: 36 레이어 × KV 헤드 8 × 헤드 차원 128 × (K+V) × 2바이트 = 토큰당 147 KB. 61,839 토큰 → 8.49 GB. ✓

하이브리드: 어텐션 레이어 8개만 컨텍스트에 비례해 커집니다. KV 헤드 4 × 헤드 차원 256 × 2 × 2바이트 = 토큰당 32 KB. Gated DeltaNet 24 레이어는 컨텍스트와 무관한 *고정 크기* 상태를 갖습니다 -- 레이어당 32헤드 × 128 × 128 순환 행렬 + 폭 4 컨볼루션 버퍼, bf16으로 총 약 25 MB. 그러니 캐시 ≈ 25 MB + 32 KB × 토큰 수. 61,839 토큰에서 1.94 GB. ✓

두 가지가 따라 나옵니다. 점근 비율은 147 / 32 = 4.6배이지 레이어 수 8/32에서 나오는 "4배"가 아닙니다 -- Qwen3.5는 KV 헤드도 더 적기 때문입니다. 그리고 짧은 컨텍스트에서는 비율이 낮습니다(2K에서 2.4배). 고정 linear 상태의 비중이 크기 때문이고, 하이브리드는 작은 고정 비용을 먼저 내고 컨텍스트가 길어질수록 점점 더 이깁니다. 첫 글의 "~25%"는 오히려 보수적이었습니다.

서빙에서 중요한 숫자는 이것입니다. 64K 컨텍스트에서 A100 한 장은 Qwen3-8B 7개 시퀀스를 담는 메모리로 Qwen3.5-9B 약 30개 시퀀스를 담습니다. 이게 하이브리드의 실제 상품입니다.

2. 속도: 무엇을 쟀고, 왜 그게 답이 아닌가

정직해야 할 부분입니다. HuggingFace eager 모드에서 프리필과 디코드도 쟀습니다.

순진하게 읽으면 하이브리드가 프리필에서 *지고* 디코드에서 비깁니다. 그 읽기는 틀렸고, 왜 틀렸는지 정확히 이해할 가치가 있습니다. 새 아키텍처를 연구 프레임워크에서 벤치마크하는 사람이라면 누구나 빠지는 같은 함정이기 때문입니다.

• 둘 다 ~25 tok/s인 디코드는 모델이 아니라 Python 루프입니다. A100은 llama.cpp나 vLLM에서 8B 모델을 130~150 tok/s로 디코드합니다. HuggingFace eager 디코드는 스텝당 프레임워크 오버헤드에 묶이고, 그 오버헤드는 두 아키텍처에 동일합니다. KV 대역폭 차이를 볼 해상도가 측정에 남아 있지 않습니다.
• 하이브리드의 프리필은 트랜스포머와 달리 커널에 묶여 있습니다. 트랜스포머의 어텐션은 수년간 다듬어진 PyTorch fused SDPA 커널로 돕니다. Gated DeltaNet 레이어는 flash-linear-attention의 Triton 커널로 도는데, 이 머신의 CUDA 12.1 툴체인으로는 causal-conv1d를 빌드하지 못해 컨볼루션이 느린 경로로 떨어집니다. 첫 2K 실행이 42초 걸렸는데 거의 전부 Triton 컴파일이었습니다. 하이브리드의 프리필 처리량은 8K에서 64K로 가며 *두 배 이상*(746 → 3,519 tok/s) 오르고 트랜스포머는 *떨어지는데*(9,877 → 5,400) -- 이론이 예측하는 선형 대 이차 형태 그대로입니다 -- 64K에서도 하이브리드는 트랜스포머의 65%입니다. 아키텍처가 아니라 커널 성숙도 때문입니다.

그러니 이 실험은 메모리 주장을 확인하고, 속도 주장은 확인도 반박도 못 합니다. 공정한 속도 비교에는 두 경로 모두에 프로덕션 커널이 있는 서빙 엔진이 필요합니다 -- vLLM이 올봄 Qwen3.5 하이브리드 지원(어텐션 레이어에는 TurboQuant까지)을 추가했고, 그게 다음에 돌릴 후속입니다.

최대 메모리에 대한 메모 하나, 저희도 놀랐기 때문입니다. 64K 프리필 중 최대 할당량은 하이브리드가 *더 높았습니다*(47.7 GB vs 41.7 GB). 이것도 아키텍처가 아닙니다. Qwen3.5의 어휘는 248K 토큰이고 Qwen3는 152K인데, HuggingFace는 프리필 중 모든 위치의 로짓을 실체화합니다: 61,839 × 248,320 × 2바이트 ≈ 30 GB. 서빙 엔진은 절대 그러지 않습니다.

3. 첫 글에서 바뀐 것

저희 프레이밍에 대한 정정 하나. 첫 글은 절약이 "75% linear 레이어"에서 온다고 설명했습니다. Qwen3.5-9B에서 더 큰 지렛대는 어텐션 레이어 8개가 Qwen3-8B의 8개 대신 KV 헤드 4개를 쓴다는 점입니다. 레이어당 절약의 절반은 하이브리드 분할이 아니라 GQA 폭입니다. 모델 계열을 가로지르는 아키텍처 비교는 늘 여러 결정을 한 묶음으로 담고 있고, 위의 캐시 산수가 그것을 푸는 방법입니다.

4. 재현

python -m venv ~/venvs/hybrid && ~/venvs/hybrid/bin/pip install torch==2.9.1 --index-url https://download.pytorch.org/whl/cu128
~/venvs/hybrid/bin/pip install "transformers>=5.9" flash-linear-attention
CUDA_VISIBLE_DEVICES=0 python bench-hybrid-hf.py --model Qwen/Qwen3-8B   --out hybrid-hf.json
CUDA_VISIBLE_DEVICES=0 python bench-hybrid-hf.py --model Qwen/Qwen3.5-9B --out hybrid-hf.json

스크립트(첨부)는 past_key_values에서 닿을 수 있는 모든 텐서의 numel × element_size를 합산합니다. 한 모델의 캐시는 K/V 텐서의 DynamicCache이고 다른 모델은 순환 상태를 들고 다닐 때, 같은 잣대로 캐시 크기를 얻는 유일한 방법입니다.

참고 자료

• Part 1: Hybrid Mamba-Transformer MoE -- 세 팀, 하나의 아키텍처
• Hugging Face의 Qwen3.5 모델 카드와 config(layer_types, full_attention_interval)
• flash-linear-attention -- Gated DeltaNet용 Triton 커널
• vLLM PR #39931 -- 후속에서 쓸 하이브리드 모델 지원