Inference on ICE-ICE-BEAR-BLOG

DGX Spark에서 Qwen3.5-122B를 28.3에서 51 tok/s로 끌어올린 추론 최적화 레시피

Thu, 07 May 2026 00:00:00 +0900

개요

albond/DGX_Spark_Qwen3.5-122B-A10B-AR-INT4는 NVIDIA DGX Spark 단일 박스에서 Qwen3.5-122B-A10B를 28.3에서 51 tok/s까지 80퍼센트 끌어올린 레시피다. INT4 양자화, FP8 dense layer hybrid, MTP-2 speculative decoding, INT8 LM head, TurboQuant KV cache까지 다섯 가지 기법을 차례로 쌓았고 256K context도 유지된다. Apache 2.0, GitHub 별 171개. “단일 워크스테이션에서 100B급 MoE 모델을 production 수준으로 돌릴 수 있는가” 라는 질문에 대한 강한 긍정 답이다.

flowchart LR
 Base["Baseline <br/> 28.3 tok/s"] --> S1["+ Hybrid INT4+FP8 <br/> 30.8 tok/s"]
 S1 --> S2["+ MTP-2 Speculative <br/> 38.4 tok/s"]
 S2 --> V2["v2: + INT8 LM Head <br/> 51 tok/s"]
 V2 --> TQ["v2-tq: + TurboQuant KV <br/> 39 tok/s <br/> 1.4M KV"]

결과 표

구성	tok/s	향상	빌드
Baseline (vLLM 0.19 + AutoRound INT4 + FlashInfer)	28.3	—	—
+ Hybrid INT4+FP8 dense layers	30.8	+8.8%	step 1
+ MTP-2 Speculative Decoding	38.4	+35.7%	step 2
v2 (+ INT8 LM Head v2)	51	+80%	`Dockerfile.v2`
v2-tq (+ TurboQuant KV Cache)	39	+38%	`Dockerfile.v2-tq`

같은 최적화로 Qwen3.5-35B-A3B (작은 형제) 는 112 tok/s까지 올라간다.

256K Context

설정	KV Cache	256K 동시 사용자
v2 (standard)	355K tokens	1
v2-tq (TurboQuant)	1.4M tokens	5

모델 한 줄

Qwen3.5-122B-A10B는 122B 총 파라미터 중 10B만 활성화하는 hybrid MoE다. 256개 expert 중 8 routed + 1 shared, Gated DeltaNet과 Gated Attention이 12:1 비율로 교차하는 48 레이어 구조에 native 262K context (YaRN 확장 시 1M)까지 지원한다. Apache 2.0. 이 모델을 Intel AutoRound로 INT4 양자화한 Intel/Qwen3.5-122B-A10B-int4-AutoRound (group size 128, shared_expert는 ignore) 가 출발점이다.

핵심 기법

1. Hybrid INT4 + FP8 Dense Layers (+9%)

AutoRound INT4 모델의 BF16 shared expert weights를 official Qwen 체크포인트의 FP8 weights로 교체한다. 즉 expert 레이어만 INT4, dense는 FP8. 정확도를 보존하면서 메모리와 연산량을 동시에 줄인다.

2. MTP-2 Speculative Decoding (+36%)

Multi-Token Prediction 방식으로 한 번에 2 토큰을 예측한다. accept rate가 약 80퍼센트로 매우 높아 디코드 throughput이 가장 크게 점프하는 단계다. 작은 draft 모델을 따로 돌리지 않고 메인 모델 자체가 multi-head 예측을 한다는 점이 주목할 만하다.

3. INT8 LM Head v2 (Triton 커널)

LM head, 즉 최종 token vocabulary projection 레이어를 INT8로 양자화한다. Triton 커스텀 커널로 구현되며 v2 빌드에서 가장 큰 점프 (38.4 → 51 tok/s) 를 만든다. LM head는 보통 양자화 대상에서 빠지지만 vocabulary가 큰 모델일수록 영향력이 크다는 게 다시 확인됐다.

4. TurboQuant KV Cache (선택)

TurboQuant로 KV cache를 4배 압축한다. 절대 throughput은 v2 대비 약간 떨어지지만 256K context 동시 사용자가 1명에서 5명으로 늘어난다. Long-context multi-tenant 시나리오에서 의미 있는 트레이드오프다.

환경

vLLM 0.19.1, CUDA 13.0, Docker 기반
추론 엔진: vLLM 0.19 + FlashInfer
모델: Intel/Qwen3.5-122B-A10B-int4-AutoRound
./install.sh 한 번으로 Step 0~4 자동 (idempotent)

인사이트

100B급 모델을 단일 워크스테이션에서 51 tok/s로 돌린다는 건 production 응답 속도 (60 tok/s 근처) 에 거의 닿았다는 뜻이다. 별 171개 짜리 레시피 치고는 짜임새가 단단해서 벤치 표, 단계별 Docker, install.sh, vLLM/CUDA 버전 호환성까지 모두 갖췄고 그대로 따라 돌릴 수 있다. 흥미로운 건 다섯 기법이 직교한다는 점이다. Hybrid quant은 메모리/정확도, MTP는 디코딩 병렬성, INT8 LM head는 컴퓨트, TurboQuant은 KV 메모리를 각각 친다. 한 곳을 짠 게 아니라 병목을 차례로 옮기면서 합산한 결과가 80퍼센트다. 그리고 v2-tq에서 보이듯 throughput과 동시 사용자 수는 다른 축이라 워크로드에 따라 다른 빌드를 골라야 한다. 다음 분기쯤이면 이런 hybrid quant + speculative + custom kernel 스택이 vLLM/SGLang에 표준으로 들어올 가능성이 높고, “100B 모델을 한 박스에서” 가 점점 demo가 아니라 default로 바뀐다.

참고

Repo and model cards

albond/DGX_Spark_Qwen3.5-122B-A10B-AR-INT4 — 별 171, Apache 2.0
Qwen/Qwen3.5-122B-A10B — 122B/10B hybrid MoE, 262K context
Intel/Qwen3.5-122B-A10B-int4-AutoRound — INT4 group128 quantized
NVIDIA DGX Spark

Inference frameworks

Optimization techniques

LLMLingua 시리즈 — 프롬프트를 20배까지 압축하는 Microsoft의 저평가 도구

Wed, 06 May 2026 00:00:00 +0900

개요

한 토론에서 누군가 LLMLingua를 언급했고, 다른 사람이 “네 굉장히 저평가 되있다고 생각합니다” 라고 동의했다. 별 6,156개에 MIT 라이선스, EMNLP'23부터 CoLM 2025까지 6편의 논문이 이어진 시리즈인데도 운영 사례를 찾기 어려운 도구다. 압축률 20배에 거의 무손실이라는 강력한 결과가 있는데 왜 production 채택이 더디게 진행되는지 — “저평가"라는 이 한 단어를 풀어보면 연구 → 프로덕션 사이의 갭이 그대로 보인다.

graph TD
 Origin["LLMLingua <br/> EMNLP 2023"] --> Long["LongLLMLingua <br/> ACL 2024"]
 Origin --> V2["LLMLingua-2 <br/> ACL 2024 Findings"]
 Long --> MInf["MInference <br/> 2024"]
 V2 --> MInf
 MInf --> SCB["SCBench <br/> 2024"]
 SCB --> Sec["SecurityLingua <br/> CoLM 2025"]

 Origin -.->|작은 LLM으로 토큰 제거| Theme1["20x 압축"]
 Long -.->|"lost in middle 완화"| Theme2["RAG +21.4%"]
 V2 -.->|GPT-4 distill BERT| Theme3["3-6x 빠름"]
 MInf -.->|long-context prefill| Theme4["1M token 10x"]

시리즈 6편 한 표로

논문	연도	핵심 결과
LLMLingua	EMNLP 2023	작은 LLM(GPT2-small, LLaMA-7B 등)으로 비핵심 토큰 제거 → 20x 압축, 최소 성능 저하
LongLLMLingua	ACL 2024	“Lost in the middle” 완화. RAG 성능 +21.4%, 토큰 1/4로
LLMLingua-2	ACL 2024 Findings	GPT-4 distillation 기반 BERT-level encoder. 3-6x 빠르고 out-of-domain에 강함
MInference	2024	Long-context inference 가속. A100에서 1M 토큰 prefill 10배
SCBench	2024	KV cache 중심 long-context 메서드 평가 벤치마크
SecurityLingua	CoLM 2025	Jailbreak 방어. 압축 기반 보호로 SOTA 가드레일 대비 100x 적은 토큰

원논문 모음과 데모는 프로젝트 페이지 llmlingua.com 에서 모두 모아 볼 수 있다.

핵심 효과 6가지

비용 절감 — 프롬프트와 생성 길이를 동시에 단축, 압축 오버헤드는 작은 LLM 한 번 호출 정도
확장 컨텍스트 — long-context 모델 위에 얹어 “lost in middle” 완화, 같은 토큰 예산으로 더 많은 정보
추가 학습 불필요 — 본 LLM은 그대로, 앞단 압축기만 끼우는 plug-in 구조
지식 보존 — ICL(In-Context Learning) 예제와 reasoning chain 같은 핵심 정보는 유지하도록 설계
KV-Cache 압축 — 추론 메모리/지연 동시 감소
복원 가능 — GPT-4가 압축 프롬프트에서 핵심 정보를 복원할 수 있음을 실험으로 보임

사용 예시 (LLMLingua 1)

from llmlingua import PromptCompressor

llm_lingua = PromptCompressor()
result = llm_lingua.compress_prompt(
 prompt, instruction="", question="", target_token=200
)
# {
# 'compressed_prompt': '...',
# 'origin_tokens': 2365,
# 'compressed_tokens': 211,
# 'ratio': '11.2x',
# 'saving': ', Saving $0.1 in GPT-4.'
# }

quantized 모델도 지원: TheBloke/Llama-2-7b-Chat-GPTQ 사용 시 8GB 미만 GPU 메모리로 압축기를 돌릴 수 있다.

사용 예시 (LongLLMLingua RAG 모드)

compressed = llm_lingua.compress_prompt(
 prompt_list,
 question=question,
 rate=0.55,
 condition_in_question="after_condition",
 reorder_context="sort",
 dynamic_context_compression_ratio=0.3,
 condition_compare=True,
 context_budget="+100",
)

retrieved chunk를 question 조건 아래 정렬하고, 위치별로 압축률을 동적으로 조절하는 옵션들이 RAG에서 정확도를 끌어올린다.

통합

LangChain retrievers 통합 — LLMLinguaCompressor를 ContextualCompressionRetriever에 끼우기만 하면 끝
LlamaIndex node postprocessor 통합 — query engine pipeline 마지막 단계에 추가
Microsoft Prompt flow 통합 — Azure 환경에서 표준 노드로 사용 가능

인사이트

“저평가” 라는 한 단어가 정확하다. 연구 결과는 5편 6편 쌓였고, 통합도 LangChain·LlamaIndex·Prompt flow까지 다 있고, 적용하면 즉시 비용이 1/3에서 1/10으로 떨어지는데, production 사례는 의외로 적다. 이유를 추정하면 첫째, 압축된 prompt의 디버깅이 어렵다 — “왜 이 토큰이 빠졌지"를 사람이 추적하기 힘들어 회귀 테스트가 까다롭다. 둘째, 압축기로 작은 LLM을 한 번 더 돌려야 해서 latency 예산이 빡빡한 실시간 시스템에는 들이밀기 어렵다. 셋째, GPT-5나 Claude 4.x 처럼 토큰 단가가 비싼 모델이 본격적으로 깔린 지금이야말로 ROI가 분명한데, 정작 이 시점에 운영팀의 인지도가 낮다. OpenAI Privacy Filter (Reversible Tokenization) 같은 LLM 파이프라인 중간 레이어들이 같은 시기에 회자된다는 점이 결정적인데 — 압축, 가명화, 복원, KV cache 관리는 production tooling으로 분화 중이고, agentmemory + agent-skills + LLMLingua = “에이전트의 컨텍스트 관리 스택” 이 만들어지는 흐름이 보인다. 한마디로, “성능 좋은데 잘 안 쓰이는” 도구는 도구의 문제가 아니라 통합 레이어의 미성숙 문제일 가능성이 높다.

참고

Repo and demos

microsoft/LLMLingua — GitHub 본 저장소 (별 6,156, MIT)
llmlingua.com — 프로젝트 페이지 (논문, 데모, 블로그 모음)
HuggingFace LLMLingua 데모
HuggingFace LLMLingua-2 데모

Papers

Integrations