AI PC의 AI 성능 부족: CPU가 NPU를 능가

 (github.com/usefulsensors)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Microsoft Surface Pro 11th Edition의 Qualcomm Arm 기반 SoC에서 NPU 벤치마크를 실행한 결과, Windows AI PC가 내세우는 가속 성능보다 훨씬 낮은 처리량이 측정됨
  • 테스트는 Onnx Runtime과 Qualcomm QNN 실행 공급자를 사용해 transformer 계열 모델의 비용 큰 레이어와 비슷한 대형 MatMul 연산을 실행하는 방식으로 구성됨
  • 예시 결과에서 CPU는 821 Gigaops/s, NPU는 float 입출력 양자화 구성에서 225 Gigaops/s, 8-bit 입출력까지 적용한 구성에서 573 Gigaops/s를 기록함
  • NPU의 573 Gigaops/s는 Microsoft Surface Pro 11th Edition 마케팅 자료의 45 Teraops/s 대비 1.3% 수준이며, 같은 모델을 Nvidia Geforce RTX 4080 Laptop GPU에서 실행하면 3.2ms, 2,160 Gigaops/s가 나옴
  • 현재 결과는 2024년 10월 2일 기준이며, 소프트웨어·프레임워크·드라이버 수준 개선으로 지연 시간이 낮아질 가능성을 기대하지만 현 벤치마크에서는 CPU가 NPU보다 빠름

Surface의 Qualcomm NPU 벤치마크 목적

  • Microsoft는 Qualcomm Arm 기반 SoC를 탑재한 Surface 태블릿을 Windows AI PC로 판매하며, 머신러닝 모델을 더 빠르고 효율적으로 실행할 수 있다고 홍보함
  • Useful Sensors는 Qualcomm 하드웨어와 NPU를 긍정적으로 보고, 자사 서드파티 앱을 이 플랫폼으로 포팅하는 데 시간과 자원을 투입함
  • 외부 개발자가 빠른 결과를 얻는 방법을 보여주는 코드 예제나 벤치마크가 많지 않아, 실제로 관찰한 성능을 작은 독립 프로젝트로 공개함
  • 측정 성능은 기대보다 크게 낮았고, Android 같은 다른 플랫폼에서는 같은 하드웨어가 효과적으로 동작한 경험이 있어 향후 애플리케이션·프레임워크·드라이버 변경을 통한 개선 가능성을 열어둠

실행 환경과 설치 제약

  • 테스트에는 Windows에서 Python 스크립트를 사용함
    • 2024년 10월 2일 기준 Microsoft Store의 Python은 Arm 아키텍처를 지원하지 않아 Qualcomm NPU 접근에 필요한 패키지 실행에 적합하지 않음
    • 결과에는 Python 3.11.9 Arm64 설치 파일이 사용됨
  • Windows on Arm용 사전 빌드 Onnx 패키지가 아직 없어 CMake와 Visual Studio 컴파일러가 필요함
    • CMake는 winget install cmake로 설치함
    • Visual Studio는 Visual Studio Community Edition을 사용하며, 설치 시 Desktop C++ Development 워크로드를 선택함
  • Python 패키지는 저장소 폴더에서 py -m pip install -r requirements.txt로 설치함
    • Onnx 브랜치는 공식 py 런처 컴파일 수정이 Onnx 1.16에 백포트된 버전임
    • Qualcomm Onnx Runtime은 최신 Onnx에서 Unsupported model IR version 오류가 나기 때문에 이 조합을 사용함
    • Qualcomm Onnx Runtime 패키지는 nightly 빌드가 사용됨

벤치마크 실행과 출력 해석

  • 벤치마크는 py benchmark_matmul.py로 실행함
  • Onnx Runtime은 초기 실행 중 로그를 많이 출력함
    • 예시로 Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz 칩 모델을 알 수 없다는 cpuinfo 메시지가 나옴
    • 그래프 마무리 단계와 완료 단계 로그도 출력됨
  • 실제 벤치마크 결과는 마지막에 표시됨
    • NPU quantized compute, float I/O accuracy difference is 0.0100
    • NPU quantized compute and I/O accuracy difference is 0.0060
    • CPU took 8.42ms, 821,141,860,688 ops per second
    • NPU (quantized compute, float I/O) took 30.63ms, 225,667,671,183 ops per second
    • NPU (quantized compute and I/O) took 12.05ms, 573,475,650,364 ops per second
  • 첫 두 줄은 CPU와 NPU의 수치 결과가 서로 맞는지 확인하는 정확도 차이를 보여줌
  • 마지막 세 줄은 모델을 처음부터 끝까지 실행하는 벽시계 시간과, 그 지연 시간에서 계산한 초당 연산량을 보여줌

측정 대상 모델과 양자화 방식

  • 벤치마크는 OpenAI Whisper 같은 transformer 모델에서 시간이 많이 걸리는 레이어와 유사한 6개의 큰 행렬 곱셈을 재현하도록 설계됨
    • 입력 모양은 (6, 1500, 256) X (6, 256, 1500)임
    • 결과 모양은 (6, 1500, 1500)임
    • 모델은 입력 2개와 출력 1개를 가진 단일 MatMul 노드로 구성됨
  • 모델은 Onnx 모델 프레임워크로 즉석 생성한 뒤 Onnx Runtime에 전달함
  • 기준 모델은 순수 float 버전이며 CPU에서만 실행됨
  • NPU는 효과적으로 실행하려면 주로 양자화 모델이 필요하며, float16은 제한적으로 지원함
  • 첫 번째 NPU 접근은 공식 ORT quantize_static() 메서드를 사용함
    • 편의를 위해 입력과 출력 텐서는 32-bit float로 남김
    • 그래프 시작과 끝에서 런타임 변환을 수행하고, 나머지 계산은 8-bit로 실행함
  • 이 구성에서는 NPU의 변환 연산이 매우 느렸고, npu_quant_profile.csv에서 변환이 전체 시간의 75% 이상을 차지함
  • 두 번째 접근은 8-bit 입력과 출력을 가진 동등한 모델 그래프를 프로그램으로 구성함
    • 이 quantized compute and I/O 방식은 float I/O 버전보다 보통 약 3배 빠름
    • 프로파일링에서는 대부분의 시간이 기대대로 행렬 곱셈에 쓰임

성능 측정에서 고려한 변수

  • Compute bound 여부를 고려해 행렬 모양을 더 정사각형에 가깝게 잡음
    • 현대 transformer 모델은 오래된 convolution 모델과 달리 큰 행렬 곱셈에 기반함
    • 레이어가 행렬-벡터 곱에 가까워지면 가중치 재사용이 줄고 DRAM 값 가져오기가 병목이 될 수 있음
    • tiny Whisper 원래 행렬의 k 차원은 64였지만, 이 벤치마크에서는 SIMD 최적화 여지를 넓히기 위해 256으로 올림
  • 전원 설정은 성능을 높이는 쪽으로 맞춤
    • Windows 에너지 설정은 모두 Best Performance로 두려 했음
    • 태블릿을 전원에 연결한 상태에서 벤치마크를 실행함
    • Qualcomm Onnx Runtime의 htp_performance_mode 세션 옵션은 실험에서 전체 지연 시간이 가장 낮았던 sustained_high_performance로 설정함
  • 모델 구조는 해석이 쉽도록 단일 행렬 곱셈으로 제한함
    • 여러 레이어, convolution, 정적 가중치도 가능했지만 LLM과 현대 모델에서 널리 쓰이는 transformer 구조를 반영하기 위해 동적 입력을 가진 단일 MatMul을 선택함
  • 구성 오류 가능성도 남아 있음
    • unsigned 8-bit 양자화와 그래프 내 qdq 요소를 사용함
    • 문서의 모범 사례를 따르려 했지만, 드라이버나 가속기 구현의 빠른 경로를 벗어났을 가능성이 있음
  • Windows에서 AI 가속에 접근하는 API 선택지도 검토됨
    • DirectML은 GPU 접근만 지원하는 것으로 보임
    • OpenVino는 해당 Arm 하드웨어에서 실행되지 않는 것으로 보임
    • Qualcomm QNN SDK를 직접 사용해도 비슷한 성능 결과를 봄
    • TensorFlow Lite는 Windows for Arm을 지원하지 않음
    • 이 조사와 실험에서는 Onnx가 Microsoft와 Qualcomm 양쪽에서 지원되며 NPU 가속 성능을 얻는 데 가장 적합한 프레임워크로 보임

결과 해석

  • 결과는 2024년 10월 2일 기준이며, Microsoft Surface Pro 11th Edition에서 측정됨
    • SoC는 Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz임
  • float 변환을 제외해도 NPU 결과가 CPU보다 느림
    • 가속기 관점에서는 이상적이지 않음
    • 다만 에너지 효율이나 지속 성능에서 이점이 있을 가능성은 배제하지 않음
  • 측정된 최고 NPU 성능인 573 billion ops/s는 Microsoft Surface Pro 11th Edition 마케팅 자료의 45 trillion ops/s 대비 1.3%임
  • 같은 모델을 Nvidia Geforce RTX 4080 Laptop GPU에서 실행하면 3.2ms가 걸림
    • 이는 2,160 billion ops/s에 해당함
    • Surface의 NPU 측정치보다 거의 4배 높은 처리량임

함께 보면 좋은 글 β

bungker   [-]

ryzen npu는 cpu보다 조금 빠른걸로 알고있었는데 스냅드래곤 뽐이 확죽네요

답변달기
GN⁺   [-]
Hacker News 의견들

  • 결과를 보면 전반적으로 연산 자원 활용이 잘 안 된 것 같음. CPU 8.4ms, GPU 3.2ms면 차이가 너무 작고, 여기서는 10~20배 차이를 기대했을 법함
    원인은 onnxruntime일 수 있음. 일부 하드웨어 업체가 연산 유닛만 내놓고 제대로 된 지원은 아직 안 붙이는 경우가 있어 보이며, 얼마나 빨리 바뀔지 지켜볼 일임
    또한 NPU의 목적을 “속도”로 오해하는 경우가 많은데, 핵심은 저전력임. 속도를 노리려면 메모리 병목을 없애야 하고, 결국 자체 메모리를 가진 ASIC을 설계하게 됨. 대부분 기기의 NPU는 CPU 주변 SoC에 붙어 AI 연산을 오프로드하는 용도임
    CPU/NPU/GPU 세 장치에서 이 벤치마크를 무한 루프로 돌리고 전력 소모를 재면 흥미로울 듯함. NPU가 가장 낮고 와트당 연산도 가장 좋을 것으로 예상함

    • NPU의 진짜 이유는 마케팅일지도 모른다는 의심이 듦. “NVDA가 3.3조 달러 가치라니, 우리 제품에도 AI 뭔가를 넣자” 같은 흐름일 수 있음
    • NPU는 오프로드 목적도 큼. 용도에 따라 CPU와 GPU가 다른 작업으로 바쁠 수 있으니, NPU는 서로 뺏지 않고 쓸 수 있는 추가 대역폭이 됨
      예를 들어 AI 사진 필터에서는 GPU가 미리보기 렌더링을 하고, CPU는 UI와 사용자 입력을 처리하느라 바쁠 가능성이 큼
    • 이게 Nvidia의 해자임. 거의 모든 것이 CUDA용 최적화 커널을 갖고 있고, 경우에 따라 Apple Accelerate 정도가 있음
      Apple Accelerate는 M4 이전 CPU 행렬 유닛과 NPU에 접근하는 사실상 유일한 경로였음. 그 외의 것을 쓰고 싶다면 선택한 머신러닝 프레임워크에 패치를 올릴 준비를 하거나, 학습과 추론 코드를 직접 쓸 준비를 해야 함
    • onnxruntime을 써서 순수 C로 앱을 만들고 있는데, Python으로 만든 비슷한 앱보다 성능이 꽤 많이 좋았음. 아직 얻을 수 있는 성능 개선이 많음
      결국 Python도 C를 호출하긴 하지만, 얼마나 많은 성능이 사라지는지 꽤 흥미로움
    • 타이밍을 제대로 재고 있지 않은 것 같고, 일반적으로 마케팅되는 “시간”도 사람들이 생각하는 측정값과 다를 때가 많음. 그래도 마케팅 수치는 비교가 쉬운 경우가 있음
      GPU를 쓴다면 타이밍 안에 비동기 작업이 포함되는지 고려해야 함
      time.time()을 순진하게 쓰면 CPU가 시간만 기록하고, model(input.cuda()).cuda()는 데이터를 GPU 메모리로 보내고 연산을 시작하지만 비동기라서, 결과가 실제로 준비됐는지와 무관하게 종료 시간이 기록될 수 있음
      시스템과 하드웨어를 모르면 기대하기 어려운 동작임. Python뿐 아니라 대부분의 언어는 작성한 코드보다 더 최적화된 형태로 컴파일되도록 설계되어 있고, 잠금이 없으니 CPU 작업을 막지 않음
      GPU 작업을 실제로 재려면 CUDA 이벤트 타이머를 봐야 함. PyTorch에서는 torch.cuda.Event(enable_timing=True)를 쓰는 방식임
      추가로 메모리 크기와 형태도 복잡함. 이 벤치마크는 NPU에 불리한 형태를 쓰고 있음. NPU와 GPU는 보통 channels last를 원하므로 [1,6,1500,1500]보다 [1,1500,1500,6]가 맞음
      1500과 6도 어색한 숫자라 NPU에 좋지 않고, 이런 장치가 아직 새롭다는 점을 고려하면 성능 손실이 꽤 클 수 있음
      더 자세한 내용은 https://news.ycombinator.com/item?id=41864828에 적어둠

  • 이런 NPU들이 상당한 실리콘 면적을 차지하고 있어서, 결국 별로 쓰이지 않는다면 정말 아쉬울 것임. Snapdragon X에서 NPU만 따로 떼어낸 다이 분석은 못 찾았지만, 비슷하게 약 50 TOPS 목표를 가진 AMD 쪽은 여기서 볼 수 있고, 고성능 CPU 코어 3개 정도의 면적을 차지함
    https://www.techpowerup.com/325035/amd-strix-point-silicon-p...

    • LLM 유행이 끝나서 다시 어느 정도의 상식과 효율이 돌아왔으면 좋겠음. 개인적으로 이 추가 하드웨어를 쓸 일이 없고, “GenAI”는 내게 아무 도움도 안 되며 업무 관련 작업도 지원하지 않음
      더 나쁘게는 대부분의 사람에게도 필요가 없어 보이고, 최근 조사에서는 AI 침투에 대한 반감이 우세하게 나타나기도 함. 이런 것에 추가 비용을 내면 안 되고, 선택 사항이어야 함
      그렇게 하면 “AI” 프리미엄을 내고 싶어 하는 사람이 얼마나 적은지 판매량으로 드러나면서, 이게 얼마나 과장되고 불필요한지 분명해질 것임
    • 현대 칩은 다이의 일정 비율을 다크 실리콘으로 남겨야 함. 그렇지 않으면 녹거나 쓸모없을 정도로 스로틀링됨. 이런 구성요소도 그 비율에 포함됨
      그래서 이런 부품의 목적은 쓰이되, 너무 많이 쓰이지 않는 것임
      NPU 대신 그 트랜지스터와 다이 공간을 여러 용도로 쓸 수는 있었겠지만, 고성능 CPU 코어를 더 넣지는 않았을 것임. 그러면 전력 밀도가 너무 높아져 영구적인 스로틀링 없이는 해결하기 어려운 열 문제가 생김
      [1] https://en.wikipedia.org/wiki/Dark_silicon
    • 나도 같은 생각임. 지금은 NPU가 있는 시스템을 사려면 일부러 찾아야 해서 아직 갖고 있지 않지만, 앞으로는 기본으로 포함될까 봄
      모델을 돌리지 않을 사람들에게는 낭비처럼 보이고, 다른 용도로 쓸 수 있는 방법이 무엇인지 궁금함
    • Snapdragon X는 여전히 12코어이고, 모두 같은 코어인 동질 구조임. Strix Point도 12코어지만 4+8 구성이고, “작은” 코어도 ARM 설계의 작은 코어처럼 존재 의미가 없을 정도로 성능을 희생하지는 않음
      소비자용 소프트웨어는 그 정도까지 확장되지 않는데, 트랜지스터를 CPU에 더 배정해서 무엇을 할 수 있겠나 싶음
      Apple이 SoC에 비디오 엔진을 많이 넣는 이유와도 비슷함. 감당 가능한 트랜지스터 예산으로 딱히 다른 데 쓸 곳이 많지 않음. 단일 스레드 성능 개선은 더 이상 트랜지스터 수만으로 제한되지 않고, 소프트웨어는 멀티스레딩을 잘 못함

  • 이런 장치의 목적은 빠른 것이 아니라, 작은 모델을 아주 낮은 전력으로 돌리는 것이라고 생각했음. NPU가 있는 최신 AMD 노트북을 쓰는데, NPU에서 돈다는 영상 효과를 켜도 전력 사용량은 변하지 않지만 Nvidia Studio Effects를 쓰면 전력 사용량이 올라감
    NPU는 시선 맞춤, 배경 흐림, 자동 교정 모델, 전사, OCR 같은 작은 작업을 하는 매우 최적화된 모델용으로 보임. 특히 Windows에서는 rewind 기능을 위해 전체 화면 OCR과 검색용 임베딩을 돌린다고 봤음

    • 특히 그 장치가 Xilinx FPGA라면 더 그렇다고 봄. 최신 모바일 Ryzen에 붙인 것은 성능도 5배 더 좋음
      AMD는 요즘 훌륭한 작업을 하고 있는데, 그걸 크게 떠들지는 않는 것 같음. 이건 특히 흥미로움: https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE1...
      수정: FPGA가 아니었음. 오늘 배움
    • 내 이해도 같음. 핵심은 저전력과 낮은 지연 시간임
      macOS에서 CoreML 모델을 평가해 보면 확인할 수 있음. ANE는 GPU의 절반 정도 시간이 걸리고, GPU는 CPU의 절반 정도 시간이 걸림. 실제 배율은 모델에 따라 달라짐
    • 저전력은 곧 더 저렴한 토큰이고, 더 감당 가능하고 지속 가능한 사용으로 이어진다고 봄. 소비자가 전반적으로 얻는 이점은 여기에 있음. 전력 많이 먹는 GPU는 연구, 상업, 엔터프라이즈에 더 잘 맞아 보임
      Nvidia를 위협할 칩은 스마트폰 같은 개인 기기에서 충분히 괜찮은 모델을 돌릴 수 있을 만큼 저렴한 칩과 메모리일 것임
      일반 대중이 LLM의 유용성에 동의하고 기기 가격에 약간의 프리미엄을 낼 의향이 있다면, 이 기술의 미래는 본질적으로 사생활 보호를 제공하는 개인 모델이라고 봄
      사람들이 ChatGPT 같은 곳에 쏟아내는 개인정보의 양은 놀라울 정도임. Reddit을 보면 AI 가상 여자친구 앱 중독자들이 가장 어두운 취향, 취약한 고백, 심지어 범죄가 될 수 있는 대화까지 이름 없는 앱 회사에 넘기는 경우가 많아 보임
      Google도 Gemini 기록을 켜면 대화 내용을 검토할 수 있다고 명시함
      더 큰 모델이 필요한 복잡한 토큰 예측은 클라우드 LLM에 물어볼 수 있겠지만, 소비자에게는 사생활 보호가 반드시 보장되어야 함
      일상적인 개인 비서, 채팅, 정보 탐색에는 최첨단 추론이나 묘기성 LLM이 필요하다고 보지 않음
    • Pixel에서 온디바이스 음성 인식을 출시할 때 들은 내용과, Google을 떠난 뒤 Apple Neural Engine과 CPU로 ONNX 작업을 돌려본 결과를 보면 이 말이 맞다고 봄
      다만 글의 구체적인 결론은 조금 의심스러움. Qualcomm의 ONNX이고, 오래됐을 수도 있음. Android 쪽에서는 Qualcomm 소프트웨어 엔지니어링을 많이 욕하곤 했음
      그래도 방향성은 맞음. 소비자 하드웨어의 AI 가속 주장 대부분은 거의 보편적으로 허풍에 가깝고, 예외는 A) 1P 소프트웨어를 쓰거나 B) 1P 내부 누군가가 정말로 당신이 그 기능을 활용하길 원하는 경우임
    • 맞음. 다만 이런 장치를 Python으로 프로그래밍하고 싶지는 않을 것임. 특히 새 장치라 최적화가 잘 이식되지 않았을 가능성이 높아서 좋은 성능을 기대하기 어려움
      TensorRT 같은 것을 써도 처음부터 직접 작성하는 것만큼 빠르지는 않을 것이고, Nvidia가 많은 인력을 투입하는 이유도 있음. 그래도 꽤 가까이 가고 작성 시간을 많이 줄여줌
      이런 장치들은 대체로 반복되는 비슷한 작업에 최적화되어 있음. 그래서 여기서 수집한 정보 일부가 부정확할 수 있다고 봄
      이 NPU 칩들을 직접 써본 것은 아니지만, 타이밍을 신뢰하기 어려움. 끝부분의 CUDA 타이밍은 코드상 제대로 측정되지 않았을 가능성이 큼. 타이밍 측정은 생각보다 쉽지 않음
      광고되는 연산 수는 NPU에서 직접 수행된 연산만 세는 반면, 원글은 NPU와 GPU 측정에 CPU 작업까지 포함했을 수 있음. 문서에는 벤치마킹 도구가 있으니 비슷한 방식을 썼을 것 같고, 워밍업 이후 분산이 어떻게 되는지도 궁금함
      데이터 형식도 잘못된 듯함. 여기서는 channels last가 필요함. 문서도 이를 확인해 줌
      1500이라는 숫자도 어색해서 추가 미스가 생길 수 있음. 1536, 2048, 256, 혹은 더 작은 값에서는 결과가 달라질 수 있음. 실제 모델은 전체 해상도 이미지를 처리하지 않고, 아키텍처를 모델용으로 최적화한다면 형태 정보가 중요해짐. 머신러닝에서는 형태 최적화가 꽤 중요함
      문서를 빠르게 보면 설정도 부적절해 보임. “Model Workflow”에서는 데이터를 8비트 또는 16비트 부동소수점으로 원한다고 하는데, 부동소수점에도 여러 종류가 있음. PyTorch의 bfloat는 torch.half나 torch.float16과 같지 않음
      혼합 정밀도는 아직도 헷갈리는 주제라, 이런 문제가 있으면 제대로 살펴볼 가치가 있음. 표준 양자화 절차만 돌리고 끝내는 것은 추천하지 않음. 시작점으로는 좋지만, “충분히 좋다”가 아니라면 거기서 멈추면 안 됨
      그래도 이 결과가 쓸모없다고 생각하지는 않음. 다만 개선이 필요함. 이런 일은 생각보다 복잡하고, 그 상당 부분은 기술이 새롭고 세부사항이 아직 정리 중이기 때문임
      CPU나 GPU, 특히 CUDA와 비교할 때는 수십만 인시가 투입됐고 Python 같은 고수준 라이브러리에도 최소 수만 인시가 들어갔다는 점을 기억해야 함. 이 장치들은 평균 사용자가 선호하는 언어 추상화 수준에서 바로 쓰기에는 아직 준비가 덜 됐지만, 하드웨어에 가깝게 작업할 의지가 있다면 꽤 유용함
      PyTorch에서 GPU 비동기 작업을 재려면 CPU 타이머로 모델 출력을 감싸는 대신 CUDA 이벤트와 torch.cuda.synchronize()를 써야 함
      [1] https://www.thonking.ai/p/what-shapes-do-matrix-multiplicati...

  • NPU에 모델을 배포하려면 프로파일 기반 최적화가 상당히 필요함. CPU에서 잘 도는 모델을 NPU용으로 최적화하지 않은 채 가져오면 보통 실망스러운 결과가 나옴

    • CPU의 아름다움은 어떤 엉망인 코드라도 합리적인 속도로 씹어 처리해 준다는 데 있음
    • IREE나 OpenXLA 같은 것을 다루는 사람들과 이야기할 때마다, 그런 컴파일러와 런타임을 이해하고 쓰는 것 자체가 하나의 직업이라는 인상을 받았음

  • GitHub 저장소의 설명이 블로그보다 훨씬 유익함
    onnx로 int8 행렬 곱을 돌리면 성능은 약 0.6TF임
    https://github.com/usefulsensors/qc_npu_benchmark

  • 입력 행렬을 더 정사각형에 가깝게 만들어 타일링과 재사용이 가능하게 했다고 하지만, 가능한 최적화 상당수가 Onnx에 들어가지 않았어도 놀랍지 않음
    Qualcomm은 NPU에 직접 접근하게 해주지 않고, 사용자가 프레임워크로 모델을 변환해 넘기도록 기대하는 것 같음. 내 경험상 변환 도구는 대체로 별로라 많은 최적화를 놓침
    따라서 “NPU가 별로”라기보다 “변환 도구가 별로”일 수 있음. 직접 접근할 수 있을 때까지 기다릴 것이고, 변환 도구는 신뢰하지 않음
    NPU는 아주 작은 머신러닝 모델과 매우 빠른 함수 근사에 좋다고 봄. 그게 내가 의도한 용도임. LLM이 요즘 뜨겁긴 하지만, 작은 모델이 정말 유용한 전문 작업은 엄청나게 많음

    • 작은 모델이 유용한 전문 작업의 예를 들어줄 수 있을까? 가능하면 작은 모델이라도 캐시에 머무를 만큼 지속적으로 실행되고, 그 캐시 점유를 정당화할 만큼 많은 사용자에게 가치 있는 예가 좋겠음
      그런 것이 없다는 뜻은 아니지만, 솔직히 무엇인지 잘 몰라서 알고 싶음
    • 나도 이 말을 하려고 왔음. Elite X는 써보지 않았지만, 이전 세대 장치들, 주로 865에서 가속기인 컴퓨트 DSP와 훨씬 작은 NPU는 매우 구체적인 설정, 전용 툴체인 컴파일, RPC 통신 같은 것이 필요했음
      Elite X의 NPU는 Copilot+ 때문에 접근이 더 쉬워졌기를 바라지만, 요점은 “범용 모델을 실행하면 마법처럼 NPU로 순간이동하겠지” 같은 식으로 쉬울 리는 없다는 것임

  • RTX 4080은 약 40 TFLOPS가 가능해야 하는데, 여기서는 초당 2,1600억 연산만 보고함. 이 정도면 벤치마크를 재검토해야 하지 않나 싶음
    FLOPS 측정에 심각한 오류가 있었을 가능성이 큼. CPU가 NPU를 이기는 것은 가능하지만, 제대로 비교하려면 애플리케이션 동기화 없이 여러 행렬 곱을 벤치마크해야 함

    • 그건 일부에 불과함. 문서를 대충 훑어봐도 CPU 추론도 비교 가능한 방식으로 수행되지 않았음

  • 벤치마크는 (6, 1500, 256) X (6, 256, 1500) 형태의 행렬 곱인데, AI 세계에서는 그리 큰 크기가 아님. 훨씬 큰 행렬이면 격차가 더 커질 것임
    예를 들어 작은 모델 중 하나인 Llama 3.1 8B도 (batch, 14336, 4096) x (batch, 4096, 14336) 같은 행렬 곱을 가짐
    이 벤치마크는 충분히 현실적이지 않다고 봄

  • 이 벤치마크에 Qualcomm NPU 프로파일러인 qprof를 돌려봤음. 프로파일 결과를 보면 작업이 NPU 연산력의 대부분을 제공하는 텐서 코어가 아니라 벡터 코어로 배분됐음
    대략 계산해보면 HMX가 HVX보다 30배 강한 것으로 보임
    작업량이 비교적 작아서 입출력 양자화/역양자화와 NCHW-NHCW 매핑의 오버헤드 때문에 하드웨어 용량을 충분히 쓰지 못함. 가중치와 입력을 64의 배수로 패딩해도 성능에 도움이 될 것임
    프로파일링 그래프: https://imgur.com/a/2OKR93e
    추정 HVX 연산 성능은 int8에서 4 * 2 * 1.43 * 1024 / 8 = 1.46TOPS임. 여기서 4는 벡터 코어 수, 2는 사이클당 연산 수, 1.43GHz는 HVX 주파수, 1024bit는 벡터 레지스터 폭, 8bit는 정밀도임

    • 수식 포맷이 잘못됐고, 4 * 2 * 1.43 * 1024 / 8이어야 함

  • 실제 글 제목은 “Benchmarking Qualcomm's NPU on the Microsoft Surface Tablet”이어야 함
    이건 NPU 일반에 관한 글이 아니라, 특정 NPU를 특정 벤치마크와 특정 라이브러리/프레임워크 조합으로 본 것임. 그래서 사실상 아무것도 증명하지 못함

답변달기