vLLM Metal 0.30: Mac 한 대를 여러 사람이 쓰는 로컬 AI 서버로 만드는 법

혼자 한 문장을 생성할 때는 메모리 대역폭³과 커널 효율이 속도를 좌우합니다. 여러 요청이 겹치면 스케줄러가 빈 계산 구간을 얼마나 잘 채우고 KV 캐시 공간을 얼마나 덜 낭비하는지가 중요해집니다. vLLM Metal은 후자의 문제를 Mac에서 다루려는 서버 엔진입니다.

사이트가 보유한 공개 측정에서 M5 Pro 64GB와 Qwen3-0.6B BF16⁴ 조건의 vLLM Metal 출력 처리량⁵은 동시성 1·8·16에서 각각 136.3·445.7·497.2 tok/s였습니다. 이 수치는 작은 모델의 서버 처리량이며 다른 모델의 개인 디코드⁶ 속도로 옮기지 않습니다. 핵심은 동시 요청이 생겼을 때 총 처리량 곡선을 따로 봐야 한다는 점입니다.

vLLM Metal 0.30은 KV 저장소를 vLLM 스케줄러가 통합 관리하고 Metal 쪽에서는 MLX⁷ view로 같은 메모리를 봅니다. 하이브리드 모델도 서로 다른 캐시 풀이 메모리를 이중으로 잡지 않고 전체 예산을 함께 사용합니다. PagedAttention은 항상 켜지므로 과거 환경 변수로 끄는 설정은 더 이상 기준이 아닙니다.

이전의 VLLM_METAL_MEMORY_FRACTION 환경 변수는 제거됐고 --gpu⁸-memory-utilization으로 예산을 정합니다. 너무 높이면 운영체제와 다른 앱이 메모리 압박을 받고, 너무 낮으면 KV 블록이 부족해 동시 요청이 대기합니다. 0.70처럼 보수적으로 시작해 실제 동시성에서 스왑과 메모리 압력을 보며 올립니다.

공식 요구 조건은 Apple Silicon, macOS 15 이상, 네이티브 arm64 Python 3.12입니다. Rosetta로 실행되는 x86 Python이 섞이면 설치가 되더라도 Metal 경로가 예상과 달라질 수 있습니다. 터미널에서 아키텍처와 Python 버전을 확인한 뒤 공식 설치 스크립트나 Homebrew 중 하나를 선택합니다.

0.30에서는 fp8⁹·int8·nvfp4¹⁰ KV 캐시 dtype을 받지 않으며 auto 또는 TurboQuant 경로를 사용해야 합니다. 다른 vLLM 서버에서 쓰던 옵션을 그대로 복사하면 시작 단계에서 거부될 수 있습니다. 릴리스 노트의 제거·변경 항목을 먼저 보고 현재 명령을 짧게 만듭니다.

단일 요청으로 정상 답변과 메모리 사용량을 확인한 뒤 동시성 2·4·8 순서로 올립니다. 각 단계에서 전체 tok/s뿐 아니라 요청별 첫 토큰¹¹ 시간과 토큰 사이 지연을 기록합니다. 총 처리량이 올라가도 개인 요청이 지나치게 늦어진다면 배치 한도나 최대 시퀀스 수를 낮춰야 합니다.

코딩 에이전트는 짧은 호출을 여러 번 보내고 문서 요약은 긴 입력을 한 번 보냅니다. 두 작업을 같은 비율로 섞은 시험을 만들어야 실제 큐와 프리필¹² 경쟁을 볼 수 있습니다. 한 종류의 짧은 프롬프트만으로 얻은 최고 처리량을 팀 서버 용량으로 쓰지 않습니다.

vLLM Metal은 Ray 실행기와 파이프라인 병렬¹³, Mac별 데이터 병렬 복제를 지원하는 방향으로 발전했습니다. 하지만 모델 하나를 여러 Mac에 나누면 네트워크 동기화가 토큰마다 개입할 수 있습니다. 모델이 한 Mac에 들어간다면 각 Mac에 같은 서버를 띄우고 요청을 나누는 구성이 문제를 찾고 복구하기 쉽습니다.

한 대가 멈춰도 나머지 서버가 요청을 받을 수 있고, 모델 업데이트도 한 대씩 검증할 수 있습니다. 반대로 모델이 한 대에 들어가지 않을 때만 파이프라인¹⁴ 분할을 검토합니다. 구매 결정은 단일 요청 최고치가 아니라 목표 동시 사용자에서 유지되는 첫 토큰 시간과 장애 복구 방식으로 내립니다.