r/LocalLLaMA•26일 전•49•55

2x3090 + DDR4 환경에서 Qwen3.8-Flash-Next: 전문가 캐시 PR 적용 후 디코드 속도 17 → 25-29 t/s 달성

Qwen3.8-Flash-Next on 2x3090 + DDR4: 17 → 25-29 t/s decode with the expert cache PR

핵심 요약

llama.cpp의 전문가 캐시 PR을 활용해 듀얼 3090 환경에서 Qwen3.8-Flash-Next의 디코드 속도를 크게 향상시킨 사례 공유.

전문가 캐시 PR — GPU 기반 LRU 캐시를 통해 VRAM 효율을 높여 디코드 속도 개선함.
ubatch 최적화 — ubatch를 2048에서 512로 줄여 VRAM을 확보하고 캐시 슬롯을 추가함.
성능 향상 — 261k 컨텍스트 환경에서 디코드 속도가 17 t/s에서 최대 29 t/s까지 상승함.
하드웨어 설정 — 듀얼 RTX 3090과 대용량 DDR4 RAM을 조합하여 모델을 효율적으로 구동함.

다들 3090 한 장 쓰거나 통합 시스템 쓰는 것 같길래 참고하라고 수치 좀 공유함.

내 현재 세팅: 2x RTX 3090 (PCIe 3.0), 듀얼 Xeon E5-2696 v4, 188 GB 사용 가능 (192GB) DDR4-2133 LRDIMM, llama.cpp, unsloth UD-Q6_K_XL. 48개 expert 레이어 전부 호스트 RAM에 박아두고 나머지는 GPU에 올림. 261k 컨텍스트 풀로 땡기고 f16 KV 사용.

이전: 26k 프롬프트에서 디코드 약 17 t/s, 프리필 약 350 t/s, 131k 깊이에서 디코드 12 t/s.

현재: 짧거나 중간 컨텍스트에서 디코드 25-29 t/s, 131k에서 약 17 t/s, 프리필은 거의 그대로임. 파이썬 코딩 프롬프트로 측정함.

뭐가 바뀌었냐면: PR #27861, GPU 상주 LRU expert 캐시를 썼음. expert 레이어 전체를 VRAM에 처박는 대신, 레이어별로 최근에 쓴 expert만 캐싱하는 방식임. 모델이 토큰 하나 뽑을 때 고르는 expert들이 바로 직전 수십 개 토큰에서 고른 거랑 거의 겹치거든. 그래서 코드 작업할 땐 적중률 80-85% 나오고, 산문 쓸 땐 더 높음. 핵심은 캐시에 VRAM을 할당해준 거임. 그리고 ubatch를 2048에서 512로 낮추니까 GPU당 약 5GB를 확보할 수 있었음(컴퓨트 버퍼가 ubatch에 비례해서 커짐). 덕분에 풀 컨텍스트에서 레이어당 슬롯을 80개에서 135개로 늘림. 대신 긴 프롬프트에서 프리필이 좀 느려지는데, 짧은 프롬프트는 별 영향 없음.

그리고 내 환경에서 아무 효과 없거나 오히려 성능 깎아먹은 것들: 스레드 개수, poll, CPU 마스크, q8 KV, lazy PLE, 산문에서의 n-gram drafts, temp 0.7에서의 MTP(배치 검증할 때 호스트 RAM에서 expert를 다시 읽어와야 해서, greedy 방식이나 아주 깊은 컨텍스트 아니면 손해임), 스텝당 2회 이상의 캐시 업로드(PCIe 3.0 대역폭 다 잡아먹어서 적중률 개박살남).

따라 해보고 싶으면 내 포크 버전 필요 없고, 그냥 마스터 브랜치에 해당 PR만 합치면 됨:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
git fetch origin pull/27861/head:pr-27861 && git merge pr-27861
cmake -B build -DGGML_CUDA=ON && cmake --build build -j

LLAMA_ATTN_ROT_DISABLE=1 numactl --interleave=all build/bin/llama-server -m Qwen3.8-Flash-Next-UD-Q6_K_XL-00001-of-00006.gguf \
  -ngl 99 -c 261888 --parallel 1 -fa on \
  -ot "ffn_(gate|up|down)_exps\.weight=CUDA_Host,per_layer_token_embd\.weight=CPU" \
  --numa distribute -t 16 -tb 44 -b 4096 -ub 512 -ctk f16 -ctv f16 \
  --moe-expert-cache 135

캐시 크기는 KV랑 컴퓨트 버퍼 빼고 남는 VRAM에 맞춰서 잡으면 됨. Q6 기준으로 GPU당 슬롯 하나에 100MB 정도 잡히더라. 다음엔 UD-Q4_K_XL 테스트해 볼 예정이고, MTP도 쓸만해지면 다시 건드려 볼 생각임. Daniel PR 계속 지켜보는 중.

나랑 비슷한 세팅 쓰는 놈들이 많을 것 같진 않은데, 혹시 도움 될까 해서 올림. 시도해 볼 만한 방법이나 궁금한 거 있으면 물어봐라.

원문

커뮤니티 목록

r/LocalLLaMA•26일 전•49•55

2x3090 + DDR4 환경에서 Qwen3.8-Flash-Next: 전문가 캐시 PR 적용 후 디코드 속도 17 → 25-29 t/s 달성

Qwen3.8-Flash-Next on 2x3090 + DDR4: 17 → 25-29 t/s decode with the expert cache PR

핵심 요약

llama.cpp의 전문가 캐시 PR을 활용해 듀얼 3090 환경에서 Qwen3.8-Flash-Next의 디코드 속도를 크게 향상시킨 사례 공유.

전문가 캐시 PR — GPU 기반 LRU 캐시를 통해 VRAM 효율을 높여 디코드 속도 개선함.
ubatch 최적화 — ubatch를 2048에서 512로 줄여 VRAM을 확보하고 캐시 슬롯을 추가함.
성능 향상 — 261k 컨텍스트 환경에서 디코드 속도가 17 t/s에서 최대 29 t/s까지 상승함.
하드웨어 설정 — 듀얼 RTX 3090과 대용량 DDR4 RAM을 조합하여 모델을 효율적으로 구동함.

다들 3090 한 장 쓰거나 통합 시스템 쓰는 것 같길래 참고하라고 수치 좀 공유함.

이전: 26k 프롬프트에서 디코드 약 17 t/s, 프리필 약 350 t/s, 131k 깊이에서 디코드 12 t/s.

현재: 짧거나 중간 컨텍스트에서 디코드 25-29 t/s, 131k에서 약 17 t/s, 프리필은 거의 그대로임. 파이썬 코딩 프롬프트로 측정함.

따라 해보고 싶으면 내 포크 버전 필요 없고, 그냥 마스터 브랜치에 해당 PR만 합치면 됨:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
git fetch origin pull/27861/head:pr-27861 && git merge pr-27861
cmake -B build -DGGML_CUDA=ON && cmake --build build -j

LLAMA_ATTN_ROT_DISABLE=1 numactl --interleave=all build/bin/llama-server -m Qwen3.8-Flash-Next-UD-Q6_K_XL-00001-of-00006.gguf \
  -ngl 99 -c 261888 --parallel 1 -fa on \
  -ot "ffn_(gate|up|down)_exps\.weight=CUDA_Host,per_layer_token_embd\.weight=CPU" \
  --numa distribute -t 16 -tb 44 -b 4096 -ub 512 -ctk f16 -ctv f16 \
  --moe-expert-cache 135

나랑 비슷한 세팅 쓰는 놈들이 많을 것 같진 않은데, 혹시 도움 될까 해서 올림. 시도해 볼 만한 방법이나 궁금한 거 있으면 물어봐라.

주요 댓글

r/localllama

사용자들이 작성자의 GPU 기반 전문가 캐시 PR을 직접 빌드하여 적용해 본 결과, 디코드 속도에서 상당한 성능 향상을 경험했다는 긍정적인 반응이 주를 이룹니다.

그 정도 퀄리티면 27b 모델이랑 비교했을 때 어떤가요? 이 서브레딧은 다들 성능(속도) 얘기만 하고 정작 결과물에 대한 얘기는 별로 없는 것 같아요. 저도 듀얼 3090 쓰는데 램이 64GB라 여유 공간이 20GB 정도밖에 안 돼요. 램 업그레이드할 가치가 있을지 고민되네요.

Flash(Q4)랑 27B 모델 사이에 지능 차이가 느껴지긴 합니다. 근데 미미해요. 저는 27B Q4 에이전트 6개를 각각 40t/s로 병렬 실행할 수 있는데(혹은 1개 80t/s), Flash는 1개 병렬에 30-40t/s 수준이라 대부분의 경우 지능 차이가 속도 차이를 정당화하지 못하네요.

난 VRAM이 8GB밖에 안 되는데 램은 많아서, 27B 모델보다 flash 모델이 훨씬 빠르더라고. 그래서 적당한 크기의 희소 모델(sparse model)을 정말 좋아해. 최근까지 내가 제일 좋아하던 모델 크기는 80B-A3B였어.

그리고 flash 모델에서 expert 개수를 8개로 줄이면 정확도 손실은 아주 미미한데, 포워드 패스당 약 1B 파라미터만큼의 대역폭을 아낄 수 있어서 진짜 좋아. 특히 DDR4는 대역폭이 그리 높지 않으니까.

그냥 궁금해서 묻는 건데, q8 에이전트 2개 돌리는 거랑 비교해서 q4 에이전트 6개를 돌릴 때 어떤 용도로 쓰는지 궁금함.

정확히 짚으셨네요. 대부분의 사용 사례에서 지능 차이가 디코더 속도 차이를 정당화할 만큼 크지 않죠.

내가 읽어본 바로는(그리고 내 첫 경험으로도 확인된 것 같지만): Flash는 같은 결론에 도달하는 데 필요한 decode 토큰이 2~3배 적음. 동의함?

동의함. 속도는 숫자로 딱 떨어지니까 비교하기 쉽지만, 모델을 실제로 자주 쓸 거라면 결국 중요한 건 실제 품질 차이임. 듀얼 3090 환경이라면 램에 돈 쓰기 전에 27B 모델이랑 3.8B 모델을 먼저 나란히 놓고 비교해 볼 것 같음.

아직 메인 워크플로우에 써보진 않았는데, 테스트 삼아 코딩 프롬프트 몇 개 던져봤더니 솔직히 아주 잘함. 경험상 3.8B 27B 모델보다 생각하는 시간도 짧음. 처음엔 속도가 너무 처참해서 품질 테스트부터 바로 들어갈 엄두가 안 났음.

듀얼 3090에서 고양자화로 풀 스피드가 나오는 27B 모델과 비교했을 때, 지능(에이전트 능력 및 일반 지식) 측면에서 감수할 만한 가치가 있나요?

저는 q4kxl로 돌리는데, nvfp4 27b랑 비교하면 제 워크플로우에서 에이전트 성능 차이가 확실히 느껴져요. 고민하는 시간도 적고, 올바른 도구 호출을 더 빨리 찾아내고, 27b보다 작업 시간이 전반적으로 짧아요. 속도는 1/4 수준인데도요. 지금은 27b를 서브 에이전트로 쓰고 있습니다.

와, 당신이 쓴 내용을 Qwen 3.8에 넣고 현재 모델 설정에 적용할 수 있는지 물어봤거든. 그랬더니 디코드 속도가 140%나 올랐어. 5090에 192GB 램 쓰고 있어.

적용 전: 50k 컨텍스트 21.3 t/s, 100k 15.5 t/s, 154k 14.2 t/s.
적용 후: 50k 46.9 t/s, 100k 38.3 t/s, 154k 34.5 t/s.
Flash next q4 4.27bpw 혼합 양자화 모델 사용 중이야. 당신이 뭘 썼는지는 모르겠지만, 진짜 대단하네.

대박이네! 실례지만 물어볼게. 내 PR 브랜치를 직접 빌드한 거야, 아니면 순정 master에서 -ot 규칙을 실행한 거야? 에이전트한테 뭘 했는지 물어보고 여기 붙여넣어 줘도 돼, 상관없어.

물어보는 이유는 master에서는 mmap이 켜져 있으면 명시적인 CUDA_Host 타겟이 자동으로 일반 CPU로 다운그레이드되거든. 그게 바로 이 PR이 해결하려는 버그야. 그러니까 만약 master를 썼다면 성능 향상은 있었겠지만, 그건 고정(pinning) 때문이 아니라 전문가 배치(expert placement) 자체에서 온 거라 좀 다른 문제거든.

원문r/LocalLLaMA