Laya Core ML, 생성 없이 로컬 결정을 내린다

토큰을 생성하지 않는 판단 모델

공유된 실행 Gist는 Apple M4 Mac에서 Laya-CoreML을 설치하고 Snake demo를 오프라인으로 실행하는 짧은 절차를 보여준다. 제목에는 초당 45 decisions가 적혔지만, 프로젝트 README의 현재 공식 측정은 uncapped 600-step episode 세 번에서 전체 active loop가 49.1~50.0 decisions/s를 유지했다고 밝힌다. 서로 다른 기기·실행 시점의 숫자를 하나의 보편 성능으로 섞어서는 안 된다.

Laya의 핵심은 자유로운 문장을 autoregressive하게 생성하지 않는다는 점이다. 개발자가 choice, ordinal score, boolean 성격의 noul 질문을 정의하면 모델이 선택지별 probability를 반환한다. 환불 요청 감지, 긴급도 판정, moderation gate처럼 출력 공간이 미리 정해진 업무에 맞는다. JSON을 생성한 뒤 parsing하고 schema를 재검증하는 경로를 줄일 수 있다.

프로젝트가 공개한 성능과 범위

README는 M3 Max, 91-token 질문, 96-token padding 조건에서 Core ML ANE FP16이 P50 4.98ms, P95 5.31ms였다고 보고한다. compiled MLX FP16은 6.94ms와 7.39ms였다. system energy per decision 추정은 각각 0.1540J와 0.4288J로, 프로젝트는 ANE가 2.78배 효율적이었다고 계산한다. W8 variant는 4.88ms와 0.1344J를 보고한다. 모두 프로젝트가 공개한 특정 장비·sensor·benchmark 결과이며 독립 검증값은 아니다.

상세 원자료는 ANE benchmark 문서와 repository의 raw result에 연결돼 있다. 일반 FP16 checkpoint는 선택된 189개 validation question에서 upstream answer와 189/189 일치했고, 짧은 ANE graph는 fitting question 59/59를 통과했다고 한다. 이것은 port fidelity 검사이지 업무 정확도 100%의 증명이 아니다.

96토큰 한계가 제품 모양을 정한다

빠른 ANE bundle은 질문·선택지·상태를 모두 합쳐 96-token limit가 있다. 더 긴 request는 capacity error를 내며, 1,024-token general model은 CPU+GPU 경로를 쓴다. 프로젝트가 별도 export한 ANE L1024 graph도 실제 긴 입력에서 약 91.7ms가 걸렸다고 밝힌다. 짧은 benchmark를 긴 문서 분류 성능으로 확대할 수 없는 이유다.

Apple Core ML 개요는 on-device inference와 hardware 활용을 설명하지만, 실제 Neural Engine 배치는 graph shape와 operator에 달려 있다. Laya port는 BC1L activation, 1×1 projection, per-head attention으로 graph를 다시 구성했고 CPU가 입출력 경계를 처리한다고 적는다. 단순히 compute unit flag 하나를 바꿔 같은 결과가 나온 것은 아니다.

생성형 AI와 경쟁하지 않는 자리

Laya-CoreML은 복잡한 보고서 작성이나 열린 질문에 답하는 모델이 아니다. 오히려 큰 agent 앞단과 뒷단의 작은 판단기로 적합하다. 예를 들어 email이 긴급한지, action이 승인을 요구하는지, sensor state가 세 등급 중 어디인지 로컬에서 판정하고 애매한 경우만 cloud LLM으로 보낼 수 있다. 개인정보가 기기를 떠나는 횟수와 API 비용을 동시에 줄일 가능성이 있다.

이는 애플 Neural Engine, 50GB/s를 되찾다, litelm, LLM 라우팅의 작은 코어를 꺼내다, 에이전트 CAD, 렌더보다 검증이 중요하다와 같은 설계 철학이다. 생성 능력을 모든 단계에 쓰지 않고, 작은 결정·routing·verification을 명시적 interface로 분리하는 것이다.

한국 개발팀의 검증 체크리스트

도입 전에는 대상 Mac model과 macOS version에서 warmup을 분리한 latency를 다시 재야 한다. 평균만 보지 말고 P50·P95·cold start·peak memory·배터리 소비를 기록해야 한다. 입력이 96-token을 넘을 때 truncate하지 말고 명시적으로 fallback해야 하며, probability calibration이 한국어 업무 데이터에서도 유지되는지 확인해야 한다. Hugging Face weight bundle의 pinned revision과 checksum도 배포 manifest에 남겨야 한다.

자주 묻는 질문

Q1: Laya-CoreML은 LLM인가요?

A: 수억 parameter의 open-weight model을 쓰지만 사용 방식은 텍스트 생성이 아니라 미리 정의한 질문에 probability를 내는 typed decision에 가깝다.

Q2: 초당 45~50회는 모든 Mac에서 나오나요?

A: 아니다. Gist의 M4 관찰과 프로젝트의 M3 Max benchmark는 조건이 다르다. 기기·OS·graph·입력 길이별로 재측정해야 한다.

Q3: 인터넷 없이 동작하나요?

A: weight를 한 번 내려받은 뒤 local directory나 cache를 강제하면 inference는 offline으로 실행할 수 있다고 문서가 설명한다.

Q4: 96토큰보다 긴 문서는 어떻게 하나요?

A: 일반 1,024-token model이나 다른 runtime으로 보내야 한다. 무음 truncate는 판단 오류를 숨기므로 권장하기 어렵다.

Q5: 가장 적합한 업무는 무엇인가요?

A: 선택지가 좁고 반복이 많으며 latency·privacy가 중요한 routing, urgency, moderation, device control 같은 판단 업무다.