혼합 GPU로 Qwen3.8 27B의 262k 문맥 실행

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 RTX 4090 노트북 GPU와 Thunderbolt 4로 연결한 XTX 7900을 CUDA·Vulkan 혼합 구성으로 묶어 Qwen3.8-27B-UD-Q6_K_XL을 262,144 토큰 문맥에서 실행했습니다. `draft-mtp`와 ngram 기반 추측 디코딩을 켜자 생성 속도는 약 16~17t/s에서 26~28t/s로 올랐고, Prefill은 CUDA와 장치 분할 조정으로 376에서 573까지 높아졌습니다. 다만 MTP가 다중 GPU ubatch 파이프라인을 깨뜨려 Prefill을 크게 낮추고, `llama-bench`의 개선이 실제 `llama-server`에서 재현되지 않는 설정도 있어 두 경로를 분리한 검증이 필요했습니다. 작성자는 문맥을 줄여 XTX 비중을 늘리는 전략이 3% 이하의 이득에 그친 반면 262k 문맥 유지의 가치가 더 크다고 판단했습니다.

주요 논점

01찬성소수

작성자는 고가의 단일 GPU를 추가하지 않고 기존 RTX 4090 노트북과 XTX 7900을 결합해 대형 문맥 모델을 실행하는 구성을 긍정적으로 평가했습니다. Thunderbolt 4 연결도 실제 사용이 가능한 수준이며, 문맥 용량을 유지하는 편이 소폭의 분할 최적화보다 가치가 높다는 판단입니다.

02중립소수

추측 디코딩은 생성 단계에서 큰 이득을 냈지만 다중 GPU Prefill 손실과 CUDA 수용률 저하가 함께 나타났습니다. 따라서 설정의 효과는 단일 수치가 아니라 Prefill, 생성, 문맥 길이, 실제 서버 경로를 분리해 판단해야 한다는 결론입니다.

합의점 vs 논쟁점

합의점

실제 배포 경로인 `llama-server`에서 설정을 재검증하지 않으면 `llama-bench`의 개선 수치를 그대로 적용하기 어렵습니다. 고정된 프롬프트와 생성 길이로 두 경로를 따로 측정해야 설정 변경의 효과를 확인할 수 있습니다.
Thunderbolt 4가 병목을 만들더라도 이 구성에서는 XTX 7900을 보조 GPU로 활용할 수 있는 수준의 생성 성능이 나왔습니다. 문맥을 줄여 GPU 분할을 바꾸는 전략은 약 3% 이하의 이득에 그쳤습니다.

논쟁점

MTP를 켜면 생성 속도는 50~70% 높아졌지만 다중 GPU 구성에서 Prefill이 크게 낮아졌습니다. 작성자는 이를 llama.cpp의 다중 GPU ubatch 파이프라인 문제로 보았지만, upstream 수정 전에는 구성별 손실 규모를 일반화하기 어렵습니다.
CUDA와 Vulkan의 성능 차이는 작업 종류에 따라 반대 방향으로 나타났습니다. 4090은 Prefill에서 우세했지만 XTX 7900은 생성과 깊은 문맥 디코드에서 우세했으며, MTP 수용률도 CUDA 41%와 Vulkan 64%로 달랐습니다.

실용적 조언

다중 GPU 설정은 `-dev CUDA0,Vulkan2`처럼 실제 장치 분할을 지정하고, `-ts 40,60`을 기준으로 문맥을 보존한 뒤 작은 비중 조정의 효과를 확인하는 편이 안전합니다. 작성자의 측정에서는 분할 비율을 5포인트씩 바꿔도 변화가 약 2%에 그쳤습니다.
추측 디코딩을 적용할 때는 생성 속도만 보지 말고 Prefill과 MTP 수용률을 별도로 기록해야 합니다. 이 구성에서는 MTP와 ngram 조합이 생성 속도를 크게 높였지만 다중 GPU Prefill을 거의 절반으로 낮췄습니다.
`llama-bench`에서 얻은 개선은 반드시 고정된 프롬프트와 생성 길이를 사용하는 실제 `llama-server` A/B 테스트로 확인해야 합니다. `-b 4096`처럼 벤치마크에서는 9% 개선돼도 실제 서버에서는 0%가 될 수 있습니다.
양자화 KV cache를 사용할 때는 `-ctk q8_0 -ctv q8_0`처럼 K와 V 타입을 맞추고 Flash Attention을 활성화해야 합니다. K/V 타입을 섞으면 조용한 커널 대체로 Prefill이 4~13배 떨어질 수 있습니다.

섹션별 상세

작성자는 RTX 4090 노트북 GPU와 Thunderbolt 4로 연결한 XTX 7900을 함께 사용해 40GB VRAM 환경을 만들고, Qwen3.8-27B-UD-Q6_K_XL의 Q6 양자화 모델을 262,144 토큰 문맥으로 실행했습니다. `llama-server`에서 CUDA0과 Vulkan2를 40 대 60으로 분할하자 생성 속도가 약 16t/s에서 27t/s로 올랐고, Prefill은 376에서 573으로 증가했습니다. Q8 KV cache는 약 190k 수준이던 사용 가능 문맥을 262k까지 늘렸지만 실제 서버에서 Prefill은 7.5%, 생성은 9%가량 낮아지는 비용이 있었습니다.

MTP와 ngram 기반 추측 디코딩은 생성 속도를 17t/s에서 26~28t/s로 높였고, 복사 중심 요청에서는 수용률 100%일 때 85t/s까지 치솟았습니다. 반면 다중 GPU layer split에서는 Draft 토큰을 따라잡는 디코드 단계가 ubatch 파이프라인을 깨뜨려 Prefill이 900대에서 500대로 떨어졌으며, 단일 GPU의 1.03~1.22배 대비 분할 구성에서는 1.8~2.0배의 지연 배수가 측정됐습니다. 작성자는 이 동작을 llama.cpp 이슈로 제출했고, CUDA에서 MTP 수용률이 Vulkan의 64%보다 낮은 41%였다는 별도 측정도 함께 제시했습니다.

두 GPU의 역할은 동일하지 않았습니다. 22k 토큰 콜드 프롬프트 Prefill에서는 4090이 34% 빨랐지만, 추측 디코딩을 끈 생성에서는 XTX 7900이 27% 앞섰고 98k 깊이의 생성에서는 2.5배 빠른 결과를 냈습니다. 문맥을 줄여 XTX에 더 많은 비중을 주는 조정은 성능을 3% 이하만 높였으므로, 작성자는 문맥 길이를 유지하는 40 대 60 분할을 선택했습니다.

작성자는 `llama-bench` 결과와 실제 `llama-server` 결과가 다를 수 있다는 점을 고정된 22k 토큰 입력과 생성 길이, 2회 반복으로 확인했습니다. `-b 4096`은 llama-bench에서 9% 개선됐지만 실제 서버에서는 변화가 없었고, `-ub 1024`와 `2048`은 다중 GPU Prefill에서 각각 13%와 31% 저하를 일으켰습니다. 혼합 KV 타입은 자동 커널 대체로 Prefill이 4~13배 무너졌고, q8_0 K/V 타입은 서로 일치해야 했습니다.

이미지 분석

Screenshot
화면 중앙에는 `llama-server` 실행 결과와 Prefill, Prompt 처리량, 생성 토큰 수, 생성 속도, Draft 수용률, 지연 시간이 표 형태로 배치돼 있습니다. 아래 런타임 그래프와 오른쪽 GPU·메모리·온도 패널은 두 장치가 작업 중 어떤 상태였는지 추적하는 데 쓰이며, 본문의 40 대 60 장치 분할과 추측 디코딩 측정 결과를 보조합니다.
다중 GPU 실행 설정, 모델과 문맥 옵션, Prefill·생성 속도 표, 런타임 텔레메트리와 작업 로그를 한 화면에 표시한 벤치마크 대시보드입니다.

Screenshot
상단에는 세션 진행률과 요청 활동 그래프가 있고, 중간에는 시간에 따른 Prompt 토큰과 생성 토큰의 변화가 표시됩니다. 하단 표는 요청별 모델, 입력 토큰, Prompt 처리량, 생성 토큰, 생성 속도와 지연 시간을 나눠 기록해 단일 벤치마크가 아닌 실제 서버 세션의 변동성을 확인하게 합니다.
세션 전체 요청 수, 입력·생성 토큰 추이, 요청별 처리량과 지연 시간을 기록한 실행 모니터링 화면입니다.

용어 해설

추측 디코딩(Speculative Decoding): — 작은 Draft 모델이나 MTP 헤드가 다음 토큰 후보를 먼저 만들고, 주 모델이 여러 후보를 한 번에 검증하는 추론 방식입니다. 후보가 많이 채택될수록 생성 단계의 반복 계산을 줄여 초당 토큰 수를 높이지만, 장치 구성과 수용률에 따라 Prefill 비용이 커질 수 있습니다.
프리필(Prefill): — 입력 프롬프트 전체를 모델에 넣어 KV cache를 처음 계산하는 단계입니다. 긴 문맥에서는 입력 토큰을 처리하는 병렬 연산량과 GPU 간 통신이 병목이 되며, 이 글에서는 22k 토큰 프롬프트 기준 처리 속도를 고정해 설정별 차이를 비교했습니다.
KV 캐시(KV Cache): — Transformer가 이미 처리한 토큰의 Key와 Value를 저장해 이어지는 생성에서 같은 계산을 반복하지 않도록 하는 메모리 구조입니다. 저장 형식과 정밀도가 문맥 길이와 속도를 함께 좌우하며, q8_0 KV cache는 262k 문맥을 가능하게 했지만 실제 서버에서 Prefill과 생성 속도를 일부 낮췄습니다.
Flash Attention: — Attention 계산에서 중간 행렬의 메모리 왕복을 줄이고 타일 단위로 연산하는 구현입니다. 이 설정에서는 양자화된 KV cache를 사용하려면 Flash Attention이 필요했고, `-fa 0`으로 끄면 컨텍스트 생성 단계에서 실행되지 않았습니다.

코드 예제

bash

llama-server -m Qwen3.8-27B-UD-Q6_K_XL.gguf -c 262144 -ngl 999 -fa on \
-ctk q8_0 -ctv q8_0 --spec-type draft-mtp,ngram-map-k4v --spec-draft-n-max 3 \
--spec-draft-device CUDA0 --split-mode layer -dev CUDA0,Vulkan2 -ts 40,60 \
--jinja -fitt 256

Qwen3.8-27B-UD-Q6_K_XL을 262,144 토큰 문맥으로 실행하면서 CUDA와 Vulkan 장치를 40 대 60으로 나누고 MTP·ngram 기반 추측 디코딩과 q8_0 KV cache를 함께 활성화하는 실행 명령입니다.

언급된 도구

llama-server추천

Qwen3.8-27B-UD-Q6_K_XL을 다중 GPU, 긴 문맥, 추측 디코딩 설정으로 실행하고 실제 서버 성능을 측정하는 데 사용했습니다.

llama.cpp중립링크

MTP의 다중 GPU Prefill 손실과 CUDA 수용률 문제를 추적하고 upstream 이슈를 제출하는 기반으로 사용했습니다.

LLM-Tuner추천링크

모델 선택, 실행 설정 저장, 실시간 성능 모니터링, 벤치마크 이력 관리와 A/B 테스트를 위한 개인용 GUI 도구입니다.

언급된 리소스

GitHubllama.cpp 이슈 #27428

GitHubLLM-Tuner