devway
홈전체 글태그

카테고리

  • 전체40
  • 인프라3
    • 하드웨어2
    • ubuntu1
  • AI34
    • 로컬 LLM8
    • AI 코딩 도구9
    • 컴퓨터 비전4
    • 디자인1
    • 이미지생성2
    • 데이터 아키텍쳐0
    • agent2
    • 모델3
  • Backend1
  • Architecture2
    • 분산 시스템1
    • 데이터0

태그

  • #로컬LLM9
  • #ClaudeCode9
  • #AI개발7
  • #LocalLLM6
  • #AI에이전트5
  • #에이전트4
  • #컴퓨터비전4
  • #MCP4
  • #LLM4
  • #RTX30904
  • #AI코딩4
  • #Anthropic4
  • #모델비교3
  • #객체탐지3
  • #로컬AI3
  • #딥러닝3
  • #개발도구3
  • #Gemma43
  • #이미지생성3
  • #백엔드3

구독

  • RSS
  • Sitemap
로컬 LLM · 2026-05-06 · 13분

노트북 NPU가 이미지 생성에서 GPU보다 빠른 경우

Intel Panther Lake NPU에서 SDXL Turbo가 같은 머신 GPU보다 빠르게 끝나는 결과를 정리. Proxmox + LXC + OpenVINO 셋업의 까다로운 부분, U-Net만 NPU에 올리고 CLIP / VAE는 CPU에 두는 파이프라인 분리 방식, 그리고 한국에서 따라하기 어려운 한계까지 같이 짚어봄.

목차
  • 셋업이 의외로 빡셈
  • 파이프라인을 셋이 나눠 듦
  • 결과 표만 봐도 좀 충격
  • 한계와 안 풀린 부분
  • 곁다리 — Intel 모델 라인업이 좀 정신 사나움
  • 마무리

이미지 생성은 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로 풀어서 굴림. 이 마지막 한 줄이 결과 해석할 때 핵심 변수가 됩니다.

책상 위에 놓인 미니 PC 본체에 야간 조명이 떨어지는 모습

셋업이 의외로 빡셈#

테스트 환경이 좀 특이합니다. 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로 강제로 다시 돌려놔야 함. 이런 디테일은 직접 안 만지면 절대 안 보일 부분이라, 새로 들어오는 사람이 처음 빌드할 때 한참 헤맬 만한 지점이라고 봅니다.

세 갈래 빛의 흐름이 한 줄기로 모이는 추상적 일러스트, 중앙이 가장 밝게 빛남

결과 표만 봐도 좀 충격#

세 모델, 세 디바이스에서 단일 측정 결과가 이렇게 나왔습니다.

모델CPUGPUNPU
lcm-dreamshaper16.05초10.19초8.01초
sd1590.81초16.28초14.31초
sdxl-turbo25.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 직비교는 직접 해볼 길이 없고. 결국 이 글에서 정리한 내용도 자료 위에서의 분석에 머무는 거라, 손으로 만져본 사람이 나타나면 디테일이 더 다듬어질 가능성이 높음.

손바닥 위에 놓인 작은 AI 칩, 부드러운 자연광 아래 클로즈업

곁다리 — 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 공식 문서 가 가장 빠릅니다.

  • #NPU
  • #PantherLake
  • #StableDiffusion
  • #로컬AI
  • #OpenVINO
  • #이미지생성
  • #IntelCoreUltra
  • #SDXLTurbo
  • #Proxmox
  • #로컬추론
D

devway

AI 도구로 실제 서비스 운영하면서 손에 쥔 결과만 적는 1인 개발 노트. RTX 3090 + 로컬 LLM 환경에서 직접 굴려보고 글로 옮긴다.

소개전체 글RSS

관련 글

AI/이미지생성2026-05-03

Z-Image Turbo 글 보다가 OpenVINO 부분에서 멈춰버림

Alibaba Tongyi 팀의 Z-Image Turbo 모델을 OpenVINO로 변환해 INT4 양자화까지 적용하는 영문 글을 한국 개발자 입장에서 다시 정리. 모델 자체의 매력과 INT4 압축의 흥미로운 부분, NVIDIA 중심 생태계에서 Intel 트랙이 갖는 애매한 위치, custom branch 의존성으로 인한 production 적용의 위험성을 솔직하게 짚어봤습니다.

  • #ZImageTurbo
  • #OpenVINO
  • #INT4양자화
  • +7
AI/로컬 LLM2026-05-09

로컬 LLM 도구 비교 글이 자주 비슷한 결론으로 가는 이유

영어권 개발자 블로그에서 자주 보이는 Ollama·LM Studio·Jan 비교 글들이 결국 같은 결론으로 흘러가는 패턴을 짚고, 그 안에서 빠져 있는 모델 선택·fine-tuning·한국어 품질 문제를 한국 개발자 관점에서 정리. 도구 비교는 30%, 진짜 차이를 만드는 건 모델과 운영 시나리오 70%라는 게 핵심.

  • #로컬LLM
  • #로컬AI
  • #AI도구
  • +6
AI/이미지생성2026-05-06

SD3가 SDXL보다 글자 잘 그리는 이유, 데이터 때문이 아니었음

Stable Diffusion 3에서 U-Net이 transformer로 바뀌고 cross-attention 대신 joint attention이 들어간 게 어떤 의미인지, MMDiT 구조를 따라가면서 정리. 이미지 생성 사이트 운영자 입장에서 아키텍처 변화가 출력 품질에 어떻게 묻어나는지, 그리고 구조만 바뀐다고 다 풀리는 건 아니라는 회의까지.

  • #StableDiffusion3
  • #SD3
  • #MMDiT
  • +6

댓글

(댓글 미설정 — NEXT_PUBLIC_GISCUS_* 환경변수 구성 필요)
소개개인정보처리방침RSSSitemapaickywayconvertprompt
© devway