Rapid-MLX: 코딩 에이전트를 위한 Apple Silicon LLM 추론 서버

로컬 LLM 영역에서 Apple Silicon은 오랫동안 애매한 위치에 있었다. 통합 메모리 덕분에 Mac mini 한 대에도 수십억 파라미터의 양자화 모델을 올릴 수 있지만, 그 주변의 추론 서버 계층은 CUDA 환경에 비해 성숙도가 한참 떨어졌다. Rapid-MLX는 바로 이 공백을 겨냥한다. Apache 2.0 라이선스로 공개된 오픈소스 추론 서버이며, 애플의 MLX 프레임워크 위에 만들어졌다. OpenAI 방식과 Anthropic 방식의 엔드포인트, 즉 /v1/chat/completions, /v1/responses, /v1/messages를 모두 제공한다. 내세우는 초점은 분명하다. 코딩 에이전트를 위한 신뢰할 수 있는 도구 호출이다. 속도만을 유일한 목표로 삼지 않고, 에이전트가 도구를 깨지지 않고 호출할 수 있는지를 같은 비중으로 다룬다는 점이 눈에 띈다. 설치도 평범하다. PyPI와 Homebrew core에서 받을 수 있고, brew install rapid-mlx 한 줄이면 서버가 뜬다. 데스크톱 앱과 모델 미러도 제공된다.

가장 눈에 띄는 주장은 속도다. 프로젝트에 따르면 같은 모델과 같은 가중치에서 디코딩 속도는 애플 공식 mlx-lm의 최대 4배, 일반적인 작업에서는 약 1.5배에 이른다. 측정은 Mac mini M4 Pro에서 Qwen3.5-9B 4비트를 그리디 디코딩으로 돌렸고, 두 서버 모두 기본 설정을 썼다. 여기에는 두 가지 유보가 필요하다. 첫째, '최대 4배'와 '일반 1.5배'의 차이는 이득이 부하의 형태에 크게 좌우됨을 보여 준다. 캐시에 적중하거나 여러 요청이 동시에 들어오는 상황일수록 차이가 커진다. 둘째, 검증이 모델 하나, 기계 한 대, 디코딩 방식 하나에 그치고 발표 주체도 프로젝트 자신이다. 따라서 방향을 알려 주는 증거로 보고, 자신의 모델과 작업으로 다시 측정한 뒤 판단해야 한다. 작업별 결과, 방법, 원시 데이터를 공개한 점은 높이 평가할 만하다. 홍보용 숫자 하나로 끝내지 않고 외부에서 검증할 수 있게 했기 때문이다.

이 수치 뒤에는 서로 맞물리는 몇 가지 장치가 있다. 첫째는 연속 배칭으로, 여러 요청이 하나의 디코딩 루프 안에서 번갈아 진행되어 긴 요청이 다른 요청을 굶기지 않게 한다. 둘째는 프리픽스 캐시다. Rapid-MLX는 기수 트리 형태의 프리픽스 캐시를 메모리에 두고, 하이브리드 구조 모델을 위해 상태 스냅숏도 보관한다. 종료할 때 디스크에 기록하고 시작할 때 복원한다. 코딩 에이전트에게 이는 특히 중요하다. 에이전트는 매 턴마다 긴 시스템 프롬프트와 도구 정의, 지금까지의 대화 전체를 다시 보내며, 그 대부분이 직전 턴과 같다. 캐시를 재사용하면 프리필 대부분을 건너뛸 수 있다. 셋째는 양자화 KV 캐시로, 정밀도를 조금 내주고 메모리를 아껴 제한된 통합 메모리에서 더 긴 문맥이나 더 많은 동시 세션을 감당하게 한다. 세 가지를 합치면 단발성 질문의 최대 처리량이 아니라, 긴 접두부와 많은 턴, 반복 호출이라는 에이전트 트래픽의 통계적 특성을 겨냥한 구성이 된다.

도구 호출 파싱은 이 프로젝트를 많은 동종 제품과 구분하는 또 하나의 축이다. 모델 계열마다 도구 호출을 내보내는 텍스트 형식이 다르다. XML 스타일 태그를 쓰는 것, JSON 조각을 쓰는 것, 추론 텍스트 속에 섞어 넣는 것이 있다. 서버가 이를 불안정하게 해석하면 에이전트는 깨진 인자를 받아 작업 도중 멈춘다. Rapid-MLX는 27개의 파서 모듈과 자동 감지 대체 로직을 갖추어, 모델을 바꿔도 손으로 맞추지 않게 하려 한다. 프로젝트의 비교표에 따르면 mlx-lm 서버는 토크나이저가 도구 호출 지원을 선언한 모델에서만 이를 제공하고, Ollama와 LM Studio는 각자 별도의 도구 호출 문서와 구현을 유지한다. 다만 파서의 개수가 곧 신뢰성은 아니다. 긴 대화, 중첩된 인자, 호출 도중 끊긴 스트림에서도 유효한 호출을 복원하는지가 진짜 시험이며, 이는 각자의 에이전트 프레임워크로 확인해야 한다.

더 넓은 시장에서 보면 경쟁자는 적지 않다. oMLX도 MLX 기반이며 메모리의 핫 계층과 SSD의 콜드 계층으로 이루어진 계층형 KV 캐시를 쓴다. Ollama는 기본적으로 모델당 병렬 요청이 하나이며, safetensors 모델용 MLX 엔진을 추가했다. LM Studio는 llama.cpp와 MLX 두 엔진을 함께 제공한다. mlx-lm에 딸린 서버는 양자화 KV 캐시를 쓰면 한 번에 요청 하나만 처리한다. 프로젝트가 2026년 9월 26일 기준으로 정리한 이 비교표는 이 분야가 비슷한 기능 집합으로 빠르게 수렴하고 있음을 보여 준다. 차이는 구현 세부와 실측 동작에서 나올 수밖에 없다. Mac에서 로컬 코딩 에이전트를 돌리는 독자라면 같은 모델과 같은 작업으로 Rapid-MLX와 현재 환경을 비교해 보는 것이 현실적이다. 첫 토큰까지의 시간, 긴 세션에서의 캐시 적중, 도구 호출 실패율, 이 세 가지를 보라. 속도 배수보다 이 수치가 적합성을 더 잘 말해 준다.