「AI PC」는 정말 AI를 할 수 있을까? ── Copilot+ PC 4개 플랫폼 비교 (2026년 5월 버전)
요약
Copilot+ PC의 핵심인 NPU 성능과 로컬 LLM 구동 능력을 4개 플랫폼(AMD, Intel, Snapdragon, Apple)을 통해 비교 분석합니다. 특히 AMD XDNA 2의 FastFlowLM을 통한 실용적 성능 향상과 iGPU 메모리 병목 현상을 중점적으로 다룹니다.
핵심 포인트
- AMD XDNA 2는 FastFlowLM을 통해 NPU 기반 LLM 추론의 실용성을 확보함
- 플랫폼별 NPU TOPS는 40 내외로 유사하나 실제 LLM 활용도는 극명히 다름
- iGPU의 메모리 공유 설계가 로컬 LLM 구동의 주요 병목 지점으로 작용함
- Snapdragon은 prefill 단계에서만 이점이 있으며 decode 단계는 CPU에 뒤처짐
서론
2024년부터 「AI PC」, 「Copilot+ PC」라는 마케팅이 휩쓸고 있다. 각 기업은 NPU 탑재를 강조하며 40 TOPS 이상을 두고 경쟁하고 있다.
하지만 실제로 로컬 LLM (Large Language Model)을 구동하려고 하면 이야기는 완전히 달라진다. NPU는 LLM 추론에 거의 기여하지 못한다는 평가를 받아왔으나, AMD XDNA 2에서는 전용 런타임(Runtime)인 「FastFlowLM」의 등장으로 상황이 변하고 있다. 한편, iGPU (Integrated GPU)의 메모리 공유 설계가 병목 현상(Bottleneck)이 되는 구조는 변하지 않았으며, 플랫폼별 실력 차이는 극명하다.
본 기사에서는 32GB 통합 조건을 기준으로 다음 4가지 플랫폼을 비교한다.
| 플랫폼 | 대표 칩 | 아키텍처 |
|---|---|---|
| AMD Strix Point | Ryzen AI 9 HX 370 | x86 / Zen 5 + RDNA 3.5 |
| ... | ... | ... |
평가 축은 로컬 LLM 추론 (7-8B 실측 / 14B-20B 추정), NPU 활용, 배터리, 가격, Linux 대응의 5가지이다.
필자의 검증 환경
본 기사는 커뮤니티의 공개 데이터를 횡단적으로 집약하였으나, 필자 자신도 다음 2대의 기기로 로컬 LLM 추론을 일상적으로 운용하고 있으며, 일부 데이터는 1차 검증에 기반하고 있다.
노트북: ThinkPad X13 Gen6 AMD
| 항목 | 스펙 |
|---|---|
| CPU / NPU | Ryzen AI 7 PRO 350 (XDNA 2 NPU 탑재) |
| ... | ... |
NPU (FastFlowLM)와 iGPU (Vulkan)를 운용하고 있는 환경이다. 본 기사의 FastFlowLM 평가 및 Arch Linux 대응에 관한 기술은 이 환경에서의 실체험을 포함한다.
데스크톱:
| 항목 | 스펙 |
|---|---|
| CPU | Ryzen AI 9 HX 370 |
| ... | ... |
실측 데이터
| 모델 | 양자화 (Quantization) | tok/s | 비고 |
|---|---|---|---|
| Qwen3-Coder-30B-A3B-Instruct | Q4_K_M | 36.7 | MoE (Mixture of Experts). 액티브 파라미터가 3B이므로 대역폭 효율이 높음 |
이 실측은 MoE 모델에서 「총 파라미터가 30B임에도 SO-DIMM DDR5 환경에서 실용적인 속도가 나온다」는 것을 보여준다. 128GB SO-DIMM이라는 대용량 메모리를 통해 GTT (Graphics Translation Table)를 108GB까지 확장할 수 있어, 일반적인 노트북 (32GB)에서는 용량 문제로 어려운 모델도 검증할 수 있는 환경에 있다.
1. NPU의 현주소
각 사의 스펙
| AMD XDNA 2 | Intel NPU 4 | Snapdragon Hexagon | Mac Neural Engine | |
|---|---|---|---|---|
| TOPS | 50 | 48 | 45 | 38 |
모두 40 TOPS를 초과하여 Copilot+ PC 요구 사항을 충족한다. 숫자만 보면 대등해 보인다.
LLM 추론에 대한 기여: 플랫폼별
AMD XDNA 2 → FastFlowLM을 통해 실용 영역에 도달 (후술). 단, llama.cpp의 네이티브 백엔드는 Feature Request 단계 (GitHub #21725, 2026년 4월) -
Intel → NPU로 LLM 추론을 실행하는 실용적인 경로가 존재하지 않는다. OpenVINO를 경유하는 경로는 있으나 llama.cpp와의 통합은 제한적 -
Snapdragon → ONNX Runtime QNN을 통해 구동되지만, 대응 모델은 4B 정도가 상한이다. 게다가 prefill (입력 처리) 단계에서만 CPU보다 빠르며, decode (토큰 생성) 단계에서는 CPU에 뒤처진다 -
Mac → Neural Engine을 사용하지 않는다. Metal GPU가 상위 호환이므로 차례가 오지 않는다
FastFlowLM: AMD NPU의 실용 런타임
FastFlowLM (FLM)은 AMD XDNA 2 NPU를 위해 깊게 최적화된 LLM 추론 런타임으로, Ollama와 유사한 CLI 경험을 제공한다. 2026년 3월에 Linux 정식 지원이 추가되었다 (Phoronix 보도).
퍼포먼스 (Ryzen AI 9 365 / XDNA 2)
| 모델 | NPU tok/s | 비고 |
|---|---|---|
| Llama 3.2 1B (Q4_1) | ~66 | 최속 클래스 |
| ... | ... |
출처: FastFlowLM 공식, Medium 기사 (2026년 3월)
FastFlowLM의 강점
CPU/GPU가 완전히 자유로움: NPU 추론 중에는 iGPU와 CPU 모두 다른 태스크에 사용할 수 있다. 브라우저, 에디터, 빌드 작업이 추론과 공존 가능 -
소비 전력 < 2W: CPU+NPU의 시스템 소비 전력이 iGPU 추론 시(~25W)의 1/10 이하 256k 토큰의 롱 컨텍스트 (Long Context) 대응-
Arch Linux 대응: AUR 패키지 있음 (Framework Community Guide), Ubuntu / Arch / 기타 배포판 대응
FastFlowLM의 제약
대응 모델은 FastFlowLM으로 변환된 모델만 가능. 임의의 GGUF 모델은 사용할 수 없음 (대응 리스트) -
XDNA 2 이후 모델로 한정. XDNA 1 (Ryzen 8040 계열)은 미지원 -
바이너리 NPU 커널은 클로즈드 소스 (Closed Source) (런타임 자체는 MIT 라이스نس이지만, 상업적 이용은 별도 라이선스) -
일반 사용자의 일상적인 이용 보고는 아직 적음. 개발 팀의 데모 및 벤치마크가 중심 (TEAM ARASHIYAMA Blog) -
4B 모델에서 10-14 t/s는 실용적인 범위지만, llama.cpp Vulkan iGPU의 7-8B 모델 17-18 t/s와 비교하면 모델 크기 대비 성능은 떨어진다
요약: NPU는 환상이 아니게 되어가고 있다
AMD XDNA 2로 한정한다면, NPU를 통한 LLM 추론은 "쓸모없는" 단계에서 "조건부로 실용적인" 단계에 도달했다. 특히 저전력 및 백그라운드 상주라는 용도에서는 iGPU 추론에는 없는 명확한 강점이 있다.
다만, llama.cpp 생태계와는 별개의 세계이며, 대응 모델의 제약으로 인해 범용성과 성숙도 면에서는 iGPU 추론에 미치지 못한다. Intel / Snapdragon / Mac의 NPU는 여전히 LLM 추론에 기여하지 못하고 있다. "AI PC의 NPU가 AI에 도움이 된다"라고 말할 수 있는 것은, 현시점에서는 AMD XDNA 2 + FastFlowLM의 조합뿐이다.
2. 메모리 대역폭과 아키텍처
32GB 시스템의 대역폭 비교
LLM 추론은 메모리 대역폭에 의해 성능이 결정되는 메모리 대역폭 제한 (Memory Bandwidth Bound) 특성을 가진다. 모델의 모든 파라미터를 매 토큰마다 읽어내야 하기 때문이다.
| AMD Strix Point (SO-DIMM) | AMD Strix Point (LPDDR5X) | Intel Lunar Lake | Snapdragon X Elite | Mac M4 |
|---|---|---|---|---|
| 메모리 종류 | DDR5 SO-DIMM | LPDDR5X | LPDDR5X-8533 (온패키지) | LPDDR5X-8448 |
| ... | ... | ... | ... | ... |
"GPU 측으로 메모리를 몰아주는" 대응 상황
iGPU 추론에서는 시스템 RAM을 GPU 측에 할당할 필요가 있다.
| AMD | Intel | Snapdragon | Mac |
|---|---|---|---|
| 메커니즘 | Adrenalin VGM / Linux GTT 파라미터 | Shared GPU Memory Override (드라이버) | 제어 수단이 부족함 |
| ... | ... | ... | ... |
32GB에서의 현실적인 GPU 할당
"93%를 GPU에 할당하면 30GB를 쓸 수 있다"라고 해도, OS 측에 남는 용량이 2GB라면 부팅조차 불확실하다.
| 구성 | OS 측 잔여 용량 | 사용 가능한 GPU 용량 | 탑재 가능한 모델 기준 |
|---|---|---|---|
| Windows 일반 사용 | 8~10GB | 22~24GB | 14B Q4 (~8GB) 여유, 20B Q4 (~11GB) 가능 |
| ... | ... | ... | ... |
Windows에서 상용으로 사용한다면 22~24GB가 현실적인 상한선이다. 14B가 쾌적한 상한이며, 20B가 한계치다.
MoE (Mixture of Experts) 모델의 경우
본 기사의 메모리 대역폭 및 추론 성능 논의는 기본적으로 Dense 모델 (모든 파라미터가 매 토큰마다 읽어내지는 구조)을 전제로 하고 있다. 하지만 2025년 하반기부터 MoE (Mixture of Experts) 아키텍처 모델이 급증하면서, 이 전제가 무너지는 사례가 나타나고 있다.
Dense와 MoE의 차이
| Dense (예: Qwen2.5-14B) | MoE (예: Qwen3-Coder-30B-A3B) |
|---|---|
| 총 파라미터 | 14B |
| ... |
MoE에서는 Expert라고 불리는 서브 네트워크 중 일부만이 매 토큰마다 활성화되기 때문에, 대역폭 소비는 활성 파라미터 (Active Parameters)에 비례한다. 반면, 모델 파일 전체는 RAM/VRAM에 올려야 하기 때문에 용량은 Dense 모델과 마찬가지로 총 파라미터에 의존한다.
즉:
대역폭 제한 (Bandwidth-bound) tok/s $\approx$ 메모리 대역폭 $\div$ (활성 파라미터 $\times$ 양자화 바이트 수)
필요 용량 $\approx$ 총 파라미터 $\times$ 양자화 바이트 수
기사의 주장으로 인한 영향
본 기사에서 "14B가 쾌적한 상한선, 20B가 한계"라고 기술한 것은 Dense 모델을 전제로 한 이야기다. MoE 모델이라면:
Qwen3-Coder-30B-A3B (Q4_K_M): 파일 크기 ~17GB로 RAM 용량 측면에서는 32GB 시스템에 수용 가능하다. 활성 파라미터는 3B 정도이므로, 대역폭 측면에서는 3B 모델 수준의 속도가 나온다. - 실측치로서, SO-DIMM DDR5 구성 (~90 GB/s)의 AMD 환경에서 36.7 t/s가 확인되었다 (필자 검증 환경, 후술).
MoE의 등장으로 인해, "32GB 시스템에서 실용적으로 구동 가능한 모델"의 범위는 Dense 14-20B뿐만 아니라, MoE 30B 이상까지 확장되었다. 메모리 용량만 충분하다면, Dense 환산 시 3-4B 정도의 속도가 나오는 대형 MoE 모델을 선택지에 넣을 수 있다.
3. iGPU 추론의 실태
주요 비교: 7-8B 실측 데이터
먼저, 각 플랫폼에서 실측 데이터가 확보된 7-8B 모델로 비교한다.
| AMD 890M | Intel Arc 130V | Snapdragon Adreno X1 | Mac M4 Metal |
|---|---|---|---|
| 주력 백엔드 (Backend) | Vulkan | Vulkan | 사용 불가 (CPU 추론 한정) |
| ... |
보조 비교: 14B / 20B 추정 데이터
14B 이상은 실측 데이터가 제한적이므로, 아래 내용은 대역폭 이론치와 모델 크기로부터의 외삽 추정(Extrapolation)을 포함한다.
추정 방법: 7-8B의 실측 tok/s $\times$ (7-8B 모델 크기 $\div$ 대상 모델 크기)로 개략적으로 계산. 메모리 대역폭이 병목(Bottleneck)이므로, 모델 크기에 반비례한다는 전제에 기반한다. 실제로는 캐시 효율이나 연산자(Operator) 최적화 차이에 따라 변동한다.
| AMD 890M | Intel Arc 130V | Snapdragon (CPU) | Mac M4 Metal |
|---|---|---|---|
| 14B tg (tok/s) | ~10-12 (추정) | ~12-15 (추정) | ~10-12 (추정) |
| 20B tg (tok/s) | ~7-9 (추정) | ~10-14 (추정) ※ | 어려움 |
※ Intel Arc 130V의 20B Vulkan 실측은 17.57 t/s이지만 (touch-sp.hateblo.jp), 이는 Windows 32GB의 풀 할당 조건이므로 일상적인 사용 시에는 다소 저하된다.
Snapdragon의 로컬 LLM 추론 상황
Snapdragon X Elite에서의 로컬 LLM 추론은 현 시점에서 큰 제약이 있다:
Adreno GPU (Vulkan) $\rightarrow$ llama.cpp의 Vulkan 백엔드에서 출력이 깨짐 (2024년 12월 기준)
Adreno GPU (OpenCL) $\rightarrow$ 동작은 하지만 CPU 추론보다 느림 (7B 기준 17.95 tok/s vs CPU 20.7 tok/s)
CPU 추론 한정 $\rightarrow$ 모든 코어를 점유하여 다른 작업을 제대로 수행할 수 없음
Snapdragon에서 로컬 모델을 돌릴 경우, PC가 LLM 전용기가 된다. 브라우저를 열어둔 채 백그라운드에서 llama-server를 구동하는 방식의 사용은 사실상 불가능하다.
다만 공정성을 기하자면, Snapdragon은 Windows on ARM으로서의 일상적 이용 (Office, Teams, 브라우저) 측면에서는 배터리 효율과 ARM 네이티브 앱 동작에 우수하며, 클라우드 AI API를 이용하는 운용 방식이라면 실용적인 선택지이다. 어디까지나 "로컬 LLM 추론"이라는 관점에서는 어렵다.
AMD NPU + iGPU의 이도류
AMD Strix Point(XDNA 2 탑재 기기)에 한하여, NPU 추론과 iGPU 추론을 나누어 사용하는 이도류(二刀流) 운용이 가능하다. 이는 다른 플랫폼에는 없는 고유한 강점이다.
| 용도 | 추론 경로 | 모델 규모 | 특징 |
|---|---|---|---|
| 백그라운드 상주·저전력 | NPU (FastFlowLM) | 1B-4B | CPU/GPU 완전 유휴, < 2W, 256k 컨텍스트 |
| 고품질 추론·대형 모델 | iGPU (llama.cpp Vulkan) | 7B-20B | 대역폭 제한적이나 범용 GGUF 대응 |
예를 들어, FastFlowLM으로 Qwen3-4B를 llama-server처럼 백그라운드에 상주시키고(NPU, ~10-14 t/s, 거의 전력 소모 없음), 무거운 작업을 할 때만 llama.cpp Vulkan으로 Qwen3-14B를 구동하는(iGPU, ~10-12 t/s) ── 식의 운용이 가능하다. NPU 추론 중에는 iGPU가 비어 있기 때문에, 브라우저의 하드웨어 가속(Hardware Acceleration)이나 빌드 작업에 영향을 주지 않는다.
이러한 이도류 방식은 Mac M4의 "Metal 하나로 모든 것을 처리하는" 접근 방식과는 대조적이며, 용도에 따른 구분 사용이라는 측면에서 AMD XDNA 2만의 독자적인 이점이라고 할 수 있다.
4. 배터리 지속 시간
| AMD Strix Point | Intel Lunar Lake | Snapdragon X Elite | Mac M4 |
|---|---|---|---|
| 동영상 재생 | 12~16시간 | 18~26시간 | 20~24시간 초과 |
| ... |
Snapdragon과 Mac은 ARM 유래의 전력 효율로 압승했다. Intel도 선전하고 있으나, AMD는 배터리 측면에서 최하위이다.
단, NPU 추론(< 2W)을 활용하면 AMD의 배터리 소모는 대폭 개선된다. iGPU 추론(~25W)과 NPU 추론의 차이는 배터리 구동 시 특히 크게 작용한다.
5. 가격대 (32GB 구성)
| AMD Strix Point | Intel Lunar Lake | Snapdragon X Elite | Mac M4 |
|---|---|---|---|
| 대표 기종 | ASUS ZenBook 등 | Dell XPS 13, ASUS Zenbook S 14 | Surface Laptop 7 |
| 32GB 가격대 | 15~22만 엔 | 18~25만 엔 | 20~25만 엔 |
32GB 구성 시 4사 모두 20만 엔 전후로 수렴한다. Mac은 약간 높게 형성되지만, 큰 차이는 나지 않는다.
6. Linux 대응
| AMD Strix Point | Intel Lunar Lake | Snapdragon X Elite | Mac M4 |
|---|---|---|---|
| 평가 | ◎ 최상 | ○ 양호 | ✗ 거의 괴멸 |
Asahi Linux의 최신 상황 (2026년 5월 시점)
M1 / M2: GPU를 포함하여 실용적인 데스크톱 Linux로서 동작. Fedora Asahi Remix로 배포 중 -
M3: 2026년 4월 Asahi Linux 7.0에서 알파(Alpha) 단계 도달. 키보드, 트랙패드, NVMe, 디스플레이 동작. 단, GPU 가속(GPU Acceleration)은 미지원 (소프트웨어 렌더링만 가능). Asahi Installer를 통한 설치도 미지원 (Phoronix 2026년 2월, Doolpa 2026년 4월) -
M4: 모든 항목 TBA (Asahi Linux M4 Feature Support). Alpine Linux의 기본적인 부팅 보고는 있으나, 실용 단계는 아님
Snapdragon의 Linux 문제 (2026년 5월 시점)
- Ubuntu 26.04에서도 펌웨어 추출 도구가 작동하지 않음
- 3D 가속 미지원, 배터리 정보 보고 불가
- Qualcomm이 DSP 헤더의 오픈 소스화를 공식적으로 거부
- TUXEDO가 Snapdragon Linux 노트북 개발을 18개월 만에 중단
- Phoronix의 2025년 말 리뷰에서 "Disappointing(실망적)"이라고 단언
Linux 사용을 전제로 한다면 Snapdragon은 선택지에 들어가지 않는다.
7. 종합 평가
| 평가 축 | AMD Strix Point | Intel Lunar Lake | Snapdragon X Elite | Mac M4 |
|---|---|---|---|---|
| LLM 추론 (7-8B 실측) | △ | ○ | △ (CPU 추론) | ◎ |
| ... |
8. 각 플랫폼의 평가
🏆 Mac M4: 종합 1위
거의 모든 항목에서 승리하거나 대등함. Metal + MLX의 소프트웨어 생태계(Software Ecosystem)가 성숙해 있으며, 통합 메모리 아키텍처 (Unified Memory Architecture) 덕분에 메모리 복사가 필요 없음. 추론 중에도 시스템이 쾌적함.
약점:
- Linux 대응: Asahi Linux는 M3에서 알파 단계이며, M4는 미지원. macOS를 전제로 하는 플랫폼
- macOS 생태계 제약: Docker / 컨테이너는 Rosetta 2 + Hypervisor.framework를 통해 동작하지만 오버헤드가 있음. x86 바이너리 호환성은 개선되었으나 완전하지 않음. 기업용 VPN/MDM과의 호환성 문제도 보고됨
- 32GB는 CTO: 베이스 모델은 16GB. 32GB를 선택하면 가격이 상승함
- 게임: Steam Mac 점유율 2% 미만
「AI PC」를 자처하지 않음에도, 로컬 AI 추론에서 가장 강력함.
🥈 AMD Strix Point: Linux 유저의 유일한 선택지, 그리고 NPU 이도류
배터리는 최하위지만, Linux 대응이 가장 뛰어남. Vulkan 백엔드(Backend)에서의 llama.cpp 추론이 안정적이며, SO-DIMM 구성이라면 용량 확장도 가능함.
FastFlowLM의 추가로 NPU + iGPU의 이도류(Dual-wielding)가 실현됨. 3-4B 클래스를 저전력으로 백그라운드에 상주시키면서, 필요에 따라 iGPU로 대형 모델을 구동할 수 있는 구성은 다른 플랫폼에는 없는 독특한 강점임. NPU 추론 (< 2W)은 배터리 구동 시의 LLM 이용 시나리오에서도 효과를 발휘함.
Arch Linux 환경에서 로컬 LLM을 구동하고 싶다면 사실상 유일한 선택지.
🥉 Intel Lunar Lake: 밸런스형이지만 돌출되는 부분은 없음
LLM 추론도 배터리도 적당한 수준. Shared GPU Memory Override를 통해 2025년 8월에 AMD를 따라잡음. Vulkan 백엔드에서 20B Q4_K_M tg128 = 17.57 t/s라는 실측값이 있으며, iGPU 단독으로는 선전하고 있음. 다만 32GB 고정으로 확장성이 제로이며, LPDDR5X-8533 온패키지(On-package) 방식으로 교체 불가능함.
NPU를 LLM 추론에 사용할 수 없다는 점에서는 Snapdragon과 같은 약점을 가짐.
Snapdragon X Elite: 로컬 LLM에는 부적합
- iGPU 추론 → Vulkan 백엔드가 제대로 작동하지 않음
- CPU 추론 → 동작은 하지만 모든 코어를 점유하여 다른 작업을 할 수 없음
- Linux → 거의 작동하지 않음
- NPU → 4B가 상한선
- 유일한 장점 → 배터리 (ARM 유래의 효율)와 Windows on ARM 네이티브 앱의 매끄러운 동작
배터리와 ARM 버전 Windows 경험 측면에서는 뛰어나지만, 「로컬 LLM 추론」이라는 축에서는 이길 수 있는 요소가 없음. 클라우드 AI API 이용을 전제로 하는 사용자에게는 나쁜 선택지가 아니지만, 본 기사의 평가 축에서는 최하위.
9. 향후 전망
본 기사의 평가는 2026년 5월 시점의 스냅샷이며, 이 영역은 급격하게 변화하고 있음. 다음은 향후 주목해야 할 포인트임.
NPU 백엔드의 동향
FastFlowLM이 이미 실용적인 경로를 제공하고 있다는 점에서, 「NPU는 LLM 추론과 무관하다」는 전제는 부분적으로 깨지고 있음. 다만 다음과 같은 과제가 남아 있음:
- llama.cpp와의 통합: AMD XDNA 백엔드가 기능 요청(Feature Request)으로 제안됨 (GitHub #21725, 2026년 4월). 독립 프로젝트(OllamaAMDNPU)에서는 디코딩(decode) 시 1.4 t/s에 도달했으나, FastFlowLM(~28 t/s @ 3B)과는 차원이 다르게 느림. llama.cpp 네이티브에서 NPU를 사용할 수 있게 된다면, 임의의 GGUF 모델이 대응되어 범용성이 비약적으로 상승할 것 -
FastFlowLM의 모델 대응 확대: 대응 모델의 변환 도구 자동화가 진행된다면, 폐쇄적인 변환 완료 모델의 제약이 완화될 것 -
Qualcomm QNN: llama.cpp의 QNN 백엔드 자체는 존재하지만, Windows on Snapdragon에서의 빌드 및 운용 보고는 제한적임. Qualcomm Support Forum에서도 가이드를 요청하는 목소리가 나오고 있는 단계 -
Intel NPU (OpenVINO): OpenVINO를 통한 NPU 추론 패스는 존재하지만, llama.cpp와의 통합은 제한적
차세대 칩 전망
| 세대 | 주목 포인트 |
|---|---|
| AMD Strix Halo | LPDDR5X 최대 128GB, iGPU 40CU (RDNA 3.5). 메모리 용량의 벽을 돌파할 가능성 |
| AMD Krackan Point | Zen 5c 기반의 저전력 버전. 배터리의 약점을 보완할 수 있을지 |
| Intel Panther Lake | Xe3 아키텍처. Vulkan 백엔드의 추가적인 개선에 기대 |
| Snapdragon X2 (가칭) | Adreno GPU의 Vulkan 대응이 수정된다면 상황이 바뀔 가능성 |
| Apple M5 | 이미 탑재된 MacBook Air가 판매 중 (¥184,800~). M4로부터의 대역폭 개선이 주목 포인트 |
기사의 유효 기간
본 기사의 결론이 크게 바뀌는 시나리오는 두 가지가 있다:
- llama.cpp에 NPU 네이티브 백엔드가 구현됨: 임의의 GGUF 모델이 NPU 추론이 가능해진다면, 「NPU는 범용성이 떨어진다」는 평가가 뒤집힘. 2026년 후반~2027년에 부분적으로 실현될 가능성이 있음 -
- FastFlowLM의 대응 모델이 대폭 확대됨: 변환 도구의 자동화가 진행되어 주요 모델이 출시 직후 NPU에 대응된다면, 폐쇄적 생태계의 제약이 실질적으로 해소됨
어느 경우든, NPU + iGPU의 하이브리드 추론이 새로운 평가 축이 되어 AMD의 순위가 올라가는 방향으로 작용한다.
결론: 「AI PC」의 NPU는──AMD만이 답을 내놓기 시작하고 있다
2024~2026년의 「AI PC」, 「Copilot+ PC」는 NPU 40 TOPS 이상이라는 요건으로 마케팅되어 왔다. 그 간판에 대한 현실은 다음과 같다:
- AMD XDNA 2: FastFlowLM을 통해 NPU가 실제로 LLM 추론에 사용 가능한 유일한 플랫폼. 단, 전용 런타임(Runtime)을 경유해야 하며, llama.cpp 생태계에서는 여전히 사용할 수 없음 -
- Intel / Snapdragon / Mac: NPU는 LLM 추론에 기여하지 못하고 있음
실제로 로컬 LLM을 구동하는 데 필요한 것은:
- 메모리 대역폭 (= tok/s의 천장) -
- 메모리 용량 (= 탑재 가능한 모델 크기) -
- iGPU의 성숙한 소프트웨어 스택 (Vulkan / Metal) -
- GPU 측으로 메모리를 몰아주는 메커니즘 (신기준) -
- NPU 추론 런타임의 성숙도
iGPU 추론에서 가장 완성도가 높은 것은 여전히 Mac M4이지만, NPU + iGPU라는 두 가지 무기를 사용하는 새로운 축에서는 AMD XDNA 2가 독자적인 강점을 보이기 시작했다.
TOPS를 다투는 NPU 경쟁에서, AMD가 FastFlowLM을 통해 한발 앞서 「사용 가능한」 단계에 도달한 반면, Intel과 Qualcomm은 여전히 헛스윙을 하고 있다. 「AI PC」라는 간판 아래, NPU가 실제로 AI에 사용될 수 있는지 여부는 플랫폼에 따라 하늘과 땅 차이가 있다──그것이 2026년 5월의 현실이다.
출처 목록
- llama.cpp GitHub 리포지토리 (Repository)
- llama.cpp SYCL 백엔드 (Backend) 문서
- llama.cpp Discussion #8273 (Snapdragon CPU 추론)
- llama.cpp Discussion #4167 (Mac Metal 추론)
- touch-sp.hateblo.jp – Intel iGPU Vulkan vs SYCL 비교 (2026년 3월)
- Marvin Damschen – llama.cpp for running local LLMs on Intel GPUs (2026년 2월)
- GitHub Issue #21725 – AMD XDNA 백엔드 (backend) 기능 요청 (Feature Request)
- Ollama AMD NPU XDNA NPU 백엔드 (Backend) 변경 로그 (Changelog)
- FastFlowLM 공식 사이트
- FastFlowLM GitHub 리포지토리 (Repository)
- FastFlowLM Linux 시작하기 (Lemonade Server)
- Medium – FastFlowLM on Ubuntu (2026년 3월)
- Framework Community – XDNA2 + FastFlowLM Arch Linux 가이드
- TEAM ARASHIYAMA Blog – Ryzen AI NPU로 Linux 로컬 LLM (2026년 3월)
- Phoronix – AMD Ryzen AI NPUs Finally Useful on Linux (2026년 3월)
- Asahi Linux M4 기능 지원
- Phoronix – Apple M3 With Asahi Linux Continues Making Progress (2026년 2월)
- Doolpa – Asahi Linux 7.0 M3 Alpha, VRR (2026년 4월)
- AMD Ryzen AI 소프트웨어 (Software) 문서
- Apple 공식 MacBook Air
Discussion
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기