Loading... # 未进行基准测试的 LLM，您可能多付 5-10 倍费用 # 一、新闻概述 ## 1. 标题 未进行基准测试的 LLM，您可能多付 5-10 倍费用 ## 2. 发布时间 2026 年 1 月 21 日 ## 3. 来源 Karl Lorey 技术博客 # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 作者帮助一位朋友通过自定义基准测试，将其 LLM API 账单降低了 80%，每月节省超过 1000 美元。 ### B. 核心亮点 - 公开基准无法预测特定任务性能 - 自定义基准测试发现性价比更高的模型 - 使用 LLM-as-judge 方法自动化评估 - 帕累托前沿理论应用于模型选择 ## 2. 关键信息 ### A. 案例背景 - 初始成本：每月 1500 美元（GPT-5） - 优化后成本：每月 300 美元 - 节省比例：80% - 测试模型数量：100+ ### B. 涉及技术 - OpenRouter API（统一接口访问多个 LLM） - LLM-as-judge（模型作为评分者） - 帕累托前沿（Pareto Frontier） ## 3. 背景介绍 ### A. 问题根源 大多数用户选择 LLM 时依赖公开基准（如 GPQA Diamond、AIME、MMLU），但这些基准无法预测模型在特定任务上的表现。 ### B. 相关上下文 作者基于此案例开发了 Evalry 工具，用于自动化基准测试流程。 # 三、详细报道 ## 1. 主要内容 ### A. 公开基准的局限性 常见的 LLM 基准包括：GPQA Diamond、AIME、SWE Bench、MATH 500、Humanity's Last Exam、ARC-AGI、MMLU。 **核心问题**： - 在推理基准中名列前茅的模型，可能在损失成本估算任务上表现平平 - 基准不反映实际成本 - 无法预测特定业务场景的性能 ### B. 自定义基准测试流程 ```mermaid graph TD A[收集真实案例] --> B[定义预期输出] B --> C[创建基准数据集] C --> D[运行所有模型] D --> E[LLM-as-judge 评分] E --> F[分析质量/成本/延迟] ```   #### 步骤 1：收集真实案例 - 通过 WHAPI 提取实际支持聊天记录 - 每条记录包含：对话历史、客户最新消息、实际响应 - 选择约 50 个聊天案例（涵盖常见问题和边缘情况） #### 步骤 2：定义预期输出 为每个案例设定明确的标准： 示例 1： > 一个好的答案应告诉客户该产品价格为 5.99，并主动提供立即下单服务。 示例 2： > 一个好的答案应告知客户退货政策提供 30 天退货期，但客户是在收货两个月后才退货，因此不符合政策。 #### 步骤 3：创建基准数据集 数据格式：提示词（对话 + 指令）+ 预期响应 #### 步骤 4：运行所有模型 使用 OpenRouter 统一接口访问 100+ LLM： ```python from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="<OPENROUTER_API_KEY>", ) completion = client.chat.completions.create( model="openai/gpt-5", # 或 "anthropic/claude-opus-4.5", "google/gemini-3-pro-preview" messages=[{"role": "user", "content": "Hello!"}] ) ``` #### 步骤 5：LLM-as-judge 评分 - 使用 Claude Opus 4.5 对每个响应进行 1-10 分评分 - 提供具体的评分标准以确保一致性 - 抽样验证评分的可靠性 - 要求模型给出评分理由 ### C. 模型选择决策框架 考虑三个维度： 1. **质量**：LLM-as-judge 评分 2. **成本**：每个答案的总成本（而非每 token 成本） 3. **延迟**：完整响应时间 ```mermaid graph LR X[成本] --> Y[质量] Y --> Z[帕累托前沿] X --> Z ```   **帕累托前沿定义**： > 在给定成本和质量的基准测试中，不存在另一个模型既更便宜又更好的模型集合。这些模型构成了帕累托前沿，即给定价格下的最佳模型选择。 ## 2. 技术细节 ### A. 成本测量 为什么不能只比较 token 价格： - 响应 token（思考 + 实际答案）成本更高 - 不同模型的答案 token 数量差异显著 - 需要测量每个答案的总成本 ### B. 延迟测量 - 对于客户支持：响应时间至关重要 - 对于损失成本估算：质量优先，延迟次要 - 聊天应用需要考虑首 token 时间 ### C. 质量评分 ```mermaid sequenceDiagram participant D as 基准数据集 participant M as 待测模型 participant J as 评判模型(Opus) participant U as 用户 D->>M: 发送提示词 M->>J: 返回响应 D->>J: 发送预期输出 J->>J: 评分(1-10) + 理由 J->>U: 返回评分结果 ```   ## 3. 数据与事实 ### A. 成本对比 | 项目 | 优化前 | 优化后 | 节省 | |------|--------|--------|------| | 月度费用 | 1500 美元 | 300 美元 | 80% | | 模型选择 | GPT-5 | 性价比模型 | - | ### B. 性价比差异 - 最高可达 10 倍成本差异（质量相当） - 最终选择保守方案：5 倍成本节省 - 质量损失可忽略不计 # 四、影响分析 ## 1. 行业影响 ### A. 技术趋势 - 公开基准的商业价值有限 - 自定义基准测试将成为标准实践 - LLM 成本优化成为核心竞争力 ### B. 工具生态 作者开发了 Evalry 工具（https://evalry.com）： - 一次性测试 300+ 模型 - 无需编码 - 结果在几秒内呈现 - 计划提供持续监控功能 ## 2. 用户影响 ### A. 现有用户 如果从未测试过替代方案，很可能多付 5-10 倍费用。 ### B. 建议 - 使用真实业务场景进行测试 - 综合考虑质量、成本、延迟 - 定期重新评估（新模型每周发布） # 五、技术分析 ## 1. 核心问题 **为什么公开基准失效？** 公开基准测试的是通用能力（推理、数学、编程），而非特定业务场景的表现。例如： - 损失成本估算：需要领域知识，而非纯推理 - 客户支持：需要语言适配和服务意识 - 数据提取：需要格式理解和精准度 ## 2. 解决方案架构 ```mermaid graph TB subgraph 输入 A1[真实业务数据] A2[预期输出标准] end subgraph 测试 B1[OpenRouter API] B2[100+ LLM 模型] end subgraph 评估 C1[LLM-as-judge] C2[质量评分] end subgraph 分析 D1[成本计算] D2[延迟测量] D3[帕累托前沿] end subgraph 输出 E1[最优模型推荐] end A1 --> B1 A2 --> C1 B1 --> B2 B2 --> C1 C1 --> C2 C2 --> D3 B2 --> D1 B2 --> D2 D1 --> D3 D2 --> D3 D3 --> E1 ```   ## 3. 关键技术点 ### A. OpenRouter 统一接口 优势： - 标准 OpenAI SDK 兼容 - 只需更换模型名称 - 统一的错误处理 ### B. LLM-as-judge 方法论 **关键实践**： 1. 定义具体的评分标准 2. 要求评分理由 3. 抽样验证一致性 4. 迭代优化提示词 **潜在问题**： - 预期答案不精确导致评分偏差 - 需要人工校准 ### C. 帕累托前沿应用 **数学定义**： 给定一组模型 M，每个模型 m ∈ M 有成本 c(m) 和质量 q(m)。 模型 m* 在帕累托前沿上，当且仅当： - 不存在另一个模型 m'，使得 c(m') < c(m*) 且 q(m') > q(m*) **实际应用**： - 过滤掉明显劣质的模型 - 聚焦于前沿模型的选择 - 简化决策复杂度 # 六、各方反应 ## 1. 业内讨论 文章在 Hacker News 和 X（Twitter）上引发讨论： - HN 讨论帖：https://news.ycombinator.com/item?id=46696300 - X 讨论：https://x.com/karllorey/status/2013691168027038056 ## 2. 社区反馈 **共鸣点**： - 大多数人从未进行过模型对比测试 - 默认选择主流模型（GPT、Claude） - 成本意识不足 **争议点**： - 自定义基准的时间成本 - LLM-as-judge 的可靠性 - 小团队是否有资源进行测试 # 七、最佳实践建议 ## 1. 基准测试清单 - [ ] 收集至少 50 个真实业务案例 - [ ] 定义明确的输出标准 - [ ] 使用统一 API 接口（如 OpenRouter） - [ ] 实施 LLM-as-judge 评分 - [ ] 测量实际成本（非 token 价格） - [ ] 测量端到端延迟 - [ ] 应用帕累托前沿筛选 - [ ] 抽样验证评分一致性 ## 2. 持续优化 - 新模型每周发布，定期重新评估 - 监控生产环境性能 - 建立模型切换机制 ## 3. 工具选择 **手动方案**： - OpenRouter + OpenAI SDK - 自建评分脚本 **自动化方案**： - Evalry（https://evalry.com） - 其他基准测试平台 # 八、相关链接 ## 1. 工具资源 - OpenRouter：https://openrouter.ai/ - Evalry：https://evalry.com - Evalry 模型列表：https://evalry.com/models ## 2. 技术参考 - LLM-as-judge 指南：https://huggingface.co/learn/cookbook/en/llm_judge - 帕累托前沿（维基百科）：https://en.wikipedia.org/wiki/Pareto_front *** ## 参考资料 1. [Without Benchmarking LLMs, You're Likely Overpaying 5-10x | Karl Lorey](https://karllorey.com/posts/without-benchmarking-llms-youre-overpaying) 最后修改：2026 年 01 月 22 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏