03-设计方案-openclaw模型选型与稳定性验证方案

OpenClaw模型选型与稳定性验证方案-设计方案

1. 文档目标

本文档用于承接本项目的设计内容，包括整体方案路线、设计原则、实验对象定义、实验分组、指标体系、统计口径和后续验证方法设计。

当前先沉淀 任务3 和 任务4 的阶段性草案，后续继续扩展 任务5 和 任务6。

2. 方案定位与设计原则

本项目定位为一套面向公司 openclaw 使用场景的模型选型与稳定性验证方案。其目的不是做一次性的性能测试，而是形成可复用的验证框架，用于支撑后续模型选型、账号准备和部署规划。

基于当前讨论，项目采用“单实例验证 + 横向扩容验证”的联合路线，重点回答以下决策问题：

• 哪些模型和渠道适合在公司 openclaw 中作为候选主力方案
• 某些渠道在下午等高峰时段是否存在明显的体验恶化
• 单账号或单凭证是否容易成为瓶颈
• 若要保障约 4000 个 openclaw 的稳定使用，是否需要采用多账号、多凭证或主备渠道策略

设计原则如下：

• 主指标以 TTFT 为核心，因为用户对卡顿的第一感知主要来自首字时间
• 主观测面以 openclaw 实际接入效果为准，不以裸 API 表现替代业务体验
• 方案目标是支撑选型和部署决策，而不是输出单纯的性能排名
• 设计上同时覆盖单实例验证和横向扩容验证，以便后续回答账号准备规模问题
• 响应时间评估不能脱离问题类型单独判断，不同问题在输入长度、复杂度、输出长度和输出格式上都会影响 TTFT 与总耗时
• 延迟评估必须按问题类型分组统计，不能用单一题目或单组样本代表模型整体体验
• 一期先形成设计方案和验证框架，具体测试台架、调度方式、日志结构和预算测算可在后续继续细化

3. 实验对象与实验分组

模型分组

• kimi
• glm
• minimax

说明：一期先限定在当前明确提到的候选模型范围内，避免模型池过大导致验证周期失控。

渠道分组

• 官方直连渠道
• 订阅或 plan 类入口
• 三方中转渠道

说明：渠道是本次选型决策的重要变量，必须与模型拆开统计。

认证方式分组

• API Key
• OAuth

说明：认证方式可能对应不同限流策略和稳定性表现，需要单独记录。

特殊分组说明

• kimi 企业账号体系下现有 100 key 中的 key
• kimi 独立账号的单独 API key

说明：kimi 需要把企业账号 key 和独立账号 key 作为正式分组维度纳入，以判断共享资源池与独立账号在稳定性和高峰期表现上的差异。

题目类型分组

• A 组：短问题短回答
• B 组：长上下文问题
• C 组：推理型问题
• D 组：结构化输出问题
• E 组：多轮连续对话问题

说明：每组后续需要固定题目集合，保证跨模型、跨渠道可比。

部署实验组定义

• G1 单实例单凭证组：1 openclaw + 1 agent + 1 credential
• G2 单实例多轮组：1 openclaw + 1 agent + 1 credential，连续多轮对话
• G3 多实例共享凭证组：N openclaw + N agent + 1 credential
• G4 多实例多独立凭证组：N openclaw + N agent + N credential

说明：

• G1 用于看单实例基线体验
• G2 用于看上下文累积影响
• G3 用于识别共享凭证瓶颈
• G4 用于评估横向扩容收益

4. 指标体系与统计口径

主指标

• TTFT：从请求发起到模型返回首个有效字符的时间

说明：TTFT 直接对应用户对“是否卡住”的第一感知，应作为本次一期验证最重要的指标。

辅指标

• 总耗时：从请求发起到完整回答结束的总时间
• 成功率：请求是否成功返回有效结果
• 超时率：在设定时限内未完成返回的比例
• 错误率：接口报错、限流、鉴权失败等异常比例
• 输出长度：回答的字符数或 token 数

说明：主辅指标都需要收集和分析，TTFT 最重要，但不能脱离总耗时、稳定性和输出长度单独判断。

分位统计口径

• P50：代表典型体验
• P90：代表偏差情况下的常见体验
• P95：代表较差情况下的边界体验

说明：均值可以保留，但不能作为主结论，避免被极端值掩盖。

总耗时统计口径

• 按单次请求独立记录
• 从请求发起时刻开始，到最后一个有效输出结束为止
• 对流式和非流式返回使用同一结束判定规则

输出长度统计口径

• 优先记录输出 token 数
• 如果暂时无法稳定获取 token 数，则先记录输出字符数
• 长短回答应分组分析，不能直接混合比较总耗时

样本粒度与分组统计口径

• 统计维度至少包含：模型、渠道、认证方式、题目类型、部署实验组、时段
• 每组样本应使用同一批固定题目，避免样本不一致
• TTFT、总耗时、输出长度都应按题目类型分组统计
• 单组内需要记录成功样本数与失败样本数，防止只统计成功结果

时段口径

• G1：做 24小时 连续观测，平峰每小时一次，高峰时段半小时一次
• G2/G3/G4：按配置时段执行
• 在 G2/G3/G4 中，至少区分上午、下午高峰、晚间三个关键时段

说明：时段是正式统计维度，G1 负责提供全天波动基线，G2/G3/G4 负责关键时段验证。

并发口径

• 单实例串行基线
• 低并发
• 中并发
• 高并发

说明：具体档位数值在后续容量设计中确定，但当前需要先保留并发作为正式统计维度。

5. 规划中的补充考虑：问题类型对响应时间的影响

模型响应时间并不只取决于模型或渠道本身，还会显著受到问题内容影响。对于 openclaw 场景，至少需要把以下因素纳入规划：

• 输入长度：问题越长、上下文越多，通常越容易拉高 TTFT
• 问题复杂度：需要多步推理、归纳或判断的问题，通常会拉长总耗时
• 输出长度：回答越长，总耗时越高，且不同模型之间差异会被放大
• 输出形式：表格、结构化列表、JSON、代码等格式化输出，可能引入额外时延
• 多轮上下文：连续对话下，上下文累积可能导致单轮响应继续变慢

因此，一期验证不应只选择少量单一问题做测速，而应建立题目分组机制，至少区分：

• 短问题短回答
• 长上下文问题
• 推理型问题
• 结构化输出问题
• 多轮连续对话问题

后续统计时，TTFT、总耗时、输出长度应结合题目分组一起看，避免把题目差异误判为模型或渠道差异。

6. 后续待补

6. 验证方法设计

6.1 主观测路径

验证以 openclaw 实际接入链路为主观测路径，不用裸 API 结果替代业务体验。

每次测试统一通过以下路径发起：

• openclaw -> agent -> credential -> model service

每次请求至少记录以下观测项：

• 请求开始时间
• 首字返回时间
• 请求结束时间
• 结果状态
• 输出长度

6.2 固定题库与题目分组

先建立一套固定题库，按以下五类分组：

• 短问题短回答
• 长上下文问题
• 推理型问题
• 结构化输出问题
• 多轮连续对话问题

每类题目先控制为 5 题，先小步验证，优先跑通方法，再根据结果决定是否扩题。

不同模型、渠道、认证方式必须跑同一批题目，避免样本不一致。

6.3 单实例验证方法

先以 G1 单实例单凭证组 作为基线实验组。

验证方法如下：

• 单实例串行执行固定题库
• 在不同时段重复执行
• 记录 TTFT、总耗时、成功率、错误率、输出长度
• 得到各模型、各渠道在低干扰条件下的基线体验

6.4 多轮与上下文验证方法

对 G2 单实例多轮组 单独测试。

验证方法如下：

• 固定连续对话轮次
• 观察同一会话中后续轮次的 TTFT 和总耗时变化
• 判断上下文累积是否会显著拉低体验

6.5 横向扩容验证方法

分别测试以下实验组：

• G3 多实例共享凭证组
• G4 多实例多独立凭证组

重点比较以下问题：

• 共享凭证是否更容易触发瓶颈
• 增加独立凭证后是否显著改善
• 改善幅度是否接近线性

6.6 时段与并发验证方法

时段至少分为：

• 白天高峰时段
• 非高峰时段

并发档位采用绝对并发数定义，不采用相对倍数写法。

当前阶段先保留以下层级：

• 串行基线
• 低并发
• 中并发
• 高并发

具体并发数值在 任务6 中进一步确定。

7. 后续待补

7. 并发与稳定性验证方案

7.1 实验组定义说明

为避免后续执行时混淆，当前实验组定义如下：

• G1 单实例单凭证组：1 openclaw + 1 agent + 1 credential
• G2 单实例多轮组：1 openclaw + 1 agent + 1 credential，连续多轮对话
• G3 多实例共享凭证组：N openclaw + N agent + 1 credential
• G4 多实例多独立凭证组：N openclaw + N agent + N credential

对应用途如下：

• G1 用于观察单路基线体验
• G2 用于观察多轮上下文累积影响
• G3 用于观察共享同一凭证时的瓶颈位置
• G4 用于观察增加独立凭证后的扩容收益

7.2 并发档位设计

并发档位采用绝对并发数定义，首轮验证使用以下档位：

• 1
• 5
• 10
• 20

执行策略采用逐级推进，不直接一次性跑完全部档位：

• 先验证 1
• 1 可接受后再验证 5
• 5 可接受后再验证 10
• 10 可接受后再验证 20

如果某一档已经明显出现瓶颈，则暂停继续向上扩压，避免进行无意义的高档位测试。

7.3 单凭证承载评估思路

目标不是一次性算出最终容量，而是先识别单凭证开始明显劣化的拐点。

建议在 G3 多实例共享凭证组 下，用同一凭证逐步提升并发档位，并记录：

• TTFT
• 总耗时
• 成功率
• 超时率
• 错误率

当出现以下任一情况时，可判定接近单凭证瓶颈：

• TTFT 明显跃升
• 总耗时显著拉长
• 超时率或错误率明显上升
• 高峰时段表现恶化远超非高峰时段

7.4 多独立凭证扩容验证思路

目标是判断横向增加凭证后，体验是否能明显改善，以及改善是否接近线性。

建议在 G4 多实例多独立凭证组 下重复相同档位测试，并与 G3 对比：

• 同档位下 TTFT 是否下降
• 成功率是否提升
• 高峰时段是否更稳定

如果 G4 明显优于 G3，说明共享凭证是核心瓶颈。
如果 G4 提升不明显，说明瓶颈可能不只在凭证侧，还可能在模型服务或渠道侧。

7.5 4000 个 openclaw 的容量推演方法

容量推演不直接从 4000 个实例硬推，而分两步进行：

第一步，先得到单凭证或单账号的可用能力区间：

• 在什么并发档位下仍可接受
• 高峰时段和非高峰时段差多少
• 安全运行建议应取哪个保守值

第二步，按保守值外推所需凭证或账号数：

• 单凭证可稳定支撑的并发能力
• 单实例的平均请求频率
• 高峰时段放大系数
• 预留冗余系数

最终推导：

• 约 4000 个 openclaw 需要多少凭证
• 需要多少账号
• 是否必须主备双渠道

7.6 面向后续更大规模部署的外推原则

为确保本次结果可复用于后续更大规模部署，外推时采用以下原则：

• 容量结论优先使用保守值，不使用最佳值
• 高峰时段数据优先级高于平均时段
• 外推时必须保留冗余，不按理论满载计算

8. 本文档职责

• 作为 任务3：定义实验对象与实验分组 的产出物
• 作为 任务4：定义指标体系与统计口径 的产出物
• 后续继续承接 任务5 和 任务6 的设计内容

9. 费用与资源预算方法

9.1 预算口径

本任务采用决策型口径，不以最低成本为优先，而是以“尽快拿到足够支撑选型和部署决策的结论”为优先。

预算方法需要回答：

• 为了形成可决策结论，需要多少调用成本
• 需要准备多少账号、凭证、实例资源
• 各阶段大致需要多少时间
• 如果扩大模型范围或补测异常点，预算如何变化

9.2 成本拆分维度

预算按以下四类拆分：

• 调用成本：模型调用费用、三方渠道费用、订阅或 plan 成本
• 资源成本：账号数、凭证数、测试实例数
• 执行成本：测试轮次、时段覆盖、并发档位数量
• 人力成本：方案整理、测试执行、结果分析、汇报整理

9.3 调用次数估算方法

总调用次数先按公式估算，不直接拍总量：

总调用次数 = 题目类型数 × 每类题目数 × 模型数 × 渠道数 × 认证方式数 × 时段数 × 实验组数 × 并发档位数 × 重复轮次

当前已知口径如下：

• 题目类型数：5
• 每类题目数：5
• 并发档位数：最多 4，但按逐级推进实际可能少于 4

补充规则如下：

• 决策关键实验组可提高重复轮次
• 非关键补充实验可降低重复轮次

9.4 分步验证规划与时间规划

时间规划拆分为前置准备阶段和执行阶段。

前置准备阶段当前先按约 3天 估算，按并行推进处理，不按事项总和累加。当前纳入并行范围的事项包括：

• 程序准备：约 3天
• 资源准备：约 3天
• 认证配置验证：约 3天
• 题库准备：约 3天

其中：

• 程序准备包括程序规划、程序开发、程序测试与部署联调
• 认证配置验证包括订阅认证在容器或虚拟机环境中的配置与稳定性验证
• 前置准备整体时间按最长路径估算
• 如果订阅认证配置遇到明显阻塞，前置准备时间可能超出 3天

前置准备基本完成后，执行阶段按 5天 规划：

• 第一阶段：方法验证
  • 目标：验证题库、记录口径、实验链路是否可用
  • 建议时间：1天
• 第二阶段：核心验证
  • 目标：覆盖核心模型、核心渠道、关键时段、关键实验组
  • 建议时间：3天
• 第三阶段：补充验证与结论整理
  • 目标：围绕瓶颈点、异常点、边界条件补测，并同步形成阶段性结论
  • 建议时间：1天

补充说明如下：

• 如果方法验证暴露明显问题，后续时间需要顺延
• 如果核心验证较早得到明确结论，补充阶段可只覆盖关键异常点
• 非关键模型、非关键渠道、非关键档位可放到后续轮次，不挤占本轮时间

9.5 账号与凭证资源估算方法

资源估算按“覆盖决策所需范围”反推，不按最小可运行集倒推。

重点看以下问题：

• 为覆盖核心模型和核心渠道，至少需要多少账号
• 为覆盖共享凭证和独立凭证对比，至少需要多少凭证
• 为覆盖高峰与非高峰时段，是否需要并行执行能力
• 为覆盖主备渠道判断，是否需要预先准备双渠道资源

9.6 预算输出方式

预算建议按“阶段 + 区间”输出，而不是单点值。

建议至少拆分为：

• 方法验证阶段预算区间
• 核心验证阶段预算区间
• 补充验证阶段预算区间
• 总预算区间

9.7 预算控制原则

预算控制按决策优先原则执行：

• 优先保障核心决策实验完整性
• 预算不足时先裁剪非关键补充项，不裁剪核心对比组
• 异常点补测优先于无差别扩样本
• 预算输出优先给区间和阶段拆分，不先给单点承诺

10. 执行计划

10.1 执行总体原则

本轮执行以形成可用于决策的阶段性结论为目标，执行方式采用：

• 主流程串行推进
• 资源准备并行展开
• 每一步根据上一阶段结果决定是否开启下一阶段

执行主顺序定义为：

• G1 -> G2 -> G3 -> G4

10.2 首轮验证范围

首轮模型范围全部纳入：

• kimi
• glm
• minimax

认证方式首轮两种都测：

• API Key
• OAuth

其中 kimi 需要额外补充特殊对比场景：

• 企业账号体系下现有 100 key 中的 key
• 独立账号的单独 API key

10.3 题库输入与设计方式

正式题库暂不直接定稿，作为待办输入项保留。

执行方式如下：

• 业务侧后续提供最近生产真实问题样本
• 基于真实样本筛选、归类、补足题型缺口
• 形成首版 25题 候选题库
• 经确认后再作为正式执行题库

正式题库结构按以下五类组织：

• A 组：短问题短回答，5 题
• B 组：长上下文问题，5 题
• C 组：推理型问题，5 题
• D 组：结构化输出问题，5 题
• E 组：多轮连续对话，5 组会话

10.4 前置准备阶段

验证执行前，需要先完成以下准备工作：

• 资源准备
  • 候选模型可用账号确认
  • 渠道接入凭证确认
  • kimi 企业账号 key 与独立账号 key 准备
  • 共享凭证与独立凭证实验条件准备
• 程序准备
  • 实验组配置规则
  • 指标采集规则
  • 日志记录字段
  • 按实验组配置执行
  • 按时段采样
  • 结果记录与汇总
  • 程序测试与部署联调
• 认证配置验证
  • 订阅认证在容器或虚拟机环境中的配置验证
  • 认证信息注入、刷新和持久化验证
  • 自动化执行可行性验证
  • 与 API Key 方式的接入复杂度对比
• 题库准备
  • 生产真实问题样本收集
  • 题目筛选与归类
  • 候选题库确认

前置准备阶段当前先按约 3天 估算，按并行推进处理。

10.5 G1 执行方式

G1 作为基线组，先执行。

定义：

• G1 单实例单凭证组：1 openclaw + 1 agent + 1 credential

执行方式：

• 做 24小时 连续观测
• 平峰每小时采集一次
• 高峰时段半小时采集一次

作用：

• 建立全天波动基线
• 识别高峰与非高峰差异
• 判断链路、数据记录、基线体验是否可解释

G1 跑完后，再决定是否开启 G2。

10.6 G2 执行方式

G2 只在 G1 结果可解释且链路稳定后开启。

定义：

• G2 单实例多轮组：1 openclaw + 1 agent + 1 credential，连续多轮对话

作用：

• 验证上下文累积是否显著影响 TTFT 和总耗时
• 判断多轮对话是否会成为实际体验风险

如果 G2 跑完后结果明确，再决定是否开启 G3。

10.7 G3 执行方式

G3 在完成 G2 后开启，用于验证共享凭证瓶颈。

定义：

• G3 多实例共享凭证组：N openclaw + N agent + 1 credential

执行方式：

• 并发按 1 -> 5 -> 10 -> 20 逐级推进
• 某档出现明显瓶颈则停止继续上探

作用：

• 找出共享凭证开始明显劣化的拐点
• 判断共享凭证是否是核心瓶颈来源

10.8 G4 执行方式

G4 仅在 G3 已观察到瓶颈或疑似瓶颈时开启。

定义：

• G4 多实例多独立凭证组：N openclaw + N agent + N credential

作用：

• 判断增加独立凭证后体验是否显著改善
• 判断扩容收益是否足以支撑资源准备建议

10.9 每阶段是否开启下一组的判断规则

建议门槛如下：

• G1 -> G2
  • 链路稳定
  • 数据记录完整
  • 基线结果可解释
• G2 -> G3
  • 多轮影响已看清
  • 有必要进入共享凭证并发验证
• G3 -> G4
  • 已出现共享凭证瓶颈或疑似瓶颈
  • 需要验证独立凭证扩容收益

10.10 执行阶段排程建议

在前置准备已基本完成的前提下，执行阶段建议如下：

• 第1天：G1 方法验证与基线启动
• 第2天：继续 G1，完成全天基线观测，视结果开启 G2
• 第3天：执行 G2，并根据结果决定是否进入 G3
• 第4天：执行 G3，必要时进入 G4
• 第5天：执行 G4 或补充验证，并整理阶段性结论

10.11 停止条件与补测条件

停止上探条件：

• TTFT 明显跃升
• 错误率或超时率明显升高
• 当前档位已无法支撑正常体验

补测条件：

• 同一组结果波动异常
• 高峰与非高峰差异过大
• G3 与 G4 对比不清晰
• 某模型或渠道结果与预期严重冲突

10.12 输出物

执行完成后至少形成：

• 阶段性验证结果表
• 初步选型与资源建议
• 阶段性结论摘要

11. 后续长期机制规划

11.1 长期机制目标

本次方案不只服务当前约 4000 个 openclaw 的阶段性验证，还要沉淀为后续更大规模部署可复用的模型选型与稳定性验证机制。

长期机制目标如下：

• 后续新增模型时，可以快速复用同一套验证框架
• 后续新增渠道时，可以快速复用同一套比较口径
• 后续部署规模变化时，可以复用同一套容量推演方法
• 后续出现时段波动时，可以复用同一套巡检方法

11.2 一期方案与长期机制的边界

建议明确边界如下：

• 一期方案解决的是：
  • 当前候选模型的首轮选型判断
  • 当前主要渠道和认证方式的验证
  • 当前规模下的容量判断方法
• 长期机制解决的是：
  • 后续模型和渠道的持续纳入
  • 周期性复测与趋势跟踪
  • 容量结论的持续修正
  • 异常波动时的快速复核

11.3 后续可持续巡检方向

长期机制采用按需触发方式，不采用固定周期全量巡检。

建议长期保留以下三类巡检：

• 基线巡检
  • 定期或按需跑 G1
  • 持续观察不同模型和渠道的全天波动
• 多轮体验巡检
  • 按需跑 G2
  • 观察上下文累积影响是否变化
• 容量巡检
  • 在重要模型、重要渠道上按需复核 G3/G4 的瓶颈变化

11.4 模型选型复用机制

建议沉淀以下复用资产：

• 固定实验组定义：G1/G2/G3/G4
• 固定题目类型分组：五类题目框架
• 固定指标体系：TTFT 最重要，同时看总耗时、稳定性和输出长度
• 固定结果对比维度：模型、渠道、认证方式、题目类型、时段、实验组

后续新增模型时，只要套用同一框架，就能快速比较。

11.5 稳定性与承载评估复用机制

建议把稳定性与承载评估沉淀为标准流程：

• 先跑 G1
• 再视情况跑 G2
• 有必要时跑 G3
• 观察到瓶颈后再跑 G4
• 最后按保守值做容量推演

这样后续新增渠道或更大规模部署时，不需要重新从零设计。

11.6 数据沉淀建议

长期机制能否复用，关键在于数据沉淀。

建议长期保留：

• 原始测试记录
• 题目版本信息
• 模型与渠道配置版本
• 关键统计结果
• 每次验证结论摘要

11.7 长期机制的启动条件

建议在以下条件满足后，将本次方法升级为长期机制：

• 一期方案跑通后
• 题库和评估口径稳定后
• 基线验证和稳定性评估能稳定复现后

11.8 长期机制的最小落地形式

长期机制先采用轻量机制，不直接走平台化方向。

最小落地形式包括：

• 一套固定文档模板
• 一套固定实验分组与指标口径
• 一套固定执行脚本或配置
• 一套固定结果汇总格式