feat(perf): 容量压测器 + 平台天花板实测曲线

cmd/loadtest：闭环加压器，阶梯并发，经 SSE 流检测完成（非轮询，避免轮询放大把网关
压成假瓶颈），输出吞吐 + 延迟分位。配套两个 benchmark 开关：
- dispatcher LLM_FORCE_STUB=1 + LLM_STUB_TTFT_MS/INTERTOKEN_MS=0：绕开真实 LLM 推理，
  量平台自身全链路天花板（不烧 token、不被模型节奏掩盖）。
- gateway RATE_LIMIT_PER_MIN 可配（缺省 120）：压测放开限流。

实测（单 dispatcher、并发64、stub）：
- 单任务纯平台开销 ~42ms；吞吐峰值 ~110 全链路任务/秒（饱和点 并发32–64）；
  并发128 优雅降速，256 硬崩。
- 吞吐瓶颈不是 DB 连接数（池 25→80 吞吐不变），是每任务多跳管线综合成本；
  256 崩根因为 DSN 用 localhost、pgx 每连接解析 → 连接churn致 DNS 取消（易修）。
- 关键判断：平台 42ms ≪ LLM 秒级出答案，平台不是瓶颈、GPU 才是；横向拆服务喂满 GPU 集群
  的意义成立。细节与曲线见 project_analysis「容量实测」。

stub 延迟改 env 可配（默认值不变）；不影响线上路径。dispatcher+gateway build/vet/test 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

project_analysis.md

@@ -203,7 +203,7 @@ Harness = 围绕 LLM 的可靠性 / 安全 / 质量治理层。4 个组件均为
 
 | 优先级 | 项目 | 说明 |
 |:------:|------|------|
-| P0 | 真实负载 + 长稳压测，给容量曲线 | "生产级并发"需数据背书 |
+| ~~P0~~ 🟡 | ~~容量压测曲线~~（首版）：`cmd/loadtest` 闭环加压器 + 平台天花板实测（见下「容量实测」）。剩长稳/真实 LLM 大压 | "生产级并发"需数据背书 |
 | ~~P0~~ ✅ | ~~本地模型(vLLM/Ollama) + reasoning_content 适配~~：Pool provider 感知（Ollama/vLLM 自动补 /v1 + 占位 key），统一走 OpenAI 兼容路径；ChatStream 加 onReasoning，思考过程 surface 到 exec 轨迹（不污染答案）。控制台加 ollama 选项。live：Ollama qwen2.5:0.5b 端到端出答案；deepseek-v4-pro「推理过程」入轨迹 | 对齐生产 Qwen |
 | P1 | 高可用：网关/调度多副本 + NATS 集群 + 自愈 | 解单点 |
 | P1 | 备份/灾备演练（PG/Milvus/Neo4j） | 数据安全 |
@@ -215,5 +215,34 @@ Harness = 围绕 LLM 的可靠性 / 安全 / 质量治理层。4 个组件均为
 
 ---
 
+## 容量实测（首版，2026-06-26）
+
+**方法**：`cmd/loadtest` 闭环加压（阶梯并发，SSE 流检测完成、非轮询，避免轮询放大）。
+dispatcher 开 `LLM_FORCE_STUB=1 LLM_STUB_*_MS=0` 绕开真实 LLM 推理，量**平台自身全链路天花板**
+（网关→NATS/JetStream→调度→图执行→工具RTT→Token回流→PG状态写），单 dispatcher、DISPATCHER_CONCURRENCY=64。
+
+| 并发 | 吞吐/s | p50 | p95 | 备注 |
+|---:|---:|---:|---:|---|
+| 1 | 23 | 42ms | 46ms | **单任务纯平台开销 ~42ms** |
+| 8 | 76 | 103ms | 115ms | |
+| 16 | 96 | 161ms | 176ms | |
+| 32 | 112 | 269ms | 345ms | **吞吐峰值** |
+| 64 | 112 | 557ms | 676ms | 饱和（延迟翻倍、吞吐不增）|
+| 128 | 102 | 1173ms | 1590ms | 过载、优雅降速 |
+| 256 | 0 | — | — | 硬崩（连接/DNS 抖动）|
+
+**结论**：
+1. **单节点平台天花板 ≈ 110 全链路任务/秒**，单任务固有开销 ~42ms，饱和点 ~并发 32–64。
+2. **吞吐瓶颈不是 DB 连接数**（池 25→80 吞吐不变），而是每任务多跳管线（JetStream fsync + 多次
+   NATS 回写 + Redis 录制 + 3 次 PG 状态写）的综合成本。
+3. **C=256 硬崩**根因：DSN 用 `localhost`，pgx 每新建连接解析一次，极端并发下连接churn致 DNS 取消
+   → 易修（DSN 换 `127.0.0.1` / 连接复用）。
+4. **关键判断**：平台开销 42ms ≪ 真实 LLM 出一轮答案的秒级延迟，**平台不是瓶颈，GPU 才是**。
+   单 GPU 跑 Qwen 32B 约出几十轮/秒，远低于平台的 ~110/s → 横向拆服务（队列组多副本喂满 GPU 集群）
+   的意义成立；要提总吞吐应加 dispatcher 副本与 GPU，而非优化平台代码。
+5. 待补：长稳（小时级）压测看内存/句柄泄漏；真实 LLM 端到端容量（受 provider 限流，需自部署后测）。
+
+---
+
 *本报告由 Opus 4.8 基于全程搭建经验 + 本次实测撰写；刻意压低自评水分。功能盘点可信，
 评分按成熟度折扣阅读。如与旧版（自动分析）冲突，以本版为准。*