23.3 Text Generation Inference（TGI）部署方案

在前两节中，我们分别介绍了高吞吐推理框架 vLLM（23.1）和 NVIDIA 官方方案 TensorRT-LLM（23.2）。本节聚焦由 Hugging Face 推出的 Text Generation Inference（TGI），它是在生产环境中部署开源大模型最为广泛使用的方案之一，尤其适合已经深度使用 Hugging Face 生态的团队。

一、TGI 是什么？定位与核心价值

TGI 是一个用 Rust + Python 开发的、专为大语言模型推理和服务而设计的框架。它的核心价值有三点：

深度兼容 Hugging Face 模型：几乎任何 transformers 库支持的模型，都可通过 TGI 一键部署。
生产级特性开箱即用：连续批处理（Continuous Batching）、张量并行（Tensor Parallelism）、量化、KV 缓存优化、流式输出、安全路由等，全部内置。
协议标准化：原生支持 OpenAI 消息格式，可直接替换 OpenAI API。

与 vLLM 和 TensorRT-LLM 的定位差异：

vLLM 追求极致吞吐，尤其适合大规模并发；
TensorRT-LLM 追求极致硬件效率，适合 NVIDIA 卡重度优化；
TGI 更偏向“一站式的开发者友好”：模型兼容性最广、Docker 部署最简、与 Hugging Face Hub 无缝集成。

二、核心能力速览

| 特性 | 说明 |
|------|------|
| 连续批处理 | 动态合并请求，提高 GPU 利用率 |
| 张量并行 | 自动将模型分片到多 GPU，无需改代码 |
| 量化支持 | GPTQ、AWQ、bitsandbytes（EETQ）、FP8 等 |
| KV 缓存优化 | Flash Attention v1/v2、Paged Attention |
| 流式输出 | SSE 协议，支持 Token-by-Token 返回 |
| 水印 | 可对生成内容添加版权标记 |
| 指南/语法约束 | 可强制输出 JSON、特定正则格式 |
| 推理参数动态控制 | 客户端可覆盖 temperature、top_p、max_tokens 等 |

三、部署实战

3.1 环境准备

TGI 提供官方 Docker 镜像，推荐在支持 CUDA 的 Linux 服务器上运行。最低环境要求：

GPU：NVIDIA 计算能力 ≥ 7.0（V100 及以上），更推荐 A100/H100
CUDA：≥ 11.8
Docker：≥ 20.10，需安装 NVIDIA Container Toolkit

镜像拉取示例（以最新稳定版为例）：

model=meta-llama/Llama-3.1-8B-Instruct
volume=$PWD/data  # 共享内存挂载点

docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data \
  ghcr.io/huggingface/text-generation-inference:2.0.4 \
  --model-id $model

注意：--shm-size 必须足够大（建议 ≥ 1g），否则连续批处理下的共享内存会爆。

3.2 启动参数速查

常用启动参数及含义：

| 参数 | 功能 | 示例值 |
|------|------|--------|
| --model-id | Hugging Face 模型名称或本地路径 | mistralai/Mistral-7B-Instruct-v0.3 |
| --num-shard | 张量并行 GPU 数量 | 4 |
| --max-input-length | 最大输入 Token 数 | 4096 |
| --max-total-tokens | 输入+输出最大 Token 总数 | 8192 |
| --max-batch-prefill-tokens | 预填充阶段最大 Token 数（控制并发） | 16384 |
| --quantize | 量化方法 | bitsandbytes-nf4、gptq、awq |
| --dtype | 推理精度 | float16、bfloat16 |
| --trust-remote-code | 执行自定义模型代码（仅限受信源） | 添加此 flag |
| --max-concurrent-requests | 最大并发请求数（默认128） | 256 |

一条生产级 Llama-3.1-70B 部署命令示例（4×A100）：

docker run --gpus all --shm-size 32g -p 8080:80 \
  --name tgi-70b \
  -e HF_TOKEN=$HUGGINGFACE_TOKEN \
  ghcr.io/huggingface/text-generation-inference:2.0.4 \
  --model-id meta-llama/Llama-3.1-70B-Instruct \
  --num-shard 4 \
  --max-total-tokens 8192 \
  --max-batch-prefill-tokens 24576 \
  --quantize awq \
  --dtype float16

3.3 量化配置建议

| 量化方法 | 适用显卡 | 精度损失 | 吞吐提升 |
|----------|----------|----------|----------|
| bitsandbytes-nf4 | 消费级 GPU | 中等 | 显存压缩至约 1/4 |
| gptq | 数据中心 GPU | 较小 | 显存减少约 1/3 |
| awq | 推荐 | 小 | 显存减少约 1/2，速度提升 1.2~1.5x |
| 不量化（FP16/BF16） | 显存充裕时 | 无 | 最优质量 |

实用建议：若需在单张 A100（80GB）上跑 70B 模型，必须使用 4-bit 量化。AWQ 在速度与精度间平衡最好，优先选择。

四、客户端调用

TGI 服务启动后，通过 REST API 访问，兼容 OpenAI Chat Completion 格式（/v1/chat/completions）和原生 /generate 接口。

OpenAI 风格调用（Python）：

import openai

client = openai.Client(
    base_url="http://localhost:8080/v1/",
    api_key="dummy"
)

response = client.chat.completions.create(
    model="tgi",
    messages=[{"role": "user", "content": "解释量子计算"}],
    temperature=0.7,
    max_tokens=512,
    stream=True
)
for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end='')

原生 /generate 格式（支持更细粒度控制）：

curl 127.0.0.1:8080/generate \
  -X POST \
  -d '{
    "inputs":"Who are you?",
    "parameters":{
      "max_new_tokens":200,
      "temperature":0.3,
      "stop":["\nUser:"]
    }
  }' \
  -H 'Content-Type: application/json'

五、性能调优与常见问题

5.1 吞吐优化要点

合理设置 --max-batch-prefill-tokens：该值越大，可同时处理的请求越多，但首次 Token 延迟（TTFT）也会升高。可通过实验找到符合 P99 延迟要求的最大值。
预分配足够的共享内存：TGI 使用共享内存进行请求队列通信，建议分配 16GB 以上。
避免不必要的日志和认证：在生产环境关闭 --json-output 以外的冗余日志；认证建议通过反向代理增加 JWT，而非让 TGI 处理。

5.2 常见故障排查

| 现象 | 可能原因 | 解决方案 |
|------|----------|----------|
| CUDA out of memory | 显存不足 | 增加 --num-shard 或启用量化 |
| 高延迟下吞吐很低 | 连续批处理未生效 | 检查 --max-batch-prefill-tokens 是否过小 |
| 模型权重下载失败 | 认证问题 | 设置 HF_TOKEN 环境变量；使用国内镜像 |
| 返回内容截断 | max_new_tokens 或 stop 触发 | 检查客户端参数或服务端默认值 |

5.3 生产化部署最佳实践

使用反向代理（如 Nginx）添加 HTTPS、限流、认证和访问日志。
监控指标：TGI 内置 Prometheus 指标端点（/metrics），集成 Grafana 面板监控吞吐、延迟、显存、队列长度等。
健康检查：定期请求 /health 端点，自动重启异常容器。
日志管理：将 TGI 日志输出到集中日志系统，注意不要输出用户请求内容以保证隐私安全。

六、TGI vs vLLM：选型速览

| 维度 | TGI | vLLM |
|------|-----|------|
| 模型兼容 | 极广（所有 Hugging Face 模型） | 较广（需内核适配，常用模型都支持） |
| 吞吐量 | 优 | 通常更高（尤其大规模并发） |
| 部署难度 | 极低（Docker 一键） | 较低（pip install + 少量配置） |
| 量化支持 | 全面 | 全面（含 GPTQ/AWQ/SqueezeLLM） |
| 社区生态 | Hugging Face 背靠，企业支持 | 开源社区活跃，迭代极快 |
| OpenAI 兼容 | 完美 | 基本兼容 |

场景建议：

如果你已经用 Hugging Face 模型，需要最快速度上线，且对模型兼容性要求极高 → TGI；
如果你追求裸机极致吞吐，且团队有较强的工程优化能力 → vLLM；
如果你的 GPU 集群完全为 NVIDIA 最新硬件，且需要 INT4 推理极致化 → TensorRT-LLM。

七、小结

TGI 将 Hugging Face 的无缝模型生态与生产级推理服务集于一身，是许多企业部署开源大模型的首选“标准答案”。它不一定是吞吐最高的，但一定是最省心的方案之一。配合 23.1 节和 23.2 节中学到的对比视角，你现在应该清楚如何根据模型规模、并发量、硬件和团队技术栈，在 vLLM、TensorRT-LLM 以及 TGI 之间做出务实选择。