노트북 NPU가 이미지 생성에서 GPU보다 빠른 경우
Intel Panther Lake NPU에서 SDXL Turbo가 같은 머신 GPU보다 빠르게 끝나는 결과를 정리. Proxmox + LXC + OpenVINO 셋업의 까다로운 부분, U-Net만 NPU에 올리고 CLIP / VAE는 CPU에 두는 파이프라인 분리 방식, 그리고 한국에서 따라하기 어려운 한계까지 같이 짚어봄.
이미지 생성은 GPU 일이라는 게 일종의 디폴트였음. CUDA 깔고, 그래픽카드에 모델 올리고, 거기서 다 돌림. NPU는 LLM 토큰 몇 개 뿌리거나 카메라 인퍼런스 돌리는 데 쓰는 거지, Stable Diffusion 같은 무거운 디퓨전 모델하고는 거리가 있는 칩이라는 인상이 컸거든요.
근데 Intel Core Ultra 시리즈 3 — 코드명 Panther Lake — 의 NPU만으로 SDXL Turbo가 6초대에 끝나고, 같은 머신의 내장 GPU보다 빨랐다는 결과를 보고 좀 다시 보게 됐습니다.
본문 들어가기 전에 짚고 가는 것 몇 개. NPU는 노트북·미니PC CPU 안에 같이 들어가 있는 AI 추론 전용 칩. Panther Lake는 Intel Core Ultra 시리즈 3의 코드명. OpenVINO는 Intel이 만드는 추론 런타임 — PyTorch / HuggingFace 모델을 자체 IR 포맷으로 변환해서 NPU·GPU·CPU 어디서든 돌리게 해줌. INT8은 모델 가중치를 8비트 정수로 줄인 양자화 형식인데, NPU는 이걸 native로 돌리고 GPU / CPU는 보통 FP16 / FP32로 풀어서 굴림. 이 마지막 한 줄이 결과 해석할 때 핵심 변수가 됩니다.
셋업이 의외로 빡셈
테스트 환경이 좀 특이합니다. Proxmox 위에 LXC 컨테이너 띄우고, 거기서 NPU랑 내장 GPU를 동시에 패스스루해서, K3s까지 깔고, OpenVINO 파이프라인을 돌리는 구조.
원래 LXC는 unprivileged 모드로 띄우는 게 격리 측면에서 더 안전한데, NPU 디바이스 노드와 모니터링용 debug 경로까지 다 노출시키려니까 결국 privileged 컨테이너로 가야 하는 상황이 됐다고 하네요. 본인 입장에서 보면 이 부분은 좀 아쉬움. 격리를 일부 포기해야 NPU 모니터링까지 다 보이는 구조면, 본격 운영 환경에서는 못 쓰고 그냥 실험 머신용임.
리눅스 쪽 NPU 드라이버랑 OpenVINO 컴퓨트 런타임 버전이 안 맞으면 GPU 커널 컴파일이 조용히 실패함. 공식 OpenVINO 도커 이미지 안에 묶여 있는 24.48 컴퓨트 런타임이 Panther Lake의 Xe3 GPU랑 안 맞아서, 결국 깡통 우분투 24.04 이미지에서 시작해 Intel kobuk-team PPA에서 호환되는 런타임을 받고 OpenVINO는 pip로 따로 까는 식으로 해결했다고 함. 새로 나온 칩 만질 때 거의 항상 따라오는 종류의 호환성 문제.
파이프라인을 셋이 나눠 듦
흥미로운 부분은 여깁니다. Stable Diffusion 파이프라인은 크게 세 덩어리.
- CLIP 텍스트 인코더 — 프롬프트를 임베딩으로
- U-Net — 노이즈를 점점 깎으면서 latent space에서 이미지 형태를 만듦
- VAE 디코더 — latent을 픽셀로 풀어줌
이걸 다 같은 디바이스에 올리는 게 아니라 CLIP은 CPU, U-Net은 NPU, VAE는 CPU 로 분배합니다. 이유가 명확한데, NPU 쪽은 static shape만 받아요. 입력 차원이 컴파일 시점에 고정되어 있어야 함. 근데 CLIP이랑 VAE는 프롬프트 길이나 batch 사이즈에 따라 shape이 달라져야 해서 NPU에 박으면 곤란해짐. U-Net은 디퓨전 스텝마다 같은 shape으로 반복 호출되니까 static에 잘 맞고, 동시에 가장 무거운 컴포넌트라 NPU 쓰는 의미가 가장 큽니다.
여기서 또 함정이 하나 있는데, OpenVINO pipe.reshape()를 호출하면 U-Net의 batch 차원을 자동으로 두 배로 잡아줍니다. classifier-free guidance 쓰는 걸 가정하기 때문. 근데 SDXL Turbo처럼 guidance 안 쓰는 모델은 batch를 1로 강제로 다시 돌려놔야 함. 이런 디테일은 직접 안 만지면 절대 안 보일 부분이라, 새로 들어오는 사람이 처음 빌드할 때 한참 헤맬 만한 지점이라고 봅니다.
결과 표만 봐도 좀 충격
세 모델, 세 디바이스에서 단일 측정 결과가 이렇게 나왔습니다.
| 모델 | CPU | GPU | NPU |
|---|---|---|---|
| lcm-dreamshaper | 16.05초 | 10.19초 | 8.01초 |
| sd15 | 90.81초 | 16.28초 | 14.31초 |
| sdxl-turbo | 25.89초 | 22.84초 | 6.59초 |
원작자도 분명히 적어놨듯이 단일 측정값이고 평균이 아니라, 정식 벤치마크가 아니라 그냥 데모 수준의 숫자. 그래도 패턴은 일관됨. 모든 모델에서 NPU가 GPU보다 빨라요.
NPU가 GPU를 이긴다는 건 처음 들으면 직관에 안 맞습니다. 근데 INT8 양자화를 NPU가 native로 돌리는 반면, GPU 쪽은 dequantize해서 FP16 / FP32로 풀어 돌리는 구조라는 점을 보면 어느 정도 설명이 됩니다. INT8 그대로 굴러갈 수 있는 칩이면, 그래픽 연산 절대치는 떨어져도 디퓨전 같은 반복 작업에서는 충분히 따라잡거나 추월할 여지가 있다는 얘기.
직접 돌려본 건 아니라 정확한 건 모르겠는데, 본인 추측으로는 SDXL Turbo가 가장 큰 격차를 보이는 건 단순히 INT8 친화도뿐 아니라 4 step 추론이라는 짧은 사이클 안에서 NPU의 호출 오버헤드가 작은 게 누적적으로 유리하게 작용하는 부분도 있을 것 같음. 이건 검증된 가설이 아니라 그냥 뇌피셜이니 누가 더 파고들어줬으면 합니다.
한계와 안 풀린 부분
원작자가 sdxl-base와 playground-v2.5도 시도했는데 결과가 이상하게 나와서 못 썼다고 적어뒀어요. 양자화 변환 과정에서 뭔가 깨졌을 가능성이 큰데, 어쨌든 결론은 NPU가 모든 SD 변종에 대해 안전한 선택지는 아니라는 점. 모델별로 골라서 써야 하는 상황이 그대로임.
GPU 결과가 NPU보다 느린 게 dequantization 오버헤드 때문이라는 건 추정 수준이고 정확히 깨진 부분은 없음. 그리고 한 가지 더 중요한데, 비교 대상이 NVIDIA RTX 같은 메인 스트림 외장 GPU가 아니라 Intel 내장 Xe3 GPU예요. 같은 머신 안에서 칩끼리 비교한 거지, "NPU가 RTX보다 빠르다" 같은 얘기는 절대 아닙니다. 외장 GPU가 들어가면 결과가 또 완전히 달라질 거예요.
한국 시점에서 가장 큰 한계는 따로 있는데, Panther Lake가 들어간 노트북·미니PC가 아직 잘 안 풀림. 원작자가 쓴 NUC 16 Pro 같은 기기는 국내 정발 기준으로는 보기 어렵고, 한국 개발자가 당장 따라할 수 있는 셋업이 아닙니다. 본인 환경도 외장 GPU 위주라 NPU 직비교는 직접 해볼 길이 없고. 결국 이 글에서 정리한 내용도 자료 위에서의 분석에 머무는 거라, 손으로 만져본 사람이 나타나면 디테일이 더 다듬어질 가능성이 높음.
곁다리 — Intel 모델 라인업이 좀 정신 사나움
조금 빗나간 얘기. Intel의 Core Ultra 네이밍이 정말 헷갈립니다. 시리즈 1 (Meteor Lake) → 시리즈 2 (Arrow Lake / Lunar Lake) → 시리즈 3 (Panther Lake) 식으로 가는데, 같은 시리즈 안에서도 노트북용·데스크탑용·서버용 코드네임이 따로 붙어있고, NPU 세대도 칩마다 달라요. 새 NPU가 들어간 칩만 골라 사야 하는데 모델명만 보고 한 번에 알기는 어려움. 한국 리테일에서는 정보가 더 부족하고. 이건 그냥 Intel이 정리 좀 해줬으면 합니다.
마무리
NPU가 처음 등장했을 때 인상은 "CPU 안에 든 작은 추론 모듈, 큰 일은 못 함" 이었습니다. 근데 이번 케이스 보면 적어도 INT8 친화적인 모델 한정으로는 그 인식이 점점 안 맞아지는 듯해요. 같은 머신 GPU 잡는 정도는 충분히 가능하고, 호스트 CPU 점유율 거의 안 쓰면서 그 결과를 낸다는 점에서는 더 가치가 있고요.
진짜 인식이 바뀌려면 동급 외장 GPU랑 비교 결과가 더 쌓여야 할 텐데, 지금 시점에서는 "NPU도 의외로 한 몫 함" 정도까지가 안전한 결론입니다. 이거 하나는 단정할 수 있을 것 같음 — 로컬 추론 자원의 그림이 점점 다층화되고 있다. 외장 GPU 한 장으로 다 처리하던 시절이 끝나가는 중.
다음 글에서는 OpenVINO 자체 — 모델 변환 파이프라인이랑 INT8 양자화 옵션 — 을 좀 정리해볼까 합니다. 본인이 일하는 백엔드 스택에 직접 맞물리는 건 아닌데, 로컬 추론 셋업을 한 번씩 다시 보는 게 머리 식힘에 의외로 좋더라고요.
참고로 모니터링 쪽이 궁금하면 open-edge-platform/edge-ai-libraries 안에 NPU 모니터링 툴이 들어 있고, 변환 파이프라인 쪽은 OpenVINO 공식 문서 가 가장 빠릅니다.
댓글
NEXT_PUBLIC_GISCUS_*환경변수 구성 필요)