生产级文本嵌入推理引擎TEI：从模型服务化到高性能部署实战

1. 项目概述：从模型服务到生产级嵌入推理引擎

如果你在AI应用开发，特别是涉及大语言模型或检索增强生成（RAG）的领域工作过，那么“模型服务化”这个痛点你一定深有体会。我们训练或微调出一个表现优异的文本嵌入模型，比如BAAI/bge-large-zh-v1.5，满心欢喜地准备集成到线上系统中，却发现困难重重：动辄几个G的模型文件如何加载？如何应对高并发请求？如何实现高效的批处理以降低延迟？如何管理多个模型版本？更别提GPU内存的精细管理和推理性能的极致优化了。这些问题往往让算法工程师被迫转型为“全栈运维”，消耗大量精力在工程部署上。

huggingface/text-embeddings-inference（简称TEI）正是为了解决这些生产环境中的核心痛点而生的。它不是另一个简单的模型加载脚本，而是一个由Hugging Face官方维护的、专为文本嵌入模型设计的高性能、生产就绪的推理服务框架。你可以把它理解为一个高度特化的“模型服务器”，但它比通用的模型服务方案（如Triton Inference Server的NLP后端，或简单的FastAPI封装）在嵌入任务上做了极致的深度优化。

简单来说，TEI的核心价值在于：它将一个PyTorch或TensorFlow格式的嵌入模型，封装成一个可以通过HTTP或gRPC协议调用的、高性能、可扩展的微服务。开发者不再需要关心模型加载、CUDA内核、批处理队列这些底层细节，只需要像调用一个普通API一样发送文本，就能获得对应的向量。这对于构建语义搜索、智能问答、内容推荐、聚类分析等需要大量文本向量化操作的业务系统来说，是基础设施级别的提效工具。

我最初接触TEI是在一个需要为百万级文档库构建实时语义搜索系统的项目中。当时我们尝试过自己用Flask包装sentence-transformers，也试过一些云服务商的方案，但在成本、性能和控制权的平衡上总不尽如人意。TEI的出现，让我们最终在自有GPU服务器上获得了接近商业化向量数据库服务的推理性能，同时保持了完全的自定义和可控性。接下来，我将从设计思路、核心特性、实战部署到深度调优，为你完整拆解这个强大的工具。

2. 核心架构与设计哲学：为什么是TEI？

在深入命令行之前，理解TEI的设计哲学至关重要。这能帮助你在后续的部署和调优中做出正确决策。TEI并非凭空创造，它的设计是对生产环境中嵌入推理需求的深刻回应。

2.1 针对嵌入任务的深度优化

通用模型服务器（如TorchServe）需要兼顾各种任务（分类、生成、嵌入），其优化是普适性的。而TEI则大胆地做了减法，专注于“文本输入，向量输出”这一单一任务范式。这种专注带来了几项关键优化：

1. 计算图编译与静态优化：TEI底层深度集成了ONNX Runtime和PyTorch的编译优化能力。在服务启动加载模型时，它会将动态图转换为静态计算图，并进行算子融合、常量折叠等优化。这意味着那些在动态图模式下每次推理都需要进行的条件判断、内存分配等开销被极大消除。对于嵌入模型常用的BERT、RoBERTa架构，其Self-Attention和Pooling层能被编译成更高效的内核。
2. 极简的预处理与后处理管道：嵌入模型的预处理（分词）和后处理（向量归一化、池化策略）是固定且计算密集的。TEI将这些流程用C++或高性能Rust代码实现，并紧密集成到推理流水线中，避免了Python GIL（全局解释器锁）带来的性能损失，也减少了数据在Python与底层引擎之间来回拷贝的开销。
3. 对批处理的先天友好设计：嵌入推理的典型场景是批量处理（如一次索引成千上万条文档）。TEI的整个架构围绕批处理设计，从请求队列、张量拼接到GPU内核启动，都为实现高吞吐量而优化。它支持动态批处理（Dynamic Batching），能将短时间内到达的多个独立请求在服务端自动组合成一个更大的批处理张量进行计算，显著提升GPU利用率。

2.2 生产环境的关键特性内建

一个合格的推理服务不能只看峰值性能，更要看其在生产环境中的稳健性。TEI内建了许多“开箱即用”的生产级特性：

• 健康检查与就绪探针：提供了/health和/ready端点，方便集成到Kubernetes等编排系统中，实现服务的优雅启动、关闭和故障转移。
• 监控与指标暴露：原生集成Prometheus指标，暴露如请求延迟（分位数P50, P90, P99）、吞吐量（QPS）、GPU内存使用率、批处理大小分布等关键指标。你无需额外编码，就能建立起完整的服务监控仪表盘。
• 多模型并行与热加载：单个TEI服务实例可以同时加载并服务多个不同的嵌入模型。你可以通过API指定模型ID进行调用。更强大的是，它支持模型的热加载和热卸载，这意味着你可以在不重启服务的情况下，更新模型版本或切换业务模型，这对需要A/B测试或蓝绿部署的场景至关重要。
• 安全与认证：支持API密钥认证，你可以为不同的客户端分配不同的密钥，并控制其访问权限（如限速、可访问的模型列表）。

2.3 开发者体验与生态集成

TEI由Hugging Face主导开发，自然与Hugging Face生态无缝集成。

• 模型中心直接支持：Hugging Face Model Hub上许多流行的嵌入模型（特别是Sentence Transformers格式的模型）页面都提供了一个“Deploy”按钮，其中一项就是“Inference Endpoint”，其背后使用的就是TEI技术。这简化了从模型选择到服务部署的流程。
• 与transformers库兼容：虽然TEI服务本身不直接使用transformers库进行推理（为了性能），但它完全兼容由该库训练和保存的模型格式（PyTorch的.bin或SafeTensors格式）。你微调好的模型可以无缝部署。
• 丰富的客户端支持：除了直接的HTTP调用，官方提供了Python和JavaScript的客户端库，封装了连接池、重试、异步请求等逻辑，让集成调用非常简单。

注意：TEI主要专注于编码器架构的文本嵌入模型（如BERT, RoBERTa, E5等）。对于需要生成文本的解码器模型（如GPT, T5）或序列到序列模型，应使用Hugging Face的另一个项目text-generation-inference(TGI)。选择正确的工具是第一步。

3. 实战部署：从零搭建你的第一个TEI服务

理论说得再多，不如亲手部署一次。这里我将以部署一个中文嵌入模型BAAI/bge-large-zh-v1.5为例，演示最经典的Docker部署方式。这是生产环境最推荐的方式，因为它提供了最好的环境隔离和可重复性。

3.1 环境准备与前置条件

首先，确保你的宿主机满足以下条件：

1. Linux系统：Ubuntu 20.04/22.04或CentOS 7/8是经过充分测试的环境。Windows可以通过WSL2进行，但生产环境不推荐。
2. NVIDIA GPU驱动：已安装对应GPU型号的最新稳定版驱动。
3. Docker与NVIDIA Container Toolkit：这是让Docker容器能使用GPU的关键。
4. 足够的磁盘空间：模型文件本身约1.3GB，加上镜像和缓存，建议预留至少10GB空间。

安装NVIDIA Container Toolkit的步骤简述如下（以Ubuntu为例）：

# 添加NVIDIA容器仓库 distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker

安装后，运行sudo docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi测试GPU在Docker中是否可用。

3.2 使用官方Docker镜像启动服务

TEI提供了预构建的Docker镜像，这是最快捷的方式。我们将模型ID作为环境变量传入，服务启动时会自动从Hugging Face Hub下载模型。

# 拉取最新的GPU版本镜像 docker pull ghcr.io/huggingface/text-embeddings-inference:latest # 运行容器 docker run -d \ --name tei-bge-zh \ --gpus all \ -p 8080:80 \ -e MODEL_ID=BAAI/bge-large-zh-v1.5 \ -e NUM_GPU_WORKERS=1 \ -e MAX_BATCH_SIZE=32 \ -v /path/to/huggingface_cache:/data \ ghcr.io/huggingface/text-embeddings-inference:latest

关键参数解析：

• -p 8080:80：将容器内的80端口映射到宿主机的8080端口。
• -e MODEL_ID：指定要加载的模型。可以是Hugging Face Hub的ID，也可以是本地路径（如果使用-v挂载了模型目录）。
• -e NUM_GPU_WORKERS：这是最重要的性能参数之一。它指定了并行处理请求的GPU工作进程数。对于单个GPU，通常设置为1。如果你有多个GPU，可以设置为GPU数量，以实现模型并行（每个GPU加载一个模型副本）来处理更高并发。
• -e MAX_BATCH_SIZE：动态批处理的最大批次大小。需要根据你的GPU内存（特别是VRAM）和模型大小来调整。对于bge-large-zh（约1.3B参数），在24GB VRAM的GPU上，设置为32或64是安全的起点。设置太大会导致OOM（内存溢出），太小则无法充分利用GPU。
• -v /path/to/huggingface_cache:/data：将宿主机的目录挂载到容器的/data目录。这有两个好处：一是持久化模型缓存，下次启动无需重新下载；二是可以将本地已有的模型文件（如/path/to/models/bge-large-zh-v1.5）直接挂载使用，对于内网环境或定制模型至关重要。

执行命令后，使用docker logs -f tei-bge-zh查看日志。当你看到类似"Connected"和"Model loaded in ..."的信息时，说明服务已就绪。

3.3 首次API调用验证

服务启动后，我们使用最常用的curl命令进行验证。TEI的主要端点是/embed。

# 单个文本嵌入 curl -X POST http://localhost:8080/embed \ -H "Content-Type: application/json" \ -d '{ "inputs": "文本嵌入技术是人工智能的重要基石。", "normalize": true }' # 批量文本嵌入 curl -X POST http://localhost:8080/embed \ -H "Content-Type: application/json" \ -d '{ "inputs": [ "今天天气真好。", "机器学习模型需要大量数据。", "文本嵌入可以将语义编码为向量。" ], "normalize": true }'

请求体参数说明：

• inputs：可以是字符串，也可以是字符串数组。这是要编码的文本。
• normalize：是否对输出的向量进行L2归一化（即将向量长度缩放到1）。强烈建议设为true。因为余弦相似度计算依赖于向量的方向而非长度，归一化后，向量间的点积就等于余弦相似度，极大简化了后续的相似度计算。
• truncate：可选。如果输入文本超过模型的最大序列长度（如512个token），是否自动截断。默认为true。对于关键业务，你可能需要先本地检查长度。

响应示例：

{ "embeddings": [ [0.012, -0.045, 0.123, ...] // 一个768维的浮点数向量（对于bge-large-zh） ], "num_tokens": 15 // 输入文本实际使用的token数量 }

如果看到返回了正确维度的向量，恭喜你，TEI服务已经成功运行！

3.4 使用Python客户端进行集成

在实际应用中，我们更倾向于使用官方Python客户端，它处理了连接管理、错误重试和异步请求。

pip install text-embeddings-inference-client

from text_embeddings_inference import Client # 初始化客户端 client = Client("http://localhost:8080") # 同步调用 embeddings = client.embed( texts=["文本嵌入技术是人工智能的重要基石。", "另一个句子"], normalize=True ) print(f"向量维度: {embeddings.shape}") # 输出: (2, 768) # 异步调用（适用于高并发） import asyncio from text_embeddings_inference import AsyncClient async def main(): async with AsyncClient("http://localhost:8080") as client: embeddings = await client.embed( texts=["异步处理文本1", "文本2"], normalize=True ) print(embeddings.shape) asyncio.run(main())

4. 高级配置与性能调优实战

让服务跑起来只是第一步，让它跑得又快又稳才是挑战。TEI提供了丰富的环境变量和启动参数用于调优。以下是我在多个生产项目中总结出的关键调优经验。

4.1 GPU与并行化配置

1. NUM_GPU_WORKERS与MAX_BATCH_SIZE的黄金组合：

   • 场景：你的服务QPS（每秒查询率）很高，但每个请求的文本数量（batch size）不大。
   • 调优：增加NUM_GPU_WORKERS。这允许多个批处理操作在GPU上并发执行（类似于CUDA Stream）。例如，在A100上，对于bge-base这类小模型，可以设置NUM_GPU_WORKERS=2甚至4。但要注意：每个worker都会在GPU上占用一份模型权重和上下文内存。总内存消耗 ≈ 模型权重内存 * NUM_GPU_WORKERS + 激活内存 * MAX_BATCH_SIZE。务必使用nvidia-smi监控VRAM使用情况。
   • 公式估算：一个粗略的VRAM估算方法是：模型参数量（单位：B） * 4字节（FP32）或2字节（FP16/BF16）。bge-large-zh约1.3B参数，FP16下约2.6GB。加上激活和中间变量，单个worker在MAX_BATCH_SIZE=32时可能需要4-5GB。两个worker就需要8-10GB，请确保你的GPU VRAM足够。

2. 精度与量化：-e QUANTIZE=bitsandbytes或-e QUANTIZE=gptq。

   • bitsandbytes (8-bit): 通过-e QUANTIZE=bitsandbytes启用。这能将模型权重量化为8位整数，通常能减少近50%的内存占用，而对嵌入质量的影响微乎其微（在余弦相似度任务上差异通常小于0.5%）。这是内存受限时的首选方案。
   • GPTQ (4-bit): 通过-e QUANTIZE=gptq启用。更激进的量化，内存减少75%。但需要模型本身提供GPTQ格式的权重（Hugging Face Hub上有些模型会提供）。精度损失稍大，适用于对内存极度敏感、对精度要求不是极端苛刻的场景（如海量文档的初步召回）。
   • 实践建议：首次部署建议使用FP16（默认）或BF16（如果GPU支持）。稳定后，尝试启用bitsandbytes量化，在几乎不影响效果的前提下获得内存收益。

4.2 批处理与吞吐量优化

1. 理解动态批处理：TEI的核心优势。假设MAX_BATCH_SIZE=32，当请求涌入时，TEI会等待一个很短的时间窗口（可配置），将窗口内收到的所有请求的文本拼接成一个批次（最大不超过32）进行推理。这能将GPU利用率从个位数提升到70%以上。
2. MAX_BATCH_TOKENS参数：比MAX_BATCH_SIZE更精细的控制。它限制的是一个批次中所有文本的总token数。因为不同文本长度差异很大，仅限制文本数量可能导致一个批次的总token数爆表（OOM）。例如，设置-e MAX_BATCH_TOKENS=8192，那么即使只有4个文本，但如果每个都长达2048个token，也会达到上限。对于长度差异大的场景，建议使用MAX_BATCH_TOKENS替代MAX_BATCH_SIZE。
3. 客户端批处理：服务端有动态批处理，客户端也应主动进行批处理。不要每秒发送成千上万个小请求，而是应该在客户端积累一定数量的文本（比如每100条或每0.1秒）后，打包成一个请求发送。这能极大减少网络往返开销和服务端的请求调度压力。

4.3 内存、监控与健康检查

1. OOM防护：除了设置合理的批处理大小，还可以通过-e MAX_INPUT_LENGTH=512来限制单个输入文本的最大token长度，防止超长文本击穿内存。
2. Prometheus监控：TEI在/metrics端点暴露了大量指标。你可以配置Prometheus来抓取，并用Grafana展示。需要重点关注的指标有：
   • tei_request_duration_seconds：请求延迟直方图。关注P99延迟是否满足SLA。
   • tei_batch_size：实际处理的批处理大小分布。如果长期远小于MAX_BATCH_SIZE，说明你的流量模式或等待窗口可能需要调整。
   • process_resident_memory_bytes和nvidia_gpu_memory_bytes：进程和GPU内存使用情况。
3. 健康检查配置：在Kubernetes或Docker Compose中，务必配置就绪性和存活型探针。

   # Kubernetes Pod Spec 示例片段 readinessProbe: httpGet: path: /ready port: 80 initialDelaySeconds: 30 # 给模型下载和加载留出时间 periodSeconds: 5 livenessProbe: httpGet: path: /health port: 80 initialDelaySeconds: 60 periodSeconds: 30

5. 生产环境部署架构与运维心得

单机部署只能用于测试或小流量场景。生产环境需要高可用和可扩展性。

5.1 基于Kubernetes的部署模式

这是最主流的方案。核心思想是将TEI服务封装为一个Kubernetes Deployment，并配以Service、HPA（Horizontal Pod Autoscaler）和Ingress。

# tei-deployment.yaml 精简示例 apiVersion: apps/v1 kind: Deployment metadata: name: tei-bge-zh spec: replicas: 2 # 初始副本数，对应两个Pod selector: matchLabels: app: tei-bge-zh template: metadata: labels: app: tei-bge-zh spec: containers: - name: tei image: ghcr.io/huggingface/text-embeddings-inference:latest args: ["--model-id", "BAAI/bge-large-zh-v1.5", "--quantize", "bitsandbytes"] ports: - containerPort: 80 env: - name: NUM_GPU_WORKERS value: "1" - name: MAX_BATCH_TOKENS value: "8192" resources: limits: nvidia.com/gpu: 1 # 申请1块GPU memory: "8Gi" requests: nvidia.com/gpu: 1 memory: "6Gi" readinessProbe: # ... 如上文配置 volumeMounts: - name: model-cache mountPath: /data volumes: - name: model-cache persistentVolumeClaim: claimName: tei-model-pvc # 使用PVC共享模型缓存，加速Pod启动 --- # 创建HPA，根据CPU/GPU利用率或自定义QPS指标进行自动扩缩容 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: tei-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: tei-bge-zh minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: nvidia.com/gpu target: type: Utilization averageUtilization: 70 # 当GPU平均利用率超过70%时扩容

关键运维经验：

• 共享模型缓存：使用网络存储（如NFS、Ceph）或高性能PVC，将模型缓存目录（/data）共享给所有Pod。这样新Pod启动时无需重新下载模型，启动时间从几分钟缩短到几秒钟。
• GPU资源管理：使用nvidia.com/gpu资源声明，让Kubernetes调度器能正确地将Pod调度到有GPU的节点上。
• 基于自定义指标的扩缩容：GPU利用率并非完美的扩缩容指标。更好的做法是使用Prometheus采集的QPS或平均延迟，并通过Kubernetes Custom Metrics API暴露给HPA。例如，当平均请求延迟超过100ms时，触发扩容。

5.2 流量治理与网关集成

在生产环境中，TEI服务前方应该有一个API网关（如Kong, Nginx, Traefik）或服务网格（如Istio）。

• 负载均衡：Kubernetes Service提供基本的负载均衡，但网关能提供更高级的策略（如一致性哈希、金丝雀发布）。
• 认证与鉴权：在网关层统一实现API密钥验证、速率限制（Rate Limiting）和访问日志。
• 金丝雀发布：当你需要升级TEI版本或切换新模型时，可以通过网关将一小部分流量导入新版本的服务Pod，进行验证后再全量切换。

5.3 模型更新与多模型管理

业务需求变化，模型也需要迭代。TEI支持两种更新方式：

1. 滚动更新：修改Deployment的镜像标签或环境变量（如MODEL_ID），Kubernetes会创建新Pod并逐步替换旧Pod。结合就绪探针，可以实现零停机更新。注意：如果新模型与旧模型不兼容（向量维度不同），需要确保客户端能同时兼容，或者采用蓝绿部署。
2. 多模型并行服务：TEI支持在启动时指定多个模型，或通过管理API动态加载模型。

   # 启动时加载多个模型 docker run ... -e MODEL_ID="BAAI/bge-small-zh-v1.5;BAAI/bge-large-zh-v1.5" ...

   调用时，在请求头中指定模型：curl -H "model: BAAI/bge-small-zh-v1.5" ...。这适用于需要同时运行“召回模型”（快而糙）和“精排模型”（慢而精）的场景。

6. 常见问题排查与性能瓶颈分析

即使配置得当，在生产中仍会遇到各种问题。以下是我踩过的一些坑和解决方案。

6.1 服务启动失败

• 问题：容器启动后立即退出，日志显示Failed to download model。

• 排查：

  1. 检查网络：对于内网环境，需要配置HTTP代理或使用离线模型。通过-v将本地模型目录挂载到容器内，并使用MODEL_ID指向该本地路径（如/data/my_model）。
  2. 检查磁盘空间：docker logs查看是否有磁盘空间不足的错误。
  3. 检查模型格式：确保模型是transformers库支持的格式，并且包含必要的文件（config.json,pytorch_model.bin或model.safetensors,tokenizer.json等）。sentence-transformers格式的模型通常兼容。

• 问题：日志显示CUDA out of memory。

• 排查：

  1. 降低MAX_BATCH_SIZE或MAX_BATCH_TOKENS。
  2. 启用量化QUANTIZE=bitsandbytes。
  3. 检查是否有其他进程占用了GPU内存。
  4. 如果使用多个NUM_GPU_WORKERS，尝试将其减少为1。

6.2 推理性能不达预期

• 问题：GPU利用率很低（例如<20%），但延迟很高。

• 排查与解决：

  1. 检查批处理：这是最常见的原因。通过Prometheus的tei_batch_size指标查看实际批处理大小。如果长期为1，说明动态批处理没有生效。可能原因是请求间隔太长，或者MAX_BATCH_SIZE设置过大，导致等待超时前凑不够一个批次。调整策略：在客户端主动进行批处理，累积一定数量后再发送。或者适当调整TEI的--max-client-batch-size参数（如果客户端批处理）和--max-batch-time（等待组批的最大时间，微秒）。
  2. 检查输入长度：非常长的文本（如整篇文章）会严重拖慢推理速度，因为Transformer的计算复杂度与序列长度成平方关系。考虑对长文本进行分段（如按段落或滑动窗口），分别获取嵌入后再进行聚合（如取平均）。
  3. 检查硬件瓶颈：使用nvtop或nvidia-smi dmon监控GPU的sm（流处理器）利用率。如果GPU计算未饱和，可能是CPU预处理（分词）成了瓶颈。TEI已用Rust优化分词，但如果你在非常老的CPU上运行，也可能受限。考虑升级CPU或使用更多CPU核心（通过Docker的--cpuset-cpus参数绑定）。

• 问题：吞吐量（QPS）上不去。

• 解决：

  1. 增加NUM_GPU_WORKERS：这允许多个推理流水线并发，能有效提升吞吐，尤其对于小批量请求。
  2. 使用更快的GPU：嵌入推理是计算密集型任务，GPU的FP16算力（Tensor Cores）和内存带宽是关键。从T4升级到A10或A100通常能获得数倍的吞吐提升。
  3. 模型蒸馏或选择更小模型：业务上是否必须使用最大的模型？bge-large-zh（1.3B）效果固然好，但bge-base-zh（0.3B）或bge-small-zh（0.03B）在多数检索任务上仍有不错的表现，而速度可能快5-10倍。进行效果-速度的权衡测试。

6.3 向量质量相关疑问

• 问题：启用量化（bitsandbytes）后，检索效果似乎下降了。
• 验证方法：不要凭感觉。构建一个小的测试集（几百对相关/不相关文本），分别计算FP16和8-bit量化模型输出的向量相似度（余弦相似度），并计算其相关性（如Spearman等级相关系数）。在我的经验中，对于BERT类架构的嵌入模型，8-bit量化对相似度排序的影响极小（相关系数>0.99）。如果发现显著差异，可能是该模型对量化特别敏感，考虑换用其他模型或使用--quantize的gptq（4-bit）选项（如果可用）。
• 问题：相同文本多次调用，得到的向量有极小差异（最后几位小数不同）。
• 解释：这是正常现象。在GPU上进行浮点计算，尤其是使用TF32或非确定性算法时，可能会产生微小的数值波动。这种波动在余弦相似度计算中影响可以忽略不计。如果要求绝对确定性，可以尝试设置环境变量CUDA_LAUNCH_BLOCKING=1和CUBLAS_WORKSPACE_CONFIG=:16:8（可能会牺牲一些性能），但这通常没有必要。

经过以上从原理到实践，从部署到调优的完整梳理，text-embeddings-inference不再是一个黑盒工具，而是一个你可以精准掌控的生产力引擎。它解决了嵌入模型服务化中最棘手的性能、扩展和运维问题，让你能更专注于上层应用逻辑和业务创新。最后再分享一个小心得：在正式大规模投入前，务必用符合你业务数据分布的测试集，对不同的模型、量化配置和批处理参数做一次全面的基准测试，记录下吞吐、延迟和准确率的平衡点。这份数据将成为你容量规划和故障排查最可靠的依据。