执行摘要
本PR修复了Anthropic API入口因使用挂钟时间（time.time()）而非单调时间（monotonic_time()）记录请求接收时间，导致下游Prometheus指标（如TTFT和端到端延迟）出现大负值的问题。变更仅影响指标收集，不影响模型输出，是OpenAI入口类似修复的扩展，提升生产环境监控准确性。
功能与动机
问题背景：Issue #22249报告Anthropic API入口（serving.py）使用time.time()（挂钟时间，约1.7e9）记录received_time，而下游req_time_stats.py使用time.perf_counter()（单调时间，约1e5）计算延迟差值，时钟不匹配导致Prometheus直方图出现大负值。生产环境中发现Anthropic请求在Grafana仪表板持续显示负TTFT和延迟。
关联修复：OpenAI入口已在PR #17640修复为使用monotonic_time()，但Anthropic入口被遗漏。本PR旨在统一时钟使用，确保指标准确性。
实现拆解
修改文件：python/sglang/srt/entrypoints/anthropic/serving.py
| 变更点 |
修改前 |
修改后 |
说明 |
| 导入 |
- |
from sglang.srt.observability.req_time_stats import monotonic_time |
引入单调时间函数 |
| 非流处理（第317行） |
received_time = time.time() |
received_time = monotonic_time() |
使用单调时钟记录接收时间 |
| 流处理（第373行） |
received_time = time.time() |
received_time = monotonic_time() |
同上 |
关键细节：
received_time_perf变量保持不变，用于本地validation_time计算。monotonic_time()是time.perf_counter()的别名，确保与下游指标计算时钟一致。
评论区精华
gemini-code-assist[bot]在review中提出优化建议：
由于monotonic_time是time.perf_counter()的别名，received_time和received_time_perf现在持有相同值。应考虑合并赋值以避免冗余时钟调用并提高清晰度，例如：received_time = received_time_perf = monotonic_time()。
但PR作者未采纳该建议，最终代码保留两个独立变量。可能原因：received_time_perf用于本地验证时间计算，但未在讨论中明确说明。JustinTong0323直接批准PR。
风险与影响
风险分析：
- 极低风险：仅更改时间戳来源，不影响核心请求处理或模型输出。
- 使用单调时钟避免挂钟调整（如NTP同步）影响延迟测量，提升指标准确性。
- 潜在轻微性能开销：未合并冗余赋值导致两次调用同一函数，但影响可忽略。
影响评估：
- 用户：修复生产监控指标，使Anthropic API的TTFT和端到端延迟指标恢复为正确定值。
- 系统：仅影响Prometheus指标收集，不改变请求处理行为。
- 团队：统一Anthropic和OpenAI入口的时钟使用，减少维护不一致性。
关联脉络
- PR #17640：OpenAI入口的相同修复，本PR扩展至Anthropic入口，体现跨入口一致性维护。
- PR #22726：同属observability标签，涉及Prometheus指标改进，反映团队对可观测性的持续投入。
- PR #21646：修改相同文件
req_time_stats.py，涉及指标计算优化，显示该模块的活跃演进。
整体趋势：sglang项目近期多个PR关注监控指标准确性（如#22726、#22331、#22506），本PR是这一方向的延续，强调生产环境可观测性的重要性。
参与讨论