收益：
- 可以解释什么是流式处理、事件类型以及为什么需要它。
- max_tokens掌握超时和128K长输出关系
- 可以根据工作负载在流式和非流式请求之间做出正确的选择
您可能已经注意到，在聊天界面中，响应是逐字“输入”的。这不是一种视觉上的华丽；而是一种视觉上的华丽。它是一种称为流式传输技术的结果，并且通常是生产质量 LLM 集成所必需的。在本单元中，您将了解流是什么、它由哪些事件组成、它与长输出和超时的关系，以及何时使用流、何时不使用流。我们将通过专业人士的真实任务来涵盖该主题——实时助理、长报告生成、批处理。
什么是流量？
对于非流式（同步）请求，您需要等待模型生成整个响应；当答案准备好后，它就会完整地到达。在流式请求中，服务器在模型生成时逐段发送响应。从技术上讲，这是通过服务器发送的事件（SSE - 服务器发送事件，一种服务器通过开放连接连续发送小事件的方法）来完成的。
这种差异在用户体验中变得很明显：在需要 8 秒的响应时，非流用户会盯着空白屏幕 8 秒；流媒体用户会在大约 0.5 秒内看到第一个单词，并且文本开始流动。感知延迟（用户感受到的等待时间）大大减少，而总时间保持不变。
流程的事件类型
流是一系列事件。从概念上讲，典型的流程如下：
事件
含义
消息开始
回应开始了；型号、ID 等标头信息已到达。
内容块开始
内容块（例如文本）开始
内容块增量
一小段文本（delta）到达；你收集这些
内容块停止
区块已完成
消息增量
更新了结束信息，例如 stop_reason 和用法
消息停止
回复结束
您的代码按顺序组合 content_block_delta 事件中的文本片段；您最终会得到与非流式响应完全相同的文本。使用情况（代币数量）通常在流程结束时很清楚 - 一旦流程结束，您就可以跟踪成本。
提示：大多数官方 SDK（软件开发工具包 - 提供商的现成库）都提供了一个帮助程序来为您收集流（例如stream.get_final_message()）。您不必手动管理所有曲目；如果您需要全文、处理单个事件但要进行实时打印，请使用此帮助程序。
长响应、max_tokens 和超时
流式传输的第二个也是更具技术性的原因是超时。如果HTTP请求在一定时间内没有完成，客户端就会断开连接。当您请求模型的大量输出（例如 40,000 个令牌的报告）时，非流调用可能会超出此限制并超时 - 请求将失败，您将必须为生成的令牌付费。
现代模型可以在单个请求中输出多达 128,000 个令牌。但经验法则很明确：如果“max_tokens”值很高（大约高于 16,000），则使用流。流式传输使连接保持活动状态并防止超时；您也会立即看到进展。
- `max_tokens`：模型可以产生的最大输出令牌；坚硬的天花板。如果发生中断，则返回 stop_reason max_tokens。
- 上下文窗口：输入+输出之和必须适合的窗口。 max_tokens是输出的上限；不要把两者混为一谈。
注意：抛出具有较大 max_tokens 的非流请求是生产中的一个典型错误。如果没有响应，连接就会断开，用户会看到错误，并且令牌成本会被浪费。长输出=流。
什么时候流动，什么时候不流动？
状态
偏好
为什么
实时聊天/助理
流量
感知延迟下降，用户看到进步
长报告/文件制作
流量
防止超时，安全承载大输出
简短的分类（例如单字标签）
无流量
产量已经很小了；不必要的额外复杂性
批量处理
无流动/间歇式
结果不会立即显示；参见第 7 单元
自动化步骤（在后台）
一般情况下没有流量
您将结果传递到下一步，不实时显示
可复制的提示/模板
流本身不是提示，但提示对于管理流产生的输出至关重要。在长而流畅的制作中，从正面施加结构可以提高质量和可追溯性。
# 将长报告分为几个部分（以便在流程中可以看到进度） 按照以下顺序编写包含以下标题的报告。每个标题以“##”开头：## 摘要## 结果## 建议## 后续步骤
# 给出目标长度以避免长生产中的截断。全文约为 800 字。保持各部分平衡；最后不要留下半句话。
# 立即为流媒体助手提供第一句话。先直接用一句话回答，然后再详细说明。因此用户在等待时可以立即看到结果。
# 保持长输出结构化（以便稍后可以解析）在这些部分中输出输出，并用单独的“###”标头标记每个部分，以便我可以以编程方式解析它： ### INRODUCTION ### BODY ### SOURCES
弱提示/强提示（长制作）
# WEAK就此主题写一份长而详细的报告。
# STRONG就此主题撰写约 900 字的报告。标题：## 摘要、## 分析、## 风险、## 建议。每个标题最多应有 3 个段落。最后不要留下半句话。
强大版本；它预先确定长度、结构和成品质量。当各个部分进入流程时，用户可以清楚地看到进度，并自行管理长度以防止模型中断的风险。
三个迷你箱
案例 1 — 黑屏投诉。一个咨询团队的客户助理在没有流程的情况下做出回应；平均响应时间7秒，用户问“卡住了吗？”他抱怨道。当我进入流程后，第一个单词在大约 0.6 秒内出现；总时间保持不变，但“慢”的抱怨几乎消失了。
案例 2 — 过时的报告。财务团队正在制作一份 30 页的季度报告；使用 max_tokens: 30000 时，无流请求将陷入 60 秒的客户端超时，请求将失败 - 并且生成的令牌将写入发票。他们随波逐流；连接仍然有效，报告已完整交付，并且消除了浪费的成本。
情况 3 — 不必要的流量。运营团队将收到的电子邮件标记为“紧急/常规”；输出是一个词，但他们习惯使用流。该流程对于单字响应没有任何好处，从而使代码变得不必要的复杂。当我切换到无流程时，代码简化了并且行为保持不变。教训：流媒体在长/实时输出中很有价值，但并非在任何地方都有价值。
常见错误
- 不在长输出中使用流：超时和浪费令牌成本。
- 在短输出中使用流式传输：不必要的复杂性，零收益。
- 不在流末尾检查 `stop_reason`：带有 max_tokens 的截断响应被认为是完整的。
- 错误合并增量：使用 SDK 帮助程序进行手动求和会产生序列/缺失部分错误。
- 尝试中途阅读“用法”：令牌编号通常在最后变得清晰；最后跟踪成本。
- 将流媒体误认为是削减成本：流媒体可以提高体验和耐力；它不会改变代币价格。
更深入：流程中断和弹性
流媒体是实时连接；这既是它的优势，也是它的弱点。如果中途连接断开（网络波动、客户端超时），您将保留到目前为止积累的文本，但响应将不完整。生产质量的流客户端应该为此做好准备：它不应该将部分文本视为“已完成的响应”，也不应该在看到 message_stop 事件之前认为响应已完成。
第二个微妙之处是流量不会改变成本。无论您收到有或没有流式传输的响应，都不会影响代币价格；流动只会提高体验和耐力。那么“如果我们采用流媒体，它们会更便宜吗？”问题的答案是否定的——对于成本，看第五和第六单元（模型选择、缓存）。
第三点是要取得实际的平衡：对于实时助手，第一个单词的快速到达（感知延迟）受到高度重视；因此，要求模型直接输入答案并首先给出一个简短的结果（通过第四单元中的系统提示）可以使流程的效益成倍增加。如果用户在第一秒看到一些有意义的内容，他们就会耐心等待接下来的细节。另一方面，该流程对后台运行的作业没有贡献，其输出将进入下一个自动化步骤；唯一的标准是工作是否正确且完整地完成。
综上所述
流式传输逐段检索响应，减少感知延迟并防止大吞吐量超时。对于现场助理和长文档制作来说几乎是强制性的；对于短期/背景工作来说这是不必要的。在长作品中，通过提示从前面强加结构和长度可以提高质量和可追溯性；当流程完成时，肯定会检查 stop_reason 和使用情况。
应用任务
选择两种场景：一种实时/长（例如向客户报告），一种短/背景（例如标记）。 (1) 决定并证明是否要对每个项目使用流程。 (2) 编写一个提示，强加长脚本的结构（标题+目标长度）。 (3)确定max_tokens值。 (4) 列出您将在流程结束时对 stop_reason 和用法执行哪些检查。
清单
- [ ] 我可以解释什么是流媒体以及它如何减少感知延迟。
- [ ] 我了解了流和增量连接的基本事件类型。
- [ ] 我知道需要使用较大的 max_tokens 进行流式传输以及超时关系。
- [ ] 我可以决定在哪些工作负载中使用流式传输，在哪些工作负载中不使用流式传输。
- [ ] 我可以在流末尾检查 stop_reason 和用法。