iPhone을 활용하여 24GB MacBook의 보조 GPU로 사용하기: Qwen 3.8 27B를 이전보다 29–44% 더 빠르게 구동하고
요약
iPhone과 MacBook을 USB-C 케이블로 연결하여, iPhone의 GPU와 Neural Engine을 보조 컴퓨팅 자원으로 활용하는 방법을 제시합니다. 이를 통해 Qwen 3.8 27B 모델 구동 시 컨텍스트 길이 확장 및 토큰 생성 속도 향상을 달성했습니다. 특히, Mac이 레이어 1-40을 처리하고 iPhone이 레이어 41-64를 처리하는 방식으로 병렬 처리를 구현하여 성능 개선 효과를 입증했습니다.
핵심 포인트
- iPhone의 GPU/Neural Engine을 보조 컴퓨팅 자원으로 활용 가능
- Mac과 iPhone 간의 스트리밍 및 병렬 처리가 핵심 기술
- 컨텍스트 길이 확장(128k까지) 및 토큰 생성 속도 향상 확인
- SME2와 같은 Mac 자체 최적화로도 성능 개선 가능
면책 조항 휴대폰에서 표시되는 프리필링 TPS는 해당 기기가 담당하는 레이어에 대해서만 계산된 것입니다. 현재 엔드투엔드(E2E) 프리필링 속도를 보여주도록 수정 중입니다. 아래 수치는 E2E 프리필링 속도에 대해 정확합니다.
24GB M4 Pro MacBook에서 에이전트가 읽는 모든 파일이나 도구 결과는 대기 시간이며, 20480으로 유선 제한을 높였음에도 불구하고 Qwen 3.8 27B (IQ4_XS)와 함께 수용 가능한 컨텍스트는 8비트 기준으로 최대 64k입니다. iPhone 17 Pro Max가 주머니에 들어 있었기 때문에, 이 추가 실리콘을 어떻게 활용할지 고민해 보았습니다.
알고 보니 필요한 것은 10 Gb/s USB-C 케이블과 약간의 소프트웨어뿐이었습니다. Mac은 각 256 토큰 배치(batch)의 레이어 1–40을 실행하고 활성화 값(activations)을 휴대폰으로 스트리밍합니다. 휴대폰은 GPU에서 레이어 41–64를 실행하는 동안, Mac은 다음 배치를 시작합니다. A19 Pro의 GPU에는 매트릭스 유닛(Metal 4 tensor ops)이 있으며, 이 덕분에 해당 기능이 없는 동일한 휴대폰보다 성능이 2.4배 더 빠릅니다.
동일한 빌드에서, 전원을 끈 상태 vs. 켠 상태로 2,000 토큰 파일을 저장된 에이전트 세션에 프리필링하는 경우:
8k 컨텍스트: Mac 단독 132 tok/s → Mac + iPhone 177 tok/s (+35%) (두 날 전에 측정, 같은 벤치)
16k 컨텍스트: Mac 단독 109 tok/s → Mac + iPhone 157 tok/s (+44%)
32k 컨텍스트: Mac 단독 101 tok/s → Mac + iPhone 130 tok/s (+29%)
48k 컨텍스트: Mac 단독 87 tok/s → Mac + iPhone 113 tok/s (+30%)
새로운 27k 토큰 에이전트 세션, 콜드 스타트(cold): stock llama.cpp에서 245초, Mac만 사용한 포크 버전에서는 228초, 휴대폰을 사용했을 때는 168초가 걸렸습니다.
64k를 넘어서면 휴대폰이 역할을 전환합니다. 가장 오래된 KV 페이지는 휴대폰으로 이동하고 Mac은 전체 64개 레이어를 실행합니다. 모든 어텐션(attention) 레이어마다, 휴대폰은 GPU에서 이전 키(keys)에 대한 어텐션을 계산하고, Mac은 이를 자체 부분과 병합합니다. 작성하는 동안에는 휴대폰의 Neural Engine도 일부 작업을 수행합니다: 오래된 컨텍스트의 각 16k-key 페이지는 키를 가중치로 하는 Neural Engine 모델로 컴파일됩니다. 140k에 도달했을 때, 이는 휴대폰 GPU 단독으로 작업한 경우 대비 토큰당 279ms에서 176ms가 걸리는 것으로 줄었습니다.
서버는 휴대폰의 여유 메모리를 기반으로 196k–229k 크기의 8비트 컨텍스트를 할당합니다. 이는 Mac이 아닌 휴대폰에 최대 약 5.7 GB의 KV cache가 존재한다는 의미이며, 따라서 Mac의 메모리 사용량은 64k에서 증가하는 것을 멈춥니다. 저는 3/3개의 심어 놓은 사실(planted facts)을 회상하며 8비트로 128k까지 늘어나는 세션을 테스트했습니다. 별도로, 4비트에서 140k로 실행했을 때, 이 과정은 그리가스 출력(greedy output)이 Mac 단독 실행의 생성된 토큰 32개와 일치하면서 통과 기준을 충족했습니다.
작동하지 않는 부분: 64k 미만의 쓰기 속도 향상. 이것은 Mac의 역할입니다. 제가 포크한 커널(M4 CPU용 SME2 및 Metal fusion)에 DFlash2 추측 디코딩(speculative decoding)을 추가하니, 일반 llama.cpp에서 11.3 tok/s였던 속도가 중간 사고 과정(medium thinking)과 함께 컨텍스트가 약 30k일 때 휴대폰 사용 여부와 관계없이 25 tok/s로 향상되었습니다. SME2는 Mac 단독으로도 프리필(prefill)에 최대 29%를 추가합니다. 64k를 넘어서면 휴대폰이 쓰기(이전 키에 대한 어텐션)를 공유하며, 이것이 없다면 Mac은 128k에 도달하기 위해 4비트 컨텍스트로 낮춰야 합니다. 실제 사용 환경에서는 낮은 컨텍스트에서 30 TPS 이상을 본 적이 있습니다.
휴대폰은 약 512 토큰에 걸쳐 프리필에 참여합니다. 한 실제 세션에서 이는 36개 요청 중 7개였지만, 읽어낸 토큰의 비율은 약 83%였습니다. 64k를 넘어서면 컨텍스트를 유지하고 이전 키 어텐션을 수행하지만, 현재는 레이어 41–64까지 실행하지 않습니다. 둘 다 하는 것이 다음 목표입니다. 한 번에 하나의 요청씩입니다.
저는 이 설정이 새로운 모델 아키텍처와 함께 무엇을 할 수 있을지 궁금합니다. DeepSeek V4.1-Flash는 글로벌 KV cache로 토큰당 890 바이트를 보고하며 n-gram 임베딩 테이블(Engram)을 추가합니다. Qwen3.8-Flash-Next, 즉 Qwen 4 아키텍처 프리뷰 버전도 n-gram 조회 테이블이 있습니다. 이들은 제가 테스트한 27B 모델의 기능은 아니며, 저는 여기서 어떤 아키텍처도 벤치마킹하지 않았습니다. 진정한 가치는 새로운 휴대폰과 모델들이 함께 작동하는 데 있습니다. iPhone 18 Pro Max에 탑재된 A20 Pro를 사용하면 제가 더 밀어붙일 수 있는 부분이 많을 것이라고 생각합니다.
코드, 설정 및 벤치마크 스크립트: https://github.com/StayLameBro/backburner
아직 할 일이 많이 남아 있지만 Opus 5.5로 이것을 만들었습니다. 무엇이든 기꺼이 답변하겠습니다.
제공자 /u/StayLameBro
[링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기