모든 걸 생성하지 않아도 된다: 맥북에서 13ms로 결정하는 Laya-MLX

LLM에게 매번 문장을 쓰게 하는 건, 선택지 세 개를 고르는 데 너무 비싸다

고객 문의가 들어왔다. “환불해줘.” 이 문장을 읽고 해야 할 일은 대개 정해져 있다. 담당 부서를 고르고, 긴급도를 매기고, 환불 요청인지 확인하면 된다. 그런데 우리는 이 간단한 판단을 거대한 생성형 모델에 맡긴다. 모델은 답변을 만들고, 우리는 그 답변에서 다시 JSON을 뽑고, 값이 맞는지 검증한다.

이 과정은 유연하지만 느리고 비싸다. 특히 로컬에서 처리하고 싶거나, 고객 데이터가 외부 API를 떠나면 안 되거나, 초당 수십 건의 분류가 필요한 순간에는 “말을 잘하는 모델”이 정답이 아닐 수 있다. 필요한 건 새로운 문장이 아니라 허용된 선택지 중 하나와 그 확률이기 때문이다.

이번에 눈에 들어온 mizorewww/laya-mlx는 이 지점을 정확히 겨냥한다. Apple Silicon에서 Laya typed decision 모델을 MLX로 실행하는 독립 포트다. 핵심은 “작은 LLM”이 아니다. 생성을 건너뛰고, 질문의 타입을 미리 정한 뒤, 결정 결과만 받는 실행기라는 데 있다.

외부 정보: Laya-MLX는 텍스트를 생성하지 않고 typed decision을 계산한다

프로젝트 README가 설명하는 흐름은 간단하다.

state + typed question → bidirectional encoder → decision heads → probabilities

상태(state)는 이메일, 티켓, 일반 텍스트, JSON, 대화 목록이 될 수 있다. 여기에 타입이 있는 질문을 붙인다. choice는 여러 선택지의 확률을, score는 순서가 있는 등급과 기대 점수를, noul은 어떤 명제가 참일 확률을 반환한다. “누가 처리할까?”, “얼마나 긴급할까?”, “환불을 요청했나?”처럼 업무에서 반복되는 질문들이다.

여기서 중요한 차이가 있다. 일반적인 LLM은 JSON을 출력하더라도 결국 토큰을 하나씩 생성한다. Laya는 bidirectional encoder와 decision head를 사용해 정해진 형태의 결과를 계산한다. 출력 토큰이 0개라는 설명은 기능이 부족하다는 뜻이 아니라, 애초에 긴 답변을 만들지 않는다는 뜻이다.

질문	생성형 LLM 방식	Laya typed decision 방식
담당 부서는?	문장 또는 JSON 생성 후 파싱	choice 확률 분포
긴급도는?	설명문에서 점수 추출	score 등급과 기대 점수
환불 요청인가?	“예/아니오” 문장 생성	noul의 P(true)
실패 처리	출력 형식 오류를 별도 검증	허용된 타입·선택지 안에서 검증

프로젝트는 Apple Silicon과 Python 3.11 이상, macOS 14 이상을 대상으로 한다. 처음 모델을 불러올 때 체크포인트를 내려받지만, 이후 추론은 로컬에서 실행된다. MLX는 Apple Silicon의 통합 메모리를 활용하도록 설계된 Apple의 오픈소스 머신러닝 프레임워크다. 그래서 이 조합은 “서버를 하나 더 붙이는 로컬 AI”라기보다, 이미 책상 위에 있는 Mac을 판단 엔진으로 쓰는 접근에 가깝다.

13밀리초라는 숫자보다 중요한 것은 ‘판단의 모양’을 고정하는 일이다

README의 M3 Max 측정에서 짧은 영어 typed decision 한 건의 FP16 중앙값은 13.42ms, 다국어 체크포인트는 7.39ms였다. 50개 질문을 한 번에 처리한 처리량은 각각 초당 146.8건과 395.0건으로 보고됐다. 측정에는 프롬프트 준비, 토큰화, 텐서 생성, 동기화된 추론, 보정, 결과 포맷팅이 포함되고 모델 로딩은 제외된다.

이 수치를 곧바로 “모든 Mac에서 13ms”라고 읽으면 안 된다. 측정 장비는 40코어 GPU와 128GB 통합 메모리를 가진 M3 Max였고, 입력 길이와 질문 수, 배치 크기에 따라 결과가 달라진다. 프로젝트의 벤치마크 문서도 한 대의 개발 머신에서 한 번 실행한 로컬 측정이며, 다른 기기나 운영 환경의 성능을 보장하지 않는다고 명시한다.

그래도 이 숫자가 의미 있는 이유는 따로 있다. 분류 결과 하나를 얻기 위해 긴 문장을 생성하고 다시 파싱하는 단계를 없애면, 지연시간만 줄어드는 게 아니다. 결과가 어떤 모양이어야 하는지 업무 설계 단계에서 고정할 수 있다. 생성 모델의 자유도를 줄이는 대신, 시스템이 검증할 수 있는 선택지를 얻는 것이다.

실제 워크플로에 넣는다면, ‘답변 작성’이 아니라 앞단의 분기부터 맡겨라

Laya-MLX를 도입할 첫 자리는 고객에게 보낼 최종 답변이 아니다. 틀려도 사람이 바로 확인할 수 있고, 결과 형식이 좁고, 반복 빈도가 높은 앞단의 분기다.

1. 문의 라우팅. 이메일이나 티켓을 billing, technical, sales 같은 담당 부서로 나눈다.
2. 위험도 분류. 일반 문의, 빠른 확인, 즉시 사람에게 넘길 사안처럼 순서가 있는 등급을 매긴다.
3. 정책 조건 확인. 환불 요청인지, 개인정보가 포함됐는지, 특정 약속을 요구하는지 확률로 확인한다.
4. 다음 도구 선택. 분류 결과를 바탕으로 검색·조회·초안 생성 등 다음 단계의 도구를 고른다. 단, 외부 상태를 바꾸는 실행은 별도의 승인 뒤에 둔다.

예를 들어 다음처럼 시작할 수 있다.

import laya_mlx as laya

agent = laya.load("aac6fef/laya-multilingual-mlx")
result = agent.predict(
    {"message": "청구서가 두 번 결제됐어요. 중복 결제를 환불해 주세요."},
    {
        "department": {
            "type": "choice",
            "instructions": "어느 팀이 처리해야 하나요?",
            "criteria": ["billing", "technical", "sales"],
        },
        "refund": {
            "type": "noul",
            "instructions": "고객이 환불을 요청했나요?",
        },
    },
)

print(result["answers"])

이 결과를 바로 고객에게 보내는 게 아니다. billing으로 라우팅하고 환불 요청 확률을 확인한 뒤, 정책 문서를 검색하고, 사람이 검토할 답변 초안을 만드는 식이다. Laya의 역할은 판단의 앞단을 빠르게 좁히는 것, 생성형 모델이나 사람의 역할은 그 뒤의 맥락과 표현을 책임지는 것이다.

로컬이라고 자동으로 안전해지는 것은 아니다

로컬 추론은 데이터가 외부 API로 나가지 않는다는 장점이 있다. 하지만 로컬이라는 말이 정확성이나 안전성을 보증하지는 않는다. 모델이 높은 확률을 냈다고 해서 그 판단이 반드시 옳은 것도 아니다. 프로젝트 README도 confidence가 accuracy를 보장하지 않는다고 선을 긋고, 영어 체크포인트를 다국어 모델의 대체품으로 쓰지 말라고 설명한다.

검증 결과도 범위를 좁혀 읽어야 한다. 프로젝트는 세 체크포인트 모두에서 준비된 63개 질문의 선택 결과가 upstream과 일치했고, FP16 반복 호출 100회에서 유한한 결과와 메모리 증가가 없었다고 보고한다. 이는 해당 fixture에서의 포팅 충실도와 안정성을 보여주는 자료이지, 세상의 모든 문의에 대한 정확도 증명은 아니다. AG News 256개 샘플의 예측 일치도 역시 작은 라벨된 샘플의 결과로 봐야 한다.

따라서 도입할 때는 확률의 최솟값보다 중단 규칙을 먼저 정해야 한다.

• 확률 차이가 작으면 자동 라우팅하지 않고 사람에게 보낸다.
• 새로운 언어·도메인·긴 입력은 별도 검증 세트로 확인한다.
• 환불, 삭제, 권한 변경, 외부 발송은 typed decision만으로 실행하지 않는다.
• 모델 선택 결과와 실제 정답을 기록해 주기적으로 재평가한다.
• FP16의 속도 이득이 필요한지, FP32의 수치 일치성이 필요한지 업무별로 결정한다.

결론: 모든 것을 생성하지 않는 AI가 오히려 운영에 잘 들어온다

Laya-MLX의 매력은 “Mac에서 돌아가는 또 하나의 LLM”이라는 데 있지 않다. 질문의 종류와 답의 범위를 미리 정하고, 그 좁은 문제를 로컬에서 빠르게 반복할 수 있다는 데 있다. 생성형 AI를 업무에 넣을 때 계속 따라오는 파싱, 형식 오류, 비용, 데이터 이동의 부담을 앞단에서 줄이는 방식이다.

내가 내리는 편집적 결론은 이렇다. LLM을 더 작은 모델로 바꾸는 것보다, 애초에 생성이 필요 없는 단계에서 생성하지 않는 것이 먼저다. 담당 부서, 등급, 조건, 다음 단계처럼 결과가 정해진 판단은 Laya-MLX 같은 typed decision 런타임으로 좁혀보고, 설명과 최종 문장 작성은 필요한 곳에만 생성형 모델을 남겨두자.

CTA: 오늘 반복되는 업무 하나를 골라서 “생성해야 하는가, 선택하면 되는가?”를 먼저 나눠봐. 선택이면 질문 타입을 choice, score, noul 중 하나로 적고, 로컬 Mac에서 작은 검증 세트를 만들어봐. laya-mlx 저장소의 Quick start와 BENCHMARKS.md를 읽고, 네 데이터에서 맞는 선택·틀린 선택·사람에게 넘겨야 할 선택을 직접 측정하는 것부터 시작하면 된다.

---

근거 출처

외부 정보 (하베스터 수집)

• mizorewww, laya-mlx GitHub 저장소 README. Laya-MLX의 목적, 설치 조건, typed decision 타입, Python API, 지원 체크포인트, 로컬 실행 방식, 독립 MLX 포트라는 설명의 근거.
• mizorewww, laya-mlx BENCHMARKS.md. M3 Max에서의 지연시간·처리량·메모리·포팅 일치도 측정과 측정 범위의 근거. 수치는 프로젝트가 공개한 로컬 벤치마크다.
• Apple Machine Learning Research, Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU. MLX가 Apple Silicon에 맞춰진 오픈소스 머신러닝 프레임워크이며 통합 메모리를 활용한다는 설명의 근거.
• Apple Developer, Get started with MLX for Apple silicon. Apple Silicon용 MLX의 공식 소개와 CPU·GPU 공유 메모리 구조에 대한 근거.
• Convai Innovations, Laya 모델 카드. Laya의 typed decision 모델 계열과 모델의 적용 범위·한계에 대한 참고 자료.

상호작용 (에이전트-드루 대화·작업)

이번 글 작성 과정에서는 laya-mlx를 실제로 설치하거나 개인 데이터로 추론을 실행하지 않았다. 따라서 본문은 사용 체험기나 자체 성능 측정이 아니다. 상호작용에서 얻은 내용은 외부 자료를 검토해 “분류·라우팅 단계부터 도입하자”는 편집적 판단과 워크플로 제안이며, 이를 개인 실행 경험이나 외부 통계로 포장하지 않았다.

외부 트렌드 raw signal은 글감 선정용 편집 신호일 뿐, 게시 승인이나 제품 성능의 근거가 아니다. 성능과 기능에 관한 주장은 위 외부 출처를 기준으로 확인했다.