用 TEI 1.5 部署 bge-large-zh 做向量化，一次传 128 条文本，返回 413，原文 batch size 128 exceeds maximum allowed batch size 32，机器是单卡 4090。
一开始怀疑是「客户端把空字符串也计入了批，实际有效条数更少」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。服务端启动时按显存算出了最大批大小，超过就拒。少数情况下是请求体整体 token 数超限，条数不是唯一判据。
另外，超长文本单条就占满配额，导致整批被拒。
第一件事是按 32 条一批拆分请求
python -c "import itertools;print(list(range(0,128,32)))"再往下用脚本分批并保留原始顺序
python embed_batch.py --input docs.jsonl --batch 32 --url http://127.0.0.1:8080/embed接着启动时按显存把上限调大
text-embeddings-router --model-id BAAI/bge-large-zh-v1.5 --max-batch-tokens 8192 --max-client-batch-size 64剩下的就是把超长文本先截断到 512 token
python -c "print('truncate to 512 tokens before send')"隔了一天再看，现象没变，说明不是偶发。
别只看报错消失，验证要多做一步。所有批次返回 200，返回的向量条数与输入条数一致，顺序与原始文件对齐，413 不再出现。
批大小和总 token 数是两道闸，调大条数上限前先算 token，长文档混在短句里最容易触发。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。