Laya on Apple Silicon: MLX 포팅이 주는 것과 주지 않는 것

Laya는 문장을 결코 쓰지 않는 의사결정 모델이다. Convai Innovations는 2026-09-18에 자사의 가중치를 Hugging Face에 공개했고, 다음 날 mizorewww라는 개발자가 Laya-MLX — 세 개의 Laya 체크포인트를 모두 MLX를 통해 Apple Silicon에서 네이티브로 실행하는 독립 포트로, PyTorch도, Transformers 런타임도, 클라우드 호출도 필요 없다. 그 포트는 M3 Max에서 421M 체크포인트의 짧은 영어 질문 하나에 중앙값 13.42ms, 322M 다국어 체크포인트에는 7.39ms, 출력 토큰은 0개를 보고한다. 한편 Kev는 같은 타입 지정 의사결정 아이디어를 추구하는 또 다른 오픈 패밀리로, Qwen3.5-4B-Base를 기반으로 하며 Mac에서 사용할 수 있기 전에 완전히 별도의 두 번째 백엔드가 필요했다. PyTorch에는 Apple GPU에서 DeltaNet 레이어를 위한 커널이 없기 때문이다. 같은 주, 같은 목표를 가진 두 프로젝트, 그리고 그중 하나만 깔끔하게 포팅되었다. 그 차이가 바로 이 이야기이며, 이는 모델 이야기가 아니라 런타임 이야기다.

오늘 이 글이 가치 있는 이유는 Laya가 새롭기 때문이 아니다. 2026-09-19까지는 PyTorch 스택을 함께 끌고 오지 않고서는 Mac에서 타입 지정 결정 모델을 실행할 방법이 없었다는 점, 그리고 독자가 실제로 품는 질문 — 이걸 내 노트북에서 실행할 수 있을까, 그리고 무엇을 포기하게 될까 — 에 마침내 측정 가능한 답이 생겼다는 점이다. 그래서 이 글은 서빙 경로, 그 뒤의 숫자들, 그리고 숫자들이 더 이상 겉모습대로의 의미를 지니지 않게 되는 지점들에 관한 것이다.

먼저, Laya가 아닌 것

Laya는 LLM이 아닙니다. 비자기회귀적입니다. 즉, 상태와 여러분의 질문에 대해 양방향 순방향 패스를 한 번 수행하면 타입이 지정된 답변이 나옵니다. 토큰 단위 디코딩도, 사고의 연쇄도, 파싱할 생성된 JSON도, 과금할 출력 토큰도 없습니다. 세 가지 답변 프리미티브는 choice (N개의 명명된 옵션 중 하나 선택), score (서수 평가 척도 수준), noul (어떤 것이 사실일 확률을 보정한 값)입니다.

이는 이 글의 모든 숫자를 여러분이 어떻게 읽어야 하는지에 중요합니다. 포트가 13.42 ms를 보고할 때, 그것은 생성 벤치마크가 그러하듯 몇백 개의 토큰을 생성하는 데 13.42 ms가 걸린다고 보고하는 것이 아닙니다. 그것은 전체 작업을 보고하는 것입니다. 결정 모델의 지연 시간을 LLM의 초당 토큰 수와 비교하는 것은 서로 다른 두 작업을 비교하는 것이며, 그렇게 하는 모든 글 — 출시 후 퍼진 화제의 "Jev보다 50배 빠름" 게시물을 포함해 — 은 기반 작업이 뒷받침하지 않는 주장을 하는 것입니다.

포트가 실제로 측정한 것

이 수치는 포트 작성자 본인의 것으로, 명시된 머신에서 측정한 것이므로 머신과 방법을 함께 제시한 상태로 읽어야 합니다. Laya-MLX는 40개의 GPU 코어와 128 GiB 통합 메모리를 갖춘 M3 Max에서 FP16으로 측정했으며, 모델 로딩은 제외했습니다.

• 짧은 질문 하나, P50 — 421M 영어 체크포인트에서 13.42ms, 322M 다국어 체크포인트에서 7.39ms.

• 짧은 질문 하나, P95 — 각각 13.92ms와 7.79ms입니다.

• 50개 질문 처리량 — 초당 146.8개 질문 및 초당 395.0개 질문

• 최대 MLX 할당량 — 943.6 MiB 및 687.6 MiB.

타이밍 경계는 두 번 읽어볼 가치가 있는 부분이다. 여기에는 프롬프트 준비, 토큰화, 텐서 구성, 동기화된 추론, 캘리브레이션 및 결과 포맷팅이 포함된다. 모델 로딩은 제외된다. 50개 질문 처리량 실행에는 batch_size=64를 사용했지만, API 기본값은 16이므로 이 숫자 쌍은 단일 대화형 호출에 드는 비용이 아니라 의도적으로 배치 처리된 워크로드를 설명한다. 입력 길이, 질문 수, 런타임 조건이 다르면 모두 결과가 달라진다. 이러한 주의 사항이 숫자와 벤치마크의 차이이며, 포트 자체가 이를 명시한다.

메모리 하한은 대부분의 독자가 실제로 행동에 옮길 수치이며, 이 세트에서 가장 모호하지 않은 값입니다. 두 체크포인트 모두에서 짧은 질문 하나에 대한 최대 MLX 할당량이 1기가바이트 미만입니다. 이는 Mac의 전체 메모리 사용량에 대한 주장이 아닙니다 — OS, 터미널, Python 프로세스도 함께 자리 잡고 있습니다 — 하지만 이는 진정한 하한이며, 중간 규모 생성 모델을 로컬에서 실행할 때 요구되는 양보다 대략 세 자릿수 낮습니다.

충실도 검사가 더 흥미로운 결과다

자신이 이식한 모델과 다르게 답하는 빠른 포트는 가치가 없으며, 바로 이 지점에서 이 프로젝트는 중요한 작업을 해냈습니다. 세 체크포인트 모두 FP32와 FP16 양쪽에서 63개의 검증 질문 중 63개에서 업스트림이 선택한 답과 일치했습니다 — 378번의 비교 중 378번입니다. 각 구성은 또한 측정된 활성 메모리 증가 없이 100번의 반복적이고 결정론적인 호출을 실행했으며, 공개된 36개 가중치 파일 모두 엄격한 원격 체크섬 검증을 통과했습니다.

범위를 솔직히 읽어 보세요. 그것은 그 픽스처들에 대한 충실도를 측정하는 것이지, 가능한 모든 질문에 대한 정확도를 측정하는 것이 아닙니다. 그것은 그 포트가 Laya에 충실하다는 것을 알려 줍니다. Laya가 옳은지에 대해서는 아무것도 알려 주지 않습니다.

독립적이며 커뮤니티가 유지 관리하고, 여전히 목록에 없습니다.

이 이식판은 자신에 대해 두 번 이렇게 밝힙니다: 독립적인 MLX 이식판이며, 공식 Convai Innovations 릴리스가 아닙니다. RLCD 학습과 파인튜닝은 업스트림에 남습니다. 가중치는 Convai Innovations의 공로로 표기됩니다. 양쪽 모두 Apache-2.0입니다.

업스트림이 이를 어떻게 대하는지는 그 어떤 면책 조항보다 더 많은 것을 드러냅니다. Laya README에는 커뮤니티 도구 목록이 있으며, 2026-09-23 기준으로 네 개의 항목이 들어 있습니다: omp-laya-judge, laya-adk-toolkit, laya-Ascend는 Huawei Ascend NPU용이며, 그리고 laya-apple — MLX GPU와 Neural Engine을 사용하는 Apple Silicon용 런타임입니다. 네 번째 항목은 2026-09-23에 병합된 풀 리퀘스트 #260을 통해 추가되었습니다. 이 기사에서 다루는 포트는 그 네 가지 항목에 포함되어 있지 않습니다. 업스트림의 목록은 이제 Apple Silicon 독자들을, 가장 먼저 출시되었고 벤치마크를 보유한 프로젝트가 아닌 다른 커뮤니티 프로젝트로 안내합니다.

업스트림의 자체 이슈 트래커가 나머지를 말해 줍니다. 2026-09-21에 열린 이슈 #50 "Apple silicon ports"는 아직 열려 있으며, 메인테이너는 같은 날 Apple Silicon 지원이 추적되고 있고 Laya-MLX 같은 커뮤니티 포트가 네이티브 Metal 추론을 탐색 중이라고 답했고, 2026-09-23에 다시 한 줄을 덧붙였는데 그대로 인용할 만합니다: "MLX 포트는 계속 커뮤니티에서 유지관리합니다." PyTorch 쪽 수정 — MPS autocast와 transformers 4.x RoPE 교정 — 은 풀 리퀘스트 #273으로 반영되어 2026-09-23에 병합되었고, 그 스레드의 한 리뷰어는 여전히 #109의 별도 autocast 리팩터와 결합해야 한다고 지적했으며 #109는 아직 열려 있습니다. 그리고 2026-09-21에 열린 이슈 #52는 몇 시간 작동하는 동안 대략 21.7GB의 Metal 메모리로 커진 Laya-MLX 사이드카를 보고하는데, vmmap은 약 21.4GB를 Python 힙이 아니라 그래픽 하위 시스템에 귀속시키며, 할당자 캐시에 상한을 두고 각 추론 후에 비울 것을 제안하고 있으며, 아직 열려 있습니다.

이것들을 종합하면 실질적인 답은 이렇습니다. 이 런타임은 업스트림의 공식 인정을 받은 것이 아니라, 유지관리자 본인의 설명에 따르면 커뮤니티에서 유지관리되며, 장기 실행 사이드카에 중요한 단 하나의 메모리 문제는 릴리스에서 수정되기보다는 공개적으로 작업 중입니다.

노트북에서 실행할 수 있나요? 그리고 무엇을 포기해야 하나요?

설치는 pip 명령 하나면 되고, 이 포트는 미리 변환된 FP16 가중치를 배포하므로 직접 아무것도 변환할 필요가 없습니다:

pip install laya-mlx

그런 다음 import laya_mlx as laya, agent = laya.load("aac6fef/laya-mlx"), 그리고 agent.predict(state, questions)를 호출합니다. 요구 사항은 Apple Silicon, Python 3.11+ 및 macOS 14+입니다. 측정 환경은 macOS 27.2, Python 3.12.13 및 MLX 0.32.2였으며 — 이식 작업은 사용한 MLX 릴리스가 macOS 14, 15 및 26용 휠을 제공했지만 설치 프로그램이 26을 선택했고, 해당 머신에서는 지원되는 이전 macOS 버전이 테스트되지 않았다고 언급합니다.

당신이 포기하게 되는 것, 차원별로:

• FP16 대 FP32 — FP16이 기본값이며 위의 모든 핵심 수치의 근거입니다. FP32는 업스트림과의 수치적 일치가 더 가깝고, 선택된 레이블이 일치하더라도 정밀도에 따라 확률이 약간 다를 수 있습니다. BF16을 요청할 수 있지만 공개된 검증 매트릭스에는 포함되지 않으므로 테스트되지 않은 것으로 간주하십시오.

• 메모리 최저선과 여유 공간 — 짧은 질문에 대해 MLX 최대 할당량이 1 GiB 미만이면 어떤 M 시리즈 Mac에서도 쾌적합니다. 이는 지속적인 서버 부하에 관한 진술이 아니며, 이를 라이브러리 호출이 아니라 장기 실행 사이드카로 돌릴 계획이라면 issue #52가 주의해야 하는 이유입니다.

• 다국어 대 영어 — 322M 다국어 체크포인트는 둘 중 더 빠르고 100개 이상의 언어를 지원하는 쪽이지만, 이 포트는 업스트림의 경고를 의도적으로 그대로 전달합니다: 영어 체크포인트는 다국어 체크포인트를 대체할 수 없습니다. 이들 사이의 라우팅은 의도된 패턴이며, 단순한 편의 기능이 아닙니다.

• 업스트림에서 공식 승인한 것 대 커뮤니티가 유지보수하는 것 — 후자입니다. 업스트림 릴리스 노트에는 이 포트가 업스트림 변경에도 계속 작동한다는 약속이 없습니다.

• 속도 대 보정 — 빠른 이식은 지나치게 확신하는 채로 배포되는 보정 버킷을 고치지 못합니다. 업스트림은 적합된 온도를 [0.5, 5.0]으로 제한하며, 배포된 choice:11+ 버킷은 0.1006인데, 이는 로짓을 대략 열 배로 날카롭게 만들고 동전 던지기를 거의 확실한 것으로 보고하게 됩니다. 적합된 보정 온도가 존재하는 데는 이유가 있습니다; 확률에 따라 분기하기 전에 자체 홀드아웃 데이터로 적합시키세요.

업스트림 자체 트래커에서 나온 두 가지 제한을 더 기억해 둘 만합니다. action.act_probability는 현재 쓸 만한 신호를 담고 있지 않습니다 — 거의 모든 입력에서 1.0을 반환하며, 원시 로짓은 396개의 라벨링된 결정 전반에서 정확도 대비 AUROC 0.30을 기록했습니다(이슈 #185). 대신 confidence에 게이트를 걸면 같은 항목에서 0.77에 도달합니다. 그리고 noul 질문은 상태가 아니라 옵션 라벨을 따라갈 수 있습니다(이슈 #156) — 업스트림 자체 카드는 명백히 긍정적인 입력에서 확신에 찬 '아니오'를 보고하며, 영어 체크포인트에서 가장 두드러집니다. 제안하는 우회 방법은 다른 모델을 찾는 것이 아니라 질문의 형태를 바꾸는 것입니다: choice를 가진 두 옵션으로 질문하되 중립적인 키(A/B)를 사용하고, 예/아니오 표현은 옵션 설명으로 넣으세요.

왜 하나의 의사결정 모델은 깔끔하게 이식되는데 다른 하나는 그렇지 않은가

여기서의 대비는 구조적인 것이며, 두 제품군 중에서 선택하려는 사람에게 이 글에서 가장 유용한 부분이다.

Laya의 백본은 ModernBERT-large로, 전적으로 어텐션으로 구성된 양방향 인코더입니다. 어텐션은 Apple의 GPU 스택이 가장 잘하는 것이자 MLX가 공을 들여온 부분입니다. 그래서 이 포팅은 이미 빠른 경로가 마련되어 있던 레이어들을 재구현한 것입니다. 인코더, 결정 헤드의 Transformer 레이어, 스코어링 헤드, 액션 헤드가 모두 MLX에서 실행되며, 토큰화는 여전히 Hugging Face의 Rust 토크나이저를 거칩니다.

Kev의 백본은 Qwen3.5 베이스이며, Qwen3.5는 어텐션 레이어와 Gated DeltaNet 레이어를 혼합한다. DeltaNet은 순환적이고 어텐션 마스크를 무시한다. 여기에는 두 가지 결과가 따른다. 첫째, 각 질문은 하나의 마스크된 시퀀스를 공유하는 대신 자체 행으로 실행되어야 하며, Kev 프로젝트는 상태를 한 번 계산한 뒤 행마다 해당 캐시를 재사용하는 방식으로 이를 처리한다. 둘째 — 그리고 이것이 Mac에서 문제가 되는 부분인데 — Apple GPU에는 해당 레이어용 PyTorch 커널이 없어서 PyTorch가 참조 코드로 폴백했다. jaredpalmer/kev-4b 모델 카드에는 그로 인한 한계가 여전히 쉬운 말로 적혀 있다: Kev-4B의 Qwen3 빌드에서 0.17초가 걸리는 5개 질문 요청이 M5에서는 bf16으로 0.78초가 걸린다.

그것을 인용하기 전에 현재 문구를 확인하세요. 문구가 바뀌었기 때문입니다. Kev 저장소 README에는 이제 서버가 Apple Silicon에서 MLX를 통해 Qwen3.5 모델을 실행한다고 나와 있으며, 대략 270토큰 상태에서 각각 세 가지 선택지가 있는 5개 질문 요청에 대한 자체 M5 수치를 게시합니다: Kev-4B는 새로운 상태에서 721ms, 프리픽스 캐시를 통한 반복 상태에서 136ms를 기록한 반면, PyTorch bf16 MPS 경로에서는 3,302ms와 847ms를 기록합니다. Kev-0.8B는 149ms와 28ms를 기록합니다. 이전 세대 Qwen3 모델은 여전히 일반 PyTorch MPS에서 실행되며, 프로젝트에서는 이들을 Mac에서 좋은 선택이라고 부릅니다.

그것을 경주 결과로 바꾸지 않도록 주의하세요. 이것들은 맞대결 측정이 아닙니다. Laya-MLX의 13.42ms는 M3 Max에서의 짧은 질문 하나이고, Kev의 721ms는 M5에서 약 270토큰 상태에 대해 각각 세 개의 선택지를 가진 다섯 개 질문입니다. 질문 수가 다르고, 선택지 수가 다르고, 상태 길이가 다르고, 기계가 다르고, 런타임이 다릅니다. 검증 가능하고 비교할 가치가 있는 것은 승자가 아니라 문제의 형태입니다. 순수 어텐션 인코더는 Apple Silicon에 별 저항 없이 이식되지만, 하이브리드 선형 어텐션 모델은 그곳에서 사용 가능해지기까지 완전히 두 번째 백엔드가 필요했습니다.

의사 결정 모델의 실제 용도

벤치마크를 걷어내고 나면 솔직한 활용 범위는 좁으며, 프로젝트 스스로도 그렇게 말한다. Laya는 특화하기 위한 빠른 기반이지, 제로샷 의사결정 엔진이 아니다. Convai 자체의 typed-decisions 벤치마크에서 두 기본 체크포인트는 제로샷으로 0.362와 0.342를 기록했는데, 이는 다수 클래스 기준선 0.461과 무작위 기준선 0.318에 맞선 결과다. 이는 항상 가장 흔한 레이블로 답했을 때 얻는 기준선보다 낮다. 대표 수치인 0.766은 laya-typed-decisions, 즉 해당 벤치마크 자체의 학습 분할로 파인튜닝된 체크포인트의 것이며, 이를 일반적인 성능으로 인용해서는 결코 안 된다.

Convai가 TypeSafe Jev 1.13.0에 대해 공개한 비교는 바로 이런 이유로 읽어볼 가치가 있으며, 그쪽에서는 이를 신중하게 표시해 두었습니다. 모든 Laya 수치는 라우터가 실제로 반환하는 값이고, Jev 수치는 Convai가 TypeSafe API에 접근할 수 없어 직접 측정한 적이 없는 제3자 공개 수치입니다. 그 비교에서 라우팅된 Laya는 typed-decisions에서 Jev의 0.727에 맞서 0.766을 기록하고, post-temperature ECE는 0.246에 맞서 0.081이며, Tesla T4에서 p50 지연 시간은 236–276 ms에 맞서 32.8 ms입니다. 한 질문에서 7.8배 차이입니다. 인용할 숫자는 바로 이것입니다. 소셜 미디어에 퍼진 "Jev보다 50배 빠르다"는 수치는 프로젝트의 문서나 벤치마크에 나오지 않으며, 프로젝트가 직접 공개한 비교도 이를 뒷받침하지 않습니다. Jev는 앞서는 곳에서는 앞섭니다. Banking77에서 Jev는 Laya의 0.425에 맞서 0.870을 기록하는데, 이는 Laya의 옵션들이 고정된 토큰 예산을 공유하고 77개 레이블이 각각 대략 3~4개 토큰만 남기기 때문입니다.

그래서 실제 배포의 형태는 저렴하고 로컬이며 범위가 좁은 결정 헤드 — 티켓 라우팅, 긴급도 점수화, 예/아니오 게이트 응답 — 이고, 그 뒤에 쓰기가 필요한 부분을 위한 생성형 무언가가 있습니다. 결정 모델은 밀리초 단위로 타입이 지정된 호출을 내리고 에스컬레이션합니다. 생성형 절반은 다른 런타임 위의 다른 모델이며, 바로 이 지점에서 라우터가 존재 가치를 발휘합니다: 하나의 키로 200개 이상의 모델을 공급자 정가 그대로, 마크업 없이, 그래서 공급업체 가격 변경이 같은 날 반영되고, 실행 중 공급자가 성능 저하를 보일 때 자동 장애 조치. OrcaRouter는 Laya를 서비스하지 않으며, Kev나 Jev도 서비스하지 않습니다 — Qwen3.5 제품군은 우리 모델 목록에 있지만, 결정 모델 자체는 목록에 없습니다. 우리가 커버하는 것은 그 스택의 생성형 절반이며, 이는 결정 헤드가 에스컬레이션하는 모든 요청에서 여러분이 호출하는 절반입니다.

두 부분을 하나의 모델로 모두 처리하려 하기보다 분리해 두는 데에는 또 하나의 이유가 있다. 출력 토큰을 전혀 소비하지 않고 네트워크에 전혀 접속하지 않는 로컬 결정 헤드는 API 호출과는 다른 종류의 의존성이다. 네트워크가 안 될 때도 계속 작동하며, 그 비용은 읽는 텍스트 양에 비례해 늘어나지 않는다. 바로 그 속성이 값을 지불할 가치가 있는 속성이다. 이 글의 나머지 모든 내용은 충실도, 메모리, 유지보수 측면에서 그 대가로 얼마를 치르는지에 관한 것이다.

누가 그것을 실행해야 하며, 누가 기다려야 합니까?

M 시리즈 Mac을 사용 중이고, 결정이 제한적인 상황 — 명명된 옵션 중 선택, 루브릭 점수, 예/아니오 게이트 — 이며, 파인튜닝할 레이블이 있거나 캘리브레이션 온도를 직접 맞출 준비가 되어 있다면 Laya-MLX를 실행하세요. 설치는 명령 하나면 되고, 메모리 최소 요구량은 1기가바이트 미만이며, 충실도 작업은 이미 완료되어 공개되었습니다.

업스트림 지원 보장이 필요하거나, 장기 실행 사이드카를 운영하며 메모리 증가 문제가 열린 이슈가 아니라 릴리스에서 해결되기를 바라거나, 질문이 개방형이라면 기다리세요. "다음에 무엇을 해야 하나요?"에 답하는 비자기회귀 인코더는 같은 일을 하는 LLM의 더 작은 버전이 아닙니다. 그것은 다른 도구이며, 질문이 이미 그것에 맞게 형성되어 있을 때만 잘 읽어냅니다.