Qwen 3.8 Flash Next에 대한 지난 게시물 이후, 많은 분들이 out-of-core MoE 스트리밍이 DeepSeek V4.1 Flash (1017)와 같은 실제 최첨단 모델에서 작동할 수 있을지, 아니면 프롬프트 처리(PP) 때문에 완전히 사용 불가능해질지에 대해 질문하셨습니다.
그리고 아닙니다. 우리는 Strata의 IQ2_XS처럼 작고 기능이 제한된 모델인 Qwen 3.8 Flash Next를 구동하는 것이 아닙니다.
우리는 DeepSeek V4.1 Flash Q8_XL을 305.6+110.6GB로 사용 가능한 속도로 구동하고 있으며, 향후 버전에서는 더 많은 성능을 짜낼 수 있도록 시도할 예정이며, 현재는 sm_86에서 가장 잘 작동합니다.
모든 사람이 SSD/하이브리드 계층에서 대규모 MoE를 구동할 때 가장 불만을 느끼는 부분은 Time To First Token (TTFT)입니다. 500 토큰짜리 프롬프트를 보내면, 엔진이 단 하나의 토큰을 출력하기 위해 그 프롬프트를 처리하는 데만 3060초 동안 13 tok/s의 속도로 머뭇거립니다.
지난 며칠 동안 저는 같은 예산의 게이밍 PC에서 DeepSeek V4.1 Flash를 인터랙티브한 속도로 구동할 수 있는지 알아보기 위해 Betelgeuse (bel-cli / bel-server)에 대한 작업을 진행했습니다:
GPU: RTX 3060 12GB
RAM: 16GB Single-Channel DDR4-3200
OS: CachyOS / Arch Linux (엄격한 MemoryMax=12G cgroup 제한, 스왑 0B에서 테스트)
Storage: PCIe 4.0 NVMe SSD
빌드 및 설정
저는 고정밀도의 Q8_XL 전문가 백본(expert backbone)을 IQ4_NL Engram 테이블과 결합하여 사용하고 있습니다 (DeepSWE에서 72.3점 기록).
110 GB의 Engram 테이블은 전적으로 NVMe SSD에 저장됩니다. 왜냐하면 Engram은 레이어 1 및 14에서만 활성화되고 토큰당 48개 행(약 192 KB)만을 건드리기 때문에, 활성 행들을 t=0 시점에 아주 작은 2MB VRAM 버퍼로 직접 스테이징하여 110 GB 파일이 RAM을 거의 사용하지 않고 CPU 그래프 분할을 일으키지 않게 하기 때문입니다.
프리필(PP) 병목 현상을 해결한 방법:
표준 구현에서, 오프로딩과 함께 대규모 MoE의 프리필은 완전히 무너집니다. 왜냐하면 프롬프트가 40개 레이어 전체에 걸쳐 거의 모든 전문가를 활성화시키기 때문입니다. 이들을 모두 순차적으로 스트리밍하려고 하면, 버스(bus)가 포화 상태인 동안 GPU는 유휴 상태로 있게 됩니다.
Betelgeuse에서는 다음 세 가지 변경 사항을 적용하여 이 문제를 해결했습니다:
- 위치 불변 캐시 분할(Location-Invariant Cache Partitioning): 레이어당 20개의 상주 슬롯(VRAM Hot 슬롯 5개 + Host-RAM 슬롯 15개)을 엄격하게 간섭하지 않는 라우팅으로 유지합니다.
- 단일 패스 레이어 메이저 프리필(Single-Pass Layer-Major Prefill): 프롬프트를 텐서 코어 점유율을 떨어뜨리는 작은 3 토큰 마이크로 배치로 자르는 대신, 프리필은 전체 16 토큰 ubatch로 실행됩니다. 모든 활성 Host-RAM 전문가들은 컴퓨팅과 병렬로 PCIe를 통해 실행 링(execution ring)으로 직접 스트리밍됩니다.
- 패스 종료 시 물리적 VRAM 통합(End-of-Pass Physical VRAM Consolidation): 엔진은 프롬프트와 초기 생성 과정에서 실제로 어떤 전문가들이 요구되었는지 학습하고, 모델의 논리적 라우팅 궤적을 변경하지 않으면서 첫 번째 패스가 끝날 때 가장 활성화된 상위 5개 전문가를 물리적으로 VRAM Hot 슬롯으로 교체합니다.
그 결과: Warm Prompt Processing은 3~6 tok/s로 느리게 진행되던 것에서 최대 61.80 tok/s까지 향상되었습니다. 표준 프롬프트의 TTFT(Time To First Token)는 이제 사실상 즉각적입니다.
Betelgeuse 대 Strata 벤치마크 비교
| 벤치마크 / 지표 | Betelgeuse | Strata |
|---|
| GPU | RTX 3060 12GB | RTX 5070 12GB / RTX 3060 12GB / 4× R9700 |
| 시스템 RAM | 16GB | 64GB (RTX 5070) / 46GB (RTX 3060) |
| 저장 공간 | 1.7 GB/s NVMe | 3.6 GB/s NVMe (RTX 5070) |
| 메모리 제한 | 12GB (MemoryMax=12G) | 명시되지 않음 |
| Warm Prompt Processing (PP) | 61.80 tok/s | RTX 5070의 경우 121 tok/s (4K) ~ 231 tok/s (8K) |
| Prompt Processing (RTX 3060) | 61.80 tok/s (RAM 사용 시 두 배, 듀얼 채널 16GB를 사용하면 61 tok/s에서 120 tok/s로!) | 149 tok/s (8K) |
| Warm Decode (TG) | 18.15–18.92 tok/s | RTX 3060 + 64GB Ram의 경우 8–10 tok/s |
| Decode Peak | 27.92 tok/s | 9.9 tok/s (코드) |
| Agent Work Decode | 24.22 tok/s | 7.8 tok/s (RTX 3060) |
| RTX 5070 Decode | 테스트 안 함 | 4.7 tok/s |
| ColdSSD Reads | 0.00% | 명시되지 않음 |
| Disk I/O Wait | 0.0 ms | 명시되지 않음 |
| Peak Memory Usage | 10.61 GiB | 명시되지 않음 |
| DSpark | On (RTX 3060의 경우 기본값) | Off |
활성화(Enabling)는 정확도 검증(Correctness Verification)을 2–13% 향상시키며, Python 구문 및 로직은 실행 전반에 걸쳐 검증되었습니다. (Not specified). 양자화(Quantization): Q8_XL (UD - 3.1), GSQ-RCO, IQ2_XS
또한 DeepSeek의 네이티브 DSpark drafter(p_min = 0.50 포함)를 사용하며, 이는 구조화된 코드에서 약 80–90%의 수용률을 달성하고 스윕당 4개 이상의 토큰에 걸쳐 순방향 패스(forward pass)를 분산시킵니다.
주제에 대한 캐시가 예열되면, 디스크 읽기(disk reads)는 문자 그대로 0.00%로 떨어지고 스왑 트래싱(swap thrashing) 없이도 생성 속도는 약 18–19 tok/s를 유지합니다.
메모리 계층화(memory tiering) 또는 도어벨 동기화(doorbell synchronization)에 대한 질문에 기꺼이 답변해 드리겠습니다!
Github: https://github.com/Betelgeuse-AI/Betelgeuse (RTX 3060 12GB + 16GB RAM에서 DeepSeek V4.1 Flash Q8_XL (1017)을 19 tok/s 디코드 및 62 tok/s 프리필로 구동): 아웃-오브-코어 MoE의 프리필 병목 현상을 마침내 해결한 방법
/u/zyxciss가 제출함 [link] [comments]