oMLX로 맥에서 로컬 AI 실행하기: 0.7.1rc1 새 설정은?

현재 안정판은 0.7.0이고 0.7.1rc1은 새 기능을 시험하는 출시 후보판이에요. 아래에는 앞선 0.7.1.dev1의 변경과 재현 절차도 남겨두었어요. 관리 화면이나 omlx --version으로 버전을 확인하고, DMG 앱으로 설치했는지 소스 저장소에서 설치했는지도 따로 확인하세요. 앱은 새 앱 번들로, 소스 설치는 해당 버전의 의존성과 커널을 맞춰 갱신해요.

oMLX는 GGUF²가 아니라 MLX 체크포인트³를 실행해요. Apple Silicon 맥과 macOS 15 이상에서 쓸 수 있어요. 처음 설치한다면 공식 Releases에서 macOS용 DMG를 받아 열고 oMLX를 Applications 폴더로 옮겨 실행해요. 시작 화면에서 모델 폴더를 정하고 서버를 시작한 뒤, 호환되는 MLX 체크포인트를 내려받아요. 모델 형식과 양자화⁴가 맥의 통합 메모리⁵에 맞는지도 확인해요.

서버가 실행되면 관리 화면은 http://localhost:8000/admin, 대화 화면은 http://localhost:8000/admin/chat에서 열려요. 먼저 짧은 질문을 보내 모델 응답을 확인해요. 개발판을 시험한다면 기존 API⁶ 연결 설정과 모델 폴더를 기록해두면 이전 환경과 비교하기 쉬워요.

화면에서 짧은 질문에 모델이 답하는 것을 확인했다면, 성능을 비교하기 전에 API 연결도 점검해요. YOUR_OMLX_API_KEY는 관리 화면에서 설정한 키로 바꿔요.

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/v1/models -H 'Authorization: Bearer YOUR_OMLX_API_KEY'

/health에서 정상 상태가 오고 /v1/models에 사용할 모델 ID가 보이면 서버와 API 인증이 준비된 거예요. 연결이 안 되면 서버 실행 여부부터 보고, 모델 목록 요청에 401이 나오면 키를 확인해요. 목록이 비어 있으면 모델 폴더와 체크포인트 다운로드 상태를 살펴봐요.

2026년 10월 15일 공개된 0.7.1rc1은 출시 후보판이에요. 안정 버전은 0.7.0이고, 새 기능을 먼저 시험하려면 rc1을 선택하면 돼요. 업데이트 전 사용 중인 모델과 설정을 기록해 두세요. 문제가 생기면 같은 모델로 안정판에 돌아가 비교할 수 있어요.

Qwen3.8·Qwen3.6를 Splash로 실행해도 모델 목록과 API 주소는 oMLX에서 그대로 관리할 수 있어요. Settings → Integrations → External engines에서 설치된 Splash를 지정하고, 해당 모델의 Model Settings → Advanced에서 Use external engine을 켜세요. 모델에 맞는 DFlash2 초안 파일도 oMLX의 모델 폴더에 준비해야 해요.

Muse Spark Open도 새로 지원해요. oQ3e 370GB 구성은 512GB Mac을 대상으로 하므로, 먼저 사용할 모델을 정한 뒤 통합 메모리와 다른 앱에 남길 공간을 계산하세요. 준비된 모델의 새 다운로드 화면은 이 Mac에서 적재할 수 있는 후보를 추천해 줘요.

프리필⁷은 모델이 질문과 문서를 읽어 첫 답변을 준비하는 단계예요. 0.7.1.dev1의 batched prefill은 여러 요청이 비슷한 시점에 입력 처리를 시작하면 각 요청의 chunk를 한 번의 forward에서 함께 계산해요. MoE⁸ 모델의 전문가 가중치를 요청마다 따로 읽는 횟수를 줄이고, 요청별 캐시는 분리해 유지해요. 별도 설정은 필요하지 않아요. 여러 사용자의 요청이 겹치는 서버에서 이 변경을 살펴봐요.

릴리스 표는 요청을 한꺼번에 보내는 경우와 간격을 두고 보내는 경우, 생성 중인 요청에 새 요청이 합류하는 경우를 나눠요. 요청이 겹치면 다음 입력의 프리필을 기존 생성 작업과 함께 처리할 수 있어, 차이는 단독 생성 속도보다 첫 토큰⁹ 대기에서 살펴볼 만해요. 표의 세 패턴과 장비별 결과를 내 요청 형태에 맞춰 읽어요.

혼자 쓰는 맥이라면 먼저 실제 요청이 겹치는지 확인해요. 같은 프롬프트¹⁰를 단독으로 보내고, 여러 요청을 겹쳐 보냈을 때의 첫 토큰 시간과 전체 완료 시간을 따로 적어요. 테스트에는 같은 모델 파일, 문맥, 답변 길이와 동시 요청 수를 사용해요. 요청 하나만으로도 첫 답이 느리다면 batched prefill 수치보다 입력 길이, 모델 로딩, 메모리 상태를 먼저 살펴보는 게 맞아요.

Qwen3.8-Flash-Next의 group size 32 체크포인트는 디코드¹¹ 경로를 최적화해요. M3 Ultra에서 MTP¹²를 켠 별도 비교는 98에서 134 tok/s(+37%)였어요. 표의 Flash-Next 행은 MTP를 끈 상태로 측정했어요.

Qwen3.8-27B oQ8e의 INT8 activation prefill은 긴 입력을 읽는 프리필 단계에 적용돼요. M5 Max에서 4K 입력 결과는 +25%였고, 16K 조건은 표에 정리했어요. Experimental Features에 해당 항목이 표시되는 모델에서 켜고, 긴 문서의 첫 토큰 대기와 생성 속도를 나눠 기록해요.

Lightning MTP는 모델에 포함된 다음 토큰 예측 헤드로 후보를 만들고 본 모델이 확인해 디코드의 순차 계산을 줄여요. 릴리스가 시험한 모델 계열과 파일 편집 조건은 표에 모았어요. 지원 체크포인트에서 기능을 켜고 같은 요청으로 일반 생성과 완료 시간, 결과를 비교해요.

같은 릴리스는 Qwen3.6-35B-A3B 디코드 +31%(M5 Max), GLM-5.3-Flash 디코드 +30%(M3 Ultra), DeepSeek V4.1 Flash 첫 실행 +48%(M3 Ultra)도 보고했어요. 처리 단계와 칩을 맞춰 결과를 읽고 테스트 기록에도 조건을 남겨요.

Qwen3.8-27B를 다른 실행기로도 시험하려면 TensorFold의 맥 메모리 변경 가이드에서 필요한 파일과 문맥 길이를 확인하세요. 같은 입력으로 메모리 사용량, 첫 답까지 걸리는 시간, 전체 완료 시간을 기록하면 현재 설정과 비교할 수 있어요.

소스 설치를 갱신하면 oMLX 0.7.1.dev1의 MLX 버전은 0.32.3이에요. 이전 MLX에서 빌드한 커널은 거부되어 느린 대체 경로로 실행될 수 있어요. 릴리스 안내에 따라 기존 저장소와 가상환경¹³을 준비하고 저장소 폴더에서 make kernels를 실행해요.

make kernels

빌드가 오류 없이 끝나면 oMLX를 다시 시작해요. 관리 화면의 Engine Versions에서 MLX 0.32.3을 확인하고, 익숙한 짧은 프롬프트를 보내요. 모델이 적재되고 응답이 오면 기본 경로가 작동하는 거예요.

make kernels가 실패하면 오류 첫 줄과 활성 Python 가상환경을 살펴봐요. 명령은 끝났는데 속도가 낮다면 Engine Versions의 MLX 버전과 커널 상태, 서버 로그의 커널 로드 오류를 확인해요. 앱 번들 설치는 이 소스 절차 대신 해당 설치판의 공식 다운로드를 이용해요.

릴리스에서는 약 150개의 디버그 OMLX_* 환경 변수를 제거하고 읽지 않아요. OMLX_MOE_EXPERT_OFFLOAD, OMLX_QWEN35_ANE_PREFILL, OMLX_RDMA_STAGE_LINKS도 여기에 포함돼요. 해당 모델이 지원하는 기능은 관리 화면의 모델 설정에서 조절해요.

예를 들어 모델별 Experimental Features에는 INT8 activation prefill이나 ANE¹⁴ prefill처럼 해당 모델이 지원할 때만 쓸 수 있는 항목이 표시돼요. 설정을 바꾸기 전 현재 값을 기록하고, 한 항목만 바꿔 같은 질문을 보내요. 입력 토큰 수와 첫 토큰 시간, 답변 생성 속도, 오류 여부를 비교해 설정이 실제 사용 흐름에 영향을 줬는지 확인해요.

모델 목록을 불러오지 못하면 모델 폴더와 다운로드 상태부터 확인해요. 서버는 열리지만 응답이 없다면 관리 화면의 상태 표시와 서버 로그에서 첫 오류를 찾고, 메모리 오류라면 다른 모델을 내리거나 동시 요청을 줄여 짧은 입력으로 다시 시도해요. 속도만 달라졌다면 실제 요청의 입력 길이·모델 파일·캐시 상태가 같은지 대조해요.

Clef와 OpenJev 계열은 매번 자유 문장을 생성하는 대신, 상태와 선택지를 읽고 각 선택지의 확률을 돌려주는 의사결정 모델이에요. oMLX는 POST /v1/systemone에서 TypeSafe System One 형식으로 요청을 받아요. 질문 유형은 noul, choice, score이고, 체크포인트를 자동 감지하거나 모델 유형을 decision으로 지정할 수 있어요. 일반 /v1/chat/completions 대화 요청과 목적이 다르므로, 이미 이 형식을 지원하는 앱이나 자체 클라이언트에서 사용해요.

EmbeddingGemma 2는 이미지와 오디오 입력도 받도록 연결됐고, rerank 요청에는 instruction과 max_length 옵션이 추가됐어요. 음성 모델 로더는 Fish, TADA, LongCat의 ref_audio 처리를 보완했어요. 이 모델을 쓰는 앱에서는 모델 카드와 API 형식에 맞춰 이미지·오디오·참고 음성 입력을 보내요.

웹 대시보드는 새 레이아웃으로 바뀌어 로그 세부 정보, 설정 섹션 링크, Restart와 Unload all, 묶음 벤치마크 프리셋을 제공해요. 업데이트 뒤 설정 레일과 Serving Stats 영역에서 모델 상태를 확인해요. 관리 화면에서 모델 로그와 재시작 위치도 살펴봐요.

동시 요청이 거의 없고 0.7.0에서 작업이 안정적으로 끝난다면 현재 안정판을 유지해도 충분해요. 여러 요청이 겹쳐 첫 토큰까지 기다리는 시간이 문제라면 0.7.1.dev1에서 같은 프롬프트와 동시 요청 수로 TTFT¹⁵를 재봐요. 특정 Qwen 체크포인트의 입력 처리나 생성이 느린 경우에는 group size, MTP, INT8 prefill의 지원 조건을 확인한 뒤 해당 모델에서 비교해요.

테스트 기록에는 설치 버전, 모델 저장소와 양자화, 맥 칩, 입력 길이, 동시 요청 수, MTP·캐시 설정, 첫 토큰 시간, 완료 시간, 답변 품질을 남겨요. 릴리스 숫자는 각 변경 직전 코드와 비교라 0.7.0 전체를 기준으로 한 포괄 비교와 달라요. 내 모델과 요청에서 반복되는 변화를 보고 업데이트를 결정해요.

기본 요청이 실패하면 새 최적화 옵션을 더 켜기 전에 먼저 서버와 모델을 정상적으로 불러와요. 같은 짧은 요청에서 정상 응답을 확인한 다음 기능을 하나씩 시험하면 어떤 변경이 문제를 만들었는지 좁힐 수 있어요. 안정판 서버가 맡은 실제 작업은 그대로 두고 개발판 실험을 분리할지, 새 기능이 확인된 뒤 옮길지는 이 기록으로 결정해요.