Zyphra는 Zyphra Optimization Engine (ZOE)을 통해 @AMD Instinct MI355X GPU용 추론(inference) 최적화의 두 번째 물결을 제시합니다.
저희의 최신 엔지니어링 블로그에서는 프런티어 오픈 모델에 대한 더 빠른 장문맥 서빙(long-context serving)을 위한 커널 작업 세부 사항을 다루었습니다. 🧵
코딩 및 리서치 에이전트들은 코드, 문서, 도구 출력으로부터 장문맥을 구축하고 이를 매 턴마다 모델에 다시 전송합니다.
장문맥에서 프런티어 전문가 혼합 모델(mixture-of-experts models)은 GPU의 컴퓨팅 자원을 거의 사용하지 않는 계산에 많은 시간을 할애하게 됩니다.
ZOE를 사용했을 때, GLM-5.3의 512K 컨텍스트에서의 첫 토큰 생성 시간(time to first token)은 178.8초에서 64.6초로 감소했습니다 (2.8배). 에이전트들은 컨텍스트의 대부분을 재사용하며, 캐싱률이 90%일 경우 42.3초에서 11.8초로 감소했습니다 (3.6배).
저희 인덱서 커널(indexer kernel)은 매트릭스 코어(matrix cores)에서 실행되며 현재 토큰을 점수화하는 동시에 다음 키를 로드합니다.
512K 컨텍스트의 GLM-5.3에서는 프리필 시간(prefill time) 대부분이 희소 어텐션 인덱서(sparse attention indexer)에 할애됩니다.
희소 어텐션은 각 새로운 토큰이 이전 2,048개의 토큰에만 주의를 기울일 수 있게 합니다. 이들을 선택하기 위해 인덱서는 모든 이전 토큰을 점수화하므로, 그 비용은 컨텍스트 길이와 함께 증가합니다.
DeepSeek-V4 역시 유사한 종류의 선택 단계를 가집니다. 새로운 토큰마다 상위 512개의 압축된 항목을 선택합니다. SGLang은 이를 GPU의 256개 컴퓨팅 유닛 중 1개에서 실행하며, 저희 커널은 이를 최대 32개에 걸쳐 분할합니다.
1M 컨텍스트에서의 단일 사용자 디코딩 속도는 43.5 토큰/초에서 61.1 토큰/초로 증가했습니다.
커널의 속도는 GPU의 컴퓨팅 자원 또는 메모리 대역폭 중 하나에 의해 제한되며, 저희는 MI355X에서 이 두 가지를 모두 경험적으로 측정했습니다. 디코딩 시 각 MoE 전문가(expert)는 몇 개의 토큰만 보기 때문에, 대역폭이 한계를 설정합니다.
저희의 통합된 MoE 커널은 vLLM의 Triton 커널보다 최대 2.0배 빠릅니다.
FP4는 가중치 바이트를 절반으로 줄여주므로, 저희는 AMD의 MXFP4 GLM-5.3을 테스트했습니다. 이 모델은 FP8 대비 756 GB에서 410 GB로 용량이 감소했으며, 네 가지 추론 벤치마크에서 3포인트 이내의 성능을 보였습니다.
이 모델은 높은 동시성(high concurrency)일 때만 더 빠르게 디코딩됩니다. 낮은 동시성에서는 FP4 커널이 절약되는 작은 가중치보다 더 많은 시간을 추가합니다.
추측 디코딩(Speculative decoding) 속도는 프롬프트에도 따라 달라집니다. 하나의 Kimi-K3 요청은 복잡한 추론(hard reasoning)보다 간단한 수학 문제(simple math)에서 2.7배 더 빠르게 디코딩됩니다.
모든 결과는 라이브 트래픽이 없는 상태에서 MI355X 단일 노드(single-node) 기준으로, 명시된 vLLM 및 SGLang 버전을 상대로 측정되었습니다.
더 자세한 내용은 다음을 참조하십시오.
