더 빠른 LLM 추론이 실제로 도움이 되는지 확인하기 위해 106회의 코딩 에이전트 세션을 실행해 보았습니다

모두가 초당 토큰 수 (tokens per second)를 두고 경쟁하고 있습니다.

하지만 자율 코딩 에이전트 (autonomous coding agents)에게 더 유용한 질문은 다음과 같다고 생각합니다:

더 빠른 추론 (inference)이 실제로 더 많은 결과물을 만들어내는 데 도움이 되는가?

저는 Xiaomi MiMo-V2.5-Pro-UltraSpeed에 대한 조기 액세스 권한을 얻었고, 기존에 표준 MiMo-V2.5-Pro와 함께 사용하던 것과 동일한 자율 코딩 워크플로우를 통해 이를 실행해 보았습니다.

이것은 합성 프롬프트 벤치마크 (synthetic prompt benchmark)가 아니었습니다. 에이전트는 실제 프로덕션 코드베이스 (production codebase)에서 작동했습니다: 파일 읽기, 변경 사항 계획, 코드 작성, 빌드 실행, 실패 디버깅, 그리고 작동하는 업데이트 커밋하기 등을 수행했습니다.

저는 다음을 비교했습니다:

• 표준 MiMo-V2.5-Pro로 62회 실행
• MiMo-V2.5-Pro-UltraSpeed로 44회 실행
• 동일한 에이전트 프레임워크 (agent framework)
• 동일한 코드베이스 (codebase)
• 유사한 프로덕션 작업 유형
• 약 30~35분으로 고정된 에이전트 윈도우 (agent windows)

실질적인 결과

지표 (Metric)	표준 Pro (Standard Pro)	UltraSpeed	차이 (Difference)
평균 실행 시간 (Average run duration)	7.7분	4.8분	37% 더 빠름
...

핵심 내용은 간단합니다:

UltraSpeed는 유사한 프로덕션 작업에서 비슷한 양의 결과물을 생성하면서도, 평균 에이전트 실행 시간을 37% 단축했습니다.

이는 중요한 사실입니다. 하지만 1,000+ tok/s가 가능한 모델이 갑자기 에이전트의 생산성을 10배로 만든다는 의미는 아닙니다.

왜 1,000 tok/s가 에이전트 내에서 1,000 tok/s가 되지 않는가

단독으로 볼 때, UltraSpeed는 매우 빠르게 생성할 수 있습니다. 하지만 생성 (generation)은 에이전트 루프 (agent loop)의 일부분일 뿐입니다.

실제 코딩 에이전트는 다음 작업에도 시간을 소비합니다:

1. 컨텍스트 (context) 및 이전 도구 출력 읽기
2. 다음 행동 계획
3. 응답 또는 코드 변경 사항 생성
4. 파일 쓰기
5. 명령, 빌드 및 테스트 실행
6. 실패 사례 읽기 및 반복 (iterating)

저의 UltraSpeed 세션에서 전형적인 실행은 약 60회의 턴 (turns)을 가졌으며, 턴당 약 397개의 출력 토큰을 생성했습니다.

1,000 tok/s 속도에서 해당 생성 단계는 약 0.4초에 불과합니다.

턴의 나머지 시간은 컨텍스트 처리 (context processing), 도구 실행 (tool execution), 계획 (planning), 그리고 환경(environment)의 응답을 기다리는 시간입니다.

그렇기 때문에 중앙값(median) 엔드 투 엔드 처리량(end-to-end throughput)은 1,000 tok/s 근처가 아닌 95 tok/s로 나타났습니다.

대화형 채팅(interactive chat)의 경우, 순수 생성 속도(raw generation speed)가 사용자 경험을 지배할 수 있습니다.

하지만 자율 코딩 에이전트(autonomous coding agents)에게 속도는 더 큰 시스템의 일부일 뿐입니다.

더 빠른 추론(inference)이 도움이 되었던 부분

그럼에도 불구하고 얻은 이점은 의미가 있었습니다.

더 빠른 첫 번째 토큰 생성 시간 (Faster time-to-first-token)

캐시된 컨텍스트(cached contexts)에서 UltraSpeed는 종종 약 35초 대신 23초 만에 응답을 시작했습니다.

단일 상호작용에서는 극적으로 들리지 않을 수 있습니다. 하지만 60회 이상의 턴(turns)을 거치면 그 효과는 복리로 쌓입니다.

코드 집약적인 긴 출력물에서의 더 나은 성능

가장 큰 이점은 에이전트가 더 큰 코드 블록을 생성할 때 나타났습니다. UltraSpeed의 P90 유효 처리량(effective throughput)은 147 tok/s로, 표준 Pro 모델의 63 tok/s와 대조를 이뤘습니다.

이는 개별 구현 단계가 실질적으로 더 빠르게 느껴지게 만듭니다.

정해진 시간 내에 더 유용한 작업 수행

이것이 제가 가장 중요하게 생각한 결과였습니다.

정해진 30분의 시간 제한 내에서, 더 빠른 설정은 보통 34회 대신 약 56회의 실행(runs)을 완료했습니다.

이는 헤드라인에 나오는 초당 토큰 수(tokens-per-second)보다 훨씬 더 유용한 지표입니다.

트레이드오프(trade-off): 속도에는 비용이 따른다

UltraSpeed는 공짜 성능이 아니었습니다.

실행당 평균 비용은 더 높았습니다:

• 표준 Pro (Standard Pro): 실행당 $2.92
• UltraSpeed: 실행당 $4.19

따라서 결정은 무엇이 당신을 제약하는지에 달려 있습니다.

다음과 같은 경우에는 더 빠른 모델을 사용하세요:

• 정해진 시간 동안 에이전트 윈도우(agent windows)를 실행할 때
• CI/CD 회전율(turnaround)이 중요할 때
• 다단계 자율 워크플로우(multi-step autonomous workflow)를 운영할 때
• 개발자 시간이 모델 비용보다 더 가치 있을 때

다음과 같은 경우에는 더 저렴한 모델을 사용하세요:

• 시간 제약이 없을 때
• 주로 실행당 비용을 최소화하는 것이 중요할 때
• 작업당 몇 분의 추가 시간이 중요하지 않을 때

에이전트 빌더를 위한 나의 교훈

순수 tok/s가 쓸모없는 것은 아니지만, 이는 생산성 지표가 되기 전에 마케팅 지표로 쓰이는 경우가 많습니다.

에이전트 기반 코딩(agentic coding)을 위해서는 다음을 추적해야 합니다:

• 시간당 완료된 실행 횟수 (completed runs per hour)
• 세션당 유용한 커밋 횟수 (useful commits per session)
• 성공적인 완료까지의 실제 경과 시간 (wall-clock time to successful completion)
• 완료된 실행당 비용 (cost per completed run)
• 도구 실행 병목 현상 (tool execution bottlenecks)
• 캐시 히트율 및 프리필 동작 (cache hit rate and prefill behaviour)

질문은 다음과 같습니다:

모델이 얼마나 빨리 토큰을 생성할 수 있는가?

이것이 아니라, 다음과 같습니다:

전체 시스템이 시간당 얼마나 많은 유용한 작업을 완료할 수 있는가?

이 워크플로우(workflow)에서 더 빠른 추론(inference)은 큰 도움이 되었습니다. 다만, 단순한 속도 수치가 암시하는 것처럼 단순하게 10배 더 빠른 방식은 아니었습니다.

방법론, 한계점, 그리고 UltraSpeed의 기술적 세부 사항을 포함한 전체 보고서를 여기에 게시했습니다:

MiMo UltraSpeed for Agentic Coding: 106 Sessions Tested

공개 사항: Xiaomi는 테스트를 위해 MiMo UltraSpeed에 대한 조기 액세스 권한을 제공했습니다. 워크플로우, 측정, 분석 및 결론은 본인의 의견입니다.