TokenSpeed는 LightSeek가 공개한 LLM 추론 엔진이다. 목표는 TensorRT-LLM 수준의 성능과 vLLM 수준의 사용성을 결합해, 프로덕션 에이전틱 워크로드에서 높은 처리량과 낮은 오버헤드를 제공하는 것이다.
에이전틱 워크로드가 다른 이유
챗봇 서빙은 긴 대화 스트림을 안정적으로 처리하는 데 초점이 있다. 반면 에이전틱 워크로드는 짧은 호출, 도구 사용, 분기, 재시도, 병렬 작업이 많다. 이때 병목은 단순 토큰 생성 속도만이 아니라 요청 수명주기, KV 캐시 소유권, CPU 제어 평면 오버헤드, GPU 커널 스케줄링까지 확장된다.
TokenSpeed는 이 문제를 추론 엔진 내부 설계로 다룬다.
주요 구성 요소
| 계층 | 설명 |
|---|---|
| 모델링 레이어 | local-SPMD 설계와 정적 컴파일러로 병렬화 로직을 모듈 경계 배치 주석에서 생성 |
| 스케줄러 | C++ 제어 평면과 Python 실행 평면을 분리하고, 요청 수명주기와 KV 캐시 소유권을 FSM으로 표현 |
| 커널 | 플러그형 커널 레지스트리와 Blackwell용 MLA(Multi-head Latent Attention) 최적화 구현 |
| 엔트리포인트 | SMG 통합 AsyncLLM으로 CPU 측 요청 처리 오버헤드 축소 |
vLLM·TensorRT-LLM과의 위치
TokenSpeed의 포지셔닝은 명확하다. TensorRT-LLM은 하드웨어 최적화 성능이 강하고, vLLM은 개발자 사용성과 서빙 생태계가 강하다. TokenSpeed는 이 둘 사이에서 에이전트 호출 패턴에 특화된 런타임을 제공하려 한다.
특히 KV 캐시 재사용을 타입 시스템과 스케줄러 상태로 안전하게 통제한다는 점은 kv-caching과 inference-caching에서 다루는 추론 캐시 최적화의 런타임 구현 사례로 볼 수 있다.
현재 상태
저장소의 README 기준 TokenSpeed는 미리보기(preview) 릴리스다. Kimi K2.5 on B200, TokenSpeed MLA on B200 결과를 재현하기 위한 버전이며, 프로덕션 배포용으로 권장되지는 않는다.
진행 중인 작업은 다음과 같다.
- 모델 커버리지: Qwen 3.6, DeepSeek V4, MiniMax M2.7
- 런타임 기능: PD, EPLB, KV store, Mamba cache, VLM, metrics
- 플랫폼 최적화: Hopper, MI350 등 추가 하드웨어 최적화
적합한 사용자
- B200 등 최신 GPU에서 LLM 추론 성능을 극단적으로 끌어올리려는 인프라 팀
- 도구 호출과 짧은 반복 호출이 많은 에이전트 서비스를 운영하는 팀
- vLLM 사용성은 유지하되 런타임 스케줄링·커널 최적화를 더 깊게 다루려는 연구자
- Kimi, DeepSeek, Qwen 계열 대형 모델의 서빙 최적화를 실험하는 엔지니어
관련 문서
- llm-inference — 토큰화부터 KV 캐시까지 LLM 추론 과정
- kv-caching — LLM 추론 속도를 높이는 KV 캐싱
- inference-caching — LLM 비용과 지연시간을 줄이는 캐시 전략
- self-hosted-llm — 로컬·온프레미스 LLM 운영의 실제 한계
- vllm-recipes — 하드웨어별·모델별 vLLM 실행 레시피
참고 자료
- lightseekorg/tokenspeed — GitHub 공식 저장소
- TokenSpeed Documentation — 공식 문서
- TokenSpeed Blog — LightSeek Blog