SaaS 模型选型：同时测质量、成本与稳定性

给 SaaS 选模型，回答更准确的那个，未必最适合上线。作者用一个虚构的反馈分析产品做案例，实际跑了 3 个模型、20 条反馈、180 次调用，最后选择 GPT-4o-mini：它的优势是请求能完成、格式稳定，成本也更低。

这组实验值得看的，是把账号额度、限流和输出格式一起纳入选型。不过，原文的统计口径存在几处矛盾，「Claude 输了」需要限定在这次接入条件下理解，不能直接当成模型能力排名。

先把业务任务固定，模型比较才有意义

案例中的 InsightFlow 是虚构的 B2B SaaS，负责处理 NPS 评论、支持工单、产品评价和满意度表单。作者要给它增加四项能力：判断正面、负面或中性情绪，识别主要类别，生成不超过 3 行的管理摘要，再给出行动建议。

这比问模型几个开放问题更接近产品选型。业务需要的是一组能被后续流程使用的结果，措辞漂亮只是其中一部分。

作者从四种来源各取 5 条反馈，共 20 条，特意加入态度混合、表达模糊和前后矛盾的样本。每条反馈对每个模型执行 3 次，总计 180 次调用。重复调用可以观察结果是否稳定，但不能把它当成 180 条独立测试数据。

实验统一系统提示词和用户提示词，设置 temperature=0.2、max_tokens=500，并开启 Streaming 测量 TTFT，即请求发出到收到首个 token 的时间。原文称 Claude Sonnet 5 拒绝 temperature，因此对它省略了这个参数。这是必要的接口适配，也让采样条件无法完全一致。

最初计划比较 GPT-4o、Claude Sonnet 和 Llama 3.3 70B，后来受账号和模型目录限制，更换了其中两个。实际分析围绕 GPT-4o-mini、Claude Sonnet，以及文中称为 Nemotron 550B 的免费模型展开；但原始结果把后者标成 modelo-gratuito，文末又提到 Free Models Router，具体请求如何映射到模型没有交代清楚。

记录由 Python 脚本 benchmark_insightflow.py 完成，覆盖耗时、tokens、JSON 有效性和错误，原文称调用于 2026 年 11 月 2 日通过 OpenRouter 执行，日志包括 resultados_brutos.csv 和 logIA.txt。

GPT-4o-mini 赢在交付完整，但统计口径要拆开看

下面这段原始输出同时展示速度、格式和错误，能看出作者为何没有只按回答准确率选型：

modelo               n  lat_med     p95  ttft_med  json_ok  erros
-----------------------------------------------------------------
gpt-4o-mini         60     2.26    2.96      1.64     100%      0
claude-sonnet       60     2.03    5.18      2.78      33%     38
modelo-gratuito     60     5.17    9.08      3.96      85%      7

重点看 claude-sonnet 这一行：虽然总耗时中位数为 2.03 秒，低于 GPT-4o-mini 的 2.26 秒，但它有 38 次错误，json_ok 也只有 33%。如果失败请求很快返回，单看耗时甚至可能把失败多的方案误判为更快，必须确认统计是否只包含成功请求。

作者称 Claude 对成功处理的 8 条反馈全部判断正确，还答对了一条 GPT-4o-mini 判断错误的歧义样本。可这个结果只覆盖成功返回的部分，不能推出它对全部样本都有 100% 准确率。

原文还有几处需要打问号。38 次错误除以 60 次调用约为 63.3%，与文中「失败 66%」不一致；8 条反馈与调用次数之间的关系也未解释。33% 的 JSON 有效率究竟包含请求失败，还是仅统计返回内容，同样不明确。

Claude 的 TTFT 中位数为 2.78 秒，却高于总耗时中位数 2.03 秒，也提示两列可能使用了不同样本集合。现有内容不足以确认原因。

请求成功、格式可解析、业务判断正确，需要分别统计。

作者还使用了 1 到 5 分的加权评分：质量 25%、一致性 15%、格式 15%、延迟 10%、成本 20%、风险 15%。这个维度组合有参考价值，但提供的原文没有列出各模型完整分数，无法复核最终加权排名。

免费额度和真实 tokens，会直接改变选型结果

Claude 的失败主要来自余额不足的 402，以及 OpenRouter 新账号的 20 RPM 限制。它们反映的是本次账号、渠道和调用节奏的约束，不能直接归结为 Claude 自身服务不可靠。

免费模型也遇到了类似问题。作者报告 Nemotron 550B 的准确率为 94%，但 OpenRouter 每天 50 次请求的限制挡住了最后几次调用。原始表中免费模型有 7 次错误，JSON 有效率为 85%，总耗时中位数为 5.17 秒，p95 为 9.08 秒。

对原型来说，免费额度可能足够；面对每月 5 万次请求，作者测试的这档免费额度无法支撑。购买额度后的方案，则需要重新计算价格和容量。

tokens 实测也改变了成本判断。GPT-4o-mini 每次请求平均约消耗 167 个输入 token、95 个输出 token；Claude 约为 265 个输入 token、250 个输出 token。同样的任务，输入输出长度并不相同，估算时不能只套一份统一 token 数。

作者据此报告 GPT-4o-mini 成本低约 40 倍，而纸面方案原先认为 GPT-4o 与 Claude 成本接近。不过，原文没有展示实际单价和完整计算表，而且计划模型与实测模型发生了变化，因此「40 倍」只能作为作者报告的实验结果，无法凭这些材料独立复算。

最终，作者选择 GPT-4o-mini 为主模型：情绪准确率 93.3%、JSON 有效率 100%、零运行错误。Claude Sonnet 5 被放到复杂任务的备用位置，前提是稳定余额、将 max_tokens 提高到 800，并为 429 实现带退避的重试；Nemotron 则用于低量受控试点。这些后续方案没有展示验证结果。

我的判断

我认同作者把完成率和成本纳入选型。对于反馈分析产品，失败调用会阻塞后续处理，JSON 无法解析会增加修复成本，这些都应该进入决策。

但「Claude 输了」更准确的表述，是它在这次账号和额度条件下没有完成测试。补足余额、控制并发后，排名是否变化，原文没有对照数据。20 条样本也只能支持初步筛选，难以代表复杂业务的长期表现。

备用模型方案还有一个缺口：线上如何知道 GPT-4o-mini 已经分类错误？离线测试有标准答案，生产请求通常没有。作者没有说明识别机制，因此不能直接照搬「主模型答错就转交 Claude」这条路由规则。

相比只看质量榜单，这种实测更贴近产品；相比条件充分控制的模型能力评测，它又混入了渠道和账号因素。两种评测回答的问题不同。这次实验支持优先选择当时能稳定完成任务的方案，尚不足以证明某个模型普遍更优。

能拿来做什么

• 给 SaaS 增加反馈分类或摘要功能前，先整理自己的典型样本，覆盖混合情绪、模糊表达和矛盾内容，再固定任务与输出字段进行比较。
• 在 Node 调用层分别记录请求成功率、成功响应中的 JSON 有效率和业务准确率；总耗时与 TTFT 使用相同样本口径，避免快速失败干扰速度判断。
• 用实际输入输出 tokens 计算单次请求成本，再结合预计月调用量检查余额、RPM 和每日额度。免费原型通过之后，仍需验证目标用量能否运行。
• 准备引入备用模型时，先明确哪些请求需要升级处理，并验证提高 max_tokens、处理 429 和退避重试后的效果，再决定是否上线路由。