저는 로컬 환경에서 두 개의 CMP 170HX 카드를 사용하여 Qwen 3.8 Flash Next를 최적화하는 작업을 진행해 왔고, 마침내 공유할 만한 결과를 얻게 되어 기쁩니다. 두 카드 모두 PCIe Gen2 x4로 구동되고 있으며, x16 모드나 TP2는 사용하지 않았습니다. 이 설정은 W4A16 AutoRound 체크포인트, 패치된 vLLM, 파이프라인 병렬 처리(pipeline parallelism), 그리고 네이티브 MTP 추측 디코딩(speculative decoding)을 사용합니다.
동시성별 디코드 처리량 (Aggregate tok/s, 사용자당 속도가 아님):
| 동시 요청 수 | 코드 JSON | 프로즈 |
|---|
| 1 | 226 | 198 |
| 2 | 363 | 320 |
| 4 | 560 | 537 |
| 8 | 840 | 873 |
동시 코드 요청이 8개일 때, 측정된 요청당 디코드 속도는 116 tok/s였으며 첫 토큰까지 걸리는 시간은 231 ms였습니다. 몇 가지 다른 결과는 다음과 같습니다:
- 4k–64k 프롬프트에 대한 프리필(prefill) 처리량: 6,300–7,100 tok/s; 128k에서는 약 5,900 tok/s.
- 프로즈 디코드는 4k 컨텍스트에서 158 tok/s를 유지하며 128k에서도 142 tok/s를 기록했습니다.
- HumanEval: 157/164 (95.7%) 및 GSM8K: 1,271/1,319 (96.4%)를 달성했으며, 둘 다 생각(thinking) 기능이 꺼진 채팅 모드에서 측정되었습니다.
- 전체 262,144-토큰 창을 사용했습니다.
처리량을 위해 sparkDash 프로토콜을 사용했는데, 이는 그리디 디코딩(greedy decoding), 생각 기능 비활성화, 고정된 400-토큰 출력, 그리고 세 번의 실행 중 중앙값(median)을 사용한 것입니다. 긴 컨텍스트 디코드 테스트는 이 프로토콜에 추가된 것입니다. 제가 찾은 어떤 공개된 2x CMP 170hx 레시피보다 빠르기 때문에 커뮤니티와 공유하고 싶었습니다. 이 카드들은 정말 잘 작동합니다 :)
전체 레시피, 고정 Docker 이미지, 패치 및 상세 결과는 다음 링크를 참고하세요: https://github.com/AlexBrandes/cmp170hx-qwen38-flash-next