Agents That Own Their Inference — Du'an Lightfoot & Khaja Omer, Akamai Technologies

한 줄 핵심

이 영상은 에이전트의 추론을 직접 소유하는 관점에서, 전용 GPU와 vLLM·Kubernetes를 활용해 지연시간과 처리량을 측정·최적화하는 실전 워크숍이다.

시간별 요약

1. 0:00
   발표자 소개 Akamai의 개발자 관계 담당자와 시니어 소프트웨어 엔지니어가 전용 GPU 위에서 프로덕션 AI 에이전트를 구축하는 배경과 문제의식을 소개한다. 토큰 비용, 로컬 모델의 한계, 컨텍스트와 메모리 제약이 왜 추론 소유의 필요로 이어지는지 설명한다.
2. 1:51
   에이전트 루프와 추론 소유 에이전트는 LLM 호출, 도구 실행, 결과 반영을 반복하는 루프로 정의된다. 데이터가 클러스터나 데이터센터를 벗어나지 않도록 GPU를 직접 소유하거나 임대하면, 지연시간·비용·통제를 함께 확보할 수 있다.
3. 3:30
   호스팅 API와 전용 GPU를 언제 쓸지 트래픽이 높고 일정하거나 데이터 보안·컴플라이언스가 중요하면 전용 GPU가 유리하다. 반대로 트래픽이 낮고 버스트성이 강하면 호스팅 API가 더 효율적일 수 있으며, 모델 규모와 인프라 여력도 함께 고려해야 한다.
4. 5:19
   워크숍 구성과 Kubernetes 환경 워크숍에서는 인프라 스택, units와 memory budget, prefill·decode·KV cache, dense model과 mixture of experts를 차례로 다룬다. 참가자별 namespace에 Jupyter notebook, vLLM 엔드포인트, 에이전트가 배치된 Kubernetes 환경에서 성능을 반복 최적화한다.
5. 9:03
   vLLM, 배칭, 서비스 지표 추론 엔진으로 vLLM을 사용하며, continuous batching과 paged attention이 생산 환경에서 큰 장점이라고 설명한다. 성능을 볼 때는 throughput, time to first token, KV cache 활용률, QEP 같은 지표를 함께 봐야 한다.
6. 11:54
   노트북 접속 QR 코드로 워크숍용 Jupyter notebook과 리포지토리에 접속하는 방법을 안내한다. 각 실습에 필요한 의존성이 이미 로드되어 있어 바로 따라가며 실험할 수 있다.
7. 13:09
   첫 번째 모듈: 추론 연결 Qwen 3 4B 모델로 vLLM 엔드포인트에 연결하고 첫 에이전트를 만들어 본다. vLLM은 인증은 지원하지만 권한·rate limiting은 약하므로 KServe나 gateway 계층이 필요하다는 점도 짚는다.
8. 16:26
   모델 정밀도와 첫 요청 현재 모델은 BF16으로 4 billion parameters가 약 8GB를 차지한다고 정리한다. 요청이 클러스터 내부에서 처리되므로 공용 API보다 빠르고, 첫 응답을 통해 모델과 서빙 구성을 확인한다.
9. 17:36
   스트리밍 토큰 지연시간 측정 스트리밍 응답을 기준으로 time to first token과 token당 지연을 계산한다. CPU는 이 환경에서 감당이 어렵고, GPU는 병렬 계산 덕분에 같은 작업을 훨씬 빠르게 처리한다는 차이를 수치로 보여준다.
10. 20:51
    에이전트 시작과 메트릭 점검 도구가 없는 간단한 에이전트를 먼저 만들고, system prompt와 응답을 확인한다. 이후에는 Prometheus, Grafana, Langfuse 같은 관측성 도구로 단계별 latency와 token 사용량을 추적해야 실제 병목을 찾을 수 있다.
11. 25:13
    워크로드 비용과 실행 시간 비교 호스팅 과금과 전용 GPU 비용을 토큰 사용량 기준으로 비교해 rent vs own 의사결정을 설명한다. 장기적으로는 SG lang, TensorRT, llama CPP처럼 워크로드에 맞는 런타임도 함께 검토해야 한다.
12. 28:22
    두 번째 모듈: 단위와 메모리 예산 모델 가중치가 차지하는 메모리와 KV cache에 남는 공간을 분리해서 생각해야 한다. 프롬프트, 시스템 프롬프트, tool call이 모두 KV cache 예산을 소모하므로, 실제로 얼마나 많은 컨텍스트를 담을 수 있는지 계산하는 것이 핵심이다.
13. 30:38
    모델 파일과 설정 Hugging Face에서 받는 config.json과 safetensors가 각각 모델 설정과 가중치를 담당한다고 설명한다. 레이어 수, attention head 수, vocabulary size 같은 설정은 모델 동작을 정의하지만 임의 변경은 불가능하며, 대신 fine-tuning이나 양자화를 고려해야 한다.
14. 33:26
    가중치 크기, 대역폭, KV 용량 BF16과 FP8의 메모리 사용량 차이를 계산해, GPU에서 남는 공간이 KV cache와 처리량을 좌우한다는 점을 보여준다. 대역폭과 roofline 관점에서 어느 지점에서 GPU가 포화되는지도 함께 따져봐야 한다.
15. 36:45
    세 번째 모듈: prefill, decode, 캐싱 prefill은 첫 토큰이 나오기까지의 구간이고, decode는 그 뒤의 토큰 생성 구간이라는 점을 다시 정리한다. naive 방식보다 KV cache 기반 처리가 병렬성과 재사용 면에서 효율적이며, 그래프 도구로 이를 관찰할 수 있다.
16. 39:32
    KV cache 사용량 측정과 점검 KV caching을 적용했을 때 time to first token과 decode 지연이 어떻게 바뀌는지 측정한다. 요청 크기를 늘리면서 peak usage와 종료 후 usage를 확인해 실제 메모리 압박이 어디서 생기는지 살핀다.
17. 40:44
    콜드와 웜 prefix 캐싱 prompt caching과 prefix caching을 구분해 설명하면서, 반복 호출이 많은 서비스에서는 비용 절감 효과가 크다고 짚는다. 같은 접두사를 재사용하면 응답 시간이 크게 줄어들 수 있어 실무에서 체감 효과가 크다.
18. 41:53
    네 번째 모듈: Dense 모델과 전문가 모델 Dense model은 전체 가중치를 매번 사용하지만, mixture of experts는 일부 expert만 활성화해 더 적은 바이트로 추론한다. decode는 메모리 병목이 심하므로, 모델 구조 선택이 처리량과 지연에 직접 영향을 준다.
19. 45:38
    추론 토큰과 성능 한계 Thinking을 켜면 reasoning token이 크게 늘어나며, tool call이 많은 에이전트일수록 그 영향이 두드러진다. prefill과 decode를 분리해 보면 prefill은 비교적 최적화 여지가 있지만, decode는 GPU 메모리 한계에 더 직접적으로 묶인다.
20. 48:19
    Omer의 최적화 워크숍 이후 파트에서는 quantization, speculative decoding, vLLM 설정 튜닝, 평가 프레임워크를 집중적으로 다룬다. 목표는 특정 워크로드에 맞는 구성값을 찾는 것이며, 단순한 이론보다 실측 결과를 기준으로 판단하는 방식이다.
21. 49:55
    다섯 번째 모듈: 양자화 선택 BF16, FP8, INT4, AWQ, GPTQ, NVFP4 등 다양한 양자화 방식을 비교한다. 핵심 목적은 모델 크기를 줄여 KV cache 여유를 확보하고, 메모리 이동을 줄여 decode 성능을 높이는 데 있다.
22. 53:08
    실제 워크로드 품질 점검 양자화는 성능을 올리지만 JSON 손상, 함수 호출 실패, 추론 저하 같은 부작용이 생길 수 있다. 그래서 반드시 자기 워크로드에 맞는 eval을 먼저 준비하고, 변경 전후를 비교해야 한다.
23. 54:03
    기준 부하 테스트와 동시성 동시성 1, 32, 64 등으로 부하를 걸어 throughput과 time to first token을 비교한다. 32와 64 사이에서 지연이 크게 튀는 지점은 현재 설정에서 사실상 한계에 가까운 신호로 해석할 수 있다.
24. 56:34
    Kubernetes 모델 배포 변경 vlm.yaml에서 BF16 모델을 FP8 모델로 바꾸고, 필요한 플래그를 조정해 배포를 롤아웃한다. dynamic quantization처럼 일부만 양자화하는 방식도 가능하며, 하드웨어가 FP8을 제대로 가속하는지 확인해야 한다.
25. 1:03:12
    FP8 성능 비교 FP8로 바꾼 뒤 같은 부하 테스트를 다시 돌려 concurrency 1과 고동시성 구간 모두에서 토큰 처리량이 개선되는지 확인한다. 같은 품질을 유지하면서도 throughput이 눈에 띄게 오를 수 있다는 점이 핵심이다.
26. 1:05:09
    여섯 번째 모듈: 추측 디코딩 작은 draft model이 미리 여러 토큰을 생성하고, 메인 모델이 이를 검증하는 방식으로 추론 속도를 높이는 기법을 다룬다. 다만 acceptance rate가 낮으면 오히려 성능이 떨어질 수 있어 모델 조합과 생성 토큰 수를 신중히 맞춰야 한다.
27. 1:11:05
    초안 모델 설정 vLLM의 speculative config로 0.6 billion parameter draft model과 생성 토큰 수를 설정한다. draft token 수, GPU 메모리 여유, 모델 호환성에 따라 결과가 크게 달라지므로 여러 값으로 실험해야 한다.
28. 1:15:14
    가속 대신 느려진 경우 이번 실습에서는 speculative decoding을 켰더니 오히려 throughput이 급감하고 latency가 늘었다. 원인은 낮은 acceptance rate, 과도한 draft token 수, 스케줄링, 그리고 draft 모델이 메인 모델과 잘 맞지 않는 점으로 설명된다.
29. 1:18:58
    기준선으로 복귀하고 호환성 논의 draft와 main model의 정밀도 불일치, 잘못 훈련된 draft model, 용도별 호환성이 성능을 크게 좌우한다. 실무에서는 모델과 함께 제공되는 drafter를 우선 쓰고, use case에 맞게 acceptance rate를 반드시 확인해야 한다.
30. 1:26:38
    일곱 번째 모듈: 포화도와 서빙 플래그 GPU를 최대한 오래, 최대한 바쁘게 돌리는 saturation 관점에서 서빙 설정을 조정한다. throughput이 더 이상 늘지 않는 지점과 latency가 급격히 나빠지는 지점 사이의 균형점을 찾는 것이 목표다.
31. 1:33:10
    노트북 장애 복구 실습 중 클러스터나 노트북이 비정상 상태가 되어도, 이전 부하 테스트 결과를 바탕으로 해석은 계속할 수 있다. 핵심은 concurrency 32 근처가 현재 환경의 성능 경계였다는 점과, 이를 기준으로 다음 튜닝을 설계하는 것이다.
32. 1:35:48
    여덟 번째 모듈: 튜닝과 평가 한 번에 하나의 플래그만 바꾸고, 변경마다 부하 테스트를 돌려 결과를 비교하는 방법론을 제시한다. GPU memory utilization, max num sequences, model length, batch tokens 같은 핵심 설정을 실측 기반으로 조정해야 한다.
33. 1:41:02
    워크숍 자료와 런타임 질문 QR 코드로 슬라이드와 리포지토리를 받아 직접 실험할 수 있도록 안내한다. 또한 단일 에이전트인지, 병렬 에이전트인지, speculative decoding을 쓸지에 따라 Olama, llama CPP, vLLM, SG lang 중 어떤 런타임이 적절한지 질문에 답한다.
34. 1:44:13
    시퀀스 한계 올리기 max_num_sequences를 32에서 128로 올려 더 많은 요청을 동시에 처리하도록 조정한다. 병목 지점을 찾고, 그 병목에 대응하는 플래그를 하나씩 바꾸며, 포화점과 지연의 균형을 다시 맞추는 방식이 반복된다.
35. 1:47:13
    처리량과 지연시간 재비교 설정 변경 후 concurrency 64에서 throughput이 더 오르고 latency가 크게 줄어든 것을 확인한다. 다만 이번 비교는 다시 full precision 모델 기준으로 돌아왔기 때문에, 정밀도 변화도 함께 해석해야 한다.
36. 1:49:07
    최종 주의사항과 마무리 양자화, speculative decoding, sequence 제한, GPU 메모리 활용률처럼 조정 가능한 레버가 많지만, 모든 변화는 반드시 자기 워크로드의 eval로 검증해야 한다. 결국 전용 GPU와 서빙 설정을 얼마나 잘 맞추느냐가 에이전트의 비용과 성능을 결정한다.

실무 인사이트

• 에이전트 추론 최적화는 모델 자체보다도 KV cache, 동시성, 배치, 메모리 예산 같은 서빙 변수에서 체감 차이가 크게 난다.
• 양자화와 speculative decoding은 무조건 성능 향상이 아니라서, 반드시 실제 워크로드 기준의 eval과 부하 테스트를 먼저 붙여야 한다.
• 전용 GPU를 쓸지 여부는 비용만이 아니라 데이터 통제, 규제, SLA, 트래픽 패턴까지 함께 보고 결정하는 것이 가장 실무적이다.