필자는 오랫동안 dwarfstar의 팬으로 GLM 5.3 Flash를 매우 마음에 들어 했지만, 쾌적하게 쓰려면 실질적으로 더 빨라야 했다. 스크린샷은 약 200k 컨텍스트 깊이에서 수많은 도구 호출과 함께 Claude Code 하네스로 이 모델을 구동한 결과를 보여주며, 평균 38tps를 넘는 출력 속도를 기록했다. 제목의 60tps는 SQL 작성을 요청하면 얻을 수 있는 수치다.

기존 ds4는 GLM-5.3-Flash를 M3 Ultra 실측 메모리 대역폭의 약 59% 속도로 단일 스트림 직렬 디코딩했고, 우리는 80%를 목표로 삼았다. 대형 웨이트 스트리밍 커널은 이미 효율적이었지만 그 사이에 수십 개의 소형 커널이 끼어 있어, GPU 상당 부분이 유휴 상태인 동안 각각 지연 비용을 부담했다. 우리는 이 작업을 더 큰 디스패치로 융합하고 파이프라인을 대기시키는 별도 패스를 제거했다. 그 결과 짧은 컨텍스트에서 29→40 t/s, 62k에서 24→38 t/s로 향상됐고, 토큰당 Metal 커널 수가 줄어 실측 대역폭 상한의 약 81%에 도달했다.

이어서 매우 긴 컨텍스트에서 남은 병목을 공략했다. 이 모델의 고비용 어텐션 연산은 62k와 300k 모두에서 약 2,048개의 선택된 위치를 대상으로 이미 동작하며, 커지는 것은 더 큰 히스토리에서 그 위치를 찾는 작업이다. 기존 구현은 GPU를 거의 활용하지 못하는 단계를 거치며 점점 커지는 후보 목록을 정렬·병합했는데, 우리는 이를 작게 남은 목록을 정렬하기 전에 후보를 좁히는 병렬 스캔으로 교체하고 모호한 경우는 기존 알고리즘이 처리하게 했다. 이로써 생성 토큰당 약 1밀리초를 회수하며, 선택되는 위치·순서·출력은 모두 동일하다. 300k 종단 간 성능은 스톡 21.6 t/s 대비 37.4 t/s이며, 더 깊은 컨텍스트는 검색 비용이 여전히 늘지만 고비용 어텐션 작업 자체는 배로 늘지 않는다.

프리필은 62k 기준 약 366 t/s에서 출발했다. 대형 행렬 커널은 이미 효율적이었지만 같은 웨이트를 반복해서 언패킹하고, 데이터를 잘게 나눠 가져오고, 커널 사이로 대형 중간 결과를 전달하며 시간을 낭비했다. 우리는 작업을 더 묶어 일괄 처리하고, 준비된 웨이트를 재사용하고, 로드 폭을 넓히고, 같은 데이터에 대한 패스를 병합했다. 그 결과 같은 웨이트로 366→550 t/s, 50% 향상을 이뤄 파이프라인 전체를 칩 실측 matmul 상한의 약 51%에서 72%로 끌어올렸다. 콜드 62k 처리 시간은 약 170초에서 113초로 줄었으며, 이는 에이전트 하네스가 컨텍스트를 압축해 다시 읽을 때마다 발생하는 대기 시간이다.

서버는 —dflash로 드래프터 파일을 넘기지 않는 한 직렬로 동작하며, 드래프터 빌드 레시피는 저장소에 있다. 드래프터는 직렬 속도 대비 자신의 비용을 측정해 이득이 없으면 물러나는 윈도우 컨트롤러 기반 어드미션 정책을 갖는다. 추론 토큰은 직렬로 디코딩되며, 32요청 에이전트 세션에서는 직렬 대비 +4%, SQL·JSON 같은 구조화 출력에서는 +20~+50%, 산문에서는 개입을 중단해 약 1%의 비용만 든다. 출력은 모든 픽스처에서 직렬 디코딩과 바이트 단위로 동일하다. 정확도 측면에서 ds4의 릴리스 QA용 100프롬프트 기준 세트에서 스톡은 FP8 기준 대비 평균 NLL 0.300804, 이 브랜치는 0.300766을 기록했고 첫 토큰 일치 역시 같은 90/100이다. 여기서 품질을 속도와 맞바꾼 것은 없다. 이 브랜치가 M3 Ultra 전용인 이유는 최적화가 이 특정 칩의 상세 측정, 즉 두 다이 메모리 동작, 시스템 레벨 캐시, 코어별 레지던시와 대역폭, Metal이 80개 GPU 코어에 걸쳐 디스패치와 스레드그룹을 스케줄링하는 방식에 의존하기 때문이다. 우리는 한 대의 머신에서 한 세트의 웨이트(Q4)로 하나의 모델 실행을 최적화하며, 예측한 커널 절감이 전체 디코딩과 프리필에서도 유지되는지 검증한다.