Coral NPU의 1 TOPS·10mW 읽는 법: 배터리 센서의 하루 전력 예산

10mW는 어디까지의 전력인가

Google은 2026년 10월 20일 Coral NPU의 32비트 아키텍처에 행렬 실행 유닛을 더하고, IREE/MLIR 기반 컴파일러 v1.0을 발표했다. 발표문은 구성을 달리해 최대 1 TOPS를 제공하며 평균 추론 전력 10mW를 목표로 한다고 설명한다. TOPS는 초당 연산 수를 나타내는 단위다. 이 글은 11월 1일 확인한 자료를 기준으로 한다. Google 공식 발표

이 두 숫자를 붙여 “1 TOPS를 항상 10mW로 처리한다”고 읽으면 조건이 빠진다. 최대 처리량과 평균 전력에는 모델·정밀도·클록·가동 시간·측정 범위가 필요하다. 마이크, 메모리, 무선 통신, 전원 변환까지 포함한 완제품 전력도 별도로 계산해야 한다. 따라서 단순히 나눈 100 TOPS/W를 이 제품의 검증된 효율로 제시할 수 없다.

Coral NPU는 이름이 같은 한 종류의 완제품이 아니다. 공개 설계, 특정 칩에 통합된 NPU, 개발 보드를 구분해야 한다. 아래는 공급자 발표의 구분이며 가격·재고·직접 성능 시험 결과는 아니다.

대상	확인한 내용	설계자가 따로 확인할 것
Google의 Coral NPU 공개 설계	행렬 유닛을 포함한 32비트 구조와 컴파일러 발표	대상 SoC가 어느 설계·명령·메모리 구성을 구현했는가
Synaptics Coralboard SL	SL2619, 1 TOPS NPU, 2GB DDR4. 10월20일 DigiKey 일반 공급 발표	모델 실행에 필요한 SDK와 보드 전체 소비 전력
Synaptics Coralboard SR	SR250 계열, 400 GOPS, 최대 8MB SRAM·256MB custom DRAM 구성 소개	실제 선택 부품·메모리 구성·구매 및 SDK 제공 조건

SL의 일반 공급과 SR의 소개를 같은 제공 상태로 합치지 않는다. SR200 제품군도 모두 400 GOPS인 것이 아니다. Synaptics는 SR210·SR230·SR250을 각각 200·300·400 GOPS로 나눈다. 같은 Coral 계열이라는 이유로 가장 큰 사양이나 새 행렬 기능을 모든 보드에 적용해서는 안 된다. Coralboard 발표, SR200 제품군 발표

행렬 엔진은 데이터를 쓰는 방식을 바꾼다

AI 모델의 행렬 곱을 작은 예로 생각해 보자. 길이 4인 열벡터와 길이 4인 행벡터의 외적을 구하면 4×4, 즉 16개의 곱이 생긴다. 다음 벡터 쌍에서도 같은 위치에 곱을 더해 나가면 행렬 곱의 결과 타일을 만들 수 있다. 여기서 타일은 전체 행렬을 나눈 작은 조각이다.

입력값을 레지스터에서 여러 곱셈에 쓰고 중간 결과를 누산기에 유지하면, 매 계산마다 중간값을 바깥 메모리로 내보냈다 다시 읽는 일을 줄일 여지가 생긴다. 연산기 개수만 늘리는 것과 데이터 이동을 줄이는 것은 함께 살펴야 한다. 이 4×4 설명은 원리를 위한 축소 예이며 Coral 하드웨어의 정확한 배열 크기나 성능 측정이 아니다.

Coral의 VME 행렬 엔진은 벡터 레지스터에서 피연산자를 읽고 별도 누산기에서 외적의 결과를 더한다. 컴파일러는 계산을 내부 타일에 맞게 나누며, 벡터 엔진은 주변 전후처리에도 쓰인다. 확인한 문서는 Zvt v0.4를 참조하고 v1.0은 2026년 말 예정으로 적고 있다. 현재 구현과 향후 규격을 같은 것으로 부르지 않아야 한다. 행렬 엔진 문서

이 구조가 있어도 모든 모델이 같은 이익을 얻지는 않는다. 작은 행렬, 배열 크기에 맞지 않는 형상, 다른 연산과의 잦은 왕복에서는 준비·이동 비용이 커질 수 있다. 설계상 재사용 가능성을 실제 모델의 지연·에너지 절감으로 바꾸는 과정이 필요하다. 서버 GPU에서 데이터 이동과 처리량의 관계를 먼저 보고 싶다면 HBM과 Roofline 해설이 연결된다. 여기서는 그 다음 질문인 “하루 동안 얼마의 에너지를 쓰는가”에 집중한다.

모델이 끝까지 실행됐어도 전력 목표를 넘길 수 있다

공식 컴파일러 안내는 모델을 중간 표현으로 변환하고, 호스트 CPU와 Coral NPU에 작업을 나누며, 지원되지 않는 연산은 호스트 CPU에서 대체 실행한다고 설명한다. 따라서 모델의 출력이 나왔다는 사실만으로 전체가 NPU에서 실행됐다고 할 수 없다. 컴파일러 구조

센서의 입력 정규화는 CPU, 큰 행렬 곱은 NPU, 지원하지 않는 후처리는 다시 CPU라는 구성이 가능하다. 이때 묻는 것은 “NPU에 몇 개 연산을 넣었나”보다 “CPU를 얼마나 오래 켜 두고 어느 데이터를 옮겼나”다. 작은 연산 하나 때문에 고전력 영역의 깨어 있는 시간이 길어지면 연산 개수 비율은 전력 비용을 잘 설명하지 못한다. 이는 특정 Coral 보드에서 재현한 현상이 아닌 배치 분석이다.

공식 사용 문서는 --coralnpu-dump-affinity-profile-format으로 장치별 dispatch 수, 추정 데이터 크기와 추정 작업량을 볼 수 있다고 안내한다. 이 보고서는 어디에 작업이 배치됐는지 확인하는 입력이다. 추정 작업량을 그대로 mJ로 환산하거나, dispatch 수의 NPU 비율을 에너지 절감률로 읽으면 안 된다. 컴파일 보고서 안내

지원 범위도 문서 층을 나눠 읽어야 한다. 발표는 여러 프레임워크를 넓게 설명하고, 사용 안내에는 JAX 및 TFLite 예제가 있다. 반면 11월 1일 확인한 저장소 README의 첫 설명은 JAX와 호스트 측 시뮬레이션을 중심으로 쓰여 있다. 이는 다른 입력이 모두 미지원이라는 증거도, 모든 모델이 보드에서 즉시 동작한다는 보증도 아니다. 실제 목표 입력·컴파일러 커밋·실행 대상의 조합으로 확인해야 한다. 이 글의 README 기준은 d715556c3853719e414182c0bf5f4a10f248f1d9다. 고정한 README

가상 사례: 작은 감지기가 큰 처리기를 깨우는 센서

설비에서 특이한 소리가 날 때 상태 점검 알림을 보내는 센서를 설계한다고 하자. 안전 제어나 고장 확정 진단을 맡기는 장치가 아니라, 담당자가 추가 확인할 알림을 만드는 가상의 설계 사례다. 실제 제품을 구현하거나 녹음·추론한 결과는 없다.

항상 켜진 작은 모델은 짧은 입력에서 후보를 찾는다. 후보가 생기면 큰 처리기를 깨워 더 긴 구간을 분석하고 필요한 알림을 만든다. 작은 모델을 거치는 이런 단계적 구조에서는 작은 모델의 전력뿐 아니라 큰 처리기가 켜지는 횟수도 중요하다. Synaptics의 SR200 설명도 상시 동작 영역과 고성능·효율 코어의 역할을 나누지만, 아래 수치는 해당 칩의 사양이나 실측값을 대입한 것이 아니다. SR200의 전력 영역 설명

설계 순서는 먼저 놓치면 안 되는 소리와 허용할 오탐을 정하고, 다음으로 처리기를 깨우는 조건을 고르는 것이다. 조용한 환경에서 전력이 낮아도 소음이 많은 작업장에서는 계속 깨울 수 있다. 반대로 임계값을 높여 배터리를 아껴도 필요한 알림을 놓치면 목적을 달성하지 못한다.

배터리에서 허용 평균 전력을 거꾸로 구한다

계산에는 다음 값을 가정한다. 모두 설명을 위한 입력이며 공급자 성능 보증이 아니다.

• 배터리: 공칭 3.7V, 100mAh. 공칭 에너지는 370mWh이며, 손실·여유를 반영해 쓸 수 있는 비율을 80%로 둔다.
• 목표: 24시간. 센서·메모리·통신 대기 등을 합친 바탕 전력은 5mW로 둔다.
• 작은 감지 모델: 하루 평균 4mW 또는 10mW인 두 경우를 비교한다. 뒤의 10mW도 계산 입력일 뿐 발표 목표의 달성을 가정한 측정값이 아니다.
• 큰 처리기: 한 번 깨어나는 동안 바탕 전력 외에 120mW를 0.4초 더 쓴다. 추가 에너지는 48mJ다. 실제 측정에서는 기동·분석·결과 전달·복귀까지 포함해야 한다.

사용 가능 에너지 = 3.7 V × 100 mAh × 0.8 = 296 mWh
24시간 허용 평균 전력 = 296 mWh ÷ 24 h ≈ 12.33 mW

깨우기의 평균 추가 전력 = 48 mJ × 하루 깨우기 횟수 ÷ 86,400 s
총 평균 전력 = 바탕 전력 + 작은 모델 평균 전력 + 깨우기 평균 추가 전력
예상 지속 시간 = 사용 가능 에너지 ÷ 총 평균 전력

배터리 공칭 전압을 쓴 단순 에너지 모델이다. 실제 방전 곡선·온도·노화·순간 전류 제한까지 예측하는 배터리 시뮬레이션은 아니다. 추가 전력을 정의했으므로 바탕 전력을 다시 더해 중복 계산하지 않는다.

가정 시나리오	총 평균 전력	단순 계산 지속 시간
작은 모델 4mW, 하루 600회 깨우기	약 9.33mW	약 31.7시간
작은 모델 10mW, 하루 600회 깨우기	약 15.33mW	약 19.3시간
작은 모델 4mW, 하루 6,000회 깨우기	약 12.33mW	24.0시간
첫 경우에 CPU 대체 비용 평균 3mW 추가	약 12.33mW	24.0시간

마지막 행은 CPU가 바탕 전력 외에 60mW를 하루의 5% 동안 더 쓴다는 별도 가정이다. 이를 작은 모델이나 깨우기 비용에 이미 포함했다면 다시 더하면 안 된다. 계산은 직접 검산했지만, 표의 시간은 실물 기기의 배터리 시험 결과가 아니다.

이 표가 바꾸는 선택은 두 가지다. 첫째, NPU 단독 전력이 낮아 보여도 주변 회로를 더하면 하루 목표를 넘길 수 있다. 둘째, 작은 모델의 전력이 같아도 오탐 등에 따른 깨우기 증가로 여유가 사라질 수 있다. 목표선에 정확히 도달한 경우 역시 실제 제품의 변동을 감당할 여유는 없다.

따라서 비교할 모델은 분류 정확도 한 숫자로 고르기 어렵다. 놓친 사건 수, 불필요한 깨우기 횟수, 알림이 늦는 시간, 전체 전력이라는 네 결과를 같은 입력에서 봐야 한다. 잡음 구간에서 감지를 일부러 포기해 전력만 낮춘 설정은 비교에서 드러나야 한다. 단계별 모델 선택의 다른 예는 작은 결정 모델을 이용한 라우팅 분석으로 이어진다.

도입 시험에서 남겨야 할 세 가지 결과물

보드를 주문하거나 모델을 바꾸기 전에는 시험이 어떤 결정을 돕는지 정하는 편이 좋다. 다음은 이 사례를 위한 제안이며 실행 완료 기록이 아니다.

결과물	담을 내용	그 결과로 할 결정
모델·컴파일 배치표	입력 형상·정밀도·모델 해시, 컴파일러 커밋, CPU/NPU 작업과 추정 이동량	CPU로 남은 부분을 바꿀지, 모델을 줄일지, 다른 장치를 비교할지
감지·깨우기 대조표	동일한 정상·이상·잡음 입력의 누락, 오탐, 깨우기 횟수, 알림 지연	요구 품질을 만족하는 임계값과 처리 단계 선택
장치 전체 전력 기록	측정 지점·샘플링 조건, 대기와 실제 동작, 기동·통신·복귀 구간	하루 목표의 여유와 배터리·주변 장치 설계 결정

컴파일 오류가 난 모델은 출력 품질 비교로 넘어갈 수 없다. 실행은 되지만 CPU 쪽 시간이 길면 배치표를 먼저 본다. 조용할 때만 목표를 만족하면 모델 피크 성능보다 깨우기 패턴을 조사한다. 이처럼 실패 위치가 달라지면 다음에 바꿀 것도 달라진다.

시뮬레이터는 출력과 실행 경로를 살피는 데 쓸 수 있지만, 호스트에서 프로그램이 끝난 시간을 실물 NPU의 전력·속도로 치환하지 않는다. Google 사용 안내의 MobileNet 예제도 NPU 부분을 시뮬레이션한다고 명시한다. 이 글에서는 해당 빌드와 실행을 수행하지 않았다. 공식 실행 대상 설명

전력 예산·모델 배치 기록지를 받아 자신의 배터리·전력·깨우기 값으로 채울 수 있다. 미측정 칸은 unknown으로 남기고, 가정 계산과 관측값의 열을 분리했다. 같은 모델·입력·보드에서 비교해야 변경 효과를 해석하기 쉽다.

어떤 팀의 선택이 달라지나

Coral NPU의 공개 하드웨어와 컴파일러는 칩과 소프트웨어를 함께 검토하려는 팀에 구체적인 출발점을 준다. 특히 작은 모델을 계속 돌리고 필요할 때 더 큰 계산으로 넘기는 제품이라면, 지원 연산과 전력 영역을 함께 보는 설계가 중요해진다. 공개 코드가 있다는 사실만으로 모델 이식·양산·소비 전력 검증 비용이 사라지지는 않는다.

이미 CPU만으로 필요한 감지 품질과 하루 전력 목표를 충족한다면 NPU 도입을 먼저 할 이유는 약하다. 반대로 모델을 확장할 때 CPU 대체나 잦은 깨우기로 목표를 넘긴다면, 행렬 엔진과 컴파일 배치가 실제 선택을 바꿀 수 있다. 최종 비교 단위는 최고 TOPS보다 필요한 사건을 놓치지 않으면서 하루를 버티는 전체 장치다.

스마트폰 앱의 런타임 배포와 GPU 준비가 고민이라면 LiteRT의 Play services 이전 분석이 더 직접적인 다음 읽을거리다. 센서 설계에는 위 기록지를 저장해 두고, 부품·모델 버전이 바뀔 때 같은 입력으로 다시 비교하면 된다.