토큰/초만 보면 놓친다 — MLPerf Edge Agentic이 만든 온디바이스 에이전트 측정 계약

새 소식은 6.4배가 아니라 측정 대상의 변화다

2026년 9월 16일 MLCommons는 MLPerf Inference v6.1 결과를 발표하며 Edge Agentic Inference를 새 시험으로 정식 도입했다. 발표문은 엣지 에이전트를 고정된 메모리·연산·전력·컨텍스트 안에서 한 사용자의 증가하는 대화를 처리하는 시스템으로 설명한다. 기존의 단발 추론과 달리, 앞선 도구 호출과 결과가 다음 요청의 입력으로 계속 누적된다(MLCommons 결과 발표).

같은 날 NVIDIA는 단일 Jetson AGX Thor에서 TensorRT Edge-LLM으로 이 시험을 수행한 결과를 공개했다. 52.33 output tok/s와 24분 36초라는 숫자가 눈에 띄지만, 더 중요한 변화는 무엇을 한 번에 측정하기 시작했는가다. 성능 재생은 장기 멀티턴 궤적을 쓰고, 별도의 정확도 단계는 잘못된 함수 호출과 불필요한 호출을 검사한다(NVIDIA 기술 글).

이 주제는 기존의 온디바이스 VLM 구조나 일반 에이전트 평가와 질문이 다르다. 여기서 묻는 것은 "어떤 모델이 더 똑똑한가"가 아니라 같은 엣지 장치에서 긴 도구 호출 세션을 정확성을 잃지 않고 얼마나 빨리 끝내는가다. 모델, 양자화, KV 캐시, 추측 디코딩, 서버 구현을 하나의 시스템으로 본다.

이 글의 기준일은 2026-09-19다. 공개 결과와 공식 하네스를 읽어 실무에 번역하되, 실제 Jetson 재실행은 하지 않았다. 따라서 재현 절차는 "공개돼 있다"고 말할 수 있지만, 여기서 그 수치가 독립 재현됐다고 말하지는 않는다.

숫자보다 먼저 고정된 조건을 본다

MLCommons의 방법론은 엣지 체제를 데이터센터와 반대로 정의한다. 가속기 하나, 요청 하나, 고정된 메모리와 컨텍스트, 단일 사용자의 턴 지연이 중심이다. 기준 설정은 context size 32,768, parallel slot 1, temperature 0, seed 42, reasoning off다(MLCommons 방법론).

이 조건은 세 가지를 비교 가능하게 만든다.

중요한 해석은 이 시험의 우승 구성이 곧 우리 제품의 최적 구성은 아니라는 것이다. 예를 들어 여러 로봇이 한 장치를 공유하거나, 비전 인코더가 매 턴 돌거나, 32K를 넘겨 요약하는 제품은 다른 병목을 가진다. 반대로 한 대의 로봇이나 차량에서 한 사용자·한 작업 세션을 처리한다면 이 계약은 데이터센터 QPS보다 훨씬 가까운 출발점이다.

MLCommons는 공개 스위트를 아키텍처 중립적이고 재현 가능한 비교를 위한 것으로 설명한다(v6.1 발표). 그러나 아키텍처 중립은 워크로드 중립을 뜻하지 않는다. 비교표를 만들기 전에 내 트래픽이 이 계약과 얼마나 닮았는가를 먼저 적어야 한다.

매 턴 새 프롬프트가 아니라 하나의 누적 궤적이다

성능 데이터는 기록된 소프트웨어 엔지니어링 에이전트 대화 20개, 총 1,007턴이다. 한 턴에서 모델이 도구 호출을 만들면 기록된 도구 결과가 다음 턴에 붙고, 입력 길이는 최대 약 23.5K 토큰까지 자란다. 모든 궤적은 32K 제공 컨텍스트 안에 들어오도록 구성돼 이 기준 실행에서는 드롭된 턴이 없어야 한다(MLCommons 방법론).

이 구조가 일반 채팅 벤치마크와 다른 이유는 계산의 중복이다. 10번째 요청은 9번째까지의 대화 대부분을 다시 포함한다. 런타임이 공유 접두부의 KV 상태를 재사용하지 못하면 같은 토큰을 턴마다 다시 prefill한다. 따라서 이 시험은 모델의 순수 디코딩 속도뿐 아니라 세션 상태를 얼마나 효율적으로 이어 가는지를 압박한다.

성능 패스에도 정합성 검사가 있다. 기록된 정답 궤적의 도구 호출과 모델이 낸 호출을 정규화해 multiset IoU를 계산한다. 이는 지연을 낮추려고 요청을 건너뛰거나 엉뚱한 출력을 내는 구현을 막는 inline check다. 다만 이 값은 실제 저장소에서 도구를 실행해 과업이 해결됐는지를 재는 end-to-end 성공률과 같지 않다.

또한 워크로드는 코딩 에이전트 궤적이다. 장기 의존성과 도구 호출이라는 시스템 특성은 로봇·차량의 고수준 에이전트에도 관련 있지만, 카메라 프레임, 센서 융합, 모터 명령의 실시간성은 포함하지 않는다. 이 구분을 지키면 범용 시스템 벤치마크로는 유용하고, 로봇 성능의 직접 증거로 오독하는 일은 피할 수 있다(공개 하네스).

빠른데 틀린 시스템을 막는 별도 시험

정확도 게이트는 Berkeley Function Calling Leaderboard v4의 단일턴 항목을 사용한다. non_live와 live는 함수명과 인수를 AST 수준에서 정답과 비교하고, hallucination은 쓸 수 있는 도구가 없을 때 호출을 참는지 본다. 표본은 세 범주에서 약 995개가 되도록 뽑는다(MLCommons 방법론).

기준 Qwen3.6-27B-Q4_K_M 설정의 공개 점수와 하한은 다음과 같다.

두 하한을 모두 넘어야 한다. 상한은 없어서 기준보다 정확한 제출은 실패하지 않는다. 전체 표본이 많은 범주 하나로 평균을 끌어올리는 일을 normalized가 막고, 실제 표본 구성의 결과를 overall이 보존한다. 공개 README는 같은 설정을 서버 재시작 후 두 번 돌려 동일한 점수를 얻었다고 기록한다(MLCommons 하네스 README).

여기에는 중요한 경계가 있다. 정식 게이트는 단일턴이다. 선택적 multi-turn 200건은 기준 실행에서 140/200, 70.00%였지만 게이트에 포함되지 않는다. MLCommons는 작은 멀티턴 표본의 신뢰구간이 넓고 장치별 양자화 차이로 항목 판정이 뒤집힐 수 있어 단일턴 대표본을 선택했다고 설명한다.

따라서 이 시험이 "장기 에이전트 정확도를 완전히 보장한다"고 말하면 과장이다. 정확도 게이트는 도구 호출의 기본 능력을 안정적으로 제한하고, 장기 궤적에서는 inline IoU로 최소 정합성을 확인한다. 실제 장기 과업 성공률은 제품 팀이 별도 게이트로 추가해야 한다.

평균 처리량 하나로는 사용자가 기다린 시간을 알 수 없다

MLCommons는 single-stream 결과에 TTFT(time to first token), TPOT(time per output token), 턴별 end-to-end latency, 입력·출력 길이(ISL/OSL)의 p50·p90·p99·최댓값을 두도록 설계했다(MLCommons 방법론). 각 지표는 다른 병목을 가리킨다.

• TTFT: 요청을 받은 뒤 첫 토큰까지. 긴 접두부 prefill, 캐시 miss, 스케줄링 비용이 크게 반영된다.
• TPOT: 생성이 시작된 뒤 토큰 사이의 시간. 디코딩 커널과 speculative/MTP 효과가 드러난다.
• 턴 지연: 첫 토큰만 빠르고 긴 JSON 인수를 천천히 내는 문제를 잡는다.
• 전체 완료 시간: 1,007턴 누적 비용을 보여준다. 세션 캐시와 상태 관리의 이득이 합쳐진다.
• ISL/OSL 분포: 평균이 숨기는 긴 꼬리를 찾는다.

실무 대시보드에서는 정확도와 지연을 분리하지 않는 편이 낫다. 예를 들어 TTFT를 줄였지만 malformed JSON이나 잘못된 도구 선택이 늘면 에이전트가 재시도하면서 전체 과업 시간은 오히려 길어질 수 있다. 이 벤치마크가 성능 패스의 inline IoU와 별도 BFCL 게이트를 두는 이유도 같은 방향이다.

NVIDIA 제출은 output throughput 52.33 tok/s와 함께 median TTFT 247.12 ms, median TPOT 14.68 ms, BFCL overall 87.94%를 보고했다(NVIDIA 결과). 이 네 숫자를 묶어야 "빠른데 정확도 하한을 넘었는가"를 말할 수 있다. 다만 공개 블로그의 요약값만으로 p99와 열 포화 이후 지연은 판단할 수 없다.

공개된 결과표

NVIDIA가 공개한 제출 조건은 단일 Jetson AGX Thor Developer Kit, 128 GB unified memory, MAXN, SingleStream, Qwen3.6-27B다. 결과는 다음과 같다(NVIDIA 기술 글).

같은 보드에서 공개된 llama.cpp 기준은 Qwen3.6-27B Q4_K_M을 사용해 2시간 37분이 걸렸다. 완료 시간 비율로 TensorRT Edge-LLM 경로가 6.4배 짧다는 것이 제목의 근거다.

공정한 해석의 경계

비교에서 모델 이름과 장치는 같지만 소프트웨어·수치 표현은 같지 않다. 기준은 llama.cpp와 Q4_K_M이고, 제출은 TensorRT Edge-LLM과 NVFP4 weight/activation, FP8 KV cache, tree MTP, 멀티턴 캐시 재사용을 묶었다. 따라서 6.4배를 다음처럼 쓰면 안 된다.

• "Jetson Thor가 다른 하드웨어보다 6.4배 빠르다" — 하드웨어 간 비교가 아니다.
• "NVFP4 하나로 6.4배 빨라진다" — 개별 최적화 분해 실험이 아니다.
• "우리 로봇 에이전트도 6.4배 빨라진다" — 워크로드가 다르다.

정확한 문장은 이렇다. 공개된 MLPerf Edge Agentic 구성에서, 동일 Jetson AGX Thor와 Qwen3.6-27B 계열을 쓴 TensorRT Edge-LLM 제출이 공개 llama.cpp 기준보다 전체 워크로드를 6.4배 짧은 시간에 마쳤다.

MLCommons의 공식 발표는 이 시험을 처음 도입했다고 확인하지만, 전체 v6.1 결과의 다양한 제출을 한 벤더 블로그의 표 하나로 대체하지는 않는다(MLCommons 발표). 구매나 아키텍처 결정을 내리기 전에는 원본 제출 결과와 자신의 전력 모드·열 조건·모델 설정을 다시 맞춰야 한다.

1. 표현 크기를 줄인다

Qwen3.6-27B 제출은 weight와 activation에 NVFP4, KV cache에 FP8을 쓴다. NVIDIA는 저배치 엣지 디코딩이 DRAM bandwidth에 크게 묶이므로 표현을 줄이면 메모리 이동량과 모델 메모리 점유를 함께 낮출 수 있다고 설명한다. 이 설명과 성능 수치는 제출 주체의 측정이라는 점을 유지해야 한다(NVIDIA 기술 글).

2. 매 턴 같은 접두부를 다시 계산하지 않는다

에이전트 요청은 직전 대화 대부분을 공유한다. TensorRT Edge-LLM은 재사용 가능한 prompt prefix의 KV page를 복원하고, Qwen3.6의 hybrid architecture에 필요한 recurrent state와 partial KV-page state도 이어 간다. 공개 결과에서는 총 13.6M prompt token 중 약 0.5M만 새로 prefill해 약 96%가 hot cache에서 제공됐다고 보고한다.

이 수치는 캐시가 "부가 최적화"가 아니라 멀티턴 에이전트 런타임의 핵심 상태라는 점을 보여준다. 그러나 제품에서 시스템 프롬프트, 도구 목록, 요약 방식이 자주 바뀌면 접두부 일치율이 낮아질 수 있다. 벤치마크의 96%를 운영 캐시 적중률로 가정하면 안 된다.

3. 한 토큰씩이 아니라 후보 트리를 검증한다

제출 설정은 8 draft step, 깊이마다 top-2, 16-node verification tree를 사용한다. 도구명과 JSON 구문처럼 예측 가능한 패턴에서 여러 후보를 한 번의 target-model forward로 검증한다. NVIDIA는 이 워크로드에서 3-step linear MTP보다 약 40% 추가 디코딩 성능 이득을 보고했다. 이것도 해당 비교 설정과 함수 호출 워크로드에 한정된 수치다.

세 최적화는 서로 다른 단계를 겨냥한다. 양자화는 메모리 대역폭과 용량, 캐시 재사용은 prefill, tree MTP는 decode를 줄인다. 병목을 단계별로 나누면 "tok/s가 낮다"는 한 문장보다 어디를 고쳐야 할지 명확해진다. 공개 구현 브랜치는 엔진 빌드와 서버 설정을 제공한다(TensorRT Edge-LLM MLPerf 브랜치).

공개된 시작점

MLCommons endpoints 저장소는 OpenAI-compatible endpoint에 요청을 보내는 CLI와 Edge Agentic 예제를 공개한다. README의 기준 환경은 Python 3.12+, 약 24 GB 메모리, Qwen3.6-27B Q4_K_M, 32K context, 고정 llama.cpp 커밋이다. 정확도만 돌리는 --accuracy-only와 성능·정확도를 연속 실행하는 설정이 분리돼 있다(공개 하네스 README).

NVIDIA도 제출에 사용한 release/0.9.1-mlpinf 브랜치에 모델 export, TensorRT engine build, OpenAI 호환 서버와 MLPerf 설정을 공개했다(NVIDIA 브랜치). 공개돼 있다는 사실은 중요하지만, 복제 가능한 실험은 다음 항목을 한 묶음으로 고정해야 한다.

model id + exact checkpoint hash
quantization format + calibration artifact
runtime repository + commit
engine build flags + compiler/CUDA/TensorRT versions
device + memory + firmware/JetPack + power mode
context size + temperature + seed + reasoning mode
concurrency/workers/connections
cache state: cold start / warm trajectory
dataset and harness commit
raw result artifacts + stderr + failure count

재현 순서는 작게 시작하는 편이 안전하다.

1. --accuracy-only로 모델 이름, tokenizer, tool-call schema와 BFCL scorer가 맞는지 확인한다.
2. 소수 샘플 smoke run으로 endpoint와 결과 파일 생성을 검증한다.
3. 전체 정확도 게이트를 수행한다. 공개 README는 단일 엣지 장치에서 수 시간이 걸릴 수 있다고 적는다.
4. 성능+정확도 전체 실행을 하고 raw artifact를 보존한다.
5. 서버 재시작 후 최소 한 번 반복해 분산을 확인한다.

이 글은 위 실행을 실제 수행하지 않았다. 따라서 수치를 옮길 때는 항상 "MLCommons/NVIDIA가 공개한 결과"라고 주체를 붙인다. 독립 재현을 주장하려면 명령 로그와 결과 파일이 추가로 필요하다.

측정하지 않은 축을 0점이 아니라 빈칸으로 둔다

좋은 벤치마크의 범위는 명시적이다. Edge Agentic이 직접 재는 것은 OpenAI 호환 모델 엔드포인트의 멀티턴 성능 재생과 BFCL 단일턴 정확도다. 성능 데이터는 코딩 궤적이고 정확도 데이터는 함수 호출 문제다(MLCommons 방법론).

따라서 다음 항목은 공개 결과만으로 결론을 낼 수 없다.

NVIDIA 결과는 MAXN 전력 모드를 명시하지만 공개 표에 평균 전력이나 에너지/턴을 싣지 않았다(NVIDIA 결과). 그러므로 "엣지에서 빠르다"를 "배터리 효율이 좋다"로 바꾸어 쓰면 안 된다.

또한 BFCL 게이트의 reasoning off가 해당 함수 호출 데이터에서는 더 높은 정확도와 짧은 시간을 보였다는 공식 설명이 있지만, 이것이 모든 계획 문제에서 reasoning을 꺼야 한다는 뜻은 아니다. 실제 제품이 복잡한 계획에 reasoning을 켠다면 그 설정으로 자체 정확도와 지연을 다시 측정해야 한다.

빈칸을 솔직히 남기는 것이 운영 신뢰성의 출발점이다. 측정하지 않은 것을 실패로 간주할 필요는 없지만, 통과로 간주해서도 안 된다.

두 겹으로 만든다

권장 구조는 표준 코어와 제품 외곽의 두 겹이다. 표준 코어는 MLCommons 하네스와 설정을 가깝게 유지해 런타임·양자화·엔진 변경의 회귀를 비교한다. 제품 외곽은 실제 에이전트의 도구와 오류를 재생한다. MLCommons가 정확도와 성능을 분리하고 OpenAI 호환 endpoint를 대상으로 삼은 구조는 이 확장에 좋은 뼈대다(공개 하네스).

1단계 — 기능 게이트

• 허용된 도구를 골랐는가
• 인수 스키마와 단위가 맞는가
• 도구가 없거나 위험할 때 기권하는가
• timeout·오류 결과 뒤에 무한 재시도하지 않는가
• 세션 재개 후 같은 작업을 중복 실행하지 않는가

2단계 — 성능 게이트

• cold/warm TTFT, TPOT, 턴 지연 p50/p95/p99
• 전체 대표 과업 완료 시간
• 입력 길이 구간별 cache hit와 prefill token
• 평균·피크 전력, 에너지/성공 과업
• 30분 이상 반복 후 온도와 throttling 여부

3단계 — 실패 주입

• 도구 timeout, 잘못된 JSON, 빈 응답
• 로컬 서비스 재시작, 네트워크 단절
• 캐시 무효화, 컨텍스트 한계 접근
• 센서 프레임 지연·누락
• 안전 컨트롤러가 명령을 거부했을 때의 복구

판정 순서는 정확도 우선이 낫다. MLPerf도 기준 정확도의 97% 하한을 통과한 구성끼리 성능을 비교한다(방법론). 제품에서도 기능·안전 하한을 넘기지 못한 빠른 구성을 Pareto 후보에서 제외하면, 처리량을 위해 정확도를 조용히 깎는 일을 막을 수 있다.

숫자는 버전과 함께 저장한다. model, runtime, engine, device, power_mode, dataset, gate, raw_artifact가 한 행에 있어야 다음 릴리스에서 회귀 원인을 찾을 수 있다.

이 수치가 증명하는 층

TensorRT Edge-LLM 저장소는 로보틱스의 자연어 상호작용·작업 계획·VQA·협업을 사용 사례로 적고, NVIDIA 결과는 한 엣지 보드에서 27B 모델의 장기 도구 호출 세션이 실행 가능함을 보여준다(공식 저장소, 제출 결과).

그러나 공개 median TTFT가 247.12 ms이고, 측정 대상은 코딩 에이전트의 텍스트·도구 호출이다. 여기서 "로봇 제어 루프를 이 모델이 직접 닫아도 된다"는 결론은 나오지 않는다. 이는 공개 조건에서 할 수 있는 공학적 추론이지 별도 실물 시험 결과가 아니다.

안전한 번역은 계층을 나누는 것이다.

사용자 목표 / 임무
        ↓
엣지 에이전트: 계획, 기술 선택, 도구 인수 생성
        ↓  (형식 검증·허용목록·timeout)
결정론적 autonomy stack: localization, planner, controller
        ↓  (속도·가속도·충돌·deadman 제한)
안전 계층 / 하드웨어 인터록
        ↓
로봇

에이전트가 navigate(goal)이나 inspect(zone) 같은 고수준 도구를 고를 수는 있다. 그러나 좌표 변환, 충돌 검사, 제어 주기, 비상 정지는 기존 결정론적 스택이 소유한다. 에이전트 출력이 유효한 JSON이라는 사실은 목표가 안전하거나 실행 가능한지 보장하지 않기 때문이다.

로봇용 확장 벤치마크에는 최소 세 축을 더한다. 첫째, 센서 입력부터 첫 유효 고수준 결정까지의 지연. 둘째, 도구 실행 후 물리적 후조건 달성률. 셋째, 안전 계층의 거부 뒤 에이전트가 중단·재계획하는 비율이다. 공식 Edge Agentic은 이 중 추론 endpoint의 기반 성능을 재는 코어로 쓰면 된다.

결론은 보수적이다. 이 발표는 온보드 고수준 에이전트의 시스템 최적화가 측정 가능한 단계에 들어왔다는 증거이지, 학습 모델이 실시간 제어와 안전을 대체했다는 증거가 아니다.

비교표의 최소 열

온디바이스 에이전트 후보를 고를 때 다음 열이 빠지면 숫자를 비교하지 않는다.

3단계 의사결정

1. 재현 가능성: MLCommons 공개 하네스로 정확도 게이트와 대표 성능 실행을 다시 만들 수 있는가. 모델·런타임·설정이 pin돼 있는가(공개 README).
2. 제품 적합성: 실제 도구와 센서를 넣은 도메인 궤적에서 정확도·지연·에너지 하한을 넘는가. 캐시 miss와 cold start에서도 허용 가능한가.
3. 운영 안전성: timeout, 프로세스 재시작, 네트워크 단절, 안전 계층 거부 뒤에 유한 시간 안에 중단하거나 복구하는가.

NVIDIA의 제출은 최적화 가능성의 강한 사례다. 단일 Jetson AGX Thor에서 27B 모델로 1,007턴을 24분 36초에 처리했고 공개 기준보다 완료 시간을 크게 줄였다(NVIDIA 결과). 동시에 그 결과는 MAXN, 특정 모델, 특정 양자화와 런타임의 묶음이다.

최종 판단은 한 문장으로 정리할 수 있다. MLPerf Edge Agentic은 "엣지 에이전트를 무엇으로 재야 하는가"에 대한 좋은 공통 바닥을 만들었지만, "우리 제품이 배포 가능한가"의 천장은 여전히 제품 팀이 만든 도메인·전력·열·복구·안전 시험이 결정한다.