14 篇博文 含有标签「成本优化」

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-05 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

有一阵子我们把多模型路由做得越来越“聪明”：

• 先按任务类型分
• 再按风险等级分
• 再按上下文长度分
• 再按历史命中率分
• 失败后还有二级 fallback

纸面上看，这套策略非常精细。真正上线后，问题却越来越明显：

• 成本走势很难解释
• 某个请求为什么走了某个模型很难追
• 调一条规则，别的路径会不会被带偏不清楚
• 出现效果抖动时，排查几乎像在查一个“规则黑箱”

后来我们做了一次很克制的重构：不是继续加规则，而是把路由策略砍掉一大半。结果反而更稳了。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-04 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人在算大模型私有化或自托管成本时，最容易先盯住的是两件事：

• 一张卡多少钱
• 模型需要多少显存

这两个数字当然重要，但如果只看到这里，最后经常会算出一张很“理论正确、线上失真”的成本表。
因为真实成本不是由单一硬件价格决定的，而是由推理引擎、显存占用、并发效率和服务稳定性一起决定的有效产能。

也就是说，真正该问的问题不是“这张卡贵不贵”，而是“这套栈每小时到底能稳定完成多少个有效请求”。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-29 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

关于开源模型和商业模型，过去很长一段时间讨论都容易变成“立场题”：

• 开源更可控
• 商业更强
• 开源更便宜
• 商业更省事

这些话都各有一部分对，但真做项目时，它们都不够。因为真正的取舍不是价值观问题，而是你愿意把复杂度放在哪一层。

我现在越来越少问“哪个阵营更好”，而是更实际地问：

• 当前业务的不确定性大不大
• 团队有没有能力接住模型基础设施
• 成本压力到底发生在调用费，还是发生在人力和运维
• 数据和合规边界到底有多硬

这些问题一回答，很多所谓“阵营之争”其实就没那么悬了。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-22 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多时候，团队会天然相信“整体分数”比单个样本更重要。这个判断通常没错，但我后来有过一次很深的体会：一个样本也可能比一百个平均分更能暴露产品问题。

那次我在看一套评测结果时，大盘分数其实不难看。可其中有一条样本让我停了很久，最后直接改了我对产品形态的判断。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-21 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多私有化部署项目，第一天讨论就会迅速滑向这些问题：

• 上哪张卡
• 部哪个开源模型
• 能不能先跑个 Demo

这些问题当然会谈，但如果第一天就直接冲进模型和机器，后面很容易越做越偏。
因为私有化部署项目最先决定成败的，往往不是“模型叫什么名字”，而是你到底在为哪个约束买单。

我现在几乎把“第一天谈什么”理解成一次边界对齐。
边界如果没对齐，后面所有技术决策都会漂：

• 你以为在做能力建设，客户其实要的是合规隔离
• 你以为要拼极致效果，业务其实更关心稳定吞吐
• 你以为要上最强模型，最后发现根本没人负责运维

所以私有化项目第一天，我更关心的是先把问题谈窄，而不是先把方案谈满。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-10 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队把 AI 成本看板做成了另一种账单页面：

• 本月花了多少钱
• 各供应商占比多少
• 同比上月涨了还是跌了

这些数字不是没用，但如果成本看板只能回答财务问题，它对产品和工程团队的帮助会非常有限。因为真正要做决策的人，通常更关心另外一些问题：

• 哪条业务链路最贵
• 贵是因为用户变多了，还是因为系统变胖了
• 哪个实验让成本突然上升
• 哪类请求根本不值得走强模型

所以我现在越来越不把成本看板当“财务报表”，而把它看成一块产品控制面板。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-09-06 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多 AI 项目一旦进入评测阶段，最容易被一个数字绑架：准确率。

准确率当然重要，但我后来越来越少单独看它。因为在线上系统里，准确率高并不自动等于业务效果好。有时候它甚至会掩盖真正的问题。

一个最典型的例子，就是某类客服分流功能。离线看分类准确率挺高，团队一开始很满意。但上线后业务同学还是不买账，因为真正痛的地方并没有被解决：

• 高价值工单还是会漏
• 低价值工单却被过度升级
• 人工审核量没有降多少
• 平均处理时长也没明显改善

也就是说，模型在“答题”这件事上可能不错，但业务在“运转”这件事上并没有变更好。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-31 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队一提到“评测”，脑子里其实混着三件完全不同的事：

• 用历史样本离线跑分
• 在真实流量里观察效果
• 把两个版本同时放给用户做 A/B

它们都叫评测，但解决的问题并不一样。
如果边界没分清，团队就很容易出现两种典型混乱：

• 明明还没离线证明安全，就急着上 A/B
• 明明用户体验已经变了，还只拿离线分数说话

所以我现在会先把这三种方法当成不同阶段的不同工具，而不是互相替代的同一种东西。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-24 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队做 AI 应用时，最先花时间调的是模型和 Prompt，最晚补上的才是评测集。结果就是每次改完一版，大家只能靠感觉判断：

• 这次是不是比上次好一点
• 好的是哪一类场景
• 会不会修好了一个问题，又带坏另外两个问题

我后来基本不再接受这种“看起来顺一点”的判断方式。因为一旦系统要持续迭代，你迟早得回答一个很现实的问题：这次变更到底改善了什么，又伤害了什么。

所以我现在给 AI 应用搭第一版评测集，目标从来不是“做出一套完美 Benchmark”，而是先做出一套能指导下一次工程决策的小而准的样本集。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-07-21 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队第一次做 AI 成本复盘时，最先盯住的都是一个总数：这周花了多少钱，比上周多了还是少了。

这个数字当然重要，但它几乎永远不够解释问题。

我后来越来越相信，AI 成本看板如果只能回答“贵了没有”，那它对工程决策的帮助非常有限。真正有价值的是：这笔钱是被哪种请求、哪种失败路径、哪种系统漂移吃掉的。

前阵子我就碰到过一次很典型的情况：业务请求量几乎没变，但一周总成本突然涨了三成多。乍一看像是模型贵了，结果真正的问题根本不在模型单价。