AI 추론비를 낮추려면 GPU보다 작업을 먼저 나눠야 한다

AI 추론비를 줄이는 첫 단계는 GPU 모델을 고르는 일이 아니라 요청을 prefill, decode, 도구 실행으로 나누는 일이다. 세 단계는 각각 연산 처리량, 메모리 대역폭·용량, 외부 시스템의 응답시간에 주로 제약되므로 한 종류의 장치에 모두 몰아넣으면 비싼 가속기가 기다리거나 적성에 맞지 않는 일을 처리할 수 있다.

기업이 비교할 대상도 GPU 구매가나 시간당 이용료 하나가 아니다. 입력·출력 토큰 길이, 동시 요청 수, 첫 토큰 및 토큰 간 지연 목표, 모델 가중치와 KV 캐시의 메모리 점유량, 실제 가동률, 전력과 운영 복잡성을 함께 계산해야 한다. 이 조건을 측정한 뒤에야 GPU·CPU·전용 가속기를 섞는 구성이 단일 GPU 풀보다 유리한지 판단할 수 있다.

Prefill과 decode는 같은 모델 안에서도 병목이 다르다

Prefill은 입력 프롬프트의 토큰을 병렬로 처리해 KV 캐시를 만드는 단계다. 입력이 길어지면 한 번에 수행할 행렬 연산이 커지므로 계산 처리량을 활용하기 좋지만, 긴 문서 요약이나 검색 증강 생성 서비스에서는 이 구간이 첫 토큰 지연을 좌우할 수 있다.

Decode는 만들어진 캐시를 읽으며 다음 토큰을 순차적으로 생성한다. 단일 요청만으로는 대형 가속기의 연산 유닛을 채우기 어렵고 모델 가중치와 KV 캐시를 거듭 읽기 때문에 메모리 대역폭과 용량의 영향이 커진다. 동시 요청을 배치로 묶으면 활용률은 높아지지만 대기시간과 캐시 점유량도 늘어 지연 목표와 충돌할 수 있다.

McKinsey의 추론 경제성 분석 은 prefill을 주로 계산 제약을 받는 단계, decode를 주로 메모리 대역폭의 제약을 받는 단계로 구분한다. 또한 토큰당 비용은 워크로드 유형, 배치 크기, 하드웨어 구성과 배포 규모에 따라 달라지며, 전력·메모리·네트워크·가동률까지 함께 봐야 한다고 설명한다. 따라서 공개 최대 FLOPS가 아니라 지연 목표를 지킨 상태의 완료 토큰당 비용과 에너지가 구매 기준이 돼야 한다.

도구 실행은 가속기 성능보다 대기시간을 먼저 본다

에이전트가 검색, 데이터베이스, 사내 API나 코드 실행을 호출하면 모델 계산과 무관한 대기 구간이 생긴다. 이때 병목은 GPU 계산 능력이 아니라 네트워크 왕복, 호출 제한, CPU 전처리, 저장장치 접근 또는 결과 검증일 수 있다. 응답을 기다리는 세션이 가속기 메모리와 실행 슬롯을 계속 차지하면 새 GPU를 추가해도 낭비가 남는다.

운영 설계에서는 도구 호출을 비동기 작업으로 분리하고 CPU가 직렬화·검증·라우팅을 맡게 할 수 있다. GPU에는 실행 준비가 끝난 prefill이나 decode 요청을 공급하고, 대기 세션의 상태는 지연 목표와 복구 요건을 해치지 않는 범위에서 호스트 메모리나 별도 저장 계층으로 옮기는 방식이다. 핵심 지표는 도구별 응답시간 분포, 시간 초과와 재시도 비율, 세션당 캐시 크기, 상태를 다시 불러오는 데 드는 시간이다.

분리가 언제나 이득인 것은 아니다. 짧은 호출이 대부분이거나 KV 캐시를 내리고 다시 올리는 비용이 도구 대기시간보다 크면 상태 이동이 오히려 지연과 전력 사용을 늘린다. 도구 실행 구간은 GPU 사양표가 아니라 실제 호출 로그와 꼬리 지연을 기준으로 판단해야 한다.

Decode 장치는 최고 속도보다 메모리 균형이 중요하다

요청을 지속적으로 모을 수 있는 초대형 사업자와 트래픽이 들쭉날쭉한 일반 기업은 같은 하드웨어에서도 다른 경제성을 갖는다. 전자는 큰 배치로 연산 자원을 채울 수 있지만, 후자는 모델과 KV 캐시를 담으려고 장치를 추가하면서도 계산 유닛을 충분히 쓰지 못할 수 있다.

2026년 7월 제출된 decode 칩 경제성 프리프린트 는 초대형 사업자 밖에서는 연산량을 더 늘리기보다 범용 메모리 용량을 확대하고 대역폭 비용을 낮춘 가속기가 경제적일 수 있다고 주장한다. 다만 특정 칩, 모델, 동시성과 소유비용 가정을 사용한 저자들의 분석이며 동료 심사를 거친 보편적 시장 벤치마크는 아니다. 유효한 시사점은 낮은 동시성과 모델 수용 능력까지 반영하면 가격 대비 FLOPS 순위와 총비용 순위가 달라질 수 있다는 점이다.

Decode 후보에는 목표 모델을 실제 운영 정밀도로 올리고 KV 캐시까지 포함해 동시 시퀀스를 몇 개 수용하는지 확인해야 한다. 그다음 지연 상한을 지키는 배치 크기에서 초당 완료 토큰, 서버 및 유휴 전력, 장치 가격이나 임차료, 소프트웨어 비용을 비교한다. 모델이 한 장치에 들어가지 않아 분할된다면 장치 간 통신, 추가 서버와 장애 지점도 비용에 포함해야 한다.

이기종 구성은 분리 이익이 전송·운영비보다 클 때 이긴다

이기종 구조는 단계별 병목과 장치의 강점이 뚜렷하게 맞을 때 유리하다. 계산 집약적 prefill은 GPU나 데이터플로 가속기에, 메모리 집약적 decode는 용량·대역폭 균형이 맞는 장치에, 제어와 도구 연동은 CPU에 배치할 수 있다. 각 작업 큐에 장치를 채울 만큼 요청이 있고 단계 사이의 상태 이동이 충분히 빠를수록 분리 이익이 커진다.

구현 사례로 Gimlet Labs의 공식 발표 는 GPU, 근접 메모리 연산 장치, 데이터플로 아키텍처와 CPU를 함께 쓰고 추론의 각 단계를 적합한 실리콘에 배치한다고 설명한다. 다만 여기에 제시된 성능 배수는 공급자의 자체 주장으로, 모든 기업 환경에서 비용 우위를 입증하는 독립 벤치마크가 아니다. 공개 자료가 확인해 주는 것은 다중 실리콘 분할이라는 구현 방향이지 국내 기업의 실제 절감률이 아니다.

트래픽이 작거나 예측하기 어렵고 지원 모델이 자주 바뀌며 가속기별 컴파일러와 지원 연산이 다르면 분리가 손해일 수 있다. 장치별로 남는 용량과 데이터 전송 비용이 생기고 스케줄러, 관측 체계, 장애 대응 역량도 추가로 필요하기 때문이다. 이런 환경에서는 범용 GPU 풀을 여러 서비스가 공유해 높은 가동률을 확보하는 편이 이론상 효율적인 전용 장치보다 총비용이 낮을 수 있다.

구매 결정은 실제 요청을 단계별 숫자로 바꾸는 일이다

비교는 대표 GPU의 공개 최대 성능이 아니라 실제 요청 로그에서 시작해야 한다. 평균값만 보면 긴 프롬프트, 긴 출력과 느린 도구 호출이 만드는 꼬리 지연을 놓치므로 입력·출력 길이와 대기시간의 분포를 서비스 유형별로 나눠야 한다.

1. 입력 토큰, 출력 토큰, 동시성, 도구 호출 비율과 도구별 대기시간을 기록한다.
2. 첫 토큰 지연과 토큰 간 지연의 상한을 정하고, 이를 지키는 배치 크기를 찾는다.
3. Prefill 시간, decode 시간, CPU 처리시간과 외부 도구 대기시간을 별도로 계측한다.
4. 후보 구성마다 완료된 유효 토큰을 기준으로 장비·클라우드 사용료, 전력, 유휴 용량, 네트워크와 운영비를 합산한다.
5. 평시와 최대 부하에서 큐 적체, KV 캐시 부족, 장치 장애와 모델 교체 시의 비용을 비교한다.

긴 입력이 지배적이면 prefill 처리량과 첫 토큰 지연을 우선하고, 긴 출력과 높은 동시성이 지배적이면 decode의 메모리 용량·대역폭과 배칭을 먼저 조정해야 한다. 도구 대기가 길다면 새 가속기보다 스케줄링과 상태 관리의 개선 여지가 크다. 가장 빠른 칩이 아니라 비싼 연산 자원이 자신에게 맞는 일을 높은 가동률로 처리하게 만드는 구성이 토큰당 비용과 전력을 낮춘다.