Text Generation Inference 文件
文字生成推論架構
加入 Hugging Face 社群
並獲得增強的文件體驗
開始使用
文字生成推論架構
本文件旨在透過描述各獨立組件之間的呼叫流程，來說明文字生成推論 (TGI) 的架構。
此處可查看高階架構圖
此圖清楚顯示了這些獨立組件：
- 路由器 (Router)，亦稱為
webserver，負責接收客戶端請求、對請求進行緩衝處理、建立批次 (batches)，並準備傳送給模型伺服器的 gRPC 呼叫。 - 啟動器 (Launcher) 是一個輔助工具，能夠啟動一個或多個模型伺服器（如果模型已分片），並使用相容的參數啟動路由器。
- 模型伺服器 (Model server)，負責接收 gRPC 請求並處理模型的推論。如果模型跨多個加速器（例如：多個 GPU）進行分片，模型伺服器分片可能會透過 NCCL 或同等技術進行同步。
請注意，對於其他後端（例如 TRTLLM），模型伺服器和啟動器是針對該後端特有的。
路由器和模型伺服器可以是兩台不同的機器，不需要部署在一起。
路由器 (The Router)
此組件是一個 Rust Web 伺服器二進位檔，接受使用自定義 HTTP API 以及 OpenAI Messages API 的 HTTP 請求。路由器接收 API 呼叫並處理「批次」(batches) 邏輯（批次處理介紹可參見此處）。它使用不同的策略來減少請求與回應之間的延遲，特別是針對解碼延遲進行優化。它會利用佇列、排程器和區塊分配器來實現這一點，並產生隨後發送到模型伺服器的批次請求。
路由器的命令列
路由器的命令列是傳遞參數給它的方式（它不依賴設定檔）。
Text Generation Webserver
Usage: text-generation-router [OPTIONS]
Options:
--max-concurrent-requests <MAX_CONCURRENT_REQUESTS>
[env: MAX_CONCURRENT_REQUESTS=] [default: 128]
--max-best-of <MAX_BEST_OF>
[env: MAX_BEST_OF=] [default: 2]
--max-stop-sequences <MAX_STOP_SEQUENCES>
[env: MAX_STOP_SEQUENCES=] [default: 4]
--max-top-n-tokens <MAX_TOP_N_TOKENS>
[env: MAX_TOP_N_TOKENS=] [default: 5]
--max-input-tokens <MAX_INPUT_TOKENS>
[env: MAX_INPUT_TOKENS=] [default: 1024]
--max-total-tokens <MAX_TOTAL_TOKENS>
[env: MAX_TOTAL_TOKENS=] [default: 2048]
--waiting-served-ratio <WAITING_SERVED_RATIO>
[env: WAITING_SERVED_RATIO=] [default: 1.2]
--max-batch-prefill-tokens <MAX_BATCH_PREFILL_TOKENS>
[env: MAX_BATCH_PREFILL_TOKENS=] [default: 4096]
--max-batch-total-tokens <MAX_BATCH_TOTAL_TOKENS>
[env: MAX_BATCH_TOTAL_TOKENS=]
--max-waiting-tokens <MAX_WAITING_TOKENS>
[env: MAX_WAITING_TOKENS=] [default: 20]
--max-batch-size <MAX_BATCH_SIZE>
[env: MAX_BATCH_SIZE=]
--hostname <HOSTNAME>
[env: HOSTNAME=] [default: 0.0.0.0]
-p, --port <PORT>
[env: PORT=] [default: 3000]
--master-shard-uds-path <MASTER_SHARD_UDS_PATH>
[env: MASTER_SHARD_UDS_PATH=] [default: /tmp/text-generation-server-0]
--tokenizer-name <TOKENIZER_NAME>
[env: TOKENIZER_NAME=] [default: bigscience/bloom]
--tokenizer-config-path <TOKENIZER_CONFIG_PATH>
[env: TOKENIZER_CONFIG_PATH=]
--revision <REVISION>
[env: REVISION=]
--validation-workers <VALIDATION_WORKERS>
[env: VALIDATION_WORKERS=] [default: 2]
--json-output
[env: JSON_OUTPUT=]
--otlp-endpoint <OTLP_ENDPOINT>
[env: OTLP_ENDPOINT=]
--otlp-service-name <OTLP_SERVICE_NAME>
[env: OTLP_SERVICE_NAME=]
--cors-allow-origin <CORS_ALLOW_ORIGIN>
[env: CORS_ALLOW_ORIGIN=]
--ngrok
[env: NGROK=]
--ngrok-authtoken <NGROK_AUTHTOKEN>
[env: NGROK_AUTHTOKEN=]
--ngrok-edge <NGROK_EDGE>
[env: NGROK_EDGE=]
--messages-api-enabled
[env: MESSAGES_API_ENABLED=]
--disable-grammar-support
[env: DISABLE_GRAMMAR_SUPPORT=]
--max-client-batch-size <MAX_CLIENT_BATCH_SIZE>
[env: MAX_CLIENT_BATCH_SIZE=] [default: 4]
-h, --help
Print help
-V, --version
Print version模型伺服器 (The Model Server)
模型伺服器是一個 Python 伺服器，能夠啟動並等待 gRPC 請求，載入指定的模型，執行分片以提供張量並行 (tensor parallelism)，並保持運作以等待新請求。模型伺服器支援使用 Pytorch 實例化並針對 CUDA/ROCM 推論進行主要優化的模型。
模型伺服器變體
Hugging Face 積極支援數種模型伺服器的變體。
- 預設情況下，模型伺服器會嘗試建置針對 NVIDIA GPU 和 CUDA 優化的伺服器。此版本的程式碼託管於主要的 TGI 儲存庫中。
- 一個針對 AMD 和 ROCm 優化的版本託管於主要的 TGI 儲存庫中。部分模型功能有所差異。
- 一個針對 Intel GPU 優化的版本託管於主要的 TGI 儲存庫中。部分模型功能有所差異。
- Intel Gaudi 版本則維護在一個分支儲存庫中，並會定期與主要的 TGI 儲存庫進行同步。
- 一個適用於 Neuron (AWS Inferentia2) 的版本維護於主要的 TGI 儲存庫中。部分模型功能有所差異。
- 適用於 Google TPU 的版本則作為 Optimum TPU 的一部分進行維護。
並非所有變體都提供相同的功能，因為硬體和中間件的能力並不提供相同的優化。
命令列介面 (CLI)
伺服器的官方命令列介面 (CLI) 支援三個子命令：download-weights、quantize 和 serve。
download-weights將從 Hub 下載權重，在某些變體中，它會將權重轉換為適合給定實作的格式；quantize允許使用qptq套件對模型進行量化。此功能並非在所有變體中都可用或受到支援；serve將啟動伺服器，載入模型（或模型分片），從路由器接收 gRPC 呼叫，執行推論，並針對給定請求提供格式化的回應。
TGI 儲存庫上 Serve 的命令列參數如下：
Usage: cli.py serve [OPTIONS] MODEL_ID
╭─ Arguments ──────────────────────────────────────────────────────────────────────────────────────────────╮
│ * model_id TEXT [default: None] [required] │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭─ Options ────────────────────────────────────────────────────────────────────────────────────────────────╮
│ --revision TEXT [default: None] │
│ --sharded --no-sharded [default: no-sharded] │
│ --quantize [bitsandbytes|bitsandbytes [default: None] │
│ -nf4|bitsandbytes-fp4|gptq │
│ |awq|eetq|exl2|fp8] │
│ --speculate INTEGER [default: None] │
│ --dtype [float16|bfloat16] [default: None] │
│ --trust-remote-code --no-trust-remote-code [default: │
│ no-trust-remote-code] │
│ --uds-path PATH [default: │
│ /tmp/text-generation-serve… │
│ --logger-level TEXT [default: INFO] │
│ --json-output --no-json-output [default: no-json-output] │
│ --otlp-endpoint TEXT [default: None] │
│ --otlp-service-name TEXT [default: │
│ text-generation-inference...│
│ --help Show this message and exit. │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────╯請注意，某些變體可能支援不同的參數，並且可能接受更多可以透過環境變數傳遞的選項。
呼叫流程 (Call Flow)
一旦兩個組件都初始化完畢、權重下載完成且模型伺服器啟動並運作後，路由器和模型伺服器便會透過 gRPC 呼叫交換資料和資訊。目前支援兩種架構：v2 和 v3。這兩個版本幾乎相同，除了以下區別：
- 支援文字和圖像資料的輸入區塊 (input chunks)；
- 支援分頁注意力 (paged attention)。
以下是展示路由器和模型伺服器啟動後交換過程的圖表。
完成這些步驟後，路由器即準備好接收來自多個客戶端的產生呼叫。這是一個範例。
在 GitHub 上更新