귀하의 엣지 디바이스는 단일 포워드 패스로 벤치마크되었습니다. 귀하의 에이전트는 루프를 실행합니다.

엣지 AI에 대한 하드웨어 논의가 지난 1년 동안 훨씬 더 솔직해졌습니다. 이 사이트의 최근 기사에서는 기존 설계 계층 구조—“처리량을 최대화하고, 그 뒤에 전력과 열을 관리한다”—가 뒤바뀌었으며, 산업 현장에서는 전력이 최우선이 되고 원시 처리량은 마지막이 되었다고 주장했습니다. 이 출판물이 오랫동안 제시해 온 주장, 즉 엣지 디바이스는 “열 제한이며, MIPS/연산 제한이 아니다”이며 스마트폰이 이미 그 한계에 도달하고 있다는 논리와 일맥상통합니다. 두 가지 모두 실제 교정이며, 이제야 제때 이루어졌습니다.

하지만 여전히 수정하려는 세계의 한 가정을 그대로 가지고 있습니다. 그 계층 구조의 모든 항목은 가정된 워크로드를 기준으로 예산이 책정되며, 대부분의 사람들이 아직도 예산을 잡는 워크로드는 단일 포워드 패스입니다: 모델이 입력을 받고 출력을 생성한 뒤 실리콘이 잠시 식는 시간.

그것은 에이전트가 하는 일이 아닙니다. 에이전트는 결정을 내리고, 도구를 호출하고, 반환된 결과를 읽은 뒤 다시 결정을 내립니다. 그 루프를 몇 번 도는지는 하드웨어의 속성이 아니며, 모델의 속성도 아닙니다. 이는 그 아침에 누군가가 전달한 문제의 속성입니다. 저는 엣지 하드웨어에서 에이전트를 실행해 보았고, 가장 오래 걸려 받아들인 점은 에이전트가 느리다는 것이 아니라, 실행 비용이 설계 시점에 전혀 볼 수 없는 곳에서 설정되고 있었다는 점이었습니다.

The Loop Is Unbounded Until Someone Types a Number

이는 수사적 표현이 아니라 프레임워크가 실제로 구축된 방식입니다. OpenAI의 Agents SDK에서는 러너가 “루프를 실행”하고, 모델이 도구 호출을 생성하면 런타임이 “그 도구 호출을 실행하고 결과를 추가한 뒤 루프를 다시 실행”합니다. 이를 멈추게 하는 유일한 요소는 턴 제한이며—max_turns를 초과하면 예외가 발생하고—문서에서는 max_turns=None을 전달하면 제한을 완전히 해제할 수 있다고 명시하고 있습니다.

서버에서는 그 숫자가 청구 결정과 연결됩니다. 누군가가 청구서를 확인하죠.

디바이스에서는 그 숫자가 열 관리 결정과 연결됩니다. 루프 길이가 듀티 사이클이기 때문입니다. 그리고 듀티 사이클은 수동 냉각이 논쟁할 수 없는 유일한 변수입니다.

Sustained Load Does Something Different to a Phone Than a Benchmark Does

2026년 3월 벤치마크 논문은 정확히 이러한 부하를 네 개의 플랫폼에 적용했습니다: 15억 파라미터 양자화 모델, 고정된 258 토큰 프롬프트, 연속 20회 실행, 각 실행마다 처리량, 전력, 온도 측정. 이는 사전 인쇄본이며 하나의 모델을 네 장치에서 테스트한 것이므로, 구체적인 수치는 해당 플랫폼을 특성화하는 자료로 보아야 하며 자연법칙이라 보기엔 무리입니다. 중요한 것은 결과의 형태입니다.

iPhone 16 Pro는 초당 40.35 토큰을 기록했지만 이를 유지하지 못했습니다. 두 번의 추론 후 성능 저하가 나타났고, 최종적으로 초당 22.56 토큰(44% 감소)으로 안정화되었으며 벤치마크 시간의 65% 동안 스로틀링 상태를 유지했습니다. 온도가 상승하면 클럭 속도를 낮추는 동적 전압·주파수 스케일링(DVFS) 메커니즘이 제 역할을 정확히 수행했습니다.

Galaxy S24 Ultra는 다른 방식으로, 더 심각하게 실패했습니다. Android 열 거버너가 6번째 반복에서 78.3°C에 도달하자 GPU 주파수 하한을 강제로 적용했고, 추론이 중단되었습니다. 저자들은 여기서 중요한 점을 강조합니다: 에이전트 배포에서는 “우아한 성능 저하”보다 “사용 불가능”이 더 파괴적이기 때문입니다.

이제 중요한 디테일을 짚어보면, 그 20번 실행 모두가 동일한 프롬프트를 사용했다는 점입니다. 이는 에이전트 하드웨어가 마주할 수 있는 가장 친절한 워크로드이며, 두 플래그십 스마트폰도 20번 연속 실행을 지속하지 못했습니다. 이는 새로운 발견이 아니라—MELTing 포인트가 2024년 MobiCom에서 발표한 바와 같이 에너지와 열 관점에서 “LLM의 지속적인 실행은 여전히 어려움”이라고 결론지었습니다. 두 해와 여러 공정 노드가 차이 나지만, 동일한 장벽이 존재합니다.

Two Curves Move Toward Each Other, and Your Product Breaks Where They Cross

에이전트의 루프는 반복 프롬프트보다 특정하고 기계적인 방식으로 더 악화됩니다.

디코딩은 메모리 대역폭에 제한됩니다: 처리량은 모델이 키‑값 캐시를 얼마나 빠르게 읽을 수 있느냐에 좌우되며, 칩이 이론적으로 수행할 수 있는 연산 수와는 무관합니다. 이 캐시는 컨텍스트가 길어질수록 커집니다. 매 루프 단계마다 도구 결과, 관찰, 부분 계획이 추가되므로, 10번째 단계는 1번째 단계보다 훨씬 큰 캐시를 대상으로 토큰을 생성합니다.

동시에 디바이스는 가열되고, 거버너는 클럭을 낮춥니다.

따라서 단계당 비용은 디바이스가 이를 감당할 수 있는 능력이 감소하는 순간에 상승합니다. 두 곡선이 교차하는 지점이 바로 제품이 실패하는 지점이며, 이는 절대 첫 번째 단계가 아닙니다. 첫 번째 단계는 여러분이 테스트한 지점일 뿐입니다.

이와 관련된 규모 문제도 존재합니다. 생성 작업은 과거 엣지 실리콘이 10년 동안 수행해 온 작업과 비용 구조가 완전히 다릅니다: 88개 모델을 측정한 결과, 텍스트 분류는 1,000회 추론당 약 0.002 kWh, 텍스트 생성은 0.047 kWh로 약 20배 더 많은 전력을 소모합니다—루프가 곱해지기 전의 수치입니다. 이 측정은 데이터센터 GPU에서 수행됐으며, 핸드셋이 아니라 GPU이므로 장치 전력 수치라기보다 작업 종류 간 비율로 이해해야 합니다. 같은 연구에 따르면 스마트폰 한 번 완전 충전은 0.022 kWh에 해당합니다.

Buy on Joules per Finished Task, Not on Tokens per Second

2026년 벤치마크에서 가장 유용한 결과는 가장 인상적이지 않은 결과였습니다.

Hailo-10H NPU는 2 W 미만에서 초당 6.9 토큰을 처리했습니다. 느리지만—진짜로 느리며—저자들도 그렇게 평가했습니다. 그러나 처리량 변동계수는 0.04%에 불과해 다른 모든 테스트 대상보다 두 자릿수 정도 더 안정적이었습니다. 같은 연구에서 노트북 GPU는 34.1 W에 초당 131.7 토큰을 기록했습니다.

이제 속도가 아니라 에너지 기준으로 두 장치를 비교해 보세요: 작은 NPU는 토큰당 270.5 mJ, GPU는 297.3 mJ를 소비했습니다. 처리량 차이가 19배나 나지만, 작은 부품이 줄당 약간 더 많은 연산을 수행했으며 변동도 거의 없었습니다.

토큰당 초당 수치를 기준으로 하드웨어를 선택하면 빠른 제품을 사게 됩니다. 하지만 에이전트가 실제로 필요로 하는 것은 예측 가능한 비용으로 제한된 루프를 완료할 수 있는 능력입니다. 사양서에 표시되어야 할 단위는 완료된 작업당 줄(J)이며, 그 옆에 변동 수치를 함께 표시해야 합니다. 피크 처리량만을 보고하는 벤치마크는 하루 중 첫 번째 추론에 대한 정보만 제공하는 셈입니다.

The Honest Objection, and What It Does Not Solve

명백한 반론은 이것이 일시적인 문제라는 것입니다: 실리콘이 개선되고, NPU가 성숙해지며, 2026년 스마트폰에 대한 모든 이야기가 옛날 얘기로 보일 겁니다. 혹은 더 실용적으로는 비용이 많이 드는 단계를 서버에 오프로드하는 방법이 있습니다.

저는 직접 하드웨어에 베팅하고 싶지만, 오프로드는 에지로 옮기려는 이유 자체를 무효화합니다. 에이전트는 한 번이 아니라 루프 단계마다 비용을 지불하며, 루프 길이는 예측할 수 없는 요소입니다. 하이브리드 설계는 변동성을 없애지 못하고 네트워크에 옮길 뿐입니다.

더 깊은 비대칭성은 공정 노드와 무관합니다. 디바이스의 예산은 설계 시점에 고정되고, 에이전트의 요구는 런타임에, 사용자가 무엇을 요청했는가에 따라 결정됩니다. 더 좋은 실리콘은 상한을 높일 뿐, 에이전트에게 그 상한이 어디인지 알려주지는 못합니다.

따라서 사양서에 턴 제한을 명시하고, 열 예산 안에서 몇 단계가 들어갈 수 있는지 결정한 뒤, 에이전트가 임의의 이상적인 답변이 아니라 그 제한 내에서 최선의 답변을 제공하도록 설계하세요. 이를 목표가 아닌 마감 기한으로 생각하십시오.

그 다음에 에이전트에게 예산을 입력값으로 제공하십시오. 남은 여유, 배터리 상태, 플랫폼이 이미 스로틀링을 시작했는지 여부 등은 현재 시간과 마찬가지로 컨텍스트에 포함됩니다. 에이전트가 10단계 중 8단계에 도달했음을 알면 요약하고 커밋할 수 있습니다. 모르면 운영 체제가 결정할 때까지 탐색을 계속합니다.

그리고 중간이 아닌 꼬리를 테스트하십시오. 물리 디바이스에서는 시뮬레이션으로 테스트하는 것이 의미합니다. 실패 사례는 깔끔한 실행이 아니라, 3단계에서 도구가 모호한 결과를 반환해 14단계까지 진행된 경우이며, 이는 시도 사이에 디바이스가 식어야 하는 상황을 손으로 일일이 열거할 수 없습니다. 저 역시 이러한 이유로 시뮬레이션을 통해 시스템을 훈련합니다: 흥미로운 동작은 장시간 실행에 있으며, 장시간 실행이 바로 하드웨어가 손으로 샘플링하지 못하게 하는 부분이기 때문입니다.

이 모든 것이 더 빠른 칩을 요구하는 것은 아닙니다. 워크로드 형태가 바뀌었음을 인정해야 합니다. 사진 한 장을 촬영하도록 배터리를 설계한 디바이스는 없습니다. 우리는 여전히 한 번의 추론에 맞춘 열 예산을 가진 디바이스를 출하하고 있습니다.