Table of Contents
๐ ไธญๆ็
Text Generation Inference (TGI) is the LLM inference server built by HuggingFace. When it was open-sourced in 2023, it was the first production-grade solution to package continuous batching, Flash Attention, and token streaming into a "start with Docker and go" experience. HuggingChat and OpenAssistant both ran on it.
On March 21, 2026, HuggingFace archived the TGI GitHub repository as read-only, entering maintenance mode โ accepting only minor bug fixes and documentation updates, with no new model architecture support. The official recommendation is to migrate to vLLM or SGLang.
This post covers TGI's architecture, capabilities, and limitations, and explains why understanding it still matters.
Architecture: Rust Router + Python Model Server
TGI's design splits into two layers:
Client request
โ
โโโโโโโโโโโโโโโโโโโโโโโโ
โ Rust Router โ โ HTTP/gRPC entry, request queuing,
โ (token streaming) โ continuous batching, SSE streaming
โโโโโโโโโโโโฌโโโโโโโโโโโโ
โ
โโโโโโโโโโโโโโโโโโโโโโโโ
โ Python Model Server โ โ Model loading, Flash Attention,
โ (transformers arch) โ quantization, tensor parallelism
โโโโโโโโโโโโโโโโโโโโโโโโ
The Rust Router handles HTTP connection management, request queuing, and Server-Sent Events (SSE) streaming. Using Rust instead of Python for the I/O layer yields low latency and high connection concurrency.
The Python Model Server handles model loading and actual inference. It directly depends on HuggingFace transformers model architecture definitions, enabling quick support for new models on HuggingFace Hub โ but also tightly coupling the core model code to transformers versions.
This architecture had one important downstream effect: TGI was the first open-source project to establish that "inference engines should use transformers model architectures directly." vLLM and SGLang later adopted the same approach rather than defining models from scratch. In its archival announcement, HuggingFace called this TGI's greatest legacy.
Core Inference Optimizations
Continuous Batching
TGI doesn't wait for a full batch before starting inference. New requests can join a running batch at any time, and completed requests can leave immediately. This keeps GPU utilization far higher than static batching, especially in production environments with uneven arrival times and variable output lengths.
Flash Attention and Paged Attention
TGI pioneered integrating Flash Attention (reducing attention memory and compute) and Paged Attention (splitting KV cache into pages to reduce fragmentation waste) in a production inference engine. Both techniques became standard features in every major inference engine that followed.
Speculative Decoding
Uses a small model to quickly generate candidate tokens, then has the large model verify them in a single pass. The official claim is ~2ร latency improvement. Actual results depend on alignment between the draft and target models โ if candidates are frequently rejected, overhead increases instead.
Structured Output (Guidance)
Grammar-based constraints force model output to conform to a JSON Schema, supporting function calling and tool use. TGI was an early adopter of this feature; vLLM and SGLang later implemented their own versions of structured output.
Quantization Support
TGI supports multiple quantization methods to run large models on smaller GPUs:
| Method | Bits | Description |
|---|---|---|
| bitsandbytes | 4-bit / 8-bit | Most common quantization library in the HuggingFace ecosystem |
| GPTQ | 4-bit | Post-training quantization, requires calibration dataset |
| AWQ | 4-bit | Activation-aware quantization, preserves important weight precision |
| EETQ | 8-bit | Fast int8 quantization |
| Marlin | 4-bit | GPTQ kernels optimized for NVIDIA GPUs |
| fp8 | 8-bit | FP8 format, natively supported on H100 |
The quantization trade-offs are the same as with other engines: lower bit counts mean smaller models and faster inference, but lower output quality. GPTQ and AWQ require pre-quantized model weights; bitsandbytes can quantize on the fly.
Deployment
Docker (Recommended)
The simplest launch method:
docker run --gpus all --shm-size 1g -p 8080:80 \
ghcr.io/huggingface/text-generation-inference:3.3.5 \
--model-id meta-llama/Llama-3.1-8B-Instruct
--shm-size 1g is required โ TGI uses shared memory for tensor parallelism; without it, the process crashes.
Multi-GPU tensor parallelism:
docker run --gpus all --shm-size 1g -p 8080:80 \
ghcr.io/huggingface/text-generation-inference:3.3.5 \
--model-id meta-llama/Llama-3.1-70B-Instruct \
--num-shard 4
Local Installation
Requires the Rust toolchain, Python 3.9+, and Protocol Buffers:
# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Install TGI
pip install text-generation-inference
# Launch
text-generation-launcher --model-id meta-llama/Llama-3.1-8B-Instruct
Local installation requires dealing with CUDA versions, protobuf compilation, and other dependencies. Docker is usually simpler.
HuggingFace Inference Endpoints
TGI is the default backend for HuggingFace's managed inference service. Clicking "Deploy โ Inference Endpoint" on HuggingFace Hub runs TGI underneath. However, HuggingFace has started offering vLLM as an alternative backend option.
API
Native API
# Text generation
curl http://localhost:8080/generate \
-X POST \
-H 'Content-Type: application/json' \
-d '{
"inputs": "Explain KV cache in three points",
"parameters": {
"max_new_tokens": 200,
"temperature": 0.7
}
}'
# Streaming output
curl http://localhost:8080/generate_stream \
-X POST \
-H 'Content-Type: application/json' \
-d '{
"inputs": "Write a short poem",
"parameters": {"max_new_tokens": 100}
}'
OpenAI-Compatible API
TGI provides a Messages API compatible with the OpenAI Chat Completion format:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8080/v1",
api_key="not-needed",
)
response = client.chat.completions.create(
model="meta-llama/Llama-3.1-8B-Instruct",
messages=[{"role": "user", "content": "What is continuous batching?"}],
temperature=0.3,
)
print(response.choices[0].message.content)
Monitoring
TGI includes a built-in Prometheus metrics endpoint and OpenTelemetry distributed tracing. Production deployments can connect directly to Grafana for request latency, queue length, and GPU utilization dashboards.
Hardware Support
TGI has one of the widest hardware coverage in this series:
| Hardware | Support Status |
|---|---|
| NVIDIA GPU (CUDA) | Full support, best performance |
| AMD Instinct (MI210, MI250) | Supported |
| AWS Inferentia | Supported |
| Intel GPU | Supported |
| Habana Gaudi | Supported |
| Google TPU | Supported |
| CPU | Partial support (poor performance) |
After entering maintenance mode, these hardware backends will not receive new optimizations. Support for newer hardware (AMD MI300X, NVIDIA B100/B200) will not be added to TGI.
Performance: Why It Was Overtaken
TGI led the open-source inference engine field in 2023โ2024. By 2025, vLLM and SGLang had clearly surpassed it in throughput and latency:
| Engine | LLaMA-2-7B Throughput (100 concurrent) |
|---|---|
| vLLM | ~15,243 tok/s |
| TGI | ~4,156 tok/s |
The 3.67ร gap comes from several factors:
- Deep PagedAttention integration: vLLM designed its entire scheduler around PagedAttention from day one; TGI grafted it on later
- Scheduler optimization: vLLM and SGLang's schedulers went through more optimization iterations for continuous batching
- Community scale: vLLM's contributor count and iteration speed far exceeded TGI's, so new optimization techniques (chunked prefill, prefix caching) reached vLLM first
HuggingFace acknowledged this. In late 2025, they tried making TGI support multiple backends โ using vLLM and TensorRT-LLM as inference backends while TGI kept only the router layer. Ultimately, HuggingFace chose to recommend migrating to vLLM/SGLang directly rather than continuing to maintain their own router.
Why It Still Matters
TGI is archived, but understanding it remains important for three reasons:
1. Existing Deployments Are Still Running
Many HuggingFace Inference Endpoints and enterprise internal deployments still run TGI. If you inherit a running inference service, there's a good chance it's TGI. Knowing its API format, configuration, and debugging methods is basic operational knowledge.
2. It Defined the Architectural Baseline for Successor Engines
Continuous batching, Flash Attention integration, OpenAI-compatible APIs, structured output, token streaming โ these features now considered "inference engine table stakes" were first packaged together by TGI. When reading vLLM or SGLang documentation, many concepts map directly to what TGI built first.
3. HuggingFace Ecosystem Integration
TGI has the deepest integration with HuggingFace Hub. Models download directly from Hub, Inference Endpoints deploy with one click, and transformers model architectures are reused directly. Even after migrating to vLLM, many concepts and workflows carry over from TGI.
Migration Path
HuggingFace's officially recommended migration targets:
| Requirement | Target Engine |
|---|---|
| General LLM serving, multi-hardware support | vLLM |
| Shared prefix reuse, high-throughput structured output | SGLang |
| Local development, consumer hardware | llama.cpp or MLX |
| Maximum performance on NVIDIA hardware | TensorRT-LLM |
The main migration work:
- API compatibility: TGI's native API (
/generate,/generate_stream) differs from vLLM/SGLang, but the OpenAI-compatible endpoint format is consistent โ if your client already uses/v1/chat/completions, switching backends only requires changingbase_url - Quantization formats: GPTQ and AWQ models work directly in vLLM; bitsandbytes quantization requires checking target engine support
- Docker images: Swap the image name and startup parameters;
--model-idis called--modelin vLLM - Monitoring: Prometheus metric names differ; Grafana dashboards need updating
Boundaries with Other Engines in This Series
- vLLM: TGI's direct successor. Higher throughput, larger community, faster new model support. Unless there's a specific reason (an existing TGI deployment not yet migrated), new projects should choose vLLM.
- SGLang: If workloads have substantial shared prefixes (multi-turn conversations, fixed system prompts), RadixAttention's performance advantage may exceed vLLM's.
- Triton Inference Server: Not an LLM-specific engine โ it's a multi-framework model server. Triton is the right layer when you need to serve both LLMs and traditional ML models simultaneously.
- Ray Serve: Handles service orchestration and cluster resources, a different layer from inference engines. Ray Serve can orchestrate vLLM or SGLang underneath.
Bottom Line
TGI's historical role is clear: it was the first open-source project to package the critical LLM inference optimizations (continuous batching, Flash Attention, Paged Attention) into a production-ready server. These techniques and design decisions were inherited and surpassed by vLLM and SGLang.
If you're deploying a new inference service today, you should not choose TGI. But if you're maintaining an existing TGI deployment, reading inference engine documentation, or trying to understand why vLLM is designed the way it is, TGI is where the story starts.
References
- TGI GitHub Repository (Archived) โ Source code, archived as read-only on 2026-03-21
- TGI Official Documentation โ Installation, configuration, API, and model support
- HuggingFace Blog: TGI Multi-Backend โ Technical details on TGI's attempt to integrate vLLM/TRT-LLM backends
- Flash Attention โ Dao et al.'s efficient attention implementation
- vLLM: PagedAttention โ Kwon et al., the paged KV cache later integrated by TGI
- vLLM Inference Engine (this site) โ Series #1, PagedAttention and continuous batching
- Self-Hosting with SGLang (this site) โ Series #3, RadixAttention and shared prefix reuse
Loading...