개요
TokenSpeed는 프로덕션급 에이전트 워크로드를 위한 오픈 소스 LLM 추론 엔진으로, TensorRT-LLM 수준의 성능과 vLLM 수준의 사용 편의성을 모두 갖추고 있습니다. 이 아키텍처는 C++ 유한 상태 머신 제어 플레인과 Python 실행 플레인을 분리하여, 컴파일 시점에 KV 캐시와 요청 라이프사이클의 안전성을 보장합니다. 커널 시스템은 플러그 가능한 설계를 채택하고 있으며, Blackwell GPU에서 가장 빠른 MLA 구현 중 하나를 포함하고 있습니다.
README 미리보기
\n \n\n\nTokenSpeed is a speed-of-light LLM inference engine designed for **agentic workloads**, with TensorRT-LLM-level performance and vLLM-level usability. The goal is to be the most performant inference engine for production agentic workloads.\n\nCore components:\n\n- **Scheduler**: C++ control plane and Python execution plane. Request\n lifecycle, KV cache ownership, and overlap timing are encoded as a\n finite-state machine, with safe KV resource reuse enforced by the type system at compile time.\n- **Kernels**: pluggable, layered kernel system with a portable public API and\n a centralized registry including one of the fastest **MLA**\n (Multi-head Latent Attention) implementations on Blackwell for agentic workloads.\n- **Entrypoint**: SMG-integrated AsyncLLM for low-overhead CPU-side request\n handling.\n\n## Differentiation\n\nTokenSpeed takes a fundamentally different architectural approach from existing LLM inference engines. The **PyTorch Foundation highlighted these architectural differentiators** when [welcoming TokenSpeed](https://pytorch.org/blog/pytorch-ecosystem-landscape-q3-update/) to the PyTorch Ecosystem Landscape:\n\n> TokenSpeed is an open source LLM inference engine and the first to separate the control plane from the execution plane. The control plane is implemented in C++ as a finite-state machine, using the type system to enforce safe resource management, including request lifecycles and KV cache state, at compile time rather than runtime. The execution plane is implemented in Python, enabling fast iteration and lowering the cognitive load for researchers and engineers. This architecture combines strong correctness guarantees in the core scheduling system with the development velocity of a high-level execution layer.\n>\n> TokenSpeed also treats kernels as a first-class, modular subsystem, separating them from the core engine through a portable public API, centralized registry and selection model, and an extensible plugin mechanism
FAQ (2)
문제 해결triton 샘플링 백엔드를 사용할 때 n>1인 단일 요청이 동일한 completions를 반환하는 이유는 무엇인가요?
알려진 버그: parallel_sampling.py의 prepare_parallel_sampling_replica가 토큰화된 요청을 얕은 복사하고 rid만 교체하므로, n개의 모든 복제본이 동일한 SamplingParams와 시드를 공유합니다. triton 샘플러는 tl.randint(seed, offset)(ops/sampling/triton/gumbel.py)에서 노이즈를 유도하므로, 모든 복제본이 각 단계에서 동일한 토큰을 뽑습니다. 그러면서도 요청은 올바른 사용량 집계와 함께 HTTP 200을 반환하므로 조용한 실패(silent failure)가 됩니다. 해결 방법: (1) n: N인 하나의 요청 대신 n: 1인 N개의 개별 요청을 보내십시오. 요청별 샘플링은 서로 다른 완성을 생성하지만(온도 0.7 및 1.2에서 확인됨), prefill 공유와 배칭을 잃는 대가가 있습니다. (2) NVIDIA GPU에서는 기본값인 --sampling-backend flashinfer를 사용하십시오. 이 백엔드의 Philox RNG는 배치 행(curand_init(philox_seed, bx, ...))을 포함하므로 복제본이 자연스럽게 갈라집니다. 또한 비슷해 보이는 원인도 배제하십시오. 비NVIDIA 플랫폼에서는 백엔드가 기본적으로 greedy로 설정되어 temperature/top_p/top_k/seed를 무시하면서도 여전히 200을 반환합니다. curl http://<host>:<control-port>/get_server_info | grep sampling_backend로 활성 백엔드를 확인하십시오. 이는 GRPO 스타일 RL 롤아웃에서 중요한데, n>1인 동일한 완성들은 분산이 0인 어드밴티지를 생성하여 학습 신호가 사라지기 때문입니다.
문제 해결AMD gfx950에서 높은 동시성으로 서빙할 때, 일부 벤치마크 단계가 무작위로 ~1초씩 스톨되며 ~36% 더 느리게 실행되는 이유는 무엇인가요?
스톨은 시작 시점이 아닌 서빙 도중에 JIT 커널 컴파일이 발생하면서 유발됩니다. 두 가지 원인이 있습니다: (1) 스케줄러는 프롬프트를 최대 8192 토큰까지 prefill 배치로 집계하지만, 기본 prefill 그래프 캡처는 최대 2048 토큰까지만 커버하므로, 큰 prefill 배치는 캡처되지 않은 경로를 타게 되어 서빙 중에 커널을 컴파일하게 됩니다. (2) 어텐션 커널에는 warmup 중에 실행되지 않는 컴파일 타임 스페셜라이제이션이 많습니다. 해결 방법: 서버 측 prefill 그래프 캡처 상한을 스케줄러의 최대 prefill 배치 크기(예: 8192 토큰)에 맞춰 설정하여 컴파일이 요청 처리 중이 아닌 캡처 시점에 일어나도록 합니다. 추가로, 프로덕션에서 사용되는 어텐션 스페셜라이제이션을 커버하는 더 대표적인 warmup 요청을 실행하세요. 진단 팁: 특징적인 증상은 중앙값 TTFT와 TPOT은 변하지 않은 상태에서 TTFT 테일(p90/p99)에 고정된 ~0.9초 스톨이 나타나며, 모든 요청은 여전히 정상적으로 완료된다는 점입니다.