Husky - MLX보다 최대 4.5배 빠른 추론 엔진

Husky는 Underdog의 Woof 모델만을 위해 만든 Apple silicon 추론 엔진으로, M5 Max에서 동일 가중치와 동일 출력 기준으로 측정한 16개 작업 모두 MLX보다 빨랐음
Husky Flash를 켜면 함수 수정 작업에서 최대 730토큰/초를 기록해 MLX 대비 약 4.5배 빨랐으며, 전체 작업의 속도 향상 폭은 1.3~4.5배였음

• 편집 작업은 프롬프트의 기존 텍스트를 후보로 삼고
  8개 토큰을 한 번에 검증해 가속함. 일반 글쓰기에서는 Woof로 학습한 소형 초안 모델이 후보 토큰을 생성함
  모델 전용 커널과 메모리 배치, GPU 실행과 겹치는 명령 제출로 범용 처리 비용을 줄임. 캐시를 사용하는 후속 응답의 첫 토큰은 약 35ms로, 캐시를 쓰는 MLX보다 3.6~5.5배 빨리 나왔음
• 일반 글쓰기는
  메모리 대역폭 한계에 가까워 Flash 없는 속도 향상이 1.02~1.27배에 그침. 더 나은 초안 모델과 NVIDIA GPU용 CUDA 메가커널을 개발 중임

Woof 하나에 맞춘 추론 엔진

Husky는 Underdog의 공개 4B 모델인 Woof만 실행하는 모델 특화 추론 엔진임

• Apple silicon용으로 설계했으며, Underdog는 Mac과 iPhone에서 와이파이 없이도 실행 가능함

• 현재 Husky는
  Mac용 Underdog에 적용돼 있음

• 속도의 핵심은 가중치를 더 빨리 읽는 것이 아니라
  한 번 읽을 때 더 많은 토큰을 생성하는 데 있음

• 토큰 생성에는 Woof의 2.4GB 가중치를 통합 메모리에서 40개 GPU 코어로 읽어 들이는 과정이 필요하며, M5 Max에서 약 6ms가 걸림

• MLX는 가중치 읽기당 토큰 1개를 생성하지만, Husky는 편집에서 평균 5.4개, Flash를 켠 글쓰기 예시에서는 2.7개를 유지함

• 시각화에 사용한 편집 예시는 MLX 159토큰/초, Husky 463토큰/초, Flash 사용 시 535토큰/초를 기록함

16개 작업의 처리량과 응답 지연

동일 Woof 가중치와 탐욕적 디코딩으로 이메일, 스레드 답장, 문체 수정, 계획, 메모, 통화 요약, 문서 질의, 청구서 JSON 변환, 표 변환, 코드 작성과 수정 등 16개 프롬프트 유형을 비교함

• Flash 없이도 전 작업에서 MLX보다 1.023.9배 빨랐고, 편집에서는 1.83.9배 빨랐음
• Flash 사용 시 전체 작업에서 1.3~4.5배 빨랐음

편집 작업에서는 프롬프트 재사용 효과가 컸음

• 함수 수정: MLX 163 → Husky 614 → Flash 730토큰/초로, Flash 기준 4.48배 빨랐음
• JSON 필드 추가: 157 → 611 → 672토큰/초로, Flash 기준 4.28배 빨랐음
• SQL 열 이름 변경: 158 → 487 → 547토큰/초, 문단 오타 수정: 159 → 463 → 535토큰/초를 기록함
• CSV를 표로 바꾸는 작업은 158 → 287 → 462토큰/초였음

새 코드 생성과 구조화 출력도 Flash의 효과가 컸음

• 함수 작성은 155 → 170 → 545토큰/초로, Flash가 기본 Husky보다 약 3.2배, MLX보다 3.52배 빨랐음
• 청구서 JSON 변환은 164 → 208 → 496토큰/초로, Flash가 기본 Husky보다 약 2.4배 빨랐음
• 일반 글쓰기에서 Flash가 더하는 향상 폭은 약 1.1~1.7배였음

대화 후속 응답은 양쪽 모두 캐시를 사용하고 새 메시지의 2631토큰만 입력하는 조건에서도 Husky가 3.65.5배 빨리 시작했음

• Husky의 첫 토큰 시간은 2939ms, MLX는 137177ms였음
• MLX의 일반
  generate

호출처럼 대화 전체를 다시 프리필하면 145295ms가 걸리며, 이 경로와 비교한 Husky의 첫 응답은 약 47배 빨랐음

콜드 프리필에서도 처음 보는 프롬프트의 첫 토큰이 1.8~3배 빨리 나왔음

• 짧은 프롬프트는 Husky 0.05초, MLX 0.15초였고, 859토큰 프롬프트는 각각 0.17초와 0.30초였음
• 859토큰 입력의 호출자 기준 처리량은 Husky 5,150토큰/초, MLX 3,094토큰/초였음
• 엔진 내부에서 측정한 긴 프롬프트 처리량은 각각 5,460토큰/초와 4,878토큰/초로, 호출자 기준 수치와 구분해야 함

일반 글쓰기의 한계와 편집 가속 원리

• 일반 글쓰기는
  메모리 대역폭 한계에 가까움
• 이 Mac에서 2.4GB를 단순 스트리밍으로 읽는 데도 약 4.5ms가 필요함
• 기본 글쓰기의 토큰당 시간은 Husky 약 6.1ms, MLX 약 6.3ms로 차이가 작음

파이프라인 제출로 GPU 명령 사이의 호스트 대기 시간을 줄였음

• 기존에는 매 단계의 명령 인코딩과 대기에 거의 0.5ms가 들었음

• 현재 단계 실행 중 다음 단계를 인코딩하고 제출해 GPU가 바로 다음 토큰 처리를 시작하며, 긴 전사문 작업의 약 5% 향상이 여기서 나옴

• 편집은 응답이 입력의 긴 구간을 그대로 반복하므로
  프롬프트 조회(prompt lookup) 가 효과적임

• 방금 생성한 몇 토큰이 프롬프트에도 있으면, 그 뒤에 있던 7개 토큰을 후보로 제안함

• Woof가 8개 토큰 블록을 검증하고 일치하는 후보를 유지하며, 보통 5~6개가 채택됨

• 검증 비용은 단일 토큰 처리의 약 1.5배로, 결과 텍스트를 바꾸지 않고 한 번에 여러 토큰을 생성함

오타 수정, 파일 필드 추가, CSV의 표 변환, 열 이름 변경, 함수 일부 수정은 모두 기존 텍스트를 상당 부분 돌려주는 작업임

• Underdog가 Woof에 일상적으로 요청하는 작업이므로, 프롬프트 재사용은 드문 예외가 아니라 주요 사용 형태임

Flash 초안 모델과 후보 선택

Flash는 프롬프트를 반복하지 않는 응답에도 8행 검증 단계를 활용하기 위한 소형 단일 레이어 초안 모델임

• Woof의 5개 레이어에서 은닉 상태를 읽고 다음 7개 토큰을 제안함

• Woof가 모든 제안을 검증하고 자신이 원래 생성했을 토큰만 유지하므로, 최종 답변은 바뀌지 않음

• 패키지에 추가되는 초안 파일 크기는
  273MB임

• 학습에는
  13만 9,000개 대화에 대한 Woof 응답을 이용한 자기 증류를 사용했으며, B200 한 대에서 약 2시간이 걸렸음

• Underdog의 편집, JSON, 표, HTML/Markdown UI, 도구 호출, 메일, 코드, 요약, 브라우저 단계, 후속 요청 형태를 포함함

• 공개 채팅, 지시 수행, 코드 데이터셋도 함께 사용함

• 매 단계마다
  프롬프트 조회와 초안 모델 중 후보 생성 방식을 선택함

• 최근 토큰이 프롬프트 앞부분에 있으면 복사에 유리한 프롬프트 조회를 사용함

• 그렇지 않으면 초안 모델을 사용하되, 단계당 채택량이 최소 0.5토큰을 유지하지 못하면 단일 행 경로로 전환해 초안 생성을 일시 중단함

• 응답 시작 부분에서 초안의 예측이 가장 나쁜 점을 고려해, 충분히 긴 구간의 실제 채택량으로 평가함

• 글쓰기에서는 단계당 약
  2개 토큰이 채택돼 164175토큰/초가 210273토큰/초로 늘어남

• 새 코드 작성에서는 약 5개가 채택돼 545토큰/초를 기록함

• 편집은 주로 프롬프트 조회를 유지하고 일치 구간 사이에서 초안의 도움을 받아 462~730토큰/초를 기록함

• 단계당 채택 토큰이 하나 늘 때마다 일반 글쓰기 처리량이 약 60토큰/초 증가함

8행 투영 커널 개선이 초안 모델의 비용을 낮췄음

• 기존에는 너비 12,800의 입력을 각
  simdgroup

이 직렬 행렬 연산 체인으로 처리해 단일 행 대비 2.3배의 비용이 들었음

• 입력을 8개
  simdgroup

에 나눠 비용을 1.5배로 낮췄으며, 같은 변경으로 SQL 수정은 403 → 487토큰/초, JSON 필드 추가는 483 → 611토큰/초로 향상됨

MSI의 네 가지 구현 요소

모델 특화 추론(MSI, model-specific inference) 은 컴파일 시점에 단일 모델의 모든 행렬 형태를 확정하고 범용 처리를 위한 비용을 없애는 접근임

• Husky는 Woof의 네 행렬 형태를 미리 알고 각각에 맞는 커널을 사용함

모델 전용 Metal 메가커널로 연산을 결합함

• 각 투영 커널에 앞선 정규화를 합치고, gate와 up 투영을 함께 처리함
• 4비트 가중치를 4개씩 풀어 바로 곱셈에 넣고, 8행 단계의 긴 입력은
  simdgroup

사이에 분산함

• 한 레이어는 GPU 시간 기준 연속된 4개 커널로 구성되며, 레이어 전체 MLP를 하나의 지속 실행 디스패치로 처리하는 구현도 있음

상주 그리드로 24개 선형 어텐션 레이어의 순환 연산을 실행함

• 지속 실행되는 스레드그룹이 명령 스트림 대신 디바이스 측 카운터로 작업을 넘김

커널이 읽는 순서로 가중치와 캐시를 저장함

• 4비트 가중치를 커널의 타일 순서로 디스크에 저장한 뒤 메모리에 직접 매핑해 로딩 시 변환과 복사를 없앰
• 8비트 키-값 캐시도 어텐션 커널이 직접 소비하는 배치를 사용하므로 실행 중 재배열이 필요 없음
• 엔진 시작 시 해당 Mac에 맞는 메모리 계획을 정하므로 설정 파일이나 수동 튜닝이 필요 없음

파이프라인 제출은 현재 디코딩 단계가 실행되는 동안 다음 단계를 인코딩하고 제출함

• 다음 토큰을 GPU에서 넘겨 호스트를 핵심 실행 경로에서 제외함
• 대화 상태도 메모리에 유지해 메시지가 추가되면 기존 접두사 캐시에서 이어서 처리함

전체 단계 메가커널의 실험과 다음 과제

• 다음 목표는
  32개 레이어 전체를 하나의 지속 실행 디스패치로 처리하는 메가커널임

• 정적인 타일 스케줄을 사용하고 단계 사이를 디바이스 측 배리어로 동기화할 계획임

• 첫 구현인
  레이어 전체 MLP의 단일 디스패치는 출력이 같았지만 속도가 더 빠르지 않았음

• 이 GPU에서는 하나의 인코더 안에 연속 배치한 디스패치가 이미 거의 빈틈없이 실행됨

• 따라서 메가커널은 현재 단계의 마지막 연산과 다음 단계의 가중치 로드를 겹칠 수 있을 때 효과가 있음

• 이런 중첩은 학습된 초안 모델이 자주 사용하게 될 8행 검증 단계에서 특히 중요함

초안 모델 개선도 계속 진행 중임

• 4차 학습 모델은 글쓰기에서 단계당 약 2개 토큰을 채택받음
• 이후 학습은 새 데이터로 이어가며, 따로 보관한 평가 데이터의 점수도 계속 개선 중임

CUDA 메가커널은 NVIDIA GPU용으로 개발 중이며, NVIDIA 및 Microsoft와 함께할 향후 출시를 대상으로 함

• 모델 형태를 컴파일 시점에 확정하는 동일한 접근을 적용함

측정 환경과 검증 조건

• 하드웨어와 소프트웨어는
  Apple M5 Max, 40코어 GPU, 메모리 128GB, macOS 26.5.1임
• 비교 대상은 MLX 0.32.2 위의
  mlx-lm

0.31.3임

• 두 엔진 모두 동일한 4비트 Woof 파일을 사용하며, Husky는 값을 바꾸지 않고 배치만 재구성함

• 변경할 때마다 탐욕적 디코딩 출력을 MLX와
  토큰 단위로 비교함

• 16개 프롬프트 측정은
  2026년 9월 20일 저녁, 부하 평균 10 미만이고 프로덕션 앱이 유휴 상태인 환경에서 수행함

• 각 프롬프트와 엔진을 별도의 조용한 시간대에 측정하고, 사전 카나리 실행 후 각각 3회 실행한 중앙값을 사용함

• 프롬프트마다 엔진 실행 순서를 번갈아 바꿨으며, 반복 측정 편차는 12% 이내였음

• 자체 반복 결과와 맞지 않는 실행은 제외하고 측정 기록을 보관함

• 콜드 프리필 수치는 같은 날 더 이른 조용한 시간대에 측정함

Mac에서 사용하기

Husky는 Mac용 Underdog에 이미 적용돼 별도 엔진 설정 없이 사용할 수 있음

• Underdog를 내려받고 메일과 캘린더를 연결하면
  Woof가 사용자 기기에서 실행되며, 데이터는 외부로 전송되지 않음

댓글과 토론