AI Embedding 批量请求变慢时怎么区分模型和网络瓶颈

AI Embedding 批量请求突然变慢时，先不要急着换模型或把 batch size 调小。把一次请求拆成客户端准备、网络往返、服务端排队和模型计算四段，再用同一批文本做对照，通常就能看出是链路慢、队列长，还是模型确实吃不下当前输入。向量维度不一致也要单独排除，它更常表现为写入失败或重试，而不是单纯的网络延迟。

最稳妥的判断方法是：固定文本、模型和输出维度，只改变批次大小；同时记录请求体大小、输入 token、网络耗时、服务端处理耗时与 p50/p95。网络耗时随请求体或跨区域链路升高，模型耗时随 token 和批次升高，队列耗时随并发升高，三者的信号并不相同。

先把一次批量请求拆成四段耗时

一个客户端从读取文本到拿到向量，往往经历四个边界：序列化与 token 统计属于客户端准备；DNS、连接建立、TLS、上传和下载属于网络往返；请求到达服务后等待可用 worker 属于服务端排队；真正执行 encoder 或 embedding 模型才是模型计算。只记录 HTTP 总耗时，会把这四段混成一个数字。

可以在客户端留下最小的结构化记录。下面的代码只演示计时字段的组织方式，具体 SDK 的请求调用应替换成项目自己的实现。

from time import perf_counter

def measure_request(prepare, send):
    # 把客户端准备和远端请求分开，避免总耗时掩盖网络瓶颈
    start = perf_counter()
    payload, input_tokens = prepare()
    prepared_at = perf_counter()

    # send 应返回服务端处理时间；没有该字段时不要把它猜成模型耗时
    response = send(payload)
    finished_at = perf_counter()
    return {
        "prepare_ms": (prepared_at - start) * 1000,
        "network_plus_queue_ms": (finished_at - prepared_at) * 1000,
        "input_tokens": input_tokens,
        "vector_dimensions": len(response["data"][0]["embedding"]),
    }

如果服务端没有返回排队或计算耗时，就只能先得到客户端准备时间与“网络加服务端”的合计。此时不要把剩余部分直接命名为模型时间；应补充服务端 trace、队列指标或同区域对照。

用批次对照看模型、队列和网络信号

批量请求变慢时，建议准备一份固定文本集，保持模型、输入内容和输出维度参数不变，只比较几个批次档位。每档至少记录成功率、总耗时、吞吐、输入 token、请求体大小以及 p50/p95；不要只看平均值，因为排队和重试往往先反映在尾延迟。

NVIDIA 的 RAG 文档把批处理、并发和服务吞吐放在同一条摄取链路里讨论；TensorRT-LLM 的 Embeddings 服务也支持动态批处理。这里的工程含义不是“批次越大越好”，而是要找到队列、显存/计算和网络都能解释的工作区间。批次变大后吞吐增加但 p95 失控，说明已经接近某个资源边界。

先排除网络链路，再判断模型是否真的变慢

网络瓶颈常有三个可观察信号。第一，请求体和响应体变大时耗时近似一起增加；第二，跨区域、代理或新建连接的请求明显更慢；第三，服务端计算时间没有同步上涨，但客户端总耗时上涨。排查时应优先复用 HTTP 连接，记录 DNS、连接、TLS、上传、首字节和下载阶段，并用同区域的小批次请求做基线。

压缩只能减少可传输字节，不能替代服务端对输入 token 的处理；重试也可能把拥塞放大。应给重试设置上限和退避，并把原始请求、重试次数与最终耗时分开记录。若同一个批次重复重试，看到的总延迟不能拿来和一次成功请求直接比较。

如果网络阶段稳定，而服务端 queue time 随并发上升，优先调整并发上限或扩展 embedding 实例；如果 queue time 稳定、compute time 随 token 和 batch 增长，再评估模型、GPU/CPU 资源或动态批处理配置。

核对向量维度，避免把契约错误当性能问题

批量接口返回的每条向量必须具有同一长度，并且这个长度要符合向量库索引的 schema。以 OpenAI Embeddings API 为例，接口支持一次传入多个字符串，也支持在部分模型上指定 dimensions；这意味着“批量输入数量”和“输出向量维度”是两类不同参数，不能混在一个性能指标里。

def check_vectors(response, expected_dimensions):
    # 在写入向量库前拒绝长度不一致，避免失败写入触发无意义重试
    vectors = [item["embedding"] for item in response["data"]]
    lengths = {len(vector) for vector in vectors}
    if lengths != {expected_dimensions}:
        raise ValueError("返回向量维度与索引 schema 不一致")
    return vectors

维度不一致通常会在解析、校验或入库时暴露。若客户端不断重试同一份不符合 schema 的响应，日志里会出现“请求很慢”，但根因是契约错误。把返回维度、模型标识、索引版本写入一次批次记录，能很快把这类假性能问题分出去。

用一次小矩阵确定调整方向

最后可以建立一个小矩阵：固定文本集和模型，选择少量 batch size；分别在低并发、目标并发和高并发下回放。每组保存输入 token、请求体大小、成功率、p50/p95、吞吐、服务端 queue/compute（若可得）和维度检查结果。

1. 网络阶段随字节数增长而增长：先检查区域、连接复用、代理和压缩。
2. queue time 随并发增长：限制客户端并发或扩展服务端容量，不要只改 batch size。
3. compute time 随 token 增长：评估模型、硬件和动态批处理，并重新观察尾延迟。
4. 维度检查失败：先统一模型参数与向量库 schema，修复契约后再讨论性能。

这样做的结果不是得到一个对所有服务都适用的神奇 batch size，而是得到一份能复现的边界记录：在什么输入规模、并发和网络条件下，哪个阶段先成为瓶颈。

常见问题

批次越大，Embedding 吞吐就一定越高吗？

不一定。批次变大可能减少请求次数，但也会增加单次输入、排队和计算压力。应同时看吞吐、p95、成功率和服务端资源。

没有服务端 queue time 怎么排查？

先用客户端分段计时和同区域小批次建立基线，再向服务端补充 trace 或队列指标。没有证据时不要把网络加服务端的剩余时间直接称为模型耗时。

向量维度不一致会让请求变慢吗？

它更常导致校验或入库失败，并触发重试；重试会放大总耗时。先记录返回维度并和索引 schema 比较，再决定是否存在真正的性能问题。

区分模型与网络瓶颈的关键不是猜一个更快的模型，而是把客户端、网络、队列和计算拆开，用固定输入做对照，并把输出维度当成独立契约检查。