에이전트 추론 인프라를 고를 때 GPU 이름보다 먼저 봐야 할 두 구간

에이전트를 붙인 서비스가 느릴 때 흔히 모델을 바꾸거나 GPU를 더 늘리는 쪽부터 생각한다. 하지만 실제 체감 지연은 한 덩어리가 아니다. 긴 문서나 코드베이스를 읽어 들이는 시간, 모델이 한 토큰씩 답을 생성하는 시간, 도구를 호출하고 결과를 다시 넣는 시간이 이어진다. 특히 여러 번 판단하고 도구를 부르는 에이전트는 한 단계의 짧은 지연도 반복해서 누적한다.

8월 24일 NVIDIA는 Groq 3 LPX가 양산에 들어갔다고 발표했다. 이 장비는 Vera Rubin NVL72과 결합해 에이전트형 AI의 빠른 토큰 생성을 맡도록 설계된 추론 가속기다. 같은 날 Nebius는 자사 Token Factory에 이를 처음 도입한다고 밝혔다. 이 소식에서 눈여겨볼 지점은 새 칩의 최고 속도 자체보다, 추론 요청을 맥락 처리와 생성 처리로 나눠 서로 다른 자원에 배치하려는 방향이다.

한 번의 요청 안에도 서로 다른 일이 있다

LLM 추론에는 크게 두 구간이 있다. 프리필(prefill)은 프롬프트, 첨부 문서, 대화 기록처럼 이미 주어진 입력을 읽고 KV 캐시를 만드는 단계다. 긴 계약서나 저장소 전체를 넣을수록 이 구간의 부담이 커진다. 디코드(decode)는 그 뒤에 다음 토큰을 하나씩 만들어 내는 단계다. 답변이 길거나, 모델이 도구 호출 전후로 여러 차례 추론할수록 디코드가 길어진다.

일반적인 대화형 서비스라면 첫 답이 얼마나 빨리 보이는지와 초당 토큰 수가 중요하다. 에이전트는 여기에 반복이 더해진다. 예를 들어 코딩 에이전트가 요구사항을 읽고, 파일을 검색하고, 테스트를 실행하고, 오류를 해석한 뒤 수정안을 만드는 동안 모델 호출이 여러 번 일어난다. 한 호출의 생성 지연이 작아도 전체 작업 시간에는 여러 번 반영된다.

Nebius는 에이전트의 한 작업에 수십 번의 순차 모델 호출이 들어갈 수 있으며, 앞 단계의 결과가 다음 단계에 의존한다고 설명한다. 독립 매체 SiliconANGLE도 이 구조에서 디코드 지연이 누적될 수 있고, 긴 맥락 처리와 토큰 생성을 분리하는 설계가 등장하고 있다고 짚었다. 이는 모든 워크로드가 저지연 장비를 필요로 한다는 뜻은 아니다. 다만 에이전트의 병목을 평균 응답 시간 하나로 판단하면 놓치는 부분이 생긴다는 뜻이다.

GPU와 전용 가속기를 나누는 이유

NVIDIA의 기술 설명에 따르면 Vera Rubin GPU는 긴 맥락의 프리필과 디코드 중 어텐션처럼 큰 메모리와 높은 처리량이 필요한 일을 맡는다. LPX의 LPU는 디코드 중 지연에 민감한 FFN, MoE 전문가 실행 같은 부분을 가속하는 역할을 맡는다. 한 요청을 둘로 쪼개기만 하는 방식이 아니라, 요청 특성에 따라 두 종류의 장비와 소프트웨어 스케줄러가 협력하는 구조다.

이런 구성을 이질적 추론, 또는 분리형 서빙이라고 부를 수 있다. 여기서 중요한 말은 ‘더 빠르다’보다 ‘어느 구간을 빠르게 하려는가’다. 배치 요약, 임베딩 생성, 야간 문서 분류처럼 응답을 즉시 보여 줄 필요가 없는 작업은 높은 처리량과 토큰당 비용이 우선일 수 있다. 반면 실시간 코딩 보조, 음성 대화, 사람이 기다리는 승인형 에이전트는 첫 응답 지연과 토큰 사이의 지연, 혼잡할 때의 긴 꼬리 지연이 서비스 품질에 직접 영향을 준다.

NVIDIA는 LPX 랙에 256개의 LPU 가속기, 128GB 온칩 SRAM, 640TB/s 규모의 스케일업 대역폭을 제시했다. Nebius는 Artificial Analysis의 측정에서 Gemma 4 31B가 단일 사용자 기준 초당 3,400개 출력 토큰을 기록했다고 소개했다. 이 수치는 특정 모델, 특정 맥락 길이, 특정 환경에서의 결과다. 다른 모델이나 한국어 업무 프롬프트, 실제 동시 사용자 수에서도 같은 체감 개선을 보장하지는 않는다. 벤치마크를 구매 근거나 아키텍처 결정의 출발점으로 쓰되, 자체 작업으로 재확인해야 하는 이유다.

숫자가 좋아도 에이전트가 빨라지지 않는 경우

토큰 생성이 빨라져도 전체 에이전트가 빨라진다는 보장은 없다. 먼저 외부 도구가 병목일 수 있다. 사내 API가 느리거나, 브라우저 자동화가 페이지 로드를 기다리거나, 사람이 승인 버튼을 눌러야 한다면 모델 생성 속도만 올려도 총 실행 시간은 크게 줄지 않는다. 검색과 RAG를 쓴다면 검색 인덱스, 재순위화, 권한 확인도 따로 봐야 한다.

또 하나는 비용과 운영 복잡도다. 프리필과 디코드를 서로 다른 자원으로 보내려면 요청 분류, KV 캐시의 위치, 중간 데이터 이동, 장애 시 우회 경로를 관리해야 한다. NVIDIA는 이를 조율하는 소프트웨어 계층으로 Dynamo를 제시한다. 하지만 이를 도입하는 팀 입장에서는 관측 항목과 장애 대응 지점이 늘어난다는 의미이기도 하다. 작은 서비스라면 단일 GPU 서빙의 단순함이 더 나을 수 있다.

모델과 작업 성격도 변수다. 짧은 답변을 한 번 생성하는 챗봇은 초당 토큰 수가 아주 높아도 이득이 제한적일 수 있다. 반대로 긴 컨텍스트를 읽고 도구를 여러 번 호출하는 코딩 또는 조사 에이전트라면, 매 단계의 지연을 줄이는 효과가 누적될 가능성이 있다. 가능성은 측정으로 확인해야 한다.

도입 전에는 작업을 둘로 쪼개 기록해 보자

대규모 전용 장비를 바로 검토할 필요는 없다. 먼저 현재 에이전트의 실행 로그에서 요청을 두 구간으로 나눠 보면 된다.

첫 토큰과 생성 속도를 분리한다. 각 모델 호출마다 입력 토큰 수, 첫 토큰까지 걸린 시간, 출력 토큰 수, 생성 완료 시간을 남긴다. 평균만 보지 말고 p95 같은 상위 지연도 함께 본다.
도구 대기 시간을 따로 적는다. 모델이 생각하는 시간과 검색, API, 브라우저, 사람 승인에 기다린 시간을 분리해야 투자 지점을 정할 수 있다.
대표 작업 하나로 전후를 비교한다. 실제 코드 수정, 문서 조사, 고객 문의 분류처럼 반복되는 작업을 고르고 성공률, 총 실행 시간, 비용, 사람이 재작업한 횟수를 같은 조건에서 비교한다.

이 기록은 특정 벤더를 고르기 위한 표가 아니라 병목을 찾는 도구에 가깝다. 긴 입력 처리보다 디코드가 문제인지, 모델보다 외부 도구가 문제인지 구분되면 그때 캐시, 모델 선택, 동시성 제어, 추론 인프라 변경의 우선순위도 달라진다.

인프라 뉴스가 실무에 남기는 질문

이번 발표는 대형 AI 인프라의 이야기다. 개인 NAS나 소규모 팀이 LPX 랙을 도입할 일은 당장 많지 않다. 그래도 에이전트가 보편화될수록 추론 서비스가 처리량 중심과 응답성 중심으로 나뉜다는 흐름은 API를 사용하는 쪽에도 영향을 준다. 앞으로는 모델 이름과 입력 단가만 비교하기보다, 긴 문맥에서의 첫 토큰 지연, 생성 중 끊김, 도구 호출이 반복되는 작업의 총 시간까지 살펴볼 필요가 있다.

에이전트의 속도는 모델의 단일 점수가 아니다. 작업이 어떤 구간에서 기다리는지 보이고, 그 구간을 줄였을 때 사람의 검토와 재작업까지 함께 줄어드는지가 더 실용적인 기준이다. 이번 LPX 발표는 그 기준을 하드웨어 이름보다 먼저 세워야 한다는 사례로 읽는 편이 낫다.