I Made My AI Agents Faster Without a GPU Upgrade

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

GPU를 업그레이드하지 않아도 KV 캐시로 AI 에이전트의 반복 읽기를 줄이면 처리량을 높일 수 있으며, LMCache의 추가 가치는 캐시 용량 확장과 서버 재시작 후 재사용에 있다.

📌 핵심 요점

1. 에이전트는 대화가 길어질수록 이전 기록을 다시 처리하는 부담이 커진다. 영상의 30턴 실험에서는 캐시 없이 세션 전체에서 200만 토큰 이상을 처리했고, prefix 캐시는 읽기 작업을 약 14분의 1로 줄였다.
2. KV 캐시는 이미 처리한 문맥의 계산 결과를 재사용하지만 GPU 메모리를 차지한다. 모델과 캐시가 메모리를 함께 사용하므로, 모델이 GPU에 들어간다는 사실만으로 충분한 캐시 공간까지 확보되는 것은 아니다.
3. GPU 메모리에 캐시가 모두 들어가면 vLLM의 기본 prefix 캐시로 충분하다. GPU 용량을 넘지만 시스템 RAM에는 들어가는 실험에서는 vLLM의 CPU offload와 LMCache가 비슷한 성능을 보였다.
4. LMCache는 캐시를 별도 서버와 RAM·NVMe에 보관할 수 있다. vLLM 프로세스 재시작 후에도 캐시를 재사용한 것이 주요 차이였지만, 메모리 해제 대기와 재시작 지연이라는 비용도 발생했다.
5. 8개 에이전트 실험에서 캐시 사용 시 분당 턴 수는 Spark에서 5.6배, RTX Pro 6000에서 7.5배로 늘었다. 이는 해당 실험의 처리량 개선이며, 에이전트의 판단력이나 결과 품질이 향상됐다는 의미는 아니다.

🧩 배경과 문제 정의

코딩 에이전트는 매 턴 이전 대화, 파일 내용, 도구 실행 결과가 포함된 문맥을 처리한다. 대화가 길어지고 같은 GPU에서 실행하는 에이전트가 늘어나면 반복 읽기가 병목이 된다. 영상은 GPU 교체 없이 이 부담을 줄이는 방법으로 KV 캐시를 설명하고, 캐시 없음·vLLM 기본 prefix 캐시·vLLM CPU offload·LMCache를 비교한다. vLLM은 제공 자막에서 VLM으로 표기된다.

핵심 질문은 캐시의 유무뿐 아니라 저장 위치와 수명이다. GPU 내부 캐시는 빠르지만 용량이 제한되고, 프로세스 내부 캐시는 서버가 종료되면 사라진다. 영상은 GPU 용량 초과, 동시 요청, 서버 재시작, NVMe 활용, 모델 호환성, 코딩 에이전트 실험으로 각 방식의 적용 조건을 살핀다.

🕒 시간순 섹션별 상세정리

1. 길어지는 대화가 만드는 지연과 도입부 광고

• RTX Pro 6000에서 한 에이전트의 첫 응답 대기는 첫 턴 약 0.12초에서 25번째 턴 약 19초로 늘어난다. 제작자는 매 턴 읽어야 하는 기록이 증가하고, 여러 에이전트가 같은 GPU에서 각자의 기록을 반복 처리하기 때문이라고 보여준다. [00:31]
• 개인정보 삭제 대행 서비스 광고가 계속된다. 데이터 브로커 대상 삭제 요청과 후속 확인을 소개하며, 정부 기록이나 임의의 소셜 게시물은 적용 대상에서 제외된다고 설명한 뒤 본론으로 돌아온다. [01:51]

2. KV 캐시는 무엇을 줄이고 무엇을 차지하는가

• 모델은 답변 생성 전에 프롬프트를 처리하며 키와 값으로 이뤄진 KV 캐시를 만든다. 영상은 이를 읽은 내용에 대한 노트에 비유하며, 재사용하면 새로 추가된 부분을 중심으로 처리할 수 있다고 보여준다. [02:40]
• 30턴 세션에서 캐시가 없으면 마지막에 약 11만 5천 토큰을 다시 읽고 세션 전체 처리량은 200만 토큰을 넘는다. prefix 캐시를 쓰면 매 턴 처리량이 약 1만 토큰 이내로 줄어 읽기 작업이 약 14분의 1이 된다. [03:14]
• 캐시는 모델과 GPU 메모리를 나눠 쓴다. 공간이 부족해 기존 캐시가 제거되면 다음 요청에서 해당 문맥을 다시 처리해야 하므로, 모델 크기뿐 아니라 캐시 여유 공간도 필요하다. [03:41]

3. 네 가지 캐시 구성의 저장 위치와 차이

• 캐시 없음은 매번 전체 문맥을 처리한다. vLLM 기본 prefix 캐시는 프롬프트 앞부분이 같을 때 GPU에 남아 있는 계산 결과를 재사용하며, 테스트한 환경에서는 기본 활성화돼 있었다. [04:07]
• vLLM CPU offload는 캐시를 시스템 RAM으로 확장하지만 vLLM 내부에서 관리한다. LMCache는 별도 서버에서 RAM을 사용하고 NVMe SSD도 활용할 수 있다. [04:28]
• 저장 위치와 프로세스 분리는 추론 서버 종료 후 캐시를 다시 사용할 수 있는지를 가르는 조건으로 드러난다. [04:34]

4. 반복 문서·용량 초과·동시 요청 실험

• GB300 장비에서 3만 2천 토큰 문서를 다시 질문하자 캐시 없음은 약 1.35초, 세 캐시 구성은 약 112~122밀리초였다. 제작자는 약 11~12배 차이라고 보여준다. [05:04]
• 48개 문서, 약 150만 토큰으로 GPU 캐시 용량을 넘기자 재방문 시 GPU 캐시 적중률이 0%가 됐다. RAM을 활용한 vLLM offload는 약 164밀리초·99.9% 적중률, LMCache는 약 140밀리초로 두 방식 모두 용량 문제를 완화했다. [06:28]
• 16개 클라이언트와 약 144개 동시 요청에서는 캐시 없음 약 187초, GPU prefix 캐시 약 107초, vLLM RAM offload 약 69초를 기록했다. LMCache와 vLLM offload는 거의 비슷해, 이 조건만으로 LMCache의 추가 가치가 뚜렷하지 않았다. [07:03]

5. 재시작 후 재사용과 NVMe 확장의 효과

• vLLM 재시작 후 기본 캐시와 CPU offload는 캐시를 잃어 약 1.35초로 돌아갔다. 별도 서버가 살아 있던 LMCache는 약 141밀리초와 99.9% 적중률을 유지했다. [07:36]
• 초기에는 LMCache가 종료된 프로세스의 GPU 메모리 약 89GB를 계속 잡아 새 vLLM 실행이 실패했다. 메모리 해제 대기 설정의 최솟값은 30초였고, 조정 후 전체 재시작은 약 173초였지만 기본 vLLM보다 여전히 약 20~30초 느렸다. [08:14]
• LMCache에 RAM 40GB만 허용하면 약 1.4초와 전부 미적중 결과가 나왔지만, NVMe를 추가하면 약 265밀리초로 줄었다. 이어진 재시작 후에도 디스크의 캐시를 읽어 비슷한 시간을 유지했다. [08:37]

6. 문서 순서와 모델 호환성의 한계

• CacheBlend는 문서 조각의 순서가 달라도 재사용하려는 기능으로 묶인다. 문서를 섞은 조건에서 기존 캐시 적중률은 5% 미만이었고, 관련 모드는 지원 문제로 제대로 시험하지 못했다. [09:11]
• 다른 모델에서는 약 1천만 토큰의 문서를 넣어도 GPU 캐시 적중률이 98%였다. 제작자는 캐시 용량 추정이 실제와 10배 이상 달라 용량 초과 실험이 성립하지 않았다고 설명하며, 재시작 후 16개 문서 처리는 LMCache 약 5.7초, 기본 캐시 약 13.8초였다고 제시한다. [09:55]
• 하이브리드 모델에서는 vLLM CPU offload가 시작되지 않았고 LMCache도 새 버전으로 다시 빌드해야 실행됐다. 실행 후 재시작 뒤 16개 문서 처리는 LMCache 약 12.3초, 기본 캐시 약 27.4초였으며 지원 상태는 바뀔 수 있다고 덧붙인다. [10:27]

7. 코딩 에이전트 실험과 배칭에 따른 측정 문제

• Spark에서 실제 파일·로그를 동일하게 재생하는 30턴 세션을 구성했다. 대화는 약 10만 토큰으로 커졌고, 8개 에이전트의 후반 턴 대기는 캐시 없이 약 104초, 캐시 사용 시 약 2.1초였으며 분당 턴 수는 5.6배로 늘었다. [11:12]
• RTX Pro 6000 한 장에서 캐시 사용·미사용 요청을 동시에 비교하자, 최대 2만 7천 토큰을 재사용해도 캐시 쪽 응답이 3~4초 걸렸다. vLLM이 요청을 함께 배칭하면서 빠른 요청이 느린 요청을 기다린 것으로 보여준다. [11:48]
• 비교 방법을 바꿔 각 구성이 GPU를 단독 사용하도록 따로 기록한 뒤 실제 소요시간에 맞춰 나란히 재생했다. [11:57]

8. RTX Pro 6000 처리량과 재시작 비용의 비교

• 약 11만 5천 토큰으로 커지는 세션에서 단일 에이전트는 캐시 없음 분당 5.2턴, 기본 prefix 캐시 12.9턴, LMCache 12.8턴이었다. 8개 에이전트 합산 처리량은 캐시 없이 분당 약 8턴에서 캐시 사용 시 거의 60턴으로 늘었고, 캐시 사용 시 읽는 문맥은 약 7%였다. [12:42]
• 후반 21~30턴의 대기는 에이전트 수가 늘면서 캐시 없이 약 14초에서 42초까지 늘었지만, 두 캐시 구성에서는 약 0.5~2초였다. 15턴 뒤 서버를 재시작한 실험의 다음 턴은 기본 캐시 약 9.5초, LMCache 약 1.1초였고 LMCache는 약 6만 토큰을 재사용했다. [13:26]
• 재시작 자체를 제외한 30턴 세션은 캐시 없음 약 350초, 기본 캐시 65초, LMCache 55초였다. 그러나 재시작은 LMCache 88초, 기본 캐시 58초여서 이를 포함하면 LMCache가 약 20초 늦었다. 캐시는 동일한 내용을 다시 읽는 작업을 줄인 것이며 에이전트가 더 똑똑해진 것은 아니라고 강조한다. [13:59]

9. 적용 조건에 따른 선택과 마무리

• 두 장비·모델의 8개 에이전트 실험에서 분당 턴 수는 Spark 5.6배, RTX Pro 6000 7.5배로 늘었다. 제작자는 함께 실행하는 에이전트가 많을수록 캐시의 효과가 커졌다고 정리한다. [14:39]
• GPU에 모두 들어가면 기본 prefix 캐시를 유지하고, GPU를 넘지만 RAM에 들어가면 vLLM CPU offload를 사용하라고 권한다. 재시작 후 캐시 재사용이 필요하거나 캐시가 RAM까지 넘으면 LMCache를 검토하되, 추가 구성요소·느린 재시작·새 모델의 설정 문제를 감수해야 한다. [15:22]
• 마지막에는 관련 장비 소개와 RTX Pro 6000 구성 영상을 안내하고 종료한다. [15:35]

🧾 결론

• 자체 하드웨어로 코딩 에이전트를 운영한다면, GPU 교체에 앞서 KV 캐시 활성화 여부와 실제 적중률을 확인할 근거가 충분하다.
• 캐시가 GPU에 들어가면 기본 prefix 캐시, RAM까지 필요하면 CPU offload, 프로세스 재시작 후 재사용이나 RAM 초과 용량이 필요하면 LMCache를 검토하는 순서가 영상의 권고다.
• LMCache의 재사용 이점과 전체 작업 시간 단축은 구분해야 한다. 마지막 에이전트 실험에서는 재시작 시간을 포함하면 LMCache가 vLLM 기본 캐시보다 약 20초 늦었다.

📈 투자·시사 포인트

• AI 인프라의 실효 처리량은 GPU 사양뿐 아니라 문맥 재사용률과 메모리 운영 방식에도 좌우된다. 영상은 동일 GPU에서 캐시 설정만으로 처리량이 크게 달라지는 사례를 보여준다.
• 긴 대화를 유지하는 여러 에이전트에서는 중복 문맥 처리 부담이 누적된다. 장비 증설의 필요성을 판단할 때 동시 실행 수와 캐시 적용 후 처리량을 함께 비교필요가 있다.
• RAM·NVMe를 이용한 캐시 확장은 GPU 메모리 부족에 대응하는 선택지지만, 저장 계층 추가에 따른 운영 복잡성과 재시작 비용까지 평가해야 한다.
• 영상에는 장비 가격, 전력 사용량, 운영 인건비 자료가 없다. 제시된 속도 개선만으로 투자수익률이나 특정 기업의 수혜 규모를 계산할 수는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 성능 수치는 영상 제작자의 특정 장비·모델·요청 구성에서 나온 결과다. 다른 문맥 길이, 동시성, 메모리 용량에서도 같은 배율이 나오는지는 확인되지 않았다.
• 일부 모델명과 제품명이 자막에서 불명확하게 표기되고, 재시작 시간 설명에도 수치가 혼재한다. 정확한 모델·버전·설정과 일부 재시작 수치는 원본 화면이나 실험 자료 확인이 필요하다.
• CacheBlend는 호환성 문제로 제대로 검증하지 못했다. 다른 모델에서는 GPU 캐시 용량 추정이 실제와 크게 달라 의도한 용량 초과 실험 자체가 성립하지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 사용하는 추론 서버의 prefix 캐시 활성화 상태를 확인하고, 대표적인 긴 에이전트 세션에서 적중률과 새로 처리한 토큰 수를 기록한다.
• 모델 적재 후 남는 GPU 메모리와 에이전트별 캐시 사용량을 측정해 GPU 캐시만으로 충분한지 판단한다.
• GPU 용량을 넘는 작업은 CPU offload와 LMCache를 같은 요청 순서·동시성 조건에서 비교한다.
• 첫 응답 대기시간, 분당 턴 수, 재시작 후 첫 요청, 재시작을 포함한 전체 시간을 각각 측정한다.

❓ 열린 질문

• 실제 운영에서 서버 재시작 빈도와 재시작 직후 요청량은 어느 정도이며, 캐시 보존 이익이 추가 재시작 시간을 상쇄하는가?
• 문서 순서와 프롬프트 앞부분이 자주 바뀌는 작업에서도 충분한 캐시 적중률을 유지할 수 있는가?
• 캐시 적중·미적중 요청이 섞이는 환경에서 배칭은 에이전트별 대기시간과 전체 처리량에 어떤 영향을 주는가?