WebAssembly에서 Apple Silicon GPU 추론, '제로 카피'는 어디까지 진짜인가

최근 공개된 "Zero-Copy GPU Inference from WebAssembly on Apple Silicon"은 WebAssembly에서 만든 데이터를 Apple Silicon의 GPU 추론 경로로 복사 없이 넘길 수 있다는 가능성을 보여줬습니다.¹ 지금 이 얘기가 중요한 이유는 단순합니다. 브라우저·하이브리드 앱·로컬 AI 도구가 모두 "맥에서는 메모리 복사가 거의 공짜일 것"이라는 기대 위에 설계되기 시작했기 때문입니다.

하지만 Apple Silicon의 통합 메모리는 마법이 아닙니다. CPU와 GPU가 같은 물리 메모리를 쓴다고 해서, JavaScript↔WASM, WASM↔네이티브 브리지, 텐서 레이아웃 변환, GPU 바인딩 과정의 복사가 저절로 사라지지는 않습니다. 실무에서 중요한 질문은 "제로 카피가 가능한가"보다 "내 병목이 어느 경계에 있나"입니다.

'제로 카피'는 하나가 아니라 경계마다 따로 봐야 한다

여기서 가장 많이 생기는 오해는 용어를 한 덩어리로 보는 겁니다.

Apple Silicon에서 MLX가 빠른 이유로 자주 언급되는 것은 통합 메모리입니다. MLX 쪽 설명은 CPU와 GPU가 공유 메모리를 쓰므로 별도 이동 비용이 줄어든다고 말합니다.² 실제로 Apple용 추론 엔진들은 이 점을 전면에 내세웁니다. ZINC는 Apple Silicon 경로에서 "zero-copy mmap"을 강조하고,³ SwiftLM도 "불필요한 메모리 복사 없음"을 성능 포인트로 내겁니다.⁴

하지만 이건 "CPU 메모리와 GPU 메모리가 분리된 PC보다 유리하다"는 뜻에 가깝습니다. 곧바로 "WASM에서 GPU까지 전체 파이프라인이 복사 없음"을 뜻하지는 않습니다. 예를 들어 토크나이징 결과를 WASM 메모리에 만들고, 이를 Metal이 읽기 좋은 버퍼나 다른 텐서 형식으로 다시 잡는 순간 이미 재구성이 들어갑니다. 복사가 사라진 게 아니라 복사 지점이 덜 눈에 띄게 바뀐 셈입니다.

실무적으로는 "제로 카피 to what?"을 따져야 합니다.
WASM 힙까지 제로 카피인지, 네이티브 버퍼까지 제로 카피인지, GPU 커널이 추가 재배치 없이 읽는지, 이 셋은 전혀 다른 문제입니다.

진짜 비용은 종종 WASM보다 형식 변환과 스케줄링에 있다

현실의 추론 경로는 생각보다 깁니다. 입력 문자열이 토큰이 되고, 토큰이 텐서가 되고, 텐서가 GPU 친화적인 레이아웃으로 바뀌고, 커맨드 버퍼에 실리고, 결과가 다시 CPU 쪽 후처리로 돌아옵니다. 여기서 숨어 있는 비용은 대개 세 가지입니다.

첫째, 레이아웃 변환입니다. 통합 메모리 위에 있어도 GPU 커널이 원하는 정렬·stride·dtype이 아니면 다시 materialize됩니다. MLX가 작은~중간 모델에서 llama.cpp보다 20~87% 빠르다는 비교가 있었지만, 큰 모델로 갈수록 격차가 줄어드는 이유도 결국 메모리 대역폭과 데이터 흐름 설계 쪽에 있습니다.²

둘째, 런타임 래퍼 오버헤드입니다. 같은 Apple Silicon에서도 어떤 레이어를 거치느냐에 따라 성능 차이가 꽤 납니다. 한 분석은 Ollama의 Apple Silicon 경로에서 래퍼 오버헤드가 체감 성능을 크게 깎을 수 있다고 지적했습니다.⁵ 즉, 복사를 한 번 줄이는 것보다 얇은 실행 경로를 고르는 편이 더 큰 개선일 수 있습니다.

셋째, 긴 문맥과 KV 캐시 처리입니다. 이 구간은 "입력 데이터를 GPU로 넘기는 비용"보다 훨씬 비싸질 수 있습니다. SwiftLM이 KV 캐시 압축과 SSD 스트리밍 같은 기법을 강조하는 이유도 여기에 있습니다.⁴ 이런 워크로드에서는 제로 카피보다 캐시 압축, 스트리밍, 커널 설계가 더 큰 승부처입니다.

따라서 프로파일링 없이 "WASM이 느리니 제로 카피를 붙이자"는 판단은 위험합니다. 병목이 토크나이저, 문자열 처리, 레이아웃 변환, 프리필, KV 캐시 중 어디인지 먼저 봐야 합니다.

브라우저, 네이티브 래퍼, 순수 네이티브: 같은 목표에 다른 해답

선택지는 크게 셋입니다.

브라우저 중심이라면 WASM+WebGPU 혹은 WASM+브리지 경로의 장점은 배포성과 샌드박스입니다. 다만 이 경로는 디버깅 편의성과 이식성은 좋지만, 숨은 복사와 API 제약을 가장 많이 만나는 편입니다. "가능하다"와 "최선이다"는 다릅니다.

네이티브 앱 안에 WASM을 넣는 구조는 절충안입니다. 비즈니스 로직이나 전처리는 WASM으로 재사용하고, GPU 추론만 Metal/MLX에 가깝게 붙일 수 있습니다. 이 경우 제로 카피 최적화가 실제로 먹힐 가능성이 높습니다. 경계가 줄고, 메모리 소유권도 더 명확해지기 때문입니다.

반대로 목표가 최고 처리량이라면 WASM을 우회하는 편이 맞을 때가 많습니다. Apple Silicon에서 MLX, Metal, 혹은 이를 바탕으로 만든 네이티브 엔진들은 이미 통합 메모리와 Metal 커널 튜닝을 전제로 움직입니다.³⁴⁶ 최근 vLLM Metal 플러그인도 Apple Silicon에서 MLX를 백엔드로 끌어들여 TTFT와 처리량 개선을 내세우고 있습니다.⁷ 이 흐름은 분명합니다. Apple 쪽 성능 상한은 점점 "웹 이식성"보다 "네이티브 데이터플로 최적화"에서 열리고 있습니다.

언제 제로 카피를 집요하게 추구해야 하나

판단 기준은 의외로 단순합니다.

입력이 원래 브라우저 안에서 생성되고, 매 요청마다 큰 텐서나 멀티모달 데이터를 넘겨야 하며, 짧은 상호작용 지연이 중요하다면 제로 카피는 worth it입니다. 카메라 프레임, 오디오 청크, 실시간 임베딩처럼요.

반대로 LLM 채팅처럼 한 번 모델이 올라간 뒤 병목이 프리필·디코드·KV 캐시로 이동하는 경우, 제로 카피만으로는 체감 개선이 제한적일 수 있습니다. 이때는 양자화, 캐시 압축, 연속 배칭, 긴 컨텍스트 최적화가 더 중요합니다.

결국 이 주제를 지금 신경 써야 하는 사람은 "브라우저에서도 GPU 추론을 붙일 수 있나?"를 묻는 팀보다, "우리 앱의 복사는 정확히 어디서 생기고, 그걸 줄이는 비용이 커널 최적화보다 큰가?"를 묻는 팀입니다. Apple Silicon은 분명 좋은 출발점이지만, 통합 메모리는 설계 실수를 가려줄 뿐 없애주진 않습니다.

참고

¹Zero-Copy GPU Inference from WebAssembly on Apple Silicon

²MLX vs llama.cpp on Apple Silicon: Which Runtime to Use for Local LLM Inference | Groundy

³GitHub - zolotukhin/zinc: Zig INferenCe Engine -- Local LLM inference on AMD GPUs and Apple Silicon · GitHub

⁴GitHub - SharpAI/SwiftLM: ⚡ Native MLX Swift LLM inference server for Apple Silicon. OpenAI-compatible API, SSD streaming for 100B+ MoE models, TurboQuant KV cache compression, MACOS + iOS iPhone app. · GitHub

⁵MLX: The Next Inference Engine for Apple Silicon

⁶GitHub - ggml-org/llama.cpp: LLM inference in C/C++ · GitHub

⁷GitHub - vllm-project/vllm-metal: Community maintained hardware plugin for vLLM on Apple Silicon · GitHub