推理延迟预算怎么定：TTFT、TPOT 与卡数换算口径
延迟预算怎么定：先定 TTFT 与 TPOT 上限，再按峰值并发×输出长度换算吞吐，最后定卡数（2026-09-28）。
三条适用条件（含什么情况下不适用）
- 对话类业务 → 锁 TTFT。先把交互能接受的首次响应时间定死，再谈卡数；台月换算参照 H100 一年期 9.3 万元/台/月（32 台，IB 组网，2026-09-28 确认），按 730 小时/月 折约 127 元/台/小时（换算值，非单独报价）。不适用：离线批量任务不看首字延迟，只需看总吞吐，见 任务成本 vs 卡时。
- 长文生成 → 锁 TPOT。输出越长，逐 token 延迟对体感影响越大；只看总耗时会被批量掩盖。不适用：输出很短（几十 token）时，TPOT 影响可忽略，见 选型口径。
- 峰值并发未知 → 先按保守值算。并发估小了卡数不够、估大了全是空转成本。不适用：内部工具类应用并发很低时，不必按互联网峰值容量设计，见 预算与排期。
五列表：延迟预算的四个量与凭证
| 要定的量 | 粗算口径 | 影响什么 | 该要的凭证 | 当期参照 |
|---|---|---|---|---|
| TTFT 上限 | 交互可接受的首次响应时间 | 首字体感与卡型选择 | 目标值书面确认 | 通用工程口径 |
| TPOT 上限 | 后续每 token 平均耗时 | 长输出体感与并发容量 | 实测压测报告 | 通用工程口径 |
| 所需吞吐 | 峰值并发 × 平均输出长度 ÷ 目标响应时间 | 卡数与副本数 | 并发与长度统计 | 见 显存测算 |
| 计费方式 | 卡时或台月（730 小时/月） | 总支出 | 分段计费条款 | H100 一年期 9.3 万元/台/月（32 台，2026-09-28） |
| 小规模验证 | 先跑仿真与压测 | 避免直接上大机 | 压测脚本与结果 | RTX 5090 仿真卡 1.2 万元/台/月（30 台） |
含税口径：报价是否含税以书面报价单为准，可开增值税专用发票。
延迟与吞吐为通用工程口径，金额仅引用事实核已登记档位（确认日期 2026-09-28）；实际以模型、推理框架与当日书面确认为准。
四个买方问题
TTFT 和 TPOT 到底差在哪？
结论：TTFT 是请求到第一个字的时间，TPOT 是之后每个字的平均耗时；对话看 TTFT、长输出看 TPOT，两条线要分别定上限。该要的凭证：两个指标的目标值与压测口径。
并发一高延迟就涨，是卡不够吗？
结论：不一定，批量能提吞吐但会抬高单请求延迟；先定延迟上限，再换算吞吐。该要的凭证：不同并发下的延迟曲线，见 监控与访问。
延迟预算怎么换成卡数？
结论：所需吞吐 ≈ 峰值并发 × 平均输出长度 ÷ 目标响应时间，再对照单卡实测吞吐取整。该要的凭证：单卡实测吞吐报告，见 短测怎么做。
推理负载该按卡时还是包月？
结论：有明显低谷按卡时，连续跑满 730 小时/月 且持续数月才看台月。该要的凭证：两种计费的同口径对比，见 卡时 vs 台月。
反例：这三种会亏
- 拿单卡标称算力选型：标称值不等于你的框构下的实测吞吐，最后差一倍以上，见 利用率与成本。
- 为峰值并发长期包月：峰值只占少数时间，其余时间按 9.3 万元/台/月 在空转，见 云上 vs 整机。
- 只压吞吐不压延迟：上线才发现对话首字要等，再回头改框构与卡数。
价格确认日期 2026-09-28，货源确认日期 2026-10-11。本页最后更新 2026-10-17；延迟与卡数口径以当日书面确认为准。
下一步
告诉我们目标 TTFT/TPOT、峰值并发与平均输出长度，我们给出卡型、卡数与租期口径。提交 GPU 租赁需求，计费单位见 计费单位怎么选。
提交 GPU 租赁需求 选型口径 按卡时 vs 按台月 显存测算
延迟与卡数口径以当次书面确认为准。电话 18601021890 · 18911222965 微信 66212664