Tom's Hardware가 에이전트형 AI 워크로드 환경에서의 CPU 성능을 측정하는 벤치마크의 첫 번째 시도를 공개했다.

에이전틱 AI는 지난 6개월 동안 CPU 업계에 큰 파문을 일으켰지만, 최신 하드웨어의 위치를 평가할 수 있는 견고하고 재현 가능한 벤치마크가 아직 부족한 성능 영역입니다. 우리는 에이전틱 루프의 쟁점이 되는 측면을 처음부터 끝까지 평가하기 위해 내부 테스트 세트를 개발해 왔으며, 이 과정에서 가속기와 분리하여 CPU와 메모리 성능이 에이전틱 루프에 어떻게 기여하는지 파악하고자 했습니다.

이 작업은 아직 진행 중이지만, Tom's Hardware Premium 독자들에게 그 이면을 보여드리고자 합니다. 이 문제를 어떻게 다루고 있는지, 테스트 방법론은 무엇인지, 그리고 그 과정에서 에이전틱 루프에 대해 무엇을 배웠는지 소개합니다. 테스트를 프로토타입으로 만들고 핵심 설계는 정했지만, 이 테스트가 산출하는 수치가 면밀한 검증을 견디려면 아직 할 일이 남아 있습니다.

이 컴퓨팅 분야는 최첨단이며 빠르게 발전하고 있으므로, 우리에게 사각지대가 있는 것은 분명합니다. 그것은 괜찮습니다. 이 테스트는 세션 수가 늘어날 때 에이전틱 성능이 CPU에서 어떻게 확장되는지를 살펴보도록 설계되었으며, 각 칩이 상호작용성을 유지하면서 지원할 수 있는 최대 에이전트 세션 수, 즉 칩별 이상적인 처리량을 제공합니다.

이 글의 끝부분에는 이 접근법의 한계에 관한 섹션과, 다중 턴 에이전틱 흐름과 같은 과제를 해결하기 위해 시험 중인 아이디어들을 담았습니다. 이 테스트는 기존의 로컬 AI 테스트를 대체하기 위한 것이 아니라 보완하기 위한 것입니다. 이 영역이 계속 진화하고 하드웨어 특성이 더 명확해지면, 이 테스트가 앞으로 어디로 나아갈지에 대해 더 현명한 결정을 내릴 수 있을 것입니다.

**에이전틱 AI 루프 정의하기**

"AI 에이전트"는 LLM을 장착하고 주어지는 어떤 작업이든 스스로 처리할 수 있는 작은 작업자를 떠올리게 합니다. 이는 괜찮은 설명이지만, 에이전틱 AI의 성능을 벤치마크하려면 더 기술적인 정의가 필요합니다.

여기서 중요한 부분은 두 가지입니다. 첫 번째는 함수입니다. 에이전틱 AI에서는 LLM에 도구에 대한 접근 권한을 줍니다. LangGraph와 같은 인기 있는 에이전틱 프레임워크의 경우, 이 도구는 Python 함수입니다. 도구는 파일을 읽거나 쓰고, 데이터베이스를 조회하고, 코드에 대해 테스트를 실행하고, 함수로 정의할 수 있는 거의 모든 작업을 수행할 수 있습니다. 다음은 기본적인 예시입니다.

```python

@tool

def run_command(command: str) -> str:

"""Run a build or test command in the repository root.

Allowed: make [targets], python -m pytest [args]."""

return traced("run_command", {"command": command}, lambda: ws.run_command(command))

```

이것은 Python에서 LangGraph로 도구 호출을 작성하는 방법이며, 우리의 LangGraph 페르소나를 통해 LLM에 접근 권한을 준 도구의 예시입니다. `@tool`로 함수를 LLM이 호출할 수 있는 도구로 지정한 다음, `def run_command`로 일반적인 Python처럼 정의하며, 명령을 인수로 전달합니다. 끝에 있는 `-> str`은 인수가 문자열이며 함수가 문자열을 반환해야 함을 나타냅니다.

삼중 따옴표로 묶인 텍스트는 LLM이 읽을 수 있는 도구의 설명입니다. 삼중 따옴표는 Python에서 텍스트를 여러 줄에 걸쳐 쓸 수 있게 해줄 뿐입니다. 여기서는 LLM에게 `make` 또는 `pytest`를 사용하여 빌드 또는 테스트 명령을 실행할 수 있다고 알려줍니다. 함수는 익명 `lambda`로 감싸져 전체 추적 함수에 전달됩니다. 이 세부 사항은 지금은 중요하지 않으며, 목표는 도구 호출이 어떤 모습인지 보여주는 것입니다.

이것은 우리 코딩 에이전트가 사용할 수 있는 여러 도구 중 하나일 뿐입니다. 또한 파일을 읽고 쓰고, 파일을 편집하고, 정규 표현식으로 코드를 검색할 수 있으며, 모두 Python 함수로 같은 방식으로 정의됩니다. 에이전틱 AI는 종종 "루프"로 묘사되는데, 작업 하나가 도구를 여러 번 호출하거나 서로 다른 도구를 호출해야 하는 경우가 많기 때문입니다.

예를 들어 Python 프로젝트를 작업하고 있다면, LLM에게 "이 Python 스크립트를 디버그해 줘"라고 요청할 수 있습니다. LLM은 "파일 목록" 도구를 호출하여 우리가 말하는 스크립트가 무엇인지 찾을 수 있습니다. 그런 다음 "파일 읽기" 도구를 호출해 내용을 이해하거나, "코드 검색"을 호출해 문제 해결을 시작할 지점을 찾습니다. 그다음 "파일 편집"과 "명령 실행"을 실행할 수 있으며, 파일이 여전히 고쳐지지 않았다면 이 도구들을 여러 번 되돌아가며 반복할 수 있습니다.

이것이 에이전틱 루프입니다. 우리가 LLM에 요청하면, LLM은 요청을 평가하고 답을 만드는 데 필요한 도구 호출을 시작합니다. 그런 다음 해당 도구 호출로부터 정보를 받아 다시 평가하고, 더 많은 도구를 호출할 수 있습니다.

**동시성으로 시작하기**

일련의 작업을 수행할 때, 세션 시간의 대부분은 GPU에서 소비되며, 단일 에이전트가 순차적으로 작동합니다. *(이미지 출처: Tom's Hardware)*

이 글의 뒷부분에서 구체적인 테스트와 그 동작을 자세히 살펴보겠지만, 먼저 벤치마크가 왜 이런 방식으로 설계되었는지 설명하면 배경을 이해하는 데 도움이 됩니다. 우리는 128GB의 통합 메모리, Blackwell GPU, 그리고 상대적으로 약한 Arm 기반 Grace CPU를 갖춘 Nvidia DGX Spark(GB10)에서 이 테스트를 개발했습니다. 위의 차트는 gemma4-26b-a4b를 사용해 GB10에서 이러한 에이전트 루프를 실행하는 데 소요된 시간의 비중을 보여줍니다. 도구를 호출할 수 있다면 모델 자체는 중요하지 않으며, 새로운 모델이 출시될 때마다 다른 모델로 테스트를 다시 기록할 수 있습니다.

핵심은 특정 모델이나 에이전트가 수행하는 작업이 아니라 소요 시간의 비중입니다. 물론 그 작업은 유용한 맥락을 제공합니다. 각 결과는 에이전트가 모델을 상대로 실행하는 순차적 작업 목록이며, 거의 모든 시간은 GPU에서 소비됩니다. 코딩 에이전트가 수행하는 작업처럼 비교적 까다로운 CPU 작업도 전체 계산 시간의 아주 작은 부분만 차지합니다. 크고 강력한 GPU가 충분히 큰 모델을 실행하고 있다면, 한두 개 또는 소수의 에이전트를 실행하는 것은 CPU에 문제가 되지 않습니다.

단일 쿼리에도 여러 도구 호출이 포함되며, 에이전트가 도구를 호출하고 응답을 전달한 뒤 다시 도구를 호출하면서 루프가 만들어집니다. *(이미지 출처: Tom's Hardware)*

특정 작업 집합을 더 자세히 들여다보면, 그 시간 동안 CPU가 실행해야 할 작업은 많지만 너무 빨리 끝나서 전체 소요 시간에서는 거의 드러나지 않습니다.

도구 호출 패턴은 작업에 따라 다릅니다. *(이미지 출처: Tom's Hardware)*

이 작업들은 고르게 분포되어 있지 않습니다. 에이전트가 도구를 호출해야 하는 시점에 따라 작업 부하의 형태가 매우 달라질 수 있습니다. 예를 들어 위의 차트는 PDF 파일 묶음을 스캔하고 정보를 추출하는 임무를 맡은 문서 에이전트를 보여줍니다. 에이전트 시간의 대부분은 작업의 맨 처음에 소비되며, 그 이후에는 거의 순수한 GPU 추론만 이루어집니다.

당연히 더 강력한 GPU는 추론 단계를 더 빨리 처리하겠지만, 적어도 이러한 일반적인 도구들로는 단일 에이전틱 루프의 CPU 부분이 병목이 되려면 CPU와 GPU 사이에 심각한 불균형을 만들어야 합니다. 그러나 에이전트는 순차적인 작업 목록만 처리하는 것이 아닙니다. 하위 에이전트를 생성하고, 여러 세션이 샌드박스 환경에서 같은 시스템에 동시에 실행되면 제한된 자원을 두고 경합이 실제 문제가 됩니다.

우리는 CPU와 GPU 사이에 심각한 불균형을 만드는 테스트 플랫폼을 설계하는 대신 동시성에 주목했습니다. 아이디어는 칩 전체에 걸쳐 동시 세션을 늘려가며, 각 세션이 자체 프로세스에서 작업 목록을 반복 실행하도록 하는 것입니다. 스윕 규모가 커지면 CPU 전반에서 경합이 나타나기 시작하고, 도구 호출, 코드 실행 및 컴파일, 웹 브라우징, 그리고 우리 에이전트가 수행하는 다양한 기타 작업들의 미세한 차이가 누적됩니다.

**벤치마크 작동 방식**

동시성을 핵심 목표로 삼으면, 벤치마크 설계와 내부 작동 방식을 세분화해 볼 수 있습니다. 전체 설계는 단순합니다. LangGraph로 만든 맞춤형 에이전트가 llama.cpp 서버에서 gemma4-26b-a4b를 상대로 순차적으로 실행할 30개의 작업 목록을 갖고 있습니다. 다만 에이전트는 서버에 직접 연결하지 않고, 추적 기록을 남기는 프록시 서버를 거칩니다.

실시간 기록 중에는 에이전트가 프록시 서버와 통신하고, 프록시 서버는 llama.cpp 서버로 실시간 호출을 전달합니다. 프록시 서버는 LLM으로 보낸 모든 요청과 응답을 하나의 상위 JSON 파일에 기록합니다. 도구 호출은 서버 체인을 우회하여 각각 별도의 JSON 파일에 기록됩니다. 마지막으로 각 작업마다 올바른 응답이 생성되어 해시 처리된 뒤 자체 JSON 파일로 저장됩니다.

*(이미지 출처: Tom's Hardware)*

모든 것을 기록하면 실시간 모델을 완전히 배제할 수 있습니다. 에이전트는 여전히 정상적으로 실행되지만, 실시간 LLM에 대해 실행하는 대신 기록된 추적을 재생하는 프록시를 상대로 실행됩니다. 요청과 도구 호출은 여전히 실시간으로 일어나지만, 에이전트는 실시간 추론 기록을 바탕으로 한 추적에서 응답을 즉시 전달받습니다.

에이전트에서 요청이 도착하면, 응답을 마스터 JSON에서 찾기 전에 세션 레이블과 해시로 대조하여 정확한지 확인합니다. 불일치가 있으면 실행은 중단되고 무효로 표시됩니다. 모든 것이 맞으면 응답이 돌려 보내지고, 에이전트 세션은 필요한 도구를 호출합니다. 각 도구 호출은 기록 단계에서 생성된 JSON과 비교되며, 기록된 결과가 다시 전달됩니다. 이 부분이 매우 중요합니다.

테스트는 실시간 도구 호출을 기록된 결과와 비교하지만, 호출이 올바르더라도 테스트가 빗나가지 않도록 항상 기록된 결과를 돌려줍니다. 실제 도구 불일치는 기록됩니다. 테스트는 계속 진행되지만, 도구 불일치가 발생한 각 단계는 무효로 표시됩니다.

이 구조 덕분에 벤치마크를 재설계하고 확장하기가 간단해집니다. LangGraph를 사용해 Python으로 새로운 페르소나를 작성하거나, CrewAI와 같은 다른 프레임워크로 확장할 수 있습니다. 앞으로 더 발전된 기능을 가진 모델을 포함해 다른 모델에 대해 추적을 다시 기록할 수도 있습니다. OpenAI 호환 엔드포인트를 통해 통신하는 한, 테스트의 구성 요소를 자유롭게 조합하여 더 폭넓은 작업 부하를 표현할 수 있습니다.

테스트는 단일 워커 프로세스에서 시작하여 CPU의 최대 스레드 수까지 확장되며, 각 단계마다 세 번 반복합니다. 각 워커 프로세스는 30개 작업 목록에서 작업을 수행하며, 새 워커 프로세스는 목록의 다음 지점에서 시작합니다. 워커 세션 1은 작업 1에서, 워커 세션 2는 작업 2에서 시작하는 식입니다. 작업마다 걸리는 시간이 같지 않으므로, 이러한 시작점의 차이가 작업이 겹칠 때 불균형한 경합을 만들어냅니다.

**이 테스트가 실제로 측정하는 것**

테스트가 산출하는 지표는 초당 세션 수입니다. 세션은 시작부터 끝까지 완료된 단일 작업을 의미하며, 각 단계에서 초당 완료된 세션 수를 측정합니다. 낮은 단계에서는 초당 완료되는 세션이 적으며, 종종 1개 미만입니다. 이는 작업 하나를 완료하는 데 1초 이상 걸린다는 뜻입니다. 작업은 순차적으로 완료됩니다. 우리가 살펴보는 것은 세션 수가 늘어날 때 칩들이 어떻게 갈라지는지, 즉 CPU에서 에이전틱 작업의 처리량이 어떠한지입니다.

스윕에서는 두 가지 핵심 점수를 도출합니다. 첫 번째는 최고 처리량으로, 기록된 가장 높은 초당 세션 수와 그때의 동시성 수준입니다. 두 번째는 이상적 처리량으로, 가장 느린 5%의 세션이 기본 동시성 수준에서 단일 세션이 걸리는 시간의 1.5배를 넘지 않는 지점입니다. 세션 수가 늘어나면 작업 시간이 길어질 것으로 예상하지만, 1.5배를 넘어서면 작업 시간이 크게 늘어나며, 프로세서의 토폴로지에 따라 처리량이 떨어지기 시작할 수 있습니다.

이 동시성 스윕에는 GPU 지연이 없다는 점을 다시 강조할 필요가 있습니다. 우리는 GPU를 완전히 제외하고, 최고 처리량이 어디에 있는지 알아내기 위해 가능한 한 많은 동시 작업을 CPU에 투입했습니다. 그렇더라도 GPU는 여전히 중요한 역할을 하므로, 결과는 현실적인 맥락에서 바라보아야 합니다.

더 많은 에이전트가