买硬件之前没人写下来的那份 GPU 成本模型
自托管只有在利用率超过某个门槛后,才在每 token 成本上赢过 API。而几乎没人达到那个门槛——低于它时,你在为闲置算力和工程师注意力付费,只有前者会写进表格。
全部文章
自托管只有在利用率超过某个门槛后,才在每 token 成本上赢过 API。而几乎没人达到那个门槛——低于它时,你在为闲置算力和工程师注意力付费,只有前者会写进表格。
微调编码的是行为,检索提供的是事实。问「哪个更好」是问错了问题——该问的是底层知识多久变一次,以及你是否需要引用来源。
每个多租户 RAG 最终都会发现同一件事:检索之后过滤结果不是隔离。过滤必须约束搜索本身,而不是裁剪它的输出。
公开的跑分表比的是公开数据集上的召回率,而那不是你的数据集、你的过滤条件,也不是你的查询分布。真正决定结果的是四个运维层面的问题。
风险不在于模型说错了什么,而在于 Agent 做错了什么——而且是带着凭证,在一个没有撤销按钮的系统里做错。
两年来的建议都是「把提示词写好」。这条建议在模型变得能稳定遵循指令之后,基本就不再产生收益了。它至今仍然做不到的事情是:推断出你根本没给它的信息。
演示在几份干净的 PDF 上跑得很好,会议室里一片赞叹,然后真实文档来了:扫描件、合并单元格、十年前的合同、三种语言混在一起。多数试点就是在这里悄悄停住的。
演示很顺利,用户也满意。然后法务问数据去了哪里,安全问谁能看到什么,财务问每月多少钱。如果这三个问题你没提前准备,试点就停在这里了。
做测量的团队往往只测简单题,因为只有这些题有人事先知道答案。而真正会让你赔钱的,是那些没人想到要放进去的题。
检索质量已经是个足够解决的问题。真正让企业 RAG 项目停下来的往往是权限——不是因为它难,而是因为它来得太晚,一来就逼你重写。
「自托管更便宜」只有在利用率超过某个水平之后才成立。低于这个水平,你在为闲置的 GPU 和工程师的注意力付费——而第二项,几乎没人写进表格。
用户感受到的不是你的架构,而是一个数字。多数团队说不清这个数字是从哪来的。在它真的变慢之前,用户早就觉得它慢了。
路由是 LLM 系统里杠杆最大的成本控制手段,却几乎总是最后才被实现——在为那些小模型回答得一模一样的问题付了十八个月高价之后。
你不会在没有测试的情况下合并代码,那也别在没有评测的情况下发布 Agent 改动。
这个头衔听起来像做研究,实际大部分时间在接数据、填安全问卷、说服部门负责人这个试点不会让他难堪——也正因为如此,这个岗位才这么抢手。
还没有内容,下一轮抓取会填充这里。