嵌入的批量计算（Batched AI 词典：Embedding">Embedding），指的是把多条文本（也可以是图片、音频片段）先攒成一个批次（batch），一次性送进嵌入模型（embedding model），通过一次前向传播（forward pass）拿到整批向量，而不是写个 for 循环一条一条地算。
一次前向传播是怎么装下 N 条文本的
嵌入模型内部几乎全是矩阵乘法。只喂一条文本时，GPU 上成千上万个计算核心大部分都闲着，就像雇了一辆 50 座大巴，每次却只拉一位乘客。
批量计算就是把座位填满：多条文本先经过分词（tokenization）变成 token 序列，长度不齐的用填充（padding）补齐到同一长度，堆成一个 [batch_size, seq_len] 的矩阵，一次矩阵乘法同时算出所有结果。填充出来的位置由注意力掩码（attention mask）屏蔽，不参与实际计算。
打个比方，这是洗衣服的逻辑。一件一件手洗，每次都要重新接水、倒洗衣液、等水温、排水，真正“搓”的那几下只占很小一部分时间。攒一桶丢进洗衣机，水电和准备时间被摊薄到每件衣服上。批量计算省下的主要是这类固定开销：框架调度、kernel 启动、显存读写、调用栈往返。
所以一万条文本一次算和循环一万次算，差距往往不止几十倍：逐条循环时每条都要走一遍完整调用链，GPU 利用率可能低到个位数；批量之后吞吐量（throughput）能上一个台阶，单位成本和总能耗也跟着降下来。
但批量计算不是无条件更好
- 延迟变高：要等凑齐一批、等整批算完，单条响应会变慢。
- 显存压力：batch 越大显存占用越高，容易爆显存（OOM）。
- 填充浪费：长短不齐时，短文本被 pad 到批次内最长的那条，白算。常见做法是按长度分桶（length bucketing），或者按 token 总数而不是条数来确定 batch。
- 数值细节：浮点运算顺序变了，结果可能有极微小的差异；需要严格复现时，固定住 batch 配置。
| 逐条循环 | 批量计算 | |
|---|---|---|
| 一次前向的输入 | 1 条 | N 条 |
| GPU 利用率 | 低 | 高 |
| 吞吐量 | 低 | 高 |
| 单条延迟 | 低 | 略高 |
| 显存峰值 | 低 | 高 |
| 典型场景 | 交互式单条请求 | 离线建库、大批量清洗 |
和几个近亲的区别
批量 vs 多进程并行：多进程像“多开几辆小车”，批量像“换大巴”，两者可以叠加。批量 vs 向量化（vectorization）：向量化是算子内部用 SIMD 一次算多个数，批量是在请求层面把多条样本拼起来，层级不同。批量 vs 动态批处理（dynamic / continuous batching）：在线服务不能等太久，于是把一小段窗口内到达的请求攒起来一起算，用来在延迟和吞吐之间取舍。批量 vs 嵌入缓存（embedding cache）：缓存是让同样的东西根本不用再算，批量是让必须算的算得更快，两件事。
对实际工作的意义
离线给几十万上百万文档建向量库时，batch size 是第一个该调的参数，调它比换硬件便宜得多。在线检索服务则要靠动态批处理把零散请求攒起来。还有一点容易忽略：做评测或对拍时，双方要用一致的 batch 配置，否则吞吐数字没有可比性。具体模型和框架的参数上限，以官方文档为准。