에이전트 턴을 2.59배 빠르게 만든 것은 캐시가 아니라 드래프터였습니다
프롬프트가 길고 답이 짧으면 프리필이, 모델이 길게 추론하면 디코드가 벽시계를 먹습니다.
사내 문서를 통째로 무는 에이전트를 운영하고 있다면, 이 글은 어느 노브가 실제로 돈을 돌려주는지에 대한 실측입니다. 결론부터 적으면 프리픽스 캐시가 아니라 드래프터였고, 같은 업무 네 건을 173.8초에서 67.2초로 줄였습니다. GPU 시간으로 환산하면 에이전트 1,000턴당 7.4시간이 돌아옵니다.
같은 엔드포인트에서 앞서 잰 값은 정반대를 말하고 있었습니다. 거기서는 프리픽스 캐시가 전부였습니다. 두 측정 다 맞습니다. 워크로드 모양이 바뀌면 먹히는 레버도 바뀝니다.
무엇을 쟀나
새로 만든 예제가 아니라 이 저장소에 실제로 있는 문서를 그대로 물렸습니다. 엔지니어링 백서 전문을 엔지니어링 에이전트에게, 백엔드 기동 로그를 인프라 진단 에이전트에게, Go 핸들러와 라우터 네 파일을 Codex 코딩 에이전트에게, 실험 findings 전량을 데이터 에이전트에게 보냈습니다. 실제로 전송된 입력은 순서대로 93,309토큰, 40,016토큰, 40,447토큰, 29,978토큰입니다. 문서만이 아니라 시스템 프롬프트와 도구 스키마까지 포함한 값이라 문서 자체보다 조금 큽니다.
에이전트도 이번에 만든 것이 아닙니다. 플랫폼에 이미 등록되어 있던 것을 그대로 썼고, 저는 모델만 바꿔 끼웠습니다.
세 팔은 전부 같은 27B NVFP4 체크포인트를 씁니다. 바뀐 것은 서빙 구성뿐입니다. 현행 팔은 vLLM 0.24.0 안정판에 프리픽스 캐시도 드래프터도 없습니다. 가운데 팔은 나이틀리 엔진에 프리픽스 캐시만 켰습니다. 오른쪽 팔은 거기에 DFlash2 드래프터를 K=7로 더했습니다.
가운데 팔이 대조군입니다. 이 팔이 없으면 캐시가 번 것과 드래프터가 번 것을 구분할 방법이 없습니다. 실제로 이 실험에서 가장 많은 것을 말해 준 팔이 대조군이었습니다.
결과
케이스마다 세 번씩 돌린 중앙값입니다.
| 케이스 | 현행 | 캐시만 | 캐시와 드래프터 |
|---|---|---|---|
| 백서 감사 | 62.4초 | 71.8초 | 18.8초 |
| 로그 진단 | 34.0초 | 30.6초 | 20.7초 |
| 코드 추적 | 47.2초 | 57.4초 | 14.7초 |
| 원장 감사 | 30.2초 | 31.0초 | 13.0초 |
| 합계 | 173.8초 | 190.8초 | 67.2초 |
캐시만 켠 팔은 0.91배입니다. 빨라지지 않았다는 뜻이고, 세 번의 반복 구간이 현행 팔과 겹치므로 느려졌다고 말할 근거도 없습니다. 그냥 아무 일도 일어나지 않았습니다.
드래프터를 켠 팔은 2.59배입니다. 네 케이스 중 세 곳에서 반복 구간이 다른 두 팔과 아예 겹치지 않습니다. 남은 한 곳도 캐시 팔과 1초 스칠 뿐입니다. 중앙값끼리 비교한 것이 아니라 관측 구간 자체가 갈라집니다.
합계를 인용해도 되는 이유는 세 팔이 만든 답변 분량이 2.4퍼센트 안에서 맞기 때문입니다. 케이스 하나만 떼어 보면 답변 길이가 팔마다 20퍼센트 넘게 벌어지는 곳이 있어서, 그런 셀의 배수는 집계 코드가 인용을 막습니다.
답변 길이는 생성량이 아니었습니다
여기서 한 번 틀렸습니다. 처음에는 답변 글자수로 시간을 나눠 정규화했는데, 그 정규화가 아무것도 정규화하지 못하고 있었습니다.
이 모델은 답하기 전에 길게 추론합니다. 트레이스에 남은 실제 숫자를 보면 가시 답변이 866자인 턴의 출력 토큰이 5,060개입니다. 생성의 대부분이 화면에 보이지 않는 추론입니다. 세 팔에 같은 프롬프트를 넣고 출력 상한을 1,024토큰으로 묶어 봤습니다. 셋 다 1,024토큰을 전부 추론에 쓰고 가시 답변 0자로 끝났습니다.
그래서 답변 글자수 대신 실제 토큰 수로 다시 갈랐습니다. Paxis는 모델 호출마다 입력 토큰, 출력 토큰, 지연을 기록해 둡니다. 같은 팔의 같은 케이스 안에서는 입력이 거의 고정이므로, 출력 토큰에 대해 지연을 회귀하면 기울기가 디코드 속도의 역수이고 절편이 프리필과 하네스 오버헤드입니다.
| 팔 | 디코드 | 절편 |
|---|---|---|
| 현행 | 122.3 tok/s | 1.7초에서 4.1초 |
| 캐시만 | 122.2 tok/s | 0.9초에서 3.6초 |
| 캐시와 드래프터 | 309.6 tok/s | 0.8초에서 3.3초 |
열두 셀 모두 결정계수가 0.91에서 1.000 사이라 선형이 거의 완벽합니다. 절편의 범위는 케이스마다 입력 길이가 다르기 때문이고, 83k 케이스가 위쪽 값입니다.
시간이 어디로 가는지가 레버를 정합니다
이 그림 한 장이 앞의 결과를 설명합니다.
83k 프롬프트에 출력 5,000토큰을 낸다고 할 때입니다. 다섯 개 수치 중 고른 것은 5,000뿐이고 프리필과 디코드는 전부 실측입니다.
캐시는 디코드 속도를 122.3에서 122.2로 만듭니다. 정확히 아무것도 하지 않습니다. 원래 그런 물건입니다. 캐시는 프리필을 줄이지 디코드를 건드리지 않습니다.
그렇다고 캐시가 고장 난 것도 아닙니다. 확인하려고 세 팔에 같은 83k 프롬프트를 넣고 출력 토큰을 128개와 1,024개로 고정해 두 점을 잡아 프리필만 분리해 봤습니다. 캐시는 프리필을 3.69초에서 0.42초로 줄입니다. 8.8배입니다. 잘 작동합니다.
문제는 그 3.3초가 어디에 얹히느냐입니다. 이 워크로드에서 디코드에 드는 시간은 케이스당 20초에서 50초입니다. 잘 작동하는 8.8배가 거기에 묻힙니다.
같은 측정에서 디코드는 119.2, 119.4, 304.8 tok/s로 나왔습니다. 토큰 수를 고정한 이 측정과 위의 회귀는 서로 독립인데 5퍼센트 안에서 일치합니다.
드래프터는 반대편에서 일합니다. 디코드를 2.53배로 만들고, 이 워크로드는 디코드가 지배자이므로 그 배수가 거의 그대로 벽시계에 나타납니다.
앞서 같은 엔드포인트에서 잰 값은 정반대를 말하고 있었습니다. 234k 프롬프트에 64토큰 답변을 요구하는 코너에서는 프리필이 벽시계의 95.9퍼센트였고, 프리픽스 캐시가 프리필을 14.70초에서 0.72초로 줄여 20.4배를 벌었습니다. 그 자리에서 드래프터의 몫은 디코드 1.85배뿐이라 거의 보이지 않습니다.
두 측정은 충돌하지 않습니다. 프롬프트가 길고 답이 짧으면 프리필이 지배하고 캐시가 답입니다. 프롬프트가 그보다 짧고 모델이 길게 추론하면 디코드가 지배하고 드래프터가 답입니다. 추론하는 모델을 쓰는 순간 대부분의 실제 업무는 뒤쪽으로 옮겨 갑니다.
무엇을 켤지는 벤치마크가 아니라 자기 트래픽의 프리필 대 디코드 비율이 정합니다. 그 비율은 위 회귀로 잽니다. 남의 배수를 그대로 가져다 쓰면 우리처럼 반대편에 도착합니다.
비용
자가 서빙이 사는 것은 토큰이 아니라 GPU 시간입니다. 그래서 속도 이득이 그대로 청구서가 됩니다. B200 한 장을 시간당 5.50달러로 잡으면 완결된 에이전트 턴 하나가 0.0664달러에서 0.0257달러가 됩니다. 1,000턴으로 키우면 12.07 GPU 시간이 4.67시간이 되고, 금액으로는 66.38달러가 25.67달러가 됩니다.
1,000턴마다 7.4 GPU 시간이 돌아옵니다. 팀 하나가 하루에 이 정도 규모의 문서 분석을 돌린다면, 그만큼의 카드가 다른 잡을 받으러 갈 수 있습니다. 상용 API와의 비교는 1편에 실었으니 여기서 되풀이하지 않겠습니다. 종류가 다른 비용이라 맞출 수 있는 단위가 애초에 요청 하나뿐입니다.
한 가지 덧붙일 것은 프롬프트 규율도 비슷한 크기의 레버라는 점입니다. 같은 네 케이스에 답변을 한 문장으로만 하라고 지시했더니 현행 팔이 173.8초에서 82.6초가 됐습니다. 엔진이 빨라진 것이 아니라 생성 토큰이 줄어든 것입니다. 다만 이 경우 세 팔의 산출량이 18.4퍼센트까지 벌어져서 배수로는 인용하지 않습니다.
화면 녹화
네 케이스를 두 팔에서 각각 찍어 나란히 붙였습니다. 왼쪽이 현행, 오른쪽이 드래프터를 켠 팔이고 둘 다 같은 순간에 출발합니다. 오른쪽이 먼저 끝나면 마지막 화면이 그대로 멈춘 채 왼쪽이 계속 도는 것을 보실 수 있습니다. 재생 속도는 손대지 않았습니다.
각 화면 아래쪽 모델 피커에 어느 백엔드인지 그대로 찍혀 있고, 여덟 개 클립 전부 백엔드 로그에서 실제로 그 모델이 답했음을 확인했습니다.
백서 감사 · 엔지니어링 에이전트
모델 호출 시간은 현행 47.7초, 드래프터 26.9초입니다. 생성 토큰은 각각 4,908개와 5,470개입니다.
로그 진단 · 인프라 진단 에이전트
모델 호출 시간은 현행 39.1초, 드래프터 21.0초입니다. 생성 토큰은 각각 2,131개와 5,376개입니다.
코드 추적 · Codex 코딩 에이전트
모델 호출 시간은 현행 83.3초, 드래프터 15.7초입니다. 생성 토큰은 각각 7,603개와 3,880개입니다.
원장 감사 · 데이터 에이전트
모델 호출 시간은 현행 111.6초, 드래프터 18.4초입니다. 생성 토큰은 각각 5,436개와 6,454개입니다.
이 여덟 클립은 케이스마다 한 번씩 찍은 것이라 앞의 2.59배와 같은 값이 아닙니다. 화면에서 벌어진 간격이 더 큰데, 여기에는 이유가 있고 숨길 이유가 없습니다. 녹화는 측정보다 여섯 시간 뒤 저녁에 했고, 그 시각 현행 팔은 같은 고정 토큰 프로브에서 37.0 tok/s를 냈습니다. 낮에는 119.2였습니다. 세 팔 모두 동시 요청은 0이었으니 제 트래픽이 밀린 것은 아니고, 그 엔드포인트가 저녁에 느려진 이유는 여기서 특정할 수 없습니다. 그래서 본문이 인용하는 배수는 낮에 세 번씩 돌린 하네스 값이고, 영상은 같은 일을 두 구성으로 하면 화면에서 어떻게 다른지 보여주는 용도입니다.
남은 것
동시성 1에서 잰 값입니다. 전용 스트림 하나의 원가이지 포화 처리량의 원가가 아닙니다.
드래프터 팔의 최대 컨텍스트는 245,760입니다. 1M이 아닙니다. 그리고 현행 팔은 vLLM 0.24.0 안정판이고 나머지 두 팔은 나이틀리라, 엔진 버전까지 통제된 비교는 가운데 팔과 오른쪽 팔 사이뿐입니다. 드래프터의 몫을 말할 때 쓴 것도 그 구간입니다.
이 글의 모든 수치는 저장소에 커밋된 원장에서 나왔고, 계산은 전부 코드가 소유합니다.