Tokens Per Second (TPS) measures the rate at which an inference engine generates output tokens during the decoding phase, excluding the Time To First Token (TTFT) latency. It directly reflects the computational throughput of the serving stack, influenced by factors such as model quantization, KV cache efficiency, and batching strategies. For enterprise deployments, high TPS is critical to maintaining interactive user experiences and maximizing the utilization of expensive GPU resources.
Glossary
Tokens Per Second (TPS)

What is Tokens Per Second (TPS)?
Tokens Per Second (TPS) is the primary metric for measuring the raw generation speed of a language model inference server, quantifying how many discrete text units are produced each second after the initial response latency.
Achieving optimal TPS requires a combination of hardware-aware kernels like Flash Attention and serving engines such as vLLM that implement continuous batching and PagedAttention. Unlike TTFT, which measures initial responsiveness, TPS defines the perceived speed of content streaming. This metric is often inversely correlated with model size and precision, making it a key optimization target when balancing output quality against infrastructure cost in self-hosted environments.
Key Factors Influencing TPS
Tokens Per Second (TPS) is not a static benchmark; it is a dynamic metric shaped by the interplay of hardware capability, model architecture, and inference software optimization. Understanding these variables is essential for capacity planning in self-hosted deployments.
Model Architecture & Parameter Count
The structural complexity of the model directly dictates computational cost per token. Mixture of Experts (MoE) architectures achieve higher TPS by activating only a fraction of total parameters per token, while dense models scale compute linearly with size. Grouped-Query Attention (GQA) reduces KV cache bandwidth, accelerating generation compared to full Multi-Head Attention. Smaller parameter counts generally yield higher TPS, but quantization can make larger models viable on fixed hardware.
Quantization Precision
Reducing numerical precision from 16-bit to 4-bit integers using formats like GGUF dramatically decreases memory bandwidth pressure and compute requirements. This allows larger models to fit entirely in GPU VRAM or even run on CPU with acceptable TPS. QLoRA enables fine-tuning at this precision. The trade-off is a minor perplexity increase for a substantial throughput gain, making quantization the single most impactful software lever for TPS on consumer or edge hardware.
Inference Engine & Batching Strategy
The serving software stack is critical. vLLM utilizes PagedAttention to manage KV cache memory with near-zero fragmentation, enabling high Continuous Batching efficiency. Llama.cpp is heavily optimized for CPU and hybrid GPU inference on personal devices. NVIDIA Triton Inference Server provides dynamic batching and model ensembles for enterprise deployments. The choice of engine and its ability to overlap computation with memory transfers directly governs achievable TPS under concurrent load.
Hardware Memory Bandwidth
For token generation, performance is often memory-bound rather than compute-bound. The rate at which model weights can be streamed from VRAM or system RAM to the processing units is the primary bottleneck. High-bandwidth memory (HBM) on data-center GPUs provides a massive advantage. On consumer hardware, ensuring the model fits entirely in fast GPU memory avoids the catastrophic TPS drop caused by offloading layers to slower system RAM or swap.
KV Cache Management
The KV Cache stores attention keys and values to avoid recomputation for each new token. Its size grows linearly with batch size and sequence length. Inefficient memory allocation leads to fragmentation and waste, capping the number of concurrent sequences. PagedAttention solves this by allocating cache in blocks, while Prefix Caching reuses the cache for identical prompt preambles. Effective cache management directly increases the maximum batch size and thus total system TPS.
Sequence Length & Generation Profile
TPS is measured on output tokens, but the prompt's length impacts the prefill phase and initial memory allocation. A very long prompt with a short generation will show a lower average TPS if prefill time is included. Speculative Decoding uses a smaller draft model to propose tokens rapidly, which the large model verifies in parallel, effectively decoupling TPS from the large model's inherent latency for low-batch, interactive scenarios.
Frequently Asked Questions
Understanding Tokens Per Second (TPS) is critical for capacity planning in sovereign AI deployments. These answers clarify how to measure, interpret, and optimize generation speed on self-hosted infrastructure.
Tokens Per Second (TPS) is the primary throughput metric measuring the rate at which an inference server generates new output tokens after the Time To First Token (TTFT) latency has elapsed. It is calculated by dividing the total number of output tokens generated by the total generation time, excluding the prefill phase. For a precise measurement, the clock starts ticking the moment the first token is streamed back to the client and stops when the end-of-sequence token is emitted. In a self-hosted environment, TPS is typically measured using benchmarking tools that simulate concurrent user load against an endpoint. It is crucial to distinguish between prefill throughput (processing the input prompt) and decode throughput (generating the output), as TPS specifically quantifies the latter. This metric directly dictates the user-facing responsiveness and the maximum number of concurrent sessions a specific GPU cluster can sustain before latency degrades unacceptably.
TPS vs. Other Inference Metrics
How Tokens Per Second compares to other critical serving metrics for self-hosted LLM deployments
| Metric | Tokens Per Second (TPS) | Time To First Token (TTFT) | Throughput (Requests/Sec) |
|---|---|---|---|
Primary Focus | Output generation speed after first token | Initial response latency | System-level request handling capacity |
Measurement Unit | Tokens per second | Milliseconds or seconds | Requests per second |
Directly Affected By | Model size, quantization, GPU compute, batch size | Prompt processing, model loading, network latency | Batching efficiency, concurrency, queue management |
User Experience Impact | Perceived reading speed and fluidity | Perceived responsiveness and interactivity | System scalability under load |
Optimization Techniques | Quantization, Flash Attention, Tensor Parallelism, Speculative Decoding | Prefix Caching, prompt compression, hardware acceleration | Continuous Batching, Paged Attention, request queuing |
Relevance to Self-Hosting | Critical for cost efficiency and user satisfaction | Critical for interactive applications | Critical for production serving at scale |
Measurement Scope | Per-request generation phase only | Per-request prefill and scheduling phase | System-wide across concurrent requests |
Trade-off Relationship | Often inversely related to TTFT under high load | Can increase if maximizing TPS via large batches | Can decrease if prioritizing low TTFT per request |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding Tokens Per Second (TPS) requires context within the broader inference optimization landscape. These concepts directly interact with and influence the throughput metrics of a self-hosted deployment.
Time To First Token (TTFT)
The latency metric measuring the delay between submitting a prompt and receiving the first output token. While TPS measures generation speed after the first token, TTFT captures the prefill phase where the model processes the entire input prompt. A high TTFT can make a system feel sluggish even if TPS is high. Optimizing TTFT often involves prefix caching and efficient attention kernels like Flash Attention.
Continuous Batching
A serving technique that maximizes GPU utilization by dynamically adding new sequences to a running batch without waiting for all sequences to complete. This directly increases aggregate TPS by preventing idle compute cycles. Unlike static batching, continuous batching allows high-priority requests to jump the queue, improving both throughput and latency under load. Implemented in engines like vLLM and NVIDIA Triton.
Model Quantization
A compression technique that reduces numerical precision of weights from FP16 to INT8 or INT4. Quantization decreases memory bandwidth pressure, allowing more data to move through the GPU per second. This often yields a 2-4x increase in TPS on the same hardware, though aggressive quantization may degrade output quality. Formats like GGUF are specifically designed for high-throughput quantized inference.
Speculative Decoding
An acceleration method that uses a small draft model to generate multiple candidate tokens quickly, which a larger target model then verifies in parallel. This can increase TPS by 2-3x without any loss in output quality, as the target model guarantees correctness. It trades a small amount of additional compute for dramatically faster wall-clock generation.
Tensor Parallelism
A distributed strategy that splits individual weight matrices across multiple GPUs to serve models too large for a single device. While it enables running massive models, it introduces inter-GPU communication overhead that can reduce per-device TPS. Efficient tensor parallelism requires high-bandwidth interconnects like NVLink to minimize this communication bottleneck.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us