在 AWS Bedrock 中启用或禁用流式响应会通过改变服务和客户端之间的数据传输方式来影响性能。 启用流式传输后，Bedrock 会在数据可用时以增量方式发送数据，从而允许客户端立即处理部分响应。 这降低了最终用户的感知延迟，因为他们能更快地收到初始结果。 然而，流式传输需要保持开放连接，这会增加服务器端资源的使用和客户端的复杂性。 禁用流式传输会强制 Bedrock 在发送整个响应之前生成它，这可能会延迟数据的首字节，但简化了客户端处理并减少了管理部分响应的开销。
例如，在使用 Bedrock 语言模型的实时聊天应用程序中，启用流式传输允许消息逐字符显示，从而创建更具交互性的体验。 客户端可以在接收到文本时呈现文本，而不是等待完整的响应。 相反，禁用流式传输更适合批处理任务，例如生成报告，在这种情况下，客户端需要在继续之前获得完整的输出。 在这种情况下，等待完整的响应可以避免部分数据处理，并确保所有结果在处理前保持一致。 网络状况也很重要：不稳定的连接可能会导致流式传输在传输过程中失败，需要重试，而非流式传输请求要么完全成功，要么完全失败，从而简化了错误恢复。
权衡取决于用例优先级。 流式传输提高了交互式应用程序的用户体验，但增加了管理部分数据、连接超时和错误处理的复杂性。 非流式传输降低了客户端代码的复杂性并确保了原子响应，但增加了等待时间。 开发人员还应考虑 Bedrock 的服务配额：流式传输可能会消耗更多的持续连接，从而可能影响可扩展性。 例如，使用流式传输的高流量 API 可能会比使用批量响应的 API 更快地达到连接限制。 在实际负载下测试这两种方法对于平衡延迟、资源使用和可靠性至关重要。