AWS为SageMaker AI双向流式推理新增用量计量通道，支持模型供应商在实时会话中向AWS Marketplace增量报告消费，并据此结算软件费，Deepgram为首发合作方。该机制不改变端点基础设施单独计费的方式，也不意味着总成本必然下降，企业仍需核对计量单位、账单一致性和连接异常时的服务策略。
亚马逊云服务（AWS）于2026年11月11日宣布，为Amazon SageMaker AI双向流式推理增加用量计量机制，让模型供应商能够在实时会话进行期间，向AWS Marketplace报告消费量并据此收取软件费用。语音AI公司Deepgram是首发合作方，应用范围包括语音识别和语音合成。
这项变化并不是首次推出双向流式推理，也不是让托管模型的全部开销改为按音频用量支付。AWS公告明确区分两笔费用：模型供应商的软件费可以依据上报的消费单位结算，而承载模型的SageMaker AI端点基础设施费用仍然另计。即使没有音频正在处理，已配置的端点仍可能持续产生基础设施费用。
对于实时客服、语音智能体和字幕服务，变化的核心是如何为一段持续进行的对话记账，而不是模型识别得更准、响应得更快，或账单必然更低。
为什么长连接需要另一套计量方式
在传统请求—响应推理中，模型服务器可以在HTTP响应头中报告消费单位。请求结束时，用了多少资源通常已经确定，AWS Marketplace据此计算软件费用。
但实时语音会话可能持续几十秒，也可能持续几十分钟。用户不断发送音频，模型不断返回转写或其他结果，用量随会话增长，最终总量要到结束时才知道。只依靠最初的响应头，无法在会话中持续报告新增消费。
AWS此前已经推出SageMaker AI实时推理的双向流式通信。客户端通过HTTP/2与SageMaker交互，SageMaker再通过WebSocket连接模型服务器。此次新增的是配套的软件用量报告通道，而非重新建立这套通信能力。
具体而言，模型服务器声明支持后，SageMaker会在原有推理数据连接旁，再建立一条专门传送计量信息的WebSocket连接。两条连接通过同一个请求标识关联：一条传输音频和推理结果，另一条记录对应会话新增的消费量。
AWS建议随用量累积逐步报告，而不是把全部记录留到会话结束。这可以减少异常中断时尚未上报的用量。每个文本帧只能包含一条计量记录，每条连接最多每秒发送一条消息，消息上限为512字节。供应商可以定期合并新增消费单位，但不能把多条记录打包成一个记录数组发送。
“按请求”标签不等于每次调用只计一个单位
新机制使用名为inference.count的计费维度，通过ConsumedUnits字段报告自上一条记录以来消耗的单位。这里的“count”不能直接理解为请求次数：一个单位代表什么，取决于模型产品的计量定义，以及Marketplace报价中的单位与价格映射。
例如，若某项产品按可计费音频秒数收费，12分钟这样的音频对应720个单位。但一条连接保持打开12分钟，并不能单独证明产生了720个可计费单位。供应商如何界定被计量的音频，仍是决定软件账单的关键。
AWS还说明，Marketplace页面会以“per request”标签显示单位价格，显示精度最多为小数点后三位。这种展示方式不能代替产品的实际计量规则。Deepgram Nova-3单语流式语音识别产品页同时展示按音频分钟描述的收费说明和“按请求”的定价维度。买方需要核对具体报价如何将音频用量映射为账单单位，而不能仅根据页面标签自行换算，也不能把一个产品的费率套用于全部语音模型。
按AWS的介绍，Deepgram模型服务器负责自动计算并上报计量数据，使用方无需在客户端另行配置这条计量通道。对于其他模型供应商，则需要在服务器端接入，并明确单位定义和异常处理方式。
计量连接断开时，继续服务还是停止推理？
把推理数据与计量记录分开，也带来一个直接的经营取舍：音频还能处理，但负责记账的连接已经不可用时，服务是否应继续？
AWS的默认行为是继续推理。X-Amzn-SageMaker-Metadata-Stream-Required默认值为false；元数据连接建立失败或中途断开，不会自动终止原有数据流。如果供应商把这个标志设为true，计量连接不可用时，推理数据流也会终止。
前者优先保障业务连续性，却可能留下未报告的软件消费；后者优先维持计量连续性，却可能中断正在进行的语音会话。这不是单纯的技术参数，而是供应商需要结合客户服务承诺作出的选择。
强制要求计量连接也不等于保证每条记录都能结算。格式错误的消息仍可能被丢弃，超过发送速率也可能造成消息丢失。可选的ClientToken支持同一连接内的重复记录去重，但不能据此推导出跨连接、端到端的完整计费保证。AWS明确提醒，传输层成功送达，并不能证明消费已经进入账单。
软件用量更清晰，不代表总成本自动下降
对买方而言，这项机制的直接价值是把流式模型软件消费纳入AWS统一账单，并可通过Marketplace私有报价协商单位费率或固定价格合同。与按模型可用时间收取软件费相比，它为按实际消费结算提供了基础，但最终费用仍取决于产品规则、合同和真实负载。
基础设施是另一层成本。即使软件费随着可计量消费变化，端点配置、实例选择、闲置时间和容量利用率仍会影响总账单。本站此前报道的SageMaker GPU分区功能处理的是硬件资源如何共享、提高部署密度的问题；此次流式计量处理的是模型软件消费如何记录。两者不能混为一种降价措施。
对供应商而言，接通计量接口只是起点。AWS Marketplace产品生命周期文档说明，新产品可以先在Limited状态下，仅向创建者和允许名单中的账户开放测试，完成验证后再转为公开可订阅产品。
AWS建议在这一阶段使用已知消费量测试，把模型服务器记录、卖方用量报告和买方实际收费逐项核对；不仅测试正常结束，也要覆盖会话中断、计量连接丢失和格式错误等情况。测试完成后还需删除不再使用的端点，避免基础设施费用继续累积。
这项更新补上了实时语音模型商业化的一环：持续进行的会话终于有了配套的增量软件计量通道。但它没有消除单位定义、账单对账和服务连续性的难题。对企业来说，真正需要确认的仍是三件事：哪些音频被收费、上报用量是否与账单一致，以及在满足业务可用性要求后，软件和基础设施合计需要多少钱。