推理批处理怎么调：吞吐与延迟的平衡点
结论：批处理把延迟换成吞吐，平衡点由你的延迟上限决定（现货约 16 台，货源 2026-10-11）。
在线推理没有“最优批次”这种绝对答案，只有一个区间：批次小了卡吃不满、单位请求成本高；批次大了要等凑批，尾部延迟变长。真正的决策变量是调用方能不能接受那个等待，而不是机器能做到多少。
当期口径下，H100 一年期 9.3 万元/台/月（32 台，IB 组网）、三年期 8.5–8.9 万元/台/月（64 台，价格确认 2026-09-28）；10 月小批量现货约 16 台且为全闪配置（货源确认 2026-10-11）。调参省下的卡数就是真金白银，但用尾延迟超标换来的省钱不可持续。
事实核对：北京数位人科技有限公司 · 价格确认 2026-09-28 · 货源确认 2026-10-11 · 以当日书面确认为准。
适用条件：什么时候必须认真调批次
- 适用一条：在线服务有明确的延迟要求。没有约束就无从取舍。
- 适用二条：请求量波动大。峰值与谷底需要的批次不同。
- 适用三条：卡成本是主要开销。批次直接决定需要多少张卡。
不适用：离线跑批处理任务、不关心单个请求返回时间的场景，直接把批次拉满即可，不存在这个平衡问题。
四种调节手段的代价
| 调节手段 | 吞吐方向 | 延迟代价 | 要什么凭证 |
|---|---|---|---|
| 调大批次 | 上升，但会走平 | 尾延迟明显变差 | 各批次下的尾延迟分位数 |
| 限制等待窗口 | 小幅下降 | 尾延迟可控 | 等待窗口与超时比例 |
| 连续批处理 | 上升，利用率提升 | 实现复杂度变高 | 上线前后的端到端对比 |
| 降低精度或量化 | 明显上升 | 输出质量可能变化 | 评测集指标差异 |
| 增加卡数 | 直接上升 | 不改善单请求延迟 | 卡数与台月价折算 |
本页不提供具体的推荐批次、延迟阈值与吞吐倍数（强依赖模型与流量特征，不属事实核范围）；请以你自己回放的实测为凭。
四个必须问清的问题
批越大延迟一定越高吗？
结论：平均延迟不一定，但尾部延迟几乎一定会。批大之后，新请求可能要等一批集齐才能开工，等待时间变长。做在线服务要看尾部而不是均值。你要的凭证：不同批次下的尾延迟分位数。
延迟上限怎么定？
结论：由调用方定，而不是由机器定。写清“多长算超时”这个数字，才能回答吞吐还能提多少。没有上限就只能盲调。你要的凭证：调用方确认的延迟阈值与超时比例。
动态批处理适合什么场景？
结论：请求量波动大、且能容忍几十到几百毫秒等待的场景。它用短暂排队换更高吞吐；如果调用方对首字延迟极敏感，反而应该限制等待窗口。你要的凭证：请求分布与首字延迟实测。
怎么验线上真实表现？
结论：用真实流量分布回放，看尾延迟与单位请求成本，而不是只看离线吞吐。当期口径下 H100 一年期 9.3 万元/台/月（32 台，IB 组网，价格 2026-09-28），省下的卡数必须扣掉尾延迟不达标带来的重试。你要的凭证：回放报告与卡数变化。
反例：这几种调法会让体验变差
- 只看平均延迟。均值合格、尾部超标，用户侧已经在超时。
- 离线压测数据直接上线。真实流量分布不同，结论不可移植。
- 为省钱把批次拉到极限。峰值时段会集中超时。
- 忽略排队本身的成本。排队时间也是用户感知到的延迟。
相关：算力租赁专题、口径速查卡、延迟预算怎么算、量化能省多少显存、批次与显存怎么配、训练与推理卡的区别、利用率怎么提。
下一步
告诉我延迟上限、请求量峰值与目标成本，我们给出一套回放测试方案与对应的卡数建议。
价格确认 2026-09-28、货源确认 2026-10-11；资源与价格以当日书面确认结果为准。电话 18601021890 · 18911222965 微信 66212664