Instead of waiting for an M5 Ultra 512 GB: pairing a new M5 Ultra 256 GB with my M3 Ultra 512 GB for disaggregated prefill/decode (GLM-5.3-Flash, MLX, Thunderbolt 5 RDMA)

r/LocalLLaMA 글을 레딧 RSS 발췌로 읽고 옮겼어요. 발췌는 끝의 "시간을 잡아먹은 것들" 부분 직전에서 잘려 있고, 레딧 페이지 직접 접근은 403이었어요.

문제

M3 Ultra 512GB는 메모리 때문에 여전히 가치가 있지만 긴 프롬프트 프리필이 느려요. 17.5k 토큰 프롬프트에서 첫 토큰까지 41초가 걸렸대요. M5 Ultra는 프리필이 빠르지만 지금은 최대 256GB예요. 그래서 M3를 바꾸는 대신 M5 Ultra 256GB를 추가해 일을 나눴어요. M5가 프리필, 캐시 상태는 썬더볼트 5 RDMA로 넘기고, M3가 512GB 풀로 디코드해요.

단일 노드 수치(GLM-5.3-Flash 4비트+MTP)

• 프리필(2k 청크): M3 438 tok/s(40초) vs M5 1,046 tok/s(16.8초)
• 프리필(8k 청크): 454 vs 1,188
• 디코드: 32.9 vs 47.2

M5는 프리필 약 2.4배, 디코드 약 1.4배예요. 디코드는 큰 메모리 덕을 보는 단계라 이 비대칭이 분리의 근거예요.

왜 2.4배뿐인가

MLX 순수 행렬곱은 bf16 118 vs 24 TFLOPS인데, 프로파일해 보니 진짜 행렬곱은 3~4배 빨라지지만 희소 어텐션의 top-2048 gather 커널, 순환 스캔, 전문가 라우팅은 1.3~1.8배로 대략 메모리 대역폭 비율(558 vs 382GB/s) 수준이었어요. M5는 프리필의 거의 절반을 행렬 유닛을 못 쓰는 커널에서 보낸대요. 개선 여지로 더 큰 프리필 청크(8k에서 +14%)와, 이웃 쿼리끼리 키를 공유하는 블록 희소 어텐션 커널을 꼽았어요. 걱정하던 선형 어텐션 스캔은 6%뿐이었어요.

분리 결과

• M5 프리필 988 tok/s, 17.8초
• 캐시 358MB를 TB5 케이블 두 개로 38ms에 전달
• 캐시 도착 후 38ms에 M3에서 첫 토큰, 총 약 18.5초(기존 약 40초)
• M3 디코드 36.8 tok/s, 출력은 M5 단독과 동일
• M5는 18초 뒤 비어서 다음 프롬프트를 프리필할 수 있어요

GLM-5.3-Flash는 고정 크기 상태의 KDA 선형 어텐션 34층과 512폭 잠재 KV 희소 어텐션 11층이라 토큰당 약 20KB예요. M3의 남는 300GB로 약 1,500만 토큰 대화 캐시를 담을 수 있대요.

스택은 MLX JACCL 백엔드(두 컨트롤러의 케이블, 합계 약 150Gb/s), mlx-vlm 0.7.6, 캐시를 세 배열로 직렬화해 mx.distributed.send/recv로 보내는 파이썬 프로토타입이에요.

한계

프리필 노드도 모델 전체가 필요해 256GB에 들어가는 모델만 돼요. 요청 하나만 보면 M5 단독 디코드가 더 빨라요(47 vs 37). 이득은 긴 프롬프트의 첫 토큰 시간, 동시 요청 처리량, 512GB 풀 활용이에요.