Qwen3.8 27B 모델을 단일 AMD Radeon AI PRO R9700으로 구동 (262K 컨텍스트 및 반백만 토큰 재사용 캐시)

요약: Qwen3.8 27B 모델을 단일 AMD Radeon AI PRO R9700(32 GB, 300 W)에서 구동할 때, 추측 디코딩(speculative decoding)과 당사의 3-bit 가중치(전체적인 3-bit 양자화가 아님. 아래 참조)를 사용하여 새로운 코딩 모드에서 569,878 토큰의 재사용 캐시를 유지합니다. 모든 요청은 262,144 토큰의 컨텍스트를 받으며, 두 개의 전체 길이 요청을 한 번에 처리할 수 있습니다. 코딩 에이전트는 매 턴마다 전체 대화를 다시 전송했지만, 이제는 새로운 부분만 읽습니다. 이후 에이전트 턴은 최대 12배 더 빨리 시작되고, 전체 에이전트 세션은 약 6배 더 빠르게 완료되며, 서버가 이미 읽은 258K 토큰 문서는 이전에는 134초 걸리던 것이 이제는 2.7초 만에 반환됩니다. 디코딩 속도와 정확도는 이전 출시 버전과 거의 차이가 없습니다. 4-bit를 선호하십니까? MXFP4는 한 명령어 거리입니다. '3-bit요? 패스.' 좋습니다. 실제 내용은 다음과 같습니다.

이것은 전체적인 3-bit 양자화가 아닙니다: 대규모 투영 행렬(large projection matrices)만 3-bit입니다: MLP, 어텐션 및 순환(Gated DeltaNet) 투영에 사용되는 24.3B의 27B 매개변수입니다. 128개의 가중치 블록 각각이 자체 스케일을 가지며, 총 가중치당 약 3.1비트를 사용합니다. 다른 모든 것은 3-bit가 아닙니다: 임베딩(embeddings), 출력 헤드(output head), 정규화(norms) 및 기타 순환 레이어 매개변수는 당사의 MXFP4 출시 버전에서 가져왔습니다. 행렬은 양자화 전에 회전됩니다: 이 회전 과정은 일반적으로 낮은 비트 가중치를 손상시키는 이상치(outliers)를 분산시킵니다. 그런 다음, 허가된 라이선스의 약 293K 토큰 데이터로 GPTQ-보정(GPTQ-calibrated)을 거칩니다. 토큰 생성은 8-bit (FP8) 활성화로 실행됩니다. 프롬프트 읽기는 회전된 행렬에 대해 4-bit 활성화를 사용합니다 (

어떤 것을 교환하든, 동일한 카드에서 기본 65K 모드: MXFP4(run-mxfp4.sh) 3비트(run-3bit.sh) 디코딩, 단일 스트림 집계 156.1 tok/s, 8 요청 428.0 tok/s 카드에 KV 캐시 174,634 토큰, 가장 긴 요청 200,000 (220,000 테스트), 한 번에 접두사 캐시를 이용한 에이전트용 200,000 토큰, 단일 요청 GSM8K 5-shot (1,319) 95.68, HumanEval pass@1 (164) 95.12, MMLU-Pro 서브셋 (1,400) 62.57 또한 질문당 두 가지를 FP8 캐시로 페어링했습니다. 오직 MMLU-Pro 간에만 노이즈를 벗어나는 차이가 있었습니다 (−2.9 포인트, 95 % CI −4.8에서 −0.9). 지식 회상(knowledge recall)은 더 적은 비트의 일반적인 비용입니다. 수학과 코드는 노이즈 범위 내에 머물렀습니다. 따라서 MMLU-Pro의 2~3점은 15% 더 많은 속도, 2.25배의 캐시, 그리고 요청당 262K 컨텍스트를 제공합니다. 만약 지식 회상이 가장 중요하다면 MXFP4를 실행하세요: 여전히 존재하며, 여전히 가장 정확한 옵션이며, 동일한 다운로드를 사용합니다. 3비트 가중치(weights)는 9.55 GB 추가 모듈이므로, 두 가지 모두 실행하여 스스로 판단할 수 있습니다. r/ROCm에서 요청하셨습니다: 더 많은 컨텍스트. 저희 r/ROCm 스레드에서 여러분은 더 많은 컨텍스트를 요청했습니다. 자, 이제 한 카드에 반백만 토큰의 캐시와 모든 구성(GSM8K, HumanEval, MMLU-Pro, 니들 테스트)에 대해 수 시간 동안 정확한 실행을 할 수 있게 되었으며, 본질적으로 이전 릴리스와 동일한 속도입니다. 이전 릴리스 (2 Oct) 이 릴리스, --mode long-kv4 재사용 가능한(접두사 캐시된) 토큰을 4비트 모드에서 0 (접두사 캐시 없음) 요청당 토큰 수 262,144 한 번에 전체 길이의 요청 1 디코딩, 단일 스트림 174.3 tok/s 집계, 8 요청 462.4 tok/s 첫 번째 토큰까지 걸리는 시간, 짧은 프롬프트 (p50) 86.7 ms GSM8K / HumanEval / MMLU-Pro 95.53 / 92.07 / 60.57 저희 이전 릴리스의 FP8 --mode long은 이미 접두사 캐시를 가지고 있었으며, 281,665 토큰을 보유했습니다. 새로운 4비트 코딩 모드는 약 두 배 더 많은 양을 캐싱합니다. 실행 방법: git clone https://github.com/Eliovp-BV/paiton-vllm-plugin && cd paiton-vllm-plugin # README에 표시된 대로 PAITON_* 모델 경로를 설정하세요 (이미 설정되어 있나요?

단순히 git pull) bash models/Qwen3.8-MXFP4-DFlash2/run-3bit.sh --mode long-kv4 에 접속하세요. 에이전트를 http://127.0.0.1:18982/v1 로 지정합니다. 모델 이름은 Qwen3.8이며, API 키는 어떤 것이든 작동하고 컨텍스트 창은 262,144 토큰입니다. 이미 3비트 가중치를 실행 중인가요? 새로운 다운로드는 없습니다. 런처가 새 컨테이너를 고정하며 첫 시작 시 Docker가 이를 가져옵니다. 모든 모드는 README에 있습니다. 새로운 엔진이 아닙니다. 이것은 플러그인이 추가된 기본 vLLM입니다: 동일한 OpenAI 호환 서버, 동일한 API, 그리고 이미 사용하던 동일한 도구와 워크플로우를 가집니다. 다시 배울 것도 없고, 마이그레이션할 것도 없습니다. 저희는 상위(upstream) vLLM을 따르는 새로운 준비된 컨테이너를 계속 게시할 것입니다. 각각은 배포되기 전에 동일한 전체 검증(속도, 정확도, 장문 컨텍스트)을 거칩니다. 직접 아무것도 구축하지 않고도 상위 개선 사항을 얻을 수 있습니다. 한 명령어만으로 서비스가 가능합니다. 코딩 에이전트에게 미치는 영향: 접두사 캐시(prefix cache)가 없으면 서버는 매 턴마다 전체 프롬프트를 다시 읽습니다. 250K 토큰에서는 첫 토큰까지 약 2분이 걸립니다. 이제 완료된 요청은 공간이 필요할 때까지 캐싱되며, 20번째 턴은 변경된 내용만 읽고, 저희 세션에서는 프롬프트 토큰의 91–92 %가 캐시에서 왔습니다. 워크로드 (3비트, 생각하는 중 오프): 이전 4비트 모드 (접두사 캐시 없음) --mode long-kv4 더 빠른 20턴 대화 (50K에서 253K 토큰으로 증가), 전체 세션 1,237초 vs 204초, 6.1배… 첫 토큰까지 평균 대기 시간, 2–20턴 63.6초 vs 7.8초, 8배× 100K 토큰 레포를 공유하는 3개 에이전트, 각 5턴, 전체 세션 655초 vs 111초, 5.9배… 첫 토큰까지 평균 대기 시간, 후반 턴 84초 vs 7.0초, 12배× 258K 토큰 문서에 대한 새로운 질문 이미 읽은 134초 vs 2.7초, 49배× 258K 토큰 문서의 캐시된 답변이 콜드 리드와 정확히 일치했습니다. 속도 세부 정보 (BetterBench, 전체 20회 패스 실행): 단일 스트림 내에서 디코딩 시 0.5% 개선; 8개 요청 사용 시 +3.5% (4개 사용 시 -2.5%); 첫 토큰까지의 시간은 변동 없음. 새로운 장문 프롬프트는 약 3% 느리게 읽고, 짧은 프롬프트는 7–13% 느립니다(0.1초 분량).

이것은 후속 요청이 캐시에서 가져올 수 있는 모든 프리필(prefill) 단계를 끝낼 때의 비용입니다. 정확도 (탐욕적 디코딩, 질문당 쌍): 코딩 모드는 이전 릴리스와 노이즈 범위 내에 있으며, 512K 모드는 코딩 모드와 노이즈 범위 내에 있습니다. MXFP4 이전 릴리스 (3비트) --mode long-kv4 --mode long-512k GSM8K 5-shot (1,319) 95.68 95.53 95.45 HumanEval pass@1 (164) 95.12 92.07 92.68 MMLU-Pro subset (1,400) 62.57 60.57 59.93 옵트인: 단일 요청에서 524,288 토큰을 사용하려면 --mode long-512k가 모델의 공식적인 장문맥 스케일링으로 위치 범위를 확장합니다. 이 스케일링은 이 모드의 모든 요청에 적용되므로, 단일 요청이 262K를 초과해야 할 때만 사용하십시오. 300K와 500K 토큰에서 각각 4/4개의 심어진 사실을 발견했습니다. 콜드 리드는 300K에서 158초가 걸리고 500K에서는 약 6분이 걸립니다. 후속 질문은 캐시에서 2.8–4.4초가 걸립니다. 캐시는 594,290 토큰을 보유하며, 가중치 디코딩(weighted decode)은 0.6% 이내입니다 (한 번의 실행에서 채팅 카테고리는 16% 더 느렸습니다). 변경되지 않은 MXFP4 (run-mxfp4.sh)는 여전히 존재하며 가장 정확한 옵션입니다. --vision은 기본 65K 모드와 --mode long에서 작동합니다 (최대 245K 토큰의 컨텍스트를 가진 이미지). 이전 릴리스는 하나의 --image 플래그만 있으면 됩니다 (README 참조). 솔직히 말해서 주의사항: 시스템 RAM: 코딩 및 512K 모드는 임베딩 테이블을 위해 2.4 GiB의 시스템 RAM을 고정하며, 16 GB의 RAM이면 충분합니다 (테스트됨). 총 RAM이 약 13.5 GiB 미만일 경우, --mode long-kv4는 테이블을 GPU에 유지하고 451,879 토큰을 캐시합니다. 여전히 요청당 262K와 접두사 캐시를 얻을 수 있습니다. --mode long-512k는 RAM이 필요합니다. 콜드 리드: 258K 토큰 프롬프트의 첫 번째 읽기는 여전히 2분이 넘게 걸립니다. 캐시는 프롬프트 시작 부분이 동일한 한(동일 시스템 프롬프트, 상단에 타임스탬프 없음) 두 번째 요청부터 도움이 됩니다. usage.prompt_tokens_details.cached_tokens는 모든 히트를 보여줍니다. Vision은 아직 코딩 또는 512K 모드에는 없습니다. 긴 컨텍스트를 가진 이미지를 사용하려면 --mode long --vision을 사용하십시오.

RAM/SSD 캐시 계층: 접두사 캐시(prefix cache)를 위한 실험적인 시스템 RAM 계층(--host-cache-gib, 그 뒤에 SSD 계층이 있음)은 더 많은 컨텍스트를 카드 밖으로 흘려보냅니다. 현재는 FP8 --mode long과 함께 작동하며, 4비트 코딩 모드 지원은 다음 릴리스에서 제공될 예정입니다. 코딩 모드의 569,878 토큰 GPU 캐시는 오늘날 작동합니다. 에이전트-세션 번호와 정확도 열은 이러한 구성의 프리릴리즈 빌드를 기반으로 측정되었으며, README에 모든 숫자가 있습니다. 저희 테스트벤치는 오래된 CPU, 제한적이고 느린 메모리(16GB)를 사용하므로, 여러분의 결과는 아마 훨씬 더 좋을 것입니다! 다음 계획: 더 많은 GPU. 더 많은 R9700이 곧 출시될 예정이며, 저희는 다음으로 텐서 병렬성(tensor parallelism)을 목표로 합니다 (그리고 다른 모델들도). 다른 사람들도 다중 카드 설정에 대해 작업하고 있으니, 그 부분에서 건강한 경쟁을 기대해 주세요. 집에서 AMD를 사용하는 모든 분들에게 좋을 것입니다! 더 보기: Paiton은 /u/evp-cloud가 제출했습니다 [링크] [댓글들]