2 篇博文 含有标签「batch-processing」

大多数使用 LLM 构建产品的团队都在针对错误的工作负载进行优化。他们过分痴迷于首个 token 生成时间（time-to-first-token）、流式传输延迟和响应速度——结果却发现，其 LLM API 支出的 60% 或更多实际上流向了无人实时监控的夜间摘要任务、数据扩充流水线和分类运行。适用于聊天应用的“延迟优先”思维模式正在主动破坏这些离线工作负载。

LLM 批处理流水线是生产环境 AI 中那些不起眼但至关重要的“劳模”。它是每晚对 50,000 张工单进行分类的任务，是每周用公司描述丰富 CRM 的流水线，也是每天为新文档生成嵌入（embeddings）的运行任务。这些工作负载的设计约束与实时服务有着本质的不同。如果将它们视为聊天 API 的“慢速版本”，问题就由此产生了。

大多数生产环境中的 AI 工程建议都假设你在构建聊天机器人。架构讨论集中在首字时间（TTFT）、流式部分响应以及亚秒级的延迟预算上。但越来越多的真实 LLM 工作负载与聊天界面毫无共同点。它们更像是每晚的数据扩充任务、每周的文档分类运行，以及每月对数百万条记录进行的合规性审查。

这些批处理流水线正是团队悄悄烧钱最多、因无声失败导致数据丢失最严重、以及积累技术债最多的地方——这正是因为来自实时服务的“延迟优先”思维模型不再适用，且尚未有人用更好的方案取而代之。