모델 벤치마크는 빠른데, 실제 에이전트 제품은 여전히 느리게 느껴지는 순간이 있다. 이유는 단순하다. 에이전트는 한 번 묻고 한 번 답하는 챗봇이 아니라, 디코딩하고, 분기하고, 도구를 호출하고, 긴 KV 캐시를 붙잡은 채 여러 턴을 오간다.
이 맥락에서 LightSeek Foundation의 TokenSpeed 공개는 "또 하나의 LLM 서빙 엔진" 이상의 의미가 있다. TokenSpeed는 오픈소스 LLM 추론 엔진으로, 에이전트 워크로드에서 TensorRT-LLM급 성능을 겨냥한다고 소개됐다1. 핵심 질문은 그래서 "vLLM보다 빠른가?"가 아니라 "어떤 종류의 느림을 겨냥하는가?"다.
속도 비교 전에 워크로드 모양을 먼저 봐야 한다
일반적인 LLM 서빙 벤치마크는 입력 길이, 출력 길이, 동시성, 토큰 처리량을 깔끔하게 고정한다. TensorRT-LLM의 공식 벤치마크 도구도 synthetic dataset, in-flight batching, 엔진 빌드, 처리량/지연시간 측정 흐름을 제공한다2. 이런 방식은 재현성과 비교 가능성이 높다.
하지만 에이전트 트래픽은 덜 깔끔하다. 코딩 에이전트는 긴 컨텍스트를 유지하고, 짧은 디코딩을 여러 번 반복하며, 중간에 툴 호출로 끊긴다. 중국 매체가 정리한 LightSeek 측 설명에 따르면 TokenSpeed 평가는 SWE-smith 기반 코딩 에이전트 트레이스에 맞춰졌고, 단일 사용자 TPS 하한을 유지하면서 GPU당 TPM을 높이는 방향으로 설계됐다3.
여기서 중요한 실무적 함의는 명확하다. 만약 당신의 서비스가 "긴 프롬프트 하나 넣고 긴 답변 하나 받는 API"라면 TokenSpeed의 장점이 크게 드러나지 않을 수 있다. 반대로 세션이 길고, 사용자당 지연시간 하한이 중요하고, speculative decoding이나 KV 캐시 재사용이 핵심이라면 평가해볼 이유가 생긴다.
vLLM, TensorRT-LLM, TokenSpeed는 서로 다른 쪽으로 당긴다
vLLM은 범용성의 기준점에 가깝다. PagedAttention, continuous batching, OpenAI 호환 API, 다양한 모델 지원 덕분에 프로덕션 API 서버의 기본 선택지로 자주 언급된다4. 빠르게 붙이고 운영하기 좋다는 뜻이다.
TensorRT-LLM은 반대로 NVIDIA 하드웨어에서 극한 성능을 끌어내는 쪽에 무게가 있다. 엔진 빌드, 정밀도 설정, GPU 상태 관리까지 벤치마크 조건을 세밀하게 맞추는 세계다2. 성능은 강하지만 운영과 디버깅 난도는 낮지 않다.
TokenSpeed의 흥미로운 지점은 이 둘 사이가 아니라, 다른 축을 잡는 데 있다. 공개 자료에 따르면 TokenSpeed는 local-SPMD 모델링, 정적 컴파일 기반 collective 생성, C++ 제어 평면과 Python 실행 평면 분리, FSM 기반 KV 캐시 소유권 관리, 플러그형 커널 레지스트리를 내세운다5. 이는 "더 빠른 큐"보다 "에이전트 요청 생명주기 자체를 더 엄격하게 모델링하겠다"는 방향에 가깝다.
다만 이 선택은 공짜가 아니다. 정적 계획과 컴파일러 중심 설계는 예측 가능한 패턴에는 강하지만, 모델·커널·하드웨어 조합이 바뀔 때 검증 부담이 커질 수 있다. 또한 현재 공개 성능 서사는 Blackwell/B200과 MLA 경로에 강하게 기대고 있다. 다른 GPU 세대나 범용 모델 서빙에서 같은 이점이 난다고 단정하긴 이르다.
지금 도입할 기술인가, 평가할 기술인가
현재 TokenSpeed는 "검토 대상"에 가깝다. 일부 자료는 preview 성격을 명시하며, PD 분리, KV store, Mamba cache, VLM, metrics, Hopper·MI350 최적화 등이 아직 진행 중이라고 정리한다5. 운영 안정성, 관측성, 장애 대응까지 필요한 팀이라면 바로 교체할 이유는 약하다.
그래도 평가할 팀은 있다. 다음 신호가 있다면 PoC 가치가 있다.
평균보다 p95/p99 토큰 지연시간이 더 큰 문제다.
요청이 긴 세션과 짧은 디코딩 burst로 쪼개진다.
KV 캐시 재사용, 소유권, eviction 이슈가 장애 원인이다.
B200/Blackwell급 인프라에서 에이전트 워크로드를 대량 서빙한다.
vLLM의 사용성은 좋지만 Python-side orchestration overhead가 눈에 보인다.
평가할 때는 headline tokens/sec만 보면 안 된다. 같은 모델, 같은 GPU, 같은 quantization, 같은 프롬프트/출력 분포에서 비교해야 한다. 특히 에이전트 제품이라면 synthetic 128:128보다 실제 trace replay가 중요하다. 측정 지표도 TTFT, TPS/user, TPM/GPU, p95 decode latency, tool-call 이후 재개 지연, KV cache hit/reuse 안정성까지 봐야 한다.
결론적으로 TokenSpeed는 "챗봇 시대의 추론 엔진 경쟁"보다 "에이전트 시대의 런타임 경쟁"에 가깝다. 지금 당장 대부분의 팀이 vLLM을 버릴 이유는 없다. 하지만 코딩 에이전트처럼 긴 컨텍스트와 반복 디코딩이 비용의 중심이 되는 팀이라면, 다음 병목이 모델이 아니라 스케줄러와 KV 캐시라는 사실을 TokenSpeed가 꽤 선명하게 보여준다.
참고
2TensorRT-LLM Benchmarking -- TensorRT-LLM
45 Best Open-Source LLM Inference Engines in 2026 (vLLM, Ollama, llama.cpp & More) - DEV Community
5TokenSpeed: Best LLM Inference Engine for Agentic Teams in 2026
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.