FW Serverless 2.0：路由模式

GLM 5.2 让开放权重模型持续成为话题焦点，大家纷纷思考如何在生产环境中利用这些开放模型。一旦将开放模型投入生产，在负载下首先出问题的并非输出质量，而是请求能否被成功处理。当共享集群的流量超过可用容量时，Fireworks 可以在生成前拒绝请求，并返回 503 Service Overloaded。传统的解决方案是提前购买容量，要么预留 GPU，要么签订按峰值规模定制的企业合同。这留下了两个糟糕的选择：为不常出现的流量过度配置，或预估不足而在流量高峰时承受失败。

Fireworks Serverless 2.0（@FireworksAI_HQ）将这种固定容量决策转变为每次请求的路由决策。每次调用可以选择处理它的服务层，因此可靠性变成了运行时的控制项，而非采购决策。下面的模式可以在不预先预留 GPU 的情况下，在拥塞期间保持实时流量可用。

三个服务层

Serverless 2.0 在一个 API 和一个端点背后提供了三个服务层。

图 1：三个同步服务路径共享同一个 API 面和同一个集群。优先级通过 service_tier 选择，而 Fast 则使用 Fast 模型 ID。来源：Fireworks Serverless 2.0 公告。

• Standard：适用于日常流量。这是生产调用的默认选项。它运行在弹性共享基础设施上，是最高效的成本路径。在平台负载较高时，Standard 请求将首先被排队或拒绝。

• Priority：用于负载下的可靠性。当丢弃请求有实际成本时（如交互式会话或长时间代理运行），请使用此层。它在拥塞期间获得更强的准入，并且最后被丢弃，但每个请求的价格高于 Standard。

• Fast：适用于对延迟敏感的生成。当挂钟时间（wall-clock generation time）成为瓶颈时（如代理循环、编码工作流和交互式应用），请使用此层。Fast 通过优化服务路径使用相同的模型系列，以获得更高的生成 token 吞吐量，而不是更智能的模型或不同的推理层。

相同的 API 面，无需容量预留。您可以按请求选择一种服务行为。将默认模型保留在 Standard 上，添加 service_tier="priority" 以在拥塞期间获得更强的准入，或切换到 Fast 模型 ID 以获得更高的生成 token 吞吐量。Priority 和 Fast 解决不同的问题，且不可在同一请求上叠加。举个具体例子：一个聊天机器人在 Standard 上正常运行，直到一次发布导致流量激增，Standard 开始返回 503。您无需配置 GPU 或将用户置于队列之后，只需在该端点上添加 service_tier="priority"，即可在高峰期持续服务，待高峰期过后再切换回 Standard。

何时切换层

您不需要提前选择 Standard 或 Priority。全天默认使用 Standard，一旦请求在拥塞时被丢弃（出现 503 Service Overloaded，而非速率限制 429），立即切换到 Priority 持续 30 分钟，然后逐渐回到 Standard。

图 2：升级策略。默认使用 Standard，在遇到 503 Service Overloaded 时切换到 Priority 持续 30 分钟窗口，窗口过期后逐渐回到 Standard。

溢价是一种控制平面权衡，而非新架构。Priority 的成本高于 Standard（针对使用它的请求），因此关键在于只升级那些请求失败会导致用户可见或工作流可见成本的流量。交互式端点和长时间代理运行获得升级路径。批处理任务应使用 Standard、Batch API 或 Background 服务（当重试和排队可接受时）。仅在 503 会浪费昂贵的多步工作时才使用 Priority。

代码

以下代码仅供说明——旨在演示文档化的 Serverless 2.0 模式，而非官方的 Fireworks 代码示例。service_tier="priority" 字段和 503 Service Overloaded 信号来自 Fireworks 文档。控制循环（包括 30 分钟窗口和 priority_until 记录）是我们推荐的实现。

重要部分在于回退的范围。仅在遇到 503 时升级，因为这表明服务容量压力。不要对 429 速率限制、认证错误、无效请求或应用程序异常使用相同的分支。这些是不同的故障模式，不应无声地将流量转移到更昂贵的层。

需要设置的防护措施

• 在指标中跟踪 priority_until、升级次数和 503 率，以便在 Priority 掩盖持续负载时能够察觉。

• 保持升级窗口有界。30 分钟窗口足以度过高峰期，而不会使服务永久提升。

• 按工作负载或按路由应用策略。用户面向的路径可以在遇到 503 时升级到 Priority。评估、离线作业和其他异步批处理工作负载应使用 Standard 或 Background，除非请求失败会浪费昂贵的进度。

• 如果 Priority 连续多个窗口保持激活，则发出警报。这代表着容量或流量整形信号，而不仅仅是临时故障转移。

Priority 的成本

以 Serverless 定价文档为最终依据。在当前定价表中，Kimi K2.7 Code Priority 的定价为 Standard 行的 1.5 倍，而 Kimi K2.7 Code Fast 作为单独的 Fast 模型 ID 定价为 Standard 的 2 倍。不同模型的定价不同，因此始终以文档为准。

操作要点很简单：如果某个工作节点需要在 30 分钟的拥塞窗口内使用 Priority，那么即使有 +50% 的每 token 溢价，当替代方案是多步工作失败时，这仍然是一个有用的权衡。有关更广泛的成本框架，请参考这篇文章，该文报告了在其基准表中，开放工作节点加顾问的设置相比 Opus-as-worker 节省了 19% 至 67% 的成本。

哪种工作负载使用哪个层

该模式在 AI 开发者实际交付的三个场景中尤为重要。

图 3：按工作负载类型路由。当重试可接受时，批处理和离线工作路由到 Standard 或 Background。当挂钟时间是瓶颈时，Fast 仍用于对延迟敏感的生成。

• 面向用户的聊天和代理。 交互式流量对延迟敏感且具有突发性。保持在使用 Standard，让高峰期的第一个 503（发布、病毒式传播）自动升级到 Priority，使用户获得答案而非错误，而您无需盯着仪表盘。

• 长时间代理运行。 单个代理任务会分支出数十个依赖调用，中间一个请求被丢弃可能导致整个运行失败。在遇到第一个 503 后升级到 Priority，可以保护昂贵、多步的工作，其中重试并非免费。

• 批处理和离线作业。 评估、合成数据、批量嵌入、夜间摘要、报告生成、离线分析和数据增强通常更关注吞吐量和完成成本，而非即时响应时间。将这些保持在使用 Standard 或 Background（当重试和排队可接受时）。仅在 503 会浪费昂贵多步工作时才使用 Priority。将 Fast 留给挂钟时间成为瓶颈的对延迟敏感的生成路径。

由于切换是按调用进行的，您可以在一套代码库中运行这些路径。实时端点可以默认使用 Standard 并带有升级防护，长时间运行的工作流可以在 503 威胁完成时升级到 Priority，异步工作节点可以保持在 Standard、Batch 或 Background。无需独立的集群，无需独立的 SDK。

无需集群即可获得可靠性

Serverless 2.0 为团队提供了更多空间，然后才需要专用容量。从 Standard 开始，当过载行为重要时添加 Priority，当挂钟延迟重要时切换到 Fast，当需要硬性保证时预留容量。

链接

• 注册

• 文档

• Serverless 2.0 公告（各层、service_tier 参数和 503 行为）

• 编码模型定价比较