维持您的 AI 功能处于快速并有着灵敏的响应度

概述（Overview）

请求延迟会直接影响用户体验。缓慢的 AI 响应不仅让用户感到沮丧，更可能造成实时应用崩溃。ModelRiver 会捕获每一个请求的持续时间指标，使您能够全面监控整体性能走向、识别排查瓶颈原因部位、并有助于指导您对供应商及模型选型做出明智的抉择。

深入了解各项性能数据指标

持续时间（Duration）指标测量

在请求日志列表中，Duration（请求持续所耗用的毫秒时间数） 列显示的数字即为从请求送达到供应商再到成功收到他们下发回传完整数据期间所实际流逝走过的大致总延迟总时长。

Duration 中所包含的项目：

• 发向供应商之间的网络交互往返由于传输引发的数据包路途耗时表现
• 服务端供应商自己系统上的执行推理等算力运转处理消耗用时
• 服务器返回响应时产生的传回流逝传输时段长

Duration 不包含的部分：

• ModelRiver 本身路由阶段产生的那些微小运行用时情况
• Webhook 数据负载下发的专门派送流逝时间（会受到独立观测记录追踪管控）
• 回调（Callback）发回服务端的等待处理业务端等答复操作的各等待耗用期限时长情况等（作单独观测管控）

在时间线（timeline）结构之中的持续时间表现

详细情况页面板的时间线会展现记录全部的各阶段情况持续消耗掉的真实耗时数据：

• 故障转移尝试历经（Failover attempts） – 每一笔以失败而收场的各项尝试所持续的过程时段。
• 主请求时段（Main request） – 真正那一个获致完好响应结果的有效执行经历的持续操作的时长表现。
• Webhooks 发送到达（Webhook deliveries） – 为了去将载好的包裹等抛到且交付传递发运给您终端服务器的传输历经时间。
• 服务端各类执行及最终后备回传答复表现（Backend callbacks） – 给由出您的端对数据作业务流和返回的加工处理反应长。

可感知总延迟值（Total perceived latency） 等同于全部各项故障耗时相加 + 获取响应请求耗长（同步调用类）+ 如果是触发异步，则需在此前两者由于等待产生的表现上等并附加上了 webhook 等各耗时及 callback 给出的最后操作答复完成长。

性能监控工作流

步骤 1：找出响应缓慢的请求

1. 在你的项目控制台中打开 Request Logs（请求日志）
2. 过滤处在 Live mode（实时模式） 的生产环境日志
3. 阅览关注 Duration（持续时间） 这一列的数据
4. 筛查那些远超系统正常水准的高延迟请求项目

步骤 2：分析根本原因

点击慢速请求，探看发生这种延迟的可能原因：

• 出现了多次故障转移尝试？ – 每跌落一次发生重试就会徒增大量的空转耗时。
• 提供商本身就慢？ – 可比较不同供应商在这方面的耗时能力。
• Token 开销太大了？ – 处理长文本无疑极大地迟滞了解析与生成表现。
• 模型体量过于巨大？ – 复杂模型普遍比小模型的推理要费时许多。

步骤 3：跨服务商对比参考

复看数据记录，以构建出一幅具有参考意义的数据表格：

步骤 4：着手予以优化

根据你的总结：

• 给后备列表调换排序 – 最快最强力的该提放到首位。
• 换用更轻巧的模型 – 轻模型能以惊人的时间做出回执响应。
• 减去提示语长度 – 所要面对的内容更少解析得也自当更快。
• 巧设 max_tokens 参数 – 切断模型无止尽思考生成。
• 引入并启用异步工作流机制 – 对延时不敏感的应用去排队执行异步调用即可。

需监控的典型性能模式

在绝大部分调用长久地均保持高延迟

症状特征： 打向特定目标的请求总是很耗时。 诊断与处理：

• 此提供商的业务正遭到限压降低系统处理效力。
• 此类大模型处理推理过程生来就较迟缓。
• 请考虑使用或是调用别家更为快捷灵敏的供应商。

发作呈现间歇性的偶发延迟突增爆表

症状特征： 只有偶发部分时候才突然发慢。 诊断与处理：

• 疑似触发对方速率等限制进而发生排队降阻。
• 利用供应商可靠度总览面版观测失效是否有共性。
• 可能属于物理基础设施遭遇临时冲击。

在较长周期时间维度上延迟变得日益缓慢

症状特征： 数月以来的平均时长呈现逐渐上涨恶化。 诊断与处理：

• 您的 Prompt 上下文是否在产品迭代更迭过程里逐渐堆叠堆高。
• 大体量产出被未受到严格设置把控。
• 按周期比对和控制 Token 用量增加趋态。

隐藏在表面正常数字背后的暗耗时

症状特征： 请求绿灯放行，只耗时奇高异样。 诊断与处理：

• 表面看成功实乃中间失败了好几次耗费等待时间。
• 去 供应商可靠度展示区 去掉不合格提供商。

建立您的参照与标准性能基线

建立合理的基线标准

1. 分析提取系统连续正常工作时的周度情况作为标尺样本。
2. 为你的所有主力系统架构确定好其该有参考指标值。
3. 把这种在接受范畴内的抖动误差值纳入。

以基准做偏差警报

• 超了 2 倍耗时： 可列入值得后续留意复核之列。
• 超了 5 倍耗时： 当即触发介入排查和介入治理应对管理。
• 出现连续的极小的缓步上升趋势： 预示着某些系统底层或者隐性问题可能出现。

关于在性能速度与造价花费彼此间考量

通常在这之间成明显的互相牵制效果：

请查阅 成本监控 掌握详细技巧。

后续引导

• 分析供应商稳定性 – 排查失效拖沓原因
• 深入做成本诊断 – 控制花销兼顾响应速度要求
• 应用调试诊断 – 找出是哪一项具体发来的异常慢请求
• 精研日志时间线 – 学会认清每个不同模块花去的时间
• 可观测性一栏 – 掌握总控视图的构成使用