llama.cpp에서 Qwen3.8-Flash-Next 테스트: CPU 전용부터 96GB VRAM까지 (8.5~109 tok/s)

모든 GPU 테스트는 동일한 RTX PRO 6000을 사용함. 제한을 건 건 메모리 용량 테스트용이지, 저사양 GPU 성능 테스트가 아님.

1. CPU에서 모델 구동

2K 프롬프트에서 CPU 단독으로 프리필 182.64 tok/s, 디코딩 8.34 tok/s 나옴.

이 정도면 대화형 챗봇으로 쓰기엔 충분하다.

MoE 구조라 토큰당 6B 파라미터만 활성화되는 게 한몫함.

2. 긴 컨텍스트에서 VRAM 등급 간 격차 감소

2K 프롬프트에선 96GB가 24GB보다 2.796배 빨랐다.

근데 245K 프롬프트에선 그 격차가 1.451배로 줄어듦.

245,760 토큰 프롬프트에서의 디코딩 속도:

• 24GB: 14.89 tok/s

• 32GB: 15.41 tok/s

• 48GB: 16.96 tok/s

• 96GB: 21.61 tok/s

컨텍스트 길어지면 모든 설정에서 속도 저하 발생함. 원래 제일 빨랐던 놈이 성능 하락폭도 제일 큼.

48개 레이어 중 12개만 어텐션 캐시가 늘어나는 구조고, 나머지 36개는 Gated DeltaNet을 씀.

덕분에 컨텍스트 메모리는 비교적 적게 먹지만, 긴 컨텍스트 디코딩이 공짜인 건 아님.

3. 이번 빌드에서 CUDA 상의 PLE는 55.6배 느렸음

GGUF 파일 안에 레이어당 27.2 GiB짜리 토큰 임베딩 테이블이 들어있음.

두 가지 방식으로 배치해서 테스트해 봄:

• 시스템 RAM: 프리필 1,967.9 tok/s, 디코딩 108.5 tok/s

• GPU VRAM: 프리필 575.7 tok/s, 디코딩 1.95 tok/s

CUDA에 올렸을 때 디코딩 속도가 55.6배 더 느렸음.

텐서가 이동한 건 확인했는데, 속도가 왜 느려지는지 원인까지는 못 찾았다.

A-B-B-A 순서로 테스트를 반복해 봤는데, 순서에 따른 오차는 0.56% 정도였음.

메모리 데이터로도 배치가 제대로 된 걸 확인했다. 테이블을 CUDA로 옮기니까 GPU 사용량이 대략 27.5 GiB 늘어나더라.

CPU에 배치했을 때는 디코드 토큰당 대략 9.2 ms가 걸림.

CUDA에 배치했을 때는 디코드 토큰당 대략 513 ms가 걸림.

이건 단순히 연산만으로 설명하기엔 지연 시간이 너무 길다. 동기화 문제나 토큰별 전송 문제 같은데, 정확한 원인은 아직 증명 못 함.

내 결론은 이번 빌드에 한정된 거다:

per_layer_token_embd=CUDA0 설정하니까 llama.cpp b10666 버전에서 디코드 속도가 108.5에서 1.95 tok/s로 떡락함.

4. RAM 상주 로딩으로 프리필(prefill) 성능 1.87배 향상

48GB 텐서 배치 상태에서 mmap이랑 RAM 상주 로딩을 비교해 봤다.

2K 프롬프트 기준:

• RAM 상주: 746.7 tok/s prefill

• mmap 평균: 400.4 tok/s prefill

• 차이: 1.87배

디코드 비율은 0.998이라서 사실상 차이가 없었음.

사용할 옵션은 이거다:

--load-mode none

이게 파일 매핑을 안 쓴다는 뜻이지, 모델을 안 불러온다는 소리는 아님.

이 모드를 쓰려면 시스템 RAM이 충분히 비어 있어야 함.

5. KV 레이아웃 변경이 동시성(concurrency)에 미치는 영향

요청 1개부터 16개까지, 통합(unified) KV 레이아웃이랑 비통합(non-unified) KV 레이아웃을 각각 테스트해 봤다.

둘 다 요청 1개일 때는 59.0 tok/s로 시작함.

동시성 16개일 때:

• 통합 KV: 68.8 tok/s

• 비통합 KV: 92.0 tok/s

동시성이 높을 때는 비통합 KV가 전체 출력량이 더 많았다.

물론 개별 요청 속도는 여전히 느려짐. 동시성을 높이면 서버 전체 처리량은 늘어나지만, 요청 하나하나가 빨라지는 건 아님.

비통합 KV는 가용 컨텍스트를 슬롯별로 쪼개기 때문에 항상 정답인 설정은 아님.

일단 제외한 결과들

보고서에는 다음 내용도 포함되어 있음:

• 마이크로배치(Microbatch) 결과

• 추론 보존(Preserved-reasoning) 결과

• 긴 문맥 검색도 전체 범위에서 잘 돌아감.

• Q4_K_XL 비교

최종 수치는 내 저장소랑 영상에 다 올려놨음.

리소스

보고서, 스크립트, 설정, 결과, 그래프가 담긴 GitHub:

https://github.com/lukaLLM/Qwen3.8-Flash-Next-VRAM-Benchmark

전체 영상:

추신: 편집하는 동안 AI를 좀 굴렸음.

내 주된 질문은 PLE CUDA 결과에 관한 거임.

혹시 다른 GPU나 더 최신 llama.cpp 빌드에서 per_layer_token_embd=CUDA0 썼을 때 똑같이 속도 저하 겪은 사람 있음?

다른 질문은 대화에서 이전 사고 과정을 유지하는 거에 대한 거임.

똑같은 5턴짜리 코딩 대화를 돌려봤는데, 이전 추론 내용을 나중 프롬프트에 남겨둘 때랑 지울 때를 비교해 봤거든.

내용을 남겨두니까 기록이 계속 뒤에 붙는 방식이라 프롬프트 재계산 토큰 수가 18,403개에서 267개로 줄어들었음. 근데 5턴째 프롬프트가 18,387개에서 63,223개 토큰으로 늘어나면서, 디코드 속도가 65.5 tok/s에서 48.9 tok/s로 떨어지더라.

이건 temperature 1.0으로 각 경우당 딱 한 번씩만 돌린 거임. 시작 속도부터 110.2 tok/s랑 96.0 tok/s로 달랐어서, 69배니 25%니 하는 수치를 완전히 신뢰하긴 좀 그럼.

이런 트레이드오프 겪어본 사람 있음? 원래 이전 추론 내용을 남겨두는 게 프롬프트 재계산을 이 정도로 줄여주는 건지, 그리고 긴 프롬프트가 디코드 속도를 어느 정도나 깎아먹는 게 정상인지 궁금함.

아니면 이 모델 효율 더 뽑아낼 수 있는 다른 팁 있으면 공유 좀.

그렇다면 작성자가 하는 것처럼 4060과 비교하는 건 무리겠네요.

고마워, 난 사람들이 올린 깃허브랑 벤치마크 읽는 거 좋아하거든 :)