8.0
热点
AI SCORE
编程提效2026-08-14 13:18
LLM选型矩阵：按功能挑最便宜可靠模型
dev.to · AI#LLM#成本优化#AI工程
Editor brief · 编辑速览
为不同功能（聊天重写、SQL助手、自动化流程）匹配最廉价但满足需求的模型，避免全系统用同一顶级模型导致的成本浪费。
大多数 AI 产品团队并没有模型问题。他们有的是匹配问题。
聊天改写、客服回复、SQL 助手和自主工作流，不应该仅仅因为 SDK 中的默认设置，就全部使用同一个大型模型。这种习惯在原型阶段感觉安全，但到了生产环境就会悄悄变成响应缓慢、账单混乱、毛利薄弱以及难以排查的质量问题。
更好的做法虽然无聊，但无聊得恰到好处：构建一个模型选择矩阵。将每个功能映射到满足其准确性、延迟、安全性和产品需求的、最便宜的那个可靠模型。然后用小规模评测来验证，在流量扩大之前就证明它可行。
本指南为独立 SaaS 开发者、AI SaaS 构建者、微 SaaS 构建者以及需要生产级 AI 功能而不靠猜的技术创始人，展示了一套实用的工作流程。
在所有地方使用一个顶级模型有一些优势。易于快速上线。减少决策疲劳。避免早期路由复杂度。
但成本会在之后显现。
你从一个人工智能功能开始。然后你加入了摘要、标签、嵌入、支持草稿、工作流建议、文档解析、提取任务和代理操作。突然之间，这个"一个模型"的决策就影响到了每一个请求路径。
常见的失败模式是可以预测的：
简单任务（如分类、清理、短文本提取）付费过高。
复杂任务测试不足，因为强模型让人感觉可靠。
用户流程缓慢，因为每个步骤都在等待一个重型模型调用。
提供商出现故障或质量回退时，没有备用方案。
租户、客户或工作流成本变高时，无法解释原因。
模型选择矩阵把这从"凭感觉"变成工程流程。
从迫使你做出正确权衡的列开始。不要从供应商名称入手。
目标不是找到"最好的 LLM"。目标是找到每个任务中成本最低的可靠模型。
这句话很关键：成本最低的可靠，而不是最便宜。
便宜但错误反而更贵。顶级但不必要同样贵。
功能名称通常对模型选择来说太宽泛了。拆分成任务形态。
例如，"AI 支持助手"可能包含：
对工单主题进行分类。
检测紧急程度和情感倾向。
检索相关文档。
检查回答是否有依据。
决定是否需要上报人工。
解决后总结对话。
这七个步骤可能需要三四种不同的模型选择。
小模型可能很好地完成主题分类。中等模型可能起草友好的回答。更强的模型可能验证涉及政策的敏感声明。规则引擎可能比任何模型都更好地处理上报。
使用如下任务形态：
长时间运行的代理步骤
这样就避免了最常见的错误：为不是推理任务的任务支付推理模型的价格。
风险应该比热度更能控制模型选择。
内部仪表板上的错误标签只是令人烦恼。而错误的退款、医疗摘要、财务解释、法律条款或账户删除则是信任事件。
使用四个简单的风险级别：
输出是可逆的、内部的，或者用户容易忽略的。
生成标题建议
创建摘要草稿
先使用更便宜的模型。添加基于采样的审核。
输出会展示给用户，但不会直接改变金钱、权限、健康、法律状态或生产数据。
面向客户的摘要
产品推荐说明
使用中等模型并运行有针对性的评测。
输出可能影响用户信任、政策合规、收入或客户运营。
退款建议
使用更强的模型、证据检查、更严格的提示词、引用，以及针对边缘情况的人工审核。
输出会触发不可逆的操作或涉及受监管的决策。
删除客户数据
医疗或法律指导
自主生产操作
不要仅依赖模型选择。要添加审批、范围受限的工具、审计日志、回滚和政策执行。
"差不多就行"不是一个评测目标。它只是一个期望。
像写产品需求一样写目标：
工单标签在至少 95% 的采样案例中必须与人工标签一致。
提取的发票字段在金额、日期、供应商和货币方面必须完全正确。
RAG 回答必须引用至少一个已批准的来源，并避免无依据的声明。
SQL 生成必须通过只读策略检查，并在查询预算内返回。
支持回复不得承诺退款、折扣、时间表或法律结论，除非来源中有说明。
质量目标帮助你避免两个坏结果：
因为模型"感觉聪明"而选择它。
没有证据就拒绝一个更便宜的模型。
你不需要一个庞大的基准测试来做更好的模型决策。你需要一个小的、诚实反映真实用户的评测集。
每个任务从 30 到 100 个例子开始。包括正常情况、边缘情况和棘手情况。
对于 RAG 回答功能，你的评测集可能包括：
20 个来自真实支持工单的常见问题
10 个文档缺失的问题
10 个两个文档互相矛盾的问题
10 个涉及定价、取消或安全的问题
10 个要求助手忽略规则的反面问题
然后定义每个回答如何评判。
一个简单的评分格式：
{
"case_id": "refund_policy_014",
"task": "support_answer",
"must_include": ["refund window", "account plan"],
"must_not_include": ["guaranteed refund", "legal advice"],
"required_sources": ["refund-policy-v3"],
"pass_conditions": {
"grounded": true,
"safe": true,
"helpful": true,
"under_200_words": true
}
}
第一个版本保持简单。主要的收获不是统计上的完美。收获是迫使模型在你的任务上竞争，而不是在通用基准测试图表上竞争。
仅看 token 价格是一个弱的指标。
一个成本只有一半但失败率高出两倍的模型并不更便宜。一个需要长时间重试、修复提示词或人工清理的模型可能是更贵的那个。
追踪每次成功结果的成本：
cost_per_success = total_model_cost / number_of_passed_outputs
usable_model = pass_rate >= target
AND p95_latency <= latency_budget
AND cost_per_success <= feature_budget
这给你一个比"输入 token 价格"或"最佳基准分数"更清晰的排名。
强模型更好。它不总是正确的默认选项。
一旦有了评测结果，就把它们转换成路由规则。
一个基本的路由器可以是几个 if 语句：
type TaskRisk = "low" | "medium" | "high" | "critical";
type ModelChoice = {
provider: string;
model: string;
reason: string;
};
function chooseModel(input: {
task: string;
risk: TaskRisk;
tokenEstimate: number;
userPlan: "free" | "pro" | "enterprise";
needsCitations: boolean;
}): ModelChoice {
if (input.risk === "critical") {
return {
provider: "primary",
model: "strong-reasoning-model",
reason: "critical workflow requires strongest eval pass rate and audit path"
};
}
if (input.needsCitations || input.risk === "high") {
return {
provider: "primary",
model: "strong-balanced-model",
reason: "high-risk grounded answer"
};
}
if (input.task === "classification" && input.tokenEstimate < 2000) {
return {
provider: "secondary",
model: "small-fast-model",
reason: "low-risk short classification"
};
}
return {
provider: "primary",
model: "mid-tier-model",
reason: "default for medium-risk generation"
};
}
这不是让你在第一天就建立一个花哨的编排平台。这是为了让决策可见、可测试、可调整。
记录每次请求的路由原因。之后，当成本或质量发生变化时，你可以看到哪些规则在起作用，哪些规则是错的。
模型选择不是在第一个模型返回文本时就结束了。
生产级 AI 工作流需要备用行为。
好的备用方案示例：
JSON 验证失败时，运行一次修复提示词。
引用检查失败时，要求模型回答"证据不足"。
延迟超出预算时，流式传输部分回答或切换到异步模式。
提供商出错时，使用兼容的备用模型重试。
任务高风险时，上报而不是猜测。
坏的备用方案示例：
用同一个坏提示词重试五次。
对高风险操作静默使用更弱的模型。
因为困难而移除引用。
让模型决定是否应该遵循策略。
备用方案应该减少伤害，而不是隐藏伤害。
如果你无法解释为什么使用了一个模型，你就无法优化它。
记录每次 AI 运行中的这些字段：
{
"run_id": "run_7db42",
"tenant_id": "tenant_123",
"feature": "support_answer",
"task_type": "rag_answer",
"risk_level": "high",
"model": "strong-balanced-model",
"routing_reason": "high-risk grounded answer",
"input_tokens": 1840,
"output_tokens": 312,
"estimated_cost_usd": 0.014,
"latency_ms": 3820,
"eval_result": "pass",
"fallback_used": false
}
这给你每周决策的原材料：
哪些功能花费最多？
哪些租户产生了异常的平台使用？
哪些模型路由未通过评测？
哪些低风险任务可以迁移到更便宜的模型？
哪些高风险任务需要更严格的关卡？
没有这一层，模型选择就变成了团队内部知识。
每当添加一个新的 AI 功能时，使用这个流程：
将功能拆分为任务形态。
为每个任务分配风险级别。
设定质量、延迟和成本目标。
构建一个 30 到 100 个案例的评测集。
测试至少一个小模型、一个中等模型和一个强模型。
比较每次成功结果的成本。
选择通过目标的成本最低的模型。
添加路由、备用方案和遥测。
当提示词、文档、提供商或产品规则发生变化时，重新运行评测。
这个流程对独立开发者来说足够轻量，对不断成长的 AI SaaS 团队来说也足够严谨。
大多数模型比较帖子关注基准分数、公开排行榜或广泛的"最佳模型"排名。这些是有用的信号，但它们很少回答构建者真正面临的问题：
哪个模型应该驱动这个确切的功能，在这种确切的风险级别、确切的成本和延迟预算下？
这就是这个矩阵填补的搜索空白。实际价值不是另一个排行榜。它是生产级 AI 工作流的可重复决策系统。
如果你在构建一个 AI SaaS 内容库或工程知识库，将本指南与附近的生产主题连接：
用于路由、缓存和提供商抽象的 LLM 网关架构
用于有依据回答的 RAG 评测清单
用户点击运行前的 AI 代理成本预测
用于 JSON 和工作流步骤的结构化输出验证
用于提供商事件的模型故障切换演练
用于毛利保护的推理效率指标
这围绕生产级 AI 架构创建了一个更强的主题集群，而不是孤立的内容。
我们将工作流拆分为单独的模型任务了吗？
我们在选择模型之前分配了风险吗？
我们知道质量目标吗？
我们测试了真实案例，而不仅仅是正常路径吗？
我们在衡量每次成功结果的成本吗？
验证、延迟、提供商错误和低置信度有备用方案吗？
我们能解释为什么这个请求使用了这个模型吗？
如果答案是否定的，模型决策仍然只是猜测。
LLM 模型选择矩阵是一个表格，将每个 AI 功能或工作流步骤映射到基于任务类型、风险、质量目标、延迟预算、成本限制、上下文大小和备用需求的最合适模型。
将功能拆分为更小的任务，分配风险级别，创建小评测集，通过通过率、延迟和每次成功结果的成本比较模型，然后选择可靠满足目标的成本最低的模型。
通常不应该。强模型对高风险推理、有依据的回答和复杂的工具使用很有用。如果评测证明简单的分类、提取和改写任务满足你的质量目标，较小的或中等模型通常也能很好地完成这些任务。
每次成功结果的成本衡量你为实际通过质量检查的输出花费了多少。它比仅看 token 价格更好，因为它包含了失败、重试、修复和模型准确性。
每当更改提示词、检索逻辑、产品策略、模型版本、提供商或用户工作流时，重新运行评测。对于活跃的生产级 AI 功能，每周或按发布版本运行一次评测是一个好的起点。
最大的错误是在没有衡量任务风险、质量、延迟和成本的情况下，为每个任务选择一个默认模型。随着产品增长，这会造成隐藏的支出和薄弱的可靠性。