+
+
+
+ 01 / decision line
+ 当前最可辩护的结论
+
+
+
0 RPS 严格运行线。
+
严格口径为成功率 ≥ 99.9%、k6 丢弃迭代为 0,并同时观察 P99。
+
+
+
357.56
+
ms · strict point P99
+
低负载 P50 增量 未运行;流式首内容 P50 增量 未运行。
+
+
+
+
0 RPS5007501,0001,5002,000
+
+
+
+
+
+
+
0–500稳定区
+
500–750严格 SLO 区
+
750–1,000边缘区
+
1,500+过载塌陷区
+
+
+
+
+
+
+
+
02 / load envelope
容量、吞吐与尾延迟
+
闭环并发回答“固定并发下能跑多快”,开环到达率回答“给定业务流量能不能准时接住”。生产容量线应以后者为主,前者用于观察调度和平台形状。
+
+
+
+ 闭环网关吞吐
+ 每档并发按重复运行取中位数;闭环峰值用于定位吞吐拐点,不等同于生产 SLO。
+
+
+
+ 闭环 P99
+ 同时展示 P50 与 P99,便于识别并发上升后是否出现排队和尾延迟放大。
+
+
+
+
+
+ 开环:目标、实际与丢弃
+
+
+
+ 开环:成功率与 P99
+
+
+
+
+ 1,500 RPS 的问题发生在上游之前,但本轮证据还不足以定位代码。
+ 一个代表性 case 中,42,938 个 HTTP 请求只有 24,462 个到达假上游并成功,另有 18,476 个 5xx,P99 约 3.0 秒。假上游最大 active 只有个位数;这排除了“假 LLM 被打满”,却不能在缺少与主运行重叠的网关日志、容器资源和 Prometheus 时序时继续下结论。
+
+
+
直连基线 vs 网关增量
+
直连假上游在高并发时把客户端 CPU 打到 99% 以上;网关 case 的客户端 CPU 峰值仅约 10–12%。因此,摘要里的“客户端可能限制容量”只适用于直连高吞吐基线,不足以解释网关约 1.25k RPS 的平台。
+
| 并发 | 直连 RPS | 网关 RPS | 网关/直连 | P50 增量 | P99 增量 |
|---|
+
+
+
+
+
+
03 / server-sent events
SSE 回放与逐 Chunk 观测
+
独立 stream loader 记录 headers、首事件、首内容、总耗时和 chunk 间隔;请求数、并发和重复次数均取自本次运行元数据。
+
+
+
+
+ 首内容与总完成时间
+
+
+
+ 怎么解读
+
+
+
+
+
+
+
+
04 / failure semantics
缓存、故障恢复、队列与耐久
+
这一组不是单纯追求成功率:error10 和 queue overload 会有意制造可接受错误。报告将“测试断言成功”和“业务 HTTP 2xx”分开。
+
+
+
+
+ 17 项可靠性断言
+
+
+
+ 本次可靠性诊断
+
+
+
+
+
+
+
+
05 / hot path
请求阶段、依赖池与错误码
+
每个 case 使用开始前和结束后的 Prometheus 累计值做差。阶段分位数来自 Histogram;reliability 包含 Queue、Provider、Retry 和 Fallback,因此不能与其子阶段相加。
+
+
+
+
+
+
+
+ 阶段 P99
+
+
+
+ 阶段分位数
+
+
| 阶段 | 样本 | avg ms | P50 ms | P95 ms | P99 ms |
|---|
+
+
+
+
+ 该 case 的网关错误码
+
+
+
+
+
+
+
+
06 / runtime envelope
客户端、网关容器与镜像
+
资源数据只使用与 case 时间窗重叠的采样;同时展示客户端负载生成器、网关容器内存和最终镜像体积。
+
+
+
+
+ 按阶段 CPU 峰值
+
+
+
+ 按阶段资源明细
+ | 阶段 | 样本 | CPU avg | CPU max | 内存 max | k6 RSS max |
|---|
+
+
+
+ 服务器采集窗口对齐
+ | 文件 | 类型 | 与主运行关系 | 采样 | 开始 UTC | 结束 UTC | 资源峰值 |
|---|
+
+ 服务器侧文件存在,但没有覆盖主运行。
+
+
+
+
+
07 / evidence audit
哪些结论能说,哪些还不能
+
“文件不存在”不是“指标为零”。尤其是 Usage:自动摘要把缺失证据显示成 observed=0,但这不能解释为 243 万事件全部丢失。
+
+
+
+
+ 四次运行痕迹
+
+
+
+ 证据审计结论
+ 本轮是一次完整、可用于建立容量包络的客户端侧实验,但还不是一次可直接驱动代码改动的服务器侧性能剖析。
+ 下一轮必须让网关/上游容器 stats、Prometheus、gateway evidence、错误响应分类和网关日志真正覆盖客户端主运行窗口。做到后,1,500 RPS 的 5xx 才能直接映射到 Queue wait timeout、Breaker、Redis、DB pool 或 Usage 链路。
+ 主运行使用提交 ,且客户端 worktree=dirty。当前工作区之后的参数改动不属于这次实测。
+
+
+
+
+
+
+
08 / external reference
和其他网关怎么比
+
唯一公平的排名来自同一硬件、同一客户端、同一假上游、同一功能开关。本节只提供公开结果的方向性坐标,不宣布跨环境“胜负”。
+
+
+
+ 独立 CI 的低负载开销参考
+ 外部项目在同一 neutral CI runner + mock upstream 上测得 Bifrost、Portkey OSS 和 LiteLLM;Model‑Velo 条目来自本次三机 c=1 P50 直连差值,拓扑不同,用斜纹标记。
+
+ 方向上,Model‑Velo 3.12 ms 位于该外部 Portkey 2.69 ms 与 LiteLLM 5.41 ms 之间,明显高于 Bifrost 0.56 ms;这只是“值得继续优化”的信号,不是同场排名。
+
+
+ 厂商自报与项目公开状态
+
+ | 网关 | 公开数字 | 能否直接比 |
+
+ | Bifrost | t3.medium 2 vCPU / 4GB,5k RPS、100% 成功;自报内部 overhead 59µs | 不能 排除项和 2.12s 上游不同 |
+ | Portkey OSS | 项目 README 声称 <1ms;独立 CI 复现为 2.69ms | 方向参考 |
+ | LiteLLM | 本次检索未找到官方、可复现、同类自托管 RPS 基线;独立 CI 为 5.41ms | 方向参考 |
+ | GoModel | 官方仓库未发布可复现 benchmark 数字 | 暂无数据 |
+ | Model‑Velo | 本次:严格 750 RPS;低负载 P50 +3.12ms;SSE TTFT P50 +5.37ms | 本轮实测 |
+
+
+
+
+ 为什么不把 Bifrost 的 5,000 RPS 画进同一吞吐柱图?Bifrost 页面使用 0.13KB 请求、1.37KB 响应、平均端到端 2.12s,并将 JSON marshalling 和 HTTP 调用排除在“59µs overhead”之外;本次 Model‑Velo 是跨三台私网服务器、完整鉴权/限流/缓存/可靠性/Usage 路径。放在一根柱图里会制造虚假的精确性。
+ 来源与核对日期(2026‑07‑27)
+
+
+
+
+
+
09 / reproducibility
环境、配置与测量口径
+
本报告对应测试提交,不对应当前未提交工作区。所有时间为 UTC;私网地址仅用于复盘三机拓扑。
+
+
+
+ 测试矩阵
+
+
+
+ 客户端环境
+
+
+
+ 查看完整 client-metadata.txt
+
+
+
+
+
10 / complete case ledger
全部测试 Case
+
这里列出本次实际生成的全部 case;数值保留到足以回查同目录原始 JSON 和日志。
+
+
+
+
+
+
+
+
+ | Case | 阶段 | 目标 | 负载 | 重复 | 请求 | RPS | 成功 | P50 | P95 | P99 | Dropped | 上游 calls | 原始文件 |
+
+
+
+
+
+
+
+
+
11 / raw evidence
原始产物索引
+
主运行目录内的每个文件都列在这里。日志和 JSON 链接使用相对路径,保持本 HTML 与结果目录一起移动即可打开。
+
+
+
+
+ 查看本报告内嵌数据说明
summary.html 内嵌 summary.json、client-metadata.txt、client-stats.jsonl 的解析结果、运行尝试目录摘要、可靠性断言名称和产物索引。原始 k6 日志与每个 case 的 JSON 不重复嵌入,使用同目录相对链接访问。
+
+
+
+
+