실행 프로그램과 확장
oMLX로 맥에 모델을 켜두기: 캐시와 가속 설정을 고르는 순서
문서를 읽히던 모델에서 코딩 모델로 바꿨더니 다시 오래 기다립니다. 앱을 몇 개 더 열면 메모리도 빠듯해집니다. oMLX는 이런 일상적인 사용을 관리하는 맥용 서버입니다. 가장 빠른 숫자보다, 내 작업이 어디서 기다리는지에 맞춰 설정해봅니다.
받아둔 모델 파일부터 확인합니다
oMLX는 Apple Silicon 맥에서 MLX 모델을 실행하고 다른 앱에 API로 연결해줍니다. 모델 이름이 같아도 GGUF와 MLX 변환본은 서로 바꿔 쓸 수 없습니다. 받을 저장소의 형식과 양자화, 필요한 구성 파일을 먼저 확인합니다.
공식 macOS 앱이나 별도로 설치한 CLI를 사용할 수 있습니다. 여기서는 설치와 모델 준비가 끝났다고 가정합니다. 모델 폴더 아래에 각 모델의 폴더를 두면 서버가 찾아서 목록에 표시합니다.
한 모델, 한 요청으로 먼저 연결합니다
처음에는 한 번에 한 요청만 처리하고 메모리 가드를 safe로 둡니다. 최고 속도 설정이 아니라 연결과 답변을 확인할 출발점입니다. 아래 명령의 모델 폴더를 실제 위치로 바꾸고, 앱에서 서버가 실행 중이면 먼저 중지하세요.
다른 터미널에서 상태를 확인합니다. healthy는 서버 준비 상태이지 모든 모델의 답변 검증은 아닙니다. loading이라면 고정한 모델을 올리는 중일 수 있습니다. 준비가 끝나면 127.0.0.1:8000/admin에서 모델을 골라 짧게 질문해봅니다.
내 맥에서만 서버 실행
omlx serve --model-dir "$HOME/.omlx/models" --host 127.0.0.1 --port 8000 --memory-guard safe --max-concurrent-requests 1oMLX와 MLX 모델이 준비된 상태에서 실행합니다. 모델 다운로드나 설치 명령은 포함하지 않습니다.
서버 상태 확인
curl http://127.0.0.1:8000/health서버를 실행한 터미널은 그대로 두고, 다른 터미널에서 확인합니다.
자주 쓰는 모델만 남겨둡니다
매번 쓰는 모델은 고정하고, 가끔 쓰는 모델에는 유휴 시간 뒤 내려가는 TTL을 둘 수 있습니다. 메모리가 부족하면 최근 덜 사용한 모델을 내리는 방식도 있습니다. 전부 고정하면 다른 모델로 전환할 여유가 줄어듭니다.
KV 캐시는 이미 읽은 입력의 계산 기록입니다. 자주 쓰는 부분은 메모리에, 보관할 부분은 SSD에 두고 같은 앞부분을 다시 만났을 때 재사용합니다. 새 문서를 처음 읽는 시간과 같은 문서를 다시 묻는 시간은 따로 재야 합니다.
Flash-Next의 PLE SSD 오프로드는 이 KV 캐시와 다릅니다. 모델의 큰 임베딩 테이블을 SSD에 배치하는 별도 로더 경로이며, Lightning MTP와 함께 설정할 수 있습니다. 실제 파일 크기와 페이지 캐시 상태에 따라 필요한 공간과 속도가 달라집니다.
메모리 경고가 나오면 문맥부터 줄입니다
맥의 통합 메모리는 다른 앱과 함께 씁니다. oMLX의 메모리 가드는 현재 여유와 한도를 보며 새 입력 처리를 늦추거나 모델을 내리고, 압박이 크면 요청을 중단할 수 있습니다. 가드를 끈다고 필요한 메모리가 줄지는 않습니다.
긴 입력에서 멈췄다면 문맥 상한과 동시 요청 수, 고정한 모델부터 줄여봅니다. SSD 캐시를 늘리는 것만으로 모델 가중치와 실행 중 작업 공간까지 모두 해결할 수는 없습니다.
MTP와 SpecPrefill은 기다림의 다른 부분을 줄입니다
Lightning MTP는 다음 토큰 후보를 만들고 검증해 답변 생성을 앞당기는 경로입니다. 지원되는 모델 구조와 실제 MTP 가중치, 켜진 모델 설정이 함께 필요합니다. 이름에 MTP가 있다고 끝이 아니며, 깊이를 높일수록 항상 빨라지는 것도 아닙니다.
SpecPrefill은 작은 초안 모델로 긴 입력의 일부를 골라 처리하는 실험 기능입니다. 같은 토크나이저를 쓰는 호환 초안 모델이 필요하고, 캐시 등을 제외한 처리 대상이 설정한 길이를 넘어야 작동합니다. 짧은 질문이나 이미지 입력까지 같은 효과를 기대하면 안 됩니다.
native MTP와 병합된 Gemma assistant의 Lightning 경로는 SpecPrefill과 별도로 설정할 수 있습니다. 반면 외부 assistant를 쓰는 VLM MTP는 현재 SpecPrefill과 동시 실행할 수 없습니다. 모델 이름보다 어떤 실행 경로인지 먼저 구분하세요.
두 설정을 켤 수 있어도 모든 요청에서 같은 이득이 나오는 것은 아닙니다. 하나씩 바꾼 결과와 함께 켠 결과의 로그, 첫 토큰 대기, 생성 속도와 답변 내용을 비교합니다. 입력 일부를 고르는 만큼 문서의 세부 조건을 놓치지 않는지도 확인하세요.
다른 서버로 옮기기 전에 남길 기록
oMLX와 MTPLX를 비교한다면 같은 변환본과 문맥, 가속 조건을 먼저 맞춥니다. 한쪽의 반복 질문과 다른 쪽의 첫 질문을 비교하면 캐시 차이를 엔진 차이로 오해하기 쉽습니다. 모델 전환의 편의와 한 답변의 속도도 별도 판단입니다.
내 문서와 코드로 몇 번 반복해보고 모델 파일, 런타임 버전, 설정과 시간을 남깁니다. 한 번의 최고 기록은 다음 작업의 보장이 아닙니다. 연결이 확인됐다면 모델별 레시피에서 내 맥에 맞는 설정을 이어서 확인하면 됩니다.
수정 내역
사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.
oMLX의 모델 관리·캐시·가속 안내 추가
MLX 모델로 서버를 시작하고 메모리 가드·모델 유지·캐시 재사용을 확인하는 순서를 추가했습니다. MTP와 SpecPrefill의 적용 조건을 나누고, SSD의 입력 캐시와 모델 가중치 오프로드를 구분했습니다.