최근 ZML이 Apple Metal에서 Llama.cpp보다 빠르다는 주장이 나왔습니다.1 흥미로운 지점은 단순한 순위 경쟁이 아닙니다. 더 중요한 변화는 AI 추론 스택이 점점 더 하드웨어 가까이 내려가고 있다는 점입니다.
ZML native Zig backend가 의미하는 것
ZML은 Zig, MLIR, Bazel 기반의 프로덕션 추론 스택입니다. 하나의 코드베이스로 여러 하드웨어에서 모델을 실행하는 것을 목표로 합니다.2
여기서 말하는 native backend는 특정 하드웨어 실행 경로를 더 직접적으로 다루는 구조에 가깝습니다. Python 중심 도구 위에 얹힌 래퍼라기보다, 메모리 사용과 커널 실행, 런타임 동작을 더 낮은 레벨에서 제어하려는 접근입니다.
이 점이 중요합니다. 로컬 AI 추론에서 성능은 모델 자체만으로 결정되지 않습니다. 같은 모델이라도 어떤 backend가 메모리를 옮기고, 커널을 호출하고, 토큰 생성을 처리하느냐에 따라 체감 속도가 달라집니다.
성능의 병목은 대개 “언어”보다 “메모리”에 있다
Zig로 작성된 Mac용 추론 엔진 MLX-Serve 사례도 같은 방향을 보여줍니다. MLX-Serve는 macOS와 Apple Silicon용 네이티브 AI 추론 엔진이며, 작성자는 AI 추론에서 메모리가 주요 병목이라고 설명했습니다.3
따라서 “Zig라서 빠르다”는 식의 설명만으로는 부족합니다. 실제 성능은 여러 요소가 함께 결정합니다.
메모리 이동 비용
KV 캐시 처리
커널 호출 방식
배치 처리
prompt 길이와 생성 토큰 수
디코딩 전략
MLX-Serve가 워크로드 유형에 따라 speculative decoding을 추가한 것도 이 맥락에서 볼 수 있습니다.3 speculative decoding은 작은 모델이 후보 토큰을 먼저 만들고 큰 모델이 검증해 생성 속도를 높이는 방식입니다. 즉, 현대 추론 backend의 경쟁은 단일 연산 최적화가 아니라 전체 생성 파이프라인 최적화에 가깝습니다.
Llama.cpp와 비교할 때 확인해야 할 것
ZML이 Apple Metal에서 Llama.cpp보다 빠르다는 주장은 주목할 만하지만, benchmark 결과는 조건을 함께 봐야 합니다. Llama.cpp의 Metal backend 역시 Metal 장치 관리, 버퍼 할당, 파이프라인 컴파일, 연산 인코딩, 커널 실행 등 여러 계층으로 구성된 복잡한 backend입니다.4
따라서 비교할 때는 다음 조건이 중요합니다.
모델 크기
양자화 포맷
prompt 길이
생성 토큰 수
배치 크기
메모리 압박 상태
사용한 backend와 실행 옵션
이 조건들이 달라지면 “더 빠르다”는 결론도 달라질 수 있습니다. 그래서 숫자 하나보다 중요한 것은 어떤 구조가 어떤 워크로드에서 강한지 이해하는 것입니다.
로컬 AI 운영자가 얻을 수 있는 교훈
Apple Silicon에서 로컬 AI를 진지하게 운영하려면 프레임워크 이름만 볼 것이 아니라 backend 구조를 봐야 합니다. ZML native Zig backend의 의미는 단순히 Llama.cpp보다 빠르다는 주장에 그치지 않습니다.
핵심은 추론 엔진이 더 낮은 레벨에서 최적화되고 있다는 흐름입니다. 메모리 병목을 줄이고, 하드웨어 실행 경로를 직접 다루며, 디코딩 전략까지 포함해 전체 파이프라인을 개선하는 방향입니다.
결국 ZML native Zig backend가 던지는 메시지는 명확합니다. 로컬 AI 성능 경쟁은 이제 모델 선택만의 문제가 아니라, backend가 하드웨어를 얼마나 효율적으로 활용하느냐의 문제입니다.
1ZML Outperforms Llama.cpp on Apple Metal With Native Zig Backend
3AI Inference engine built in Zig for Mac's, MLX-Serve - Showcase - Ziggit
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.