[{"content":"前两天试了个小实验：让两个AI做同一件事——“把这个文件夹里的材料整理一下，按项目、年份和类型分类，找出重复文件，生成一份目录清单”。\n第一个AI的回答很像样：建议先建几个文件夹，给了一段批量重命名的脚本，最后说“你可以把文件上传给我，我再帮你细看”。\n第二个AI没怎么废话，直接打开了那个文件夹，读文件、判断格式、拆分类别、检查重复、生成目录，最后甩给我一份可以直接用的清单，附带一份“我做了什么”的执行记录。\n两个AI背后可能是差不多水平的大模型，为什么一个只给建议，另一个真的动手把事办完了？这篇想把这件事拆开讲清楚。\n一、点菜vs自己下厨 聊天机器人像坐在桌边帮你点菜的人。你问它今天吃什么、这道菜怎么做、三个人该点几个菜，它能分析、能建议、能讲得头头是道。但回答说完，这件事在它这儿就结束了——它不会去看冰箱里还剩什么、该采购点什么、火候不对了要不要重炒，更不会把菜端上桌。\nAgent更像是接到目标后真正进厨房的人。你给它的不是一步步的指令，而是一个目标——“晚上六点前准备三菜一汤，有一个人不吃辣”。剩下的事它自己张罗：看现有食材、定菜单、决定先炒哪道、缺了什么自己想办法、中途火大了自己调整，直到达成目标为止。\n这不是“服务员”和“更聪明的服务员”的差别，而是谁掌握了执行路径的决定权。区别不在于点菜的人只能说固定答案——他其实也能开放式地分析、建议、讲清楚利弊——而在于他说完以后，采购、烹饪、调整、验收，仍然要由你自己一步步完成。下厨时目标定了，用什么锅、先做哪样、中途要不要改主意，是他自己当场拿主意。\n这个类比对应的是两家主流模型公司目前的工程定义，但需要先说明一句：行业对Agent并没有完全统一的术语边界。Anthropic把系统分成workflow和agent两类：workflow是LLM和工具按预先写好的代码路径走，agent则是LLM自己动态决定下一步做什么、调用什么工具。OpenAI的说法角度略有不同：workflow是为达成用户目标必须走完的一串步骤，agent则是能代表用户、由模型控制这串步骤执行的系统——换句话说，在OpenAI的语境里，Agent是在“执行workflow”，而不是把两者当成互斥的类别。两家措辞不完全一样，但共同强调的是同一件事：模型是否掌握了执行流程的控制权。\n本文采用的是偏工程化的狭义口径：预设路径称为workflow，模型根据当前状态动态决定执行路径，才称为Agent。现实产品里，聊天、workflow和Agent能力往往被放在同一个界面里，不必强行归类。\n二、真正的分界线：不是会不会说话，是谁决定下一步 聊天机器人的典型流程是这样的：用户提问，AI回答，用户判断这个答案有没有用，用户决定下一步该问什么，AI再回答。举个真实场景——让AI查资料，你复制结果，再让它整理，你保存成文档，再让它改格式，你发邮件出去。AI在每一步都参与了，但整条流程是靠你自己一步步连起来的。\nAgent内部跑的是另一套循环：接收目标，判断当前处于什么状态，自己选择下一步该做什么，调用工具，拿到反馈，根据反馈修正计划，继续往下推进，直到自己判断“这件事完成了”。\n判断一个系统的Agent成色，最核心的一问是：模型能不能根据当前状态决定下一步，并在拿到工具反馈后继续调整？这不是唯一条件，但它是区分固定workflow和Agent的第一道门槛。假设一套系统能搜网页、能读文件、能生成PPT，仍然要接着问——是你每次手动点选功能，还是程序按固定顺序走，还是模型根据当前结果自己拿主意？只有第三种，才算得上真正意义上的Agent。\n这里有四个很容易被混淆的说法，值得单独拎出来说清楚：\n能联网搜索≠Agent。搜索只是一件工具，如果搜什么、搜几次、什么时候停都是你在控制，它本质上还是个联网增强版的聊天机器人。\n能记住上下文≠Agent。记忆能让多轮对话更连贯，但“记得你说过什么”和“能替你把事办完”是两码事。\n能调用插件≠Agent。调一次天气、算一次数字、查一次数据库，都不构成对完整任务流程的控制权。\n多个模型协作≠必要条件。单个Agent同样能完成复杂任务，OpenAI自己也建议先把单Agent做扎实，只有工具太多、逻辑分支太复杂、职责需要拆分时，才考虑上多Agent架构。\n一句话小结这节：工具决定AI能做什么，执行权决定它是不是Agent。\n聊天机器人、Workflow和Agent的真正区别：谁在决定下一步？ 三、“会执行”到底难在哪——两组基准，三层难题 概念讲清楚之后，容易冒出一个乐观误解：既然Agent就是“自己决定下一步”，那是不是接上工具就基本齐活了？现实要泼盆冷水——真正把一件事稳定执行完，比听起来难得多，而且难在三个不同的层次上。\n第一层，完成一个受规则约束的业务闭环就不容易。Sierra研究团队2024年发布的τ-bench，测的不是Agent会不会调用某一个函数，而是它能不能在模拟的零售和航空客服场景中，一边和用户多轮沟通、一边调用API，还要遵守复杂的业务规则——这本身就和“给定所有信息、一次性执行”的旧基准不是一回事。评分重点也不只是数据库最终状态对不对，还要看Agent有没有把必要信息传达给用户。结果是，即便用GPT-4o跑function calling，零售场景的成功率也只有约61%，航空场景更是只有约35%。这说明“说清楚该怎么做”和“真的把这件事办对”，中间隔着一大截。\n第二层，稳定执行比偶尔跑通更难。τ-bench提出了一个叫pass^k的指标，衡量的是同一个任务连续跑k次是不是次次都成功。直观理解，如果把每次执行看作相互独立，单次成功率即使有90%，连续8次全部成功的概率也只有43%左右。而在τ-bench的实际测试里，GPT-4o零售场景的平均成功率超过60%，pass^8却降到25%以下——这也是为什么“Agent能跑出一个漂亮的demo”和“Agent能每天稳定地跑”完全是两件事。\n第三层，长链路任务是目前公认的最大短板。2026年发布的OSWorld 2.0专门测试长流程真实任务，一共108个，每个任务对熟练的人类操作者来说，中位耗时都要1.6小时。在论文测试的配置里，Claude Opus 4.8开最大思考、批量工具调用，严格意义上的完成率是20.6%（放宽到部分得分能到54.8%），token效率更高的GPT-5.5完成率约13%。这组数字只对应OSWorld 2.0所测的这类长流程电脑操作任务，不能代表客服Agent、代码Agent这些其他场景的整体水平；而且这个领域进展很快，7月Anthropic已经发布了新一代的Opus 5，官方称其在这项基准上的表现已经超过Opus 4.8，所以这里给出的仍是“当时那批模型能做到什么程度”，不是当前的最新水平。\n三层难度合在一起，指向的是同一件事：Agent真正的门槛不在“能不能调用工具”，而在“能不能把一条受规则约束的长链路任务，稳定、正确地走到底”。\nAgent执行能力的三道关 这几组数据来自不同模型、不同版本、不同评测框架，彼此之间不能直接换算比较，只用来说明“执行”这件事本身有多难，不做具体产品的排名依据。\n四、Agent内部到底多了什么 拆开来看，一个能稳定干活的Agent，通常要具备六个部件：\nAgent = 大模型 + 工具 + 环境权限 + 任务状态 + 执行循环 + 安全护栏\n大模型负责理解目标、判断下一步、处理意外情况，相当于厨房里的大脑，但光有大脑做不出饭 工具是它和外部世界打交道的手，包括读写文件、查数据库、发邮件、执行命令 权限决定它真正能动什么——没有权限，Agent说到底也只能给建议 状态让它知道任务走到哪一步了，不用每次都从头猜一遍 执行循环是“观察→规划→行动→反馈→检查→继续”这条闭环，这是Agent和“调用过一次工具的聊天机器人”最本质的区别 安全护栏决定哪些操作必须停下来问人，比如删除文件、发邮件前的确认 大模型能力已经相当普及，工具接入也越来越常见；真正拉开差距的通常是后四个部件——权限给到什么程度、状态记不记得住、循环转不转得起来、护栏立在哪儿。\n五、真实片段：WorkBuddy的一次多步执行，和一个反例 上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里记录过几个真实场景，这里挑一个执行场景和一个对照场景重新看一遍。先说清楚：下面这个例子能证明它完成了多步任务，但不足以证明每一步都是“临场动态决策”——这一点留在下一节一起说。\n一个是手机远程遥控电脑：在外面发一句“看一下当前文件夹下有哪些文件，把内容转写成markdown保存一份，总结主要内容给我”，到家活儿已经跑完了。这句话背后是它自己拆成了“列文件→读取→转写→总结”几步，而不是我手动点了四次功能——这至少说明它具备了“接收目标、自己拆解步骤”的能力，是本文第二节说的执行权的一种体现。\n再对比同一篇里的“每日AI新闻推送”：设定好时间和内容规则，到点自动推送——这更接近固定workflow而不是严格意义上的Agent，因为触发条件和执行动作都是提前定好的，模型没有在中途做新的决策。这个对比恰好能落回本文第二节的核心判断：同一个产品里，不同功能可能分别落在workflow和Agent两端，不能一概而论。\n六、Agent不是越自主越好 篇幅有限，这里只强调一个容易被忽略的判断：Agent能自主决策，不代表应该在所有事情上都放手自主。\n先说一个真实的小例子：上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里，让WorkBuddy围绕一个主题跑一份调研报告，结果不算完美——报告里列的要点，有几个是没想到的，但也有几个是它“想当然”给出的，得自己核实过才能用。这提醒的是：Agent能自己往前推进，不代表它推进的每一步都对。在当前阶段，尤其是面对调研、发布、邮件和数据修改这类任务，把Agent的产出当成待验收的结果，而不是直接当最终结果使用，是正常的使用方式。\n行业层面也有数据支撑这个判断。Gartner预测，超过40%的agentic AI项目会在2027年底前被取消，直接原因包括成本上升、业务价值不清晰、风险控制不足；同一份报告也指出，当前模型的成熟度和自主能力，仍不足以稳定完成复杂的业务目标。换句话说，项目失败通常不是单一的技术问题，而是能力、成本、价值和治理共同作用的结果。报告里还提到一个更扎心的现象：市面上数千家自称“agentic AI”的厂商里，真正名副其实的大概只有130家左右——这就是所谓的“agent washing”，把聊天机器人换个说法包装成Agent。\n这个判断其实和第三节的执行数据是一体两面：在OSWorld 2.0测试的这类长流程电脑操作任务上，当时最佳配置的完整完成率也只有约两成。这不能代表所有Agent场景，但足以说明——面对长链路、高权限、难以回滚的任务，默认让Agent完全自治，在当下不是一个稳妥的选择。\n一个更实用的判断方法，是看三个因素：操作是否可逆、影响范围有多大、是否涉及敏感权限。读取文件、整理材料、生成草稿，可以允许自动执行；批量改名、修改数据、准备邮件，适合先生成预览再确认；删除文件、发送邮件、付款、对外发布这类不可逆操作，则必须保留人工授权这一步。\nAgent自主权的三级边界 上个月那篇《AI干完了853个人的活，为什么签字的还得是人？》里讲过一个类似的道理——AI出错之后，责任能不能找到人，比它能力强不强更关键。放到Agent这里同样成立：失败往往不是单纯的模型问题，是“该让它自己拿主意到哪一步”这件事，一开始就没想清楚。\n七、六问判断法 下次再看到一个产品自称“AI Agent”，可以拿这六个问题过一遍：\n它接收的是一个目标，还是只回答一个问题？ 它能不能自己拆解出执行步骤？ 它能不能根据中途的反馈调整计划？ 它能不能真正操作外部环境（文件、邮件、数据库）？ 它能不能检查自己做得对不对？ 它知不知道什么时候该停下来问人？ 满足得越多，Agent的成色就越足——但不用设一条机械的及格线，不同类型的Agent（客服、编程、文件处理）不一定需要同时满足全部六项。这六个问题背后，其实只是同一件事的六个切面——谁掌握了执行路径的决定权。\n写在最后 聊天机器人解决的是“这件事该怎么做”，Agent尝试解决的是“这件事能不能真的做完”。\n但从“会说”走向“会做”，意味着AI开始拿到文件、账号、系统的操作权限，这不是一件可以完全撒手不管的事。所以Agent时代最值得问的问题，从来不是它能干多少活，而是——它自己能决定什么，什么时候必须停下来给你看一眼草稿，出了错之后，责任又在谁身上。\n本文涉及的基准测试（τ-bench、OSWorld 2.0）对应的模型版本和评测框架各不相同，具体数字请以论文原文和官方榜单为准，不作为产品横向排名依据。\n数据来源\nAnthropic《Building Effective Agents》：anthropic.com/engineering/building-effective-agents OpenAI《A Practical Guide to Building Agents》：cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf τ-bench原始论文（Yao et al.， 2024）：arxiv.org/abs/2406.12045 OSWorld 2.0论文（2026）：arxiv.org/abs/2606.29537 Gartner新闻稿《Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027》：gartner.com/en/newsroom/press-releases/2025-06-25 站内引用：《我用WorkBuddy做了几件小事，才明白Agent是什么》（2026-06-22）、《AI干完了853个人的活，为什么签字的还得是人？》（2026-07-15） ","permalink":"https://blog.onecai.site/2026/08/08/069-agent-vs-chatbot-execution-power/","summary":"\u003cp\u003e前两天试了个小实验：让两个AI做同一件事——“把这个文件夹里的材料整理一下，按项目、年份和类型分类，找出重复文件，生成一份目录清单”。\u003c/p\u003e\n\u003cp\u003e第一个AI的回答很像样：建议先建几个文件夹，给了一段批量重命名的脚本，最后说“你可以把文件上传给我，我再帮你细看”。\u003c/p\u003e\n\u003cp\u003e第二个AI没怎么废话，直接打开了那个文件夹，读文件、判断格式、拆分类别、检查重复、生成目录，最后甩给我一份可以直接用的清单，附带一份“我做了什么”的执行记录。\u003c/p\u003e\n\u003cp\u003e两个AI背后可能是差不多水平的大模型，为什么一个只给建议，另一个真的动手把事办完了？这篇想把这件事拆开讲清楚。\u003c/p\u003e\n\u003ch2 id=\"一点菜vs自己下厨\"\u003e一、点菜vs自己下厨\u003c/h2\u003e\n\u003cp\u003e聊天机器人像坐在桌边帮你点菜的人。你问它今天吃什么、这道菜怎么做、三个人该点几个菜，它能分析、能建议、能讲得头头是道。但回答说完，这件事在它这儿就结束了——它不会去看冰箱里还剩什么、该采购点什么、火候不对了要不要重炒，更不会把菜端上桌。\u003c/p\u003e\n\u003cp\u003eAgent更像是接到目标后真正进厨房的人。你给它的不是一步步的指令，而是一个目标——“晚上六点前准备三菜一汤，有一个人不吃辣”。剩下的事它自己张罗：看现有食材、定菜单、决定先炒哪道、缺了什么自己想办法、中途火大了自己调整，直到达成目标为止。\u003c/p\u003e\n\u003cp\u003e这不是“服务员”和“更聪明的服务员”的差别，而是\u003cstrong\u003e谁掌握了执行路径的决定权\u003c/strong\u003e。区别不在于点菜的人只能说固定答案——他其实也能开放式地分析、建议、讲清楚利弊——而在于他说完以后，采购、烹饪、调整、验收，仍然要由你自己一步步完成。下厨时目标定了，用什么锅、先做哪样、中途要不要改主意，是他自己当场拿主意。\u003c/p\u003e\n\u003cp\u003e这个类比对应的是两家主流模型公司目前的工程定义，但需要先说明一句：行业对Agent并没有完全统一的术语边界。Anthropic把系统分成workflow和agent两类：workflow是LLM和工具按预先写好的代码路径走，agent则是LLM自己动态决定下一步做什么、调用什么工具。OpenAI的说法角度略有不同：workflow是为达成用户目标必须走完的一串步骤，agent则是能代表用户、由模型控制这串步骤执行的系统——换句话说，在OpenAI的语境里，Agent是在“执行workflow”，而不是把两者当成互斥的类别。两家措辞不完全一样，但共同强调的是同一件事：模型是否掌握了执行流程的控制权。\u003c/p\u003e\n\u003cp\u003e本文采用的是偏工程化的狭义口径：预设路径称为workflow，模型根据当前状态动态决定执行路径，才称为Agent。现实产品里，聊天、workflow和Agent能力往往被放在同一个界面里，不必强行归类。\u003c/p\u003e\n\u003ch2 id=\"二真正的分界线不是会不会说话是谁决定下一步\"\u003e二、真正的分界线：不是会不会说话，是谁决定下一步\u003c/h2\u003e\n\u003cp\u003e聊天机器人的典型流程是这样的：用户提问，AI回答，用户判断这个答案有没有用，用户决定下一步该问什么，AI再回答。举个真实场景——让AI查资料，你复制结果，再让它整理，你保存成文档，再让它改格式，你发邮件出去。AI在每一步都参与了，但整条流程是靠你自己一步步连起来的。\u003c/p\u003e\n\u003cp\u003eAgent内部跑的是另一套循环：接收目标，判断当前处于什么状态，自己选择下一步该做什么，调用工具，拿到反馈，根据反馈修正计划，继续往下推进，直到自己判断“这件事完成了”。\u003c/p\u003e\n\u003cp\u003e判断一个系统的Agent成色，最核心的一问是：\u003cstrong\u003e模型能不能根据当前状态决定下一步，并在拿到工具反馈后继续调整\u003c/strong\u003e？这不是唯一条件，但它是区分固定workflow和Agent的第一道门槛。假设一套系统能搜网页、能读文件、能生成PPT，仍然要接着问——是你每次手动点选功能，还是程序按固定顺序走，还是模型根据当前结果自己拿主意？只有第三种，才算得上真正意义上的Agent。\u003c/p\u003e\n\u003cp\u003e这里有四个很容易被混淆的说法，值得单独拎出来说清楚：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能联网搜索≠Agent\u003c/strong\u003e。搜索只是一件工具，如果搜什么、搜几次、什么时候停都是你在控制，它本质上还是个联网增强版的聊天机器人。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能记住上下文≠Agent\u003c/strong\u003e。记忆能让多轮对话更连贯，但“记得你说过什么”和“能替你把事办完”是两码事。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能调用插件≠Agent\u003c/strong\u003e。调一次天气、算一次数字、查一次数据库，都不构成对完整任务流程的控制权。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e多个模型协作≠必要条件\u003c/strong\u003e。单个Agent同样能完成复杂任务，OpenAI自己也建议先把单Agent做扎实，只有工具太多、逻辑分支太复杂、职责需要拆分时，才考虑上多Agent架构。\u003c/p\u003e\n\u003cp\u003e一句话小结这节：\u003cstrong\u003e工具决定AI能做什么，执行权决定它是不是Agent。\u003c/strong\u003e\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"agent-vs-chatbot-execution-power-1.avif\"\n          alt=\"聊天机器人、Workflow和Agent的真正区别：谁在决定下一步？\"/\u003e \u003cfigcaption\u003e\n             聊天机器人、Workflow和Agent的真正区别：谁在决定下一步？\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"三会执行到底难在哪两组基准三层难题\"\u003e三、“会执行”到底难在哪——两组基准，三层难题\u003c/h2\u003e\n\u003cp\u003e概念讲清楚之后，容易冒出一个乐观误解：既然Agent就是“自己决定下一步”，那是不是接上工具就基本齐活了？现实要泼盆冷水——真正把一件事稳定执行完，比听起来难得多，而且难在三个不同的层次上。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一层，完成一个受规则约束的业务闭环就不容易\u003c/strong\u003e。Sierra研究团队2024年发布的τ-bench，测的不是Agent会不会调用某一个函数，而是它能不能在模拟的零售和航空客服场景中，一边和用户多轮沟通、一边调用API，还要遵守复杂的业务规则——这本身就和“给定所有信息、一次性执行”的旧基准不是一回事。评分重点也不只是数据库最终状态对不对，还要看Agent有没有把必要信息传达给用户。结果是，即便用GPT-4o跑function calling，零售场景的成功率也只有约61%，航空场景更是只有约35%。这说明“说清楚该怎么做”和“真的把这件事办对”，中间隔着一大截。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二层，稳定执行比偶尔跑通更难\u003c/strong\u003e。τ-bench提出了一个叫\u003ccode\u003epass^k\u003c/code\u003e的指标，衡量的是同一个任务连续跑k次是不是次次都成功。直观理解，如果把每次执行看作相互独立，单次成功率即使有90%，连续8次全部成功的概率也只有43%左右。而在τ-bench的实际测试里，GPT-4o零售场景的平均成功率超过60%，\u003ccode\u003epass^8\u003c/code\u003e却降到25%以下——这也是为什么“Agent能跑出一个漂亮的demo”和“Agent能每天稳定地跑”完全是两件事。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三层，长链路任务是目前公认的最大短板\u003c/strong\u003e。2026年发布的OSWorld 2.0专门测试长流程真实任务，一共108个，每个任务对熟练的人类操作者来说，中位耗时都要1.6小时。在论文测试的配置里，Claude Opus 4.8开最大思考、批量工具调用，严格意义上的完成率是20.6%（放宽到部分得分能到54.8%），token效率更高的GPT-5.5完成率约13%。这组数字只对应OSWorld 2.0所测的这类长流程电脑操作任务，不能代表客服Agent、代码Agent这些其他场景的整体水平；而且这个领域进展很快，7月Anthropic已经发布了新一代的Opus 5，官方称其在这项基准上的表现已经超过Opus 4.8，所以这里给出的仍是“当时那批模型能做到什么程度”，不是当前的最新水平。\u003c/p\u003e\n\u003cp\u003e三层难度合在一起，指向的是同一件事：Agent真正的门槛不在“能不能调用工具”，而在“能不能把一条受规则约束的长链路任务，稳定、正确地走到底”。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"agent-vs-chatbot-execution-power-2.avif\"\n          alt=\"Agent执行能力的三道关\"/\u003e \u003cfigcaption\u003e\n             Agent执行能力的三道关\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e这几组数据来自不同模型、不同版本、不同评测框架，彼此之间不能直接换算比较，只用来说明“执行”这件事本身有多难，不做具体产品的排名依据。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"四agent内部到底多了什么\"\u003e四、Agent内部到底多了什么\u003c/h2\u003e\n\u003cp\u003e拆开来看，一个能稳定干活的Agent，通常要具备六个部件：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAgent = 大模型 + 工具 + 环境权限 + 任务状态 + 执行循环 + 安全护栏\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e大模型\u003c/strong\u003e负责理解目标、判断下一步、处理意外情况，相当于厨房里的大脑，但光有大脑做不出饭\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e工具\u003c/strong\u003e是它和外部世界打交道的手，包括读写文件、查数据库、发邮件、执行命令\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e权限\u003c/strong\u003e决定它真正能动什么——没有权限，Agent说到底也只能给建议\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e状态\u003c/strong\u003e让它知道任务走到哪一步了，不用每次都从头猜一遍\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e执行循环\u003c/strong\u003e是“观察→规划→行动→反馈→检查→继续”这条闭环，这是Agent和“调用过一次工具的聊天机器人”最本质的区别\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e安全护栏\u003c/strong\u003e决定哪些操作必须停下来问人，比如删除文件、发邮件前的确认\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e大模型能力已经相当普及，工具接入也越来越常见；真正拉开差距的通常是后四个部件——权限给到什么程度、状态记不记得住、循环转不转得起来、护栏立在哪儿。\u003c/p\u003e\n\u003ch2 id=\"五真实片段workbuddy的一次多步执行和一个反例\"\u003e五、真实片段：WorkBuddy的一次多步执行，和一个反例\u003c/h2\u003e\n\u003cp\u003e上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里记录过几个真实场景，这里挑一个执行场景和一个对照场景重新看一遍。先说清楚：下面这个例子能证明它完成了多步任务，但不足以证明每一步都是“临场动态决策”——这一点留在下一节一起说。\u003c/p\u003e\n\u003cp\u003e一个是手机远程遥控电脑：在外面发一句“看一下当前文件夹下有哪些文件，把内容转写成markdown保存一份，总结主要内容给我”，到家活儿已经跑完了。这句话背后是它自己拆成了“列文件→读取→转写→总结”几步，而不是我手动点了四次功能——这至少说明它具备了“接收目标、自己拆解步骤”的能力，是本文第二节说的执行权的一种体现。\u003c/p\u003e\n\u003cp\u003e再对比同一篇里的“每日AI新闻推送”：设定好时间和内容规则，到点自动推送——这更接近固定workflow而不是严格意义上的Agent，因为触发条件和执行动作都是提前定好的，模型没有在中途做新的决策。这个对比恰好能落回本文第二节的核心判断：\u003cstrong\u003e同一个产品里，不同功能可能分别落在workflow和Agent两端，不能一概而论。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"六agent不是越自主越好\"\u003e六、Agent不是越自主越好\u003c/h2\u003e\n\u003cp\u003e篇幅有限，这里只强调一个容易被忽略的判断：Agent能自主决策，不代表应该在所有事情上都放手自主。\u003c/p\u003e\n\u003cp\u003e先说一个真实的小例子：上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里，让WorkBuddy围绕一个主题跑一份调研报告，结果不算完美——报告里列的要点，有几个是没想到的，但也有几个是它“想当然”给出的，得自己核实过才能用。这提醒的是：\u003cstrong\u003eAgent能自己往前推进，不代表它推进的每一步都对\u003c/strong\u003e。在当前阶段，尤其是面对调研、发布、邮件和数据修改这类任务，把Agent的产出当成待验收的结果，而不是直接当最终结果使用，是正常的使用方式。\u003c/p\u003e\n\u003cp\u003e行业层面也有数据支撑这个判断。Gartner预测，超过40%的agentic AI项目会在2027年底前被取消，直接原因包括成本上升、业务价值不清晰、风险控制不足；同一份报告也指出，当前模型的成熟度和自主能力，仍不足以稳定完成复杂的业务目标。换句话说，项目失败通常不是单一的技术问题，而是能力、成本、价值和治理共同作用的结果。报告里还提到一个更扎心的现象：市面上数千家自称“agentic AI”的厂商里，真正名副其实的大概只有130家左右——这就是所谓的“agent washing”，把聊天机器人换个说法包装成Agent。\u003c/p\u003e\n\u003cp\u003e这个判断其实和第三节的执行数据是一体两面：在OSWorld 2.0测试的这类长流程电脑操作任务上，当时最佳配置的完整完成率也只有约两成。这不能代表所有Agent场景，但足以说明——面对长链路、高权限、难以回滚的任务，默认让Agent完全自治，在当下不是一个稳妥的选择。\u003c/p\u003e","title":"Agent和聊天机器人的本质区别是什么？"},{"content":" 本文是「上下文窗口」系列第三篇。前两篇分别讲了《标称1M的token，为什么32K就开始变笨》（为什么会变笨）和《KV Cache：每读1个token，就要交一笔“显存税”》（为什么会爆显存）。这一篇不重复论证，直接回答一个更实际的问题：到底该设多大。\n两位读者间隔两天，问了同一个问题：\n“Mac 24GB，到底该开16K还是32K？”\n“现在的模型动不动就说支持1M上下文，是不是就该一直开满？”\n答案我已经在评论区打完字了，只是散在各处。这篇把它整理成一套能直接照抄的判断框架。\n一、上下文有三个长度，不是一个 三个Context长度概念模型 先纠正一个直觉误区：Context越大越好。\n前两篇已经用数据说清楚过：厂商标称的窗口，和模型真正“读懂”的窗口，从来不是一回事——在NoLiMa这项刻意排除关键词匹配、只测语义理解的基准测试中，32K的长度下，12个主流模型里有11个的表现跌到了短上下文性能的50%以下；而KV Cache这笔显存账，会随长度线性膨胀到硬件扛不住。这两条结论不重新展开，直接拿来当地基。\n在这两条结论之上，这篇提出一个更好用的框架——任何一个模型的上下文窗口，其实是三个数字，不是一个：\n标称长度（Advertised）：厂商发布会念的数字，128K、1M。它的含义仅仅是“技术上能塞进去”，不代表“能读懂”。 有效长度（Effective）：大海捞针、NoLiMa、RULER这类基准测出来的、模型表现开始明显滑坡之前的长度。这是“真正建议放心使用”的上限。 最佳长度（Optimal）：综合了速度、成本、显存、稳定性之后，日常真正该设的那个值。它通常比有效长度还要保守——因为有效长度只回答“模型还读得懂”，没回答“划不划算”“跑不跑得动”。 三层长度往往是层层递减的：标称1M，有效可能只有128K，而落到你的日常使用，最佳长度经常只有32K甚至更低。后面每一节，本质上都是在帮你把“最佳长度”这个数字，套到你的具体场景里去。\n二、云端API：按任务场景，不按模型规格 面对一个API，第一反应不该是“这个模型支持多少”，而是“我这个任务该设多少”。按任务类型分场景，给一套可以直接抄的建议：\n任务类型 建议长度 为什么 日常聊天 8K～16K 没必要背着几百页历史对话，多背的都是白付费 写作/总结单篇长文 16K～32K 覆盖绝大多数文档，还没进入U形曲线最吃亏的中段 代码Agent 32K～64K 需要跨文件理解，但推理能力和检索能力是两件事，别无脑往上加 RAG检索类任务 64K～128K 真正决定效果的是检索准不准，不是Context开多大——这条对应前一篇讲过的“新模型捞针能力已经不差” 法律/论文/合同/整本书级长文档 128K以上 就算窗口够大，也建议先分章节处理，一次性塞满不如分块问得准 这张表背后有一条硬规律：任务越接近“综合推理”“多步分析”，越不该无脑加长上下文；越接近“从一堆材料里找一个具体的点”，越可以放心用长窗口。这也是前一篇里讲过的机制——长上下文里干扰项越多、格式越相似，模型越容易自信地编答案。加长窗口能扩大你能塞的材料范围，但不会让模型的推理能力跟着变强。\n把厂商的收费拐点，当成性价比参考线 2026年两个真实的定价规则：Gemini3.1Pro（即前两篇提到的Gemini3Pro系列）上下文超过200K开始阶梯涨价，GPT-5.5输入超过272K直接翻倍。\n这两个数字不只是“厂商想多赚钱”这么简单。标准全量注意力机制的理论计算复杂度随长度平方增长——这是长上下文对厂商算力成本构成实打实负担的根本原因；当然，实际部署中MLA、滑动窗口注意力等架构优化（前一篇讲过的DeepSeek MLA就是典型）能显著降低真实计算和显存开销，但压力并不会被完全抹平，只是被推迟或减轻。厂商选择在哪个长度设收费闸门，某种程度上等于厂商自己交了一份“这个长度开始不划算”的答卷。你不需要知道他们后台的具体成本曲线，看价目表拐点在哪，就知道大概在哪一档之后，性价比开始变差。\n需要说清楚的是：这只是一种经验性的判断框架，不是绝对规律——不同厂商的定价还会受市场策略、模型架构差异、竞争态势的影响，同样是长上下文，有的厂商靠架构优化（比如KV Cache本身压缩得狠）扛住了成本，定价就没这么陡。把它当参考线，而不是当铁律。\n三、为什么Context越大，不只是变笨，还会变慢 KV Cache那篇算过一笔硬账，这里只提炼成一条因果链，不重新推导：\nContext↑ → KV Cache↑ → 显存占用↑ → 首字等待时间（TTFT）和生成速度↓ → 本地部署OOM风险↑\n翻译成人话：上下文每往上调一档，模型要保管的“草稿纸”就线性变厚。Prefill阶段（读入你的输入）变慢是因为要把这些草稿纸现算出来；Decode阶段（一个字一个字往外吐）变慢，是因为每吐一个字，都要把这张越来越厚的草稿纸整个翻一遍。云端用户感知到的是“响应变慢、账单变贵”；本地部署用户感知到的是“内存肉眼可见地涨、模型直接加载失败”。\n本地部署为什么不能照搬云端的长度设置，答案就在这条链条里。\n四、本地部署：显存决定你的上限，不是模型决定 本地部署24GB Mac推理限制模型 云端用户只受“有效长度”这一个约束——模型能力不够，顶多是回答质量下降。本地部署用户要同时扛住两个约束：能力上限和硬件上限，取较小值。硬件上限往往先到。\n以一台MacBook Pro M4 Pro、24GB统一内存为例，这是项目里实测过的配置：\n模型 量化 24GB Mac下的状态 已验证的上下文设置 Qwen3-32B IQ4_XS / MLX 4bit 临界状态，需要手动把GPU内存上限从默认约16GB抬高到21GB左右，且机器需要专用 先设8192（8K）跑通，验证过可以再往上试16384（16K） Gemma3-27B / Qwen3-27B Q4_K_M 同样临界，比32B多留一点余量 目前没有单独测过具体上限，暂不给精确数字 几个要点：\n第一，macOS默认不会把全部内存都给GPU用。 24GB的机器，默认只放行大约16GB给Metal，很多人第一反应“明明24GB怎么27B都加载不了”，就是卡在这一步。需要手动执行sudo sysctl iogpu.wired_limit_mb=21504把上限抬到21GB左右（留约3GB给系统），重启会失效，想长期生效需要建一个LaunchDaemon常驻。这条属于系统级内存参数调整，执行前建议先了解它的影响范围（把过多内存划给GPU可能导致系统本身卡顿甚至无响应）；如果不确定，优先尝试LM Studio等推理框架里自带的参数调节，而不是直接改系统参数。\n第二，上下文长度是你手动签的一张显存支票。 llama.cpp和LM Studio这类推理框架，会按你设置的上下文长度，把对应的KV Cache显存提前划走——不管你实际用不用得到那么长。把Context Length拉满再抱怨内存不够，等于自己签了张空头支票怪银行。\n第三，落地动作就三个，KV Cache那篇已经给过：\n按需设置，别拉满。日常总结任务8K～16K够用，代码和长文任务再往上试。 把KV Cache量化打开：llama.cpp用--cache-type-k q8_0 --cache-type-v q8_0（V的量化要同时开Flash Attention），LM Studio在加载参数里也有对应开关。8-bit能把同样长度的KV Cache砍掉一半，日常任务质量基本无感。 长对话/Agent场景，定期用摘要换草稿纸——让模型总结当前进展、状态，带着摘要开新会话，而不是让KV Cache背着几万token的历史一路涨上去。 所以，本地部署不是“模型支持多长你就能开多长”，是“你的显存装得下多长，你就只能开多长”。\n五、社区案例：Qwen3.6-35B的“复读机”翻车，是不是长上下文的锅 这一节的数据全部来自公开的社区报告，不是本号实测，先说明白这一点。\nQwen3.6-35B-A3B官方标称原生支持262,144（约256K）token上下文，可扩展到1,010,000。听起来是一款长上下文能力很能打的模型。但社区里反复出现同一类反馈：长对话跑到一定长度后，输出会陷入逐句循环，同一句话反复重复，怎么都停不下来——俗称“复读机”。公开的报告里，触发的长度并不统一：LM Studio的bug追踪上有用户记录约20K附近就开始高概率触发；另一份社区教程记录的是128K附近出现同类问题，靠调整--repeat-penalty、--min-p等采样参数缓解，配合关闭过度的重复惩罚冲突后基本能解决。\n这个案例值得放进这篇文章，是因为它补了一个前两篇没覆盖到的角度：前面讲的“变笨”，是模型读了但理解跑偏；这里的“复读”，更接近生成阶段的稳定性问题（可能涉及采样参数、重复惩罚设置、位置编码扩展方式等具体机制），而不一定代表模型理解能力本身下降。 换句话说，即便你的任务量刚好卡在“有效长度”以内，也不代表长上下文下什么故障都不会发生——这也是为什么“最佳长度”往往要比“有效长度”更保守一档：留出的不只是显存和成本的余量，也是稳定性的余量。\n写在最后 上下文长度决策树 把这篇的判断压缩成一张决策树，日常直接照抄：\n1 2 3 4 5 是不是日常聊天？ → 8K～16K 写作/总结单篇长文？ → 16K～32K 代码Agent、跨文件任务？ → 32K～64K RAG检索类任务？ → 64K～128K 法律/论文/合同/整本书级材料？ → 128K以上（建议分章节处理） 一句话总结这篇：上下文窗口的最佳值，从来不是宣传页上的数字，而是任务复杂度、硬件资源、成本预算、响应速度这几个变量共同决定的。调到刚好够用，通常比一味追求更大，更稳、更快、也更省。\n找机会再讨论一下新一代模型（DeepSeek V4、Gemini3.5这类支持超长上下文的新模型）该怎么设，留到下一篇专门拆。\n数据来源\nNoLiMa基准、RULER基准、Chroma《Context Rot》报告、斯坦福《Lost in the Middle》论文：详见本系列第一篇《标称1M的token，为什么32K就开始变笨》 Qwen3官方技术报告、DeepSeek-V2论文（MLA架构）、vLLM《PagedAttention》论文：详见本系列第二篇《KV Cache：每读1个token，就要交一笔“显存税”》 《别再被的模型名劝退了（下）》：24GB MacBook Pro M4 Pro实测数据、Qwen3-32B部署流程 Qwen3.6-35B-A3B模型卡（Hugging Face）：huggingface.co/Qwen/Qwen3.6-35B-A3B Qwen3.6-35B-A3B长上下文循环输出问题（LM Studio bug tracker）：github.com/lmstudio-ai/lmstudio-bug-tracker/issues/1913 ","permalink":"https://blog.onecai.site/2026/08/07/068-context-window-practical-guide/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文是「上下文窗口」系列第三篇。前两篇分别讲了《标称1M的token，为什么32K就开始变笨》（为什么会变笨）和《KV Cache：每读1个token，就要交一笔“显存税”》（为什么会爆显存）。这一篇不重复论证，直接回答一个更实际的问题：\u003cstrong\u003e到底该设多大。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e两位读者间隔两天，问了同一个问题：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e“Mac 24GB，到底该开16K还是32K？”\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e“现在的模型动不动就说支持1M上下文，是不是就该一直开满？”\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e答案我已经在评论区打完字了，只是散在各处。这篇把它整理成一套能直接照抄的判断框架。\u003c/p\u003e\n\u003ch2 id=\"一上下文有三个长度不是一个\"\u003e一、上下文有三个长度，不是一个\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"context-window-practical-guide-1.avif\"\n          alt=\"三个Context长度概念模型\"/\u003e \u003cfigcaption\u003e\n             三个Context长度概念模型\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e先纠正一个直觉误区：\u003cstrong\u003eContext越大越好\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e前两篇已经用数据说清楚过：厂商标称的窗口，和模型真正“读懂”的窗口，从来不是一回事——在NoLiMa这项刻意排除关键词匹配、只测语义理解的基准测试中，32K的长度下，12个主流模型里有11个的表现跌到了短上下文性能的50%以下；而KV Cache这笔显存账，会随长度线性膨胀到硬件扛不住。这两条结论不重新展开，直接拿来当地基。\u003c/p\u003e\n\u003cp\u003e在这两条结论之上，这篇提出一个更好用的框架——\u003cstrong\u003e任何一个模型的上下文窗口，其实是三个数字，不是一个\u003c/strong\u003e：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e标称长度（Advertised）\u003c/strong\u003e：厂商发布会念的数字，128K、1M。它的含义仅仅是“技术上能塞进去”，不代表“能读懂”。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e有效长度（Effective）\u003c/strong\u003e：大海捞针、NoLiMa、RULER这类基准测出来的、模型表现开始明显滑坡\u003cstrong\u003e之前\u003c/strong\u003e的长度。这是“真正建议放心使用”的上限。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e最佳长度（Optimal）\u003c/strong\u003e：综合了速度、成本、显存、稳定性之后，日常真正该设的那个值。它通常比有效长度还要保守——因为有效长度只回答“模型还读得懂”，没回答“划不划算”“跑不跑得动”。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e三层长度往往是层层递减的：标称1M，有效可能只有128K，而落到你的日常使用，最佳长度经常只有32K甚至更低。后面每一节，本质上都是在帮你把“最佳长度”这个数字，套到你的具体场景里去。\u003c/p\u003e\n\u003ch2 id=\"二云端api按任务场景不按模型规格\"\u003e二、云端API：按任务场景，不按模型规格\u003c/h2\u003e\n\u003cp\u003e面对一个API，第一反应不该是“这个模型支持多少”，而是“我这个任务该设多少”。按任务类型分场景，给一套可以直接抄的建议：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e任务类型\u003c/th\u003e\n          \u003cth\u003e建议长度\u003c/th\u003e\n          \u003cth\u003e为什么\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e日常聊天\u003c/td\u003e\n          \u003ctd\u003e8K～16K\u003c/td\u003e\n          \u003ctd\u003e没必要背着几百页历史对话，多背的都是白付费\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e写作/总结单篇长文\u003c/td\u003e\n          \u003ctd\u003e16K～32K\u003c/td\u003e\n          \u003ctd\u003e覆盖绝大多数文档，还没进入U形曲线最吃亏的中段\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e代码Agent\u003c/td\u003e\n          \u003ctd\u003e32K～64K\u003c/td\u003e\n          \u003ctd\u003e需要跨文件理解，但推理能力和检索能力是两件事，别无脑往上加\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eRAG检索类任务\u003c/td\u003e\n          \u003ctd\u003e64K～128K\u003c/td\u003e\n          \u003ctd\u003e真正决定效果的是检索准不准，不是Context开多大——这条对应前一篇讲过的“新模型捞针能力已经不差”\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e法律/论文/合同/整本书级长文档\u003c/td\u003e\n          \u003ctd\u003e128K以上\u003c/td\u003e\n          \u003ctd\u003e就算窗口够大，也建议先分章节处理，一次性塞满不如分块问得准\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这张表背后有一条硬规律：\u003cstrong\u003e任务越接近“综合推理”“多步分析”，越不该无脑加长上下文\u003c/strong\u003e；越接近“从一堆材料里找一个具体的点”，越可以放心用长窗口。这也是前一篇里讲过的机制——长上下文里干扰项越多、格式越相似，模型越容易自信地编答案。加长窗口能扩大你能塞的材料范围，但不会让模型的推理能力跟着变强。\u003c/p\u003e\n\u003ch3 id=\"把厂商的收费拐点当成性价比参考线\"\u003e把厂商的收费拐点，当成性价比参考线\u003c/h3\u003e\n\u003cp\u003e2026年两个真实的定价规则：Gemini3.1Pro（即前两篇提到的Gemini3Pro系列）上下文超过200K开始阶梯涨价，GPT-5.5输入超过272K直接翻倍。\u003c/p\u003e\n\u003cp\u003e这两个数字不只是“厂商想多赚钱”这么简单。标准全量注意力机制的理论计算复杂度随长度平方增长——这是长上下文对厂商算力成本构成实打实负担的根本原因；当然，实际部署中MLA、滑动窗口注意力等架构优化（前一篇讲过的DeepSeek MLA就是典型）能显著降低真实计算和显存开销，但压力并不会被完全抹平，只是被推迟或减轻。\u003cstrong\u003e厂商选择在哪个长度设收费闸门，某种程度上等于厂商自己交了一份“这个长度开始不划算”的答卷\u003c/strong\u003e。你不需要知道他们后台的具体成本曲线，看价目表拐点在哪，就知道大概在哪一档之后，性价比开始变差。\u003c/p\u003e\n\u003cp\u003e需要说清楚的是：这只是一种经验性的判断框架，不是绝对规律——不同厂商的定价还会受市场策略、模型架构差异、竞争态势的影响，同样是长上下文，有的厂商靠架构优化（比如KV Cache本身压缩得狠）扛住了成本，定价就没这么陡。把它当参考线，而不是当铁律。\u003c/p\u003e\n\u003ch2 id=\"三为什么context越大不只是变笨还会变慢\"\u003e三、为什么Context越大，不只是变笨，还会变慢\u003c/h2\u003e\n\u003cp\u003eKV Cache那篇算过一笔硬账，这里只提炼成一条因果链，不重新推导：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eContext↑ → KV Cache↑ → 显存占用↑ → 首字等待时间（TTFT）和生成速度↓ → 本地部署OOM风险↑\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e翻译成人话：上下文每往上调一档，模型要保管的“草稿纸”就线性变厚。Prefill阶段（读入你的输入）变慢是因为要把这些草稿纸现算出来；Decode阶段（一个字一个字往外吐）变慢，是因为每吐一个字，都要把这张越来越厚的草稿纸整个翻一遍。云端用户感知到的是“响应变慢、账单变贵”；本地部署用户感知到的是“内存肉眼可见地涨、模型直接加载失败”。\u003c/p\u003e\n\u003cp\u003e本地部署为什么不能照搬云端的长度设置，答案就在这条链条里。\u003c/p\u003e\n\u003ch2 id=\"四本地部署显存决定你的上限不是模型决定\"\u003e四、本地部署：显存决定你的上限，不是模型决定\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"context-window-practical-guide-2.avif\"\n          alt=\"本地部署24GB Mac推理限制模型\"/\u003e \u003cfigcaption\u003e\n             本地部署24GB Mac推理限制模型\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e云端用户只受“有效长度”这一个约束——模型能力不够，顶多是回答质量下降。本地部署用户要同时扛住两个约束：\u003cstrong\u003e能力上限和硬件上限，取较小值\u003c/strong\u003e。硬件上限往往先到。\u003c/p\u003e\n\u003cp\u003e以一台\u003cstrong\u003eMacBook Pro M4 Pro、24GB统一内存\u003c/strong\u003e为例，这是项目里实测过的配置：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e量化\u003c/th\u003e\n          \u003cth\u003e24GB Mac下的状态\u003c/th\u003e\n          \u003cth\u003e已验证的上下文设置\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-32B\u003c/td\u003e\n          \u003ctd\u003eIQ4_XS / MLX 4bit\u003c/td\u003e\n          \u003ctd\u003e临界状态，需要手动把GPU内存上限从默认约16GB抬高到21GB左右，且机器需要专用\u003c/td\u003e\n          \u003ctd\u003e先设8192（8K）跑通，验证过可以再往上试16384（16K）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGemma3-27B / Qwen3-27B\u003c/td\u003e\n          \u003ctd\u003eQ4_K_M\u003c/td\u003e\n          \u003ctd\u003e同样临界，比32B多留一点余量\u003c/td\u003e\n          \u003ctd\u003e目前没有单独测过具体上限，暂不给精确数字\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e几个要点：\u003c/p\u003e","title":"上下文窗口实战：不同任务、不同部署方式，到底该设多长"},{"content":" 文中价格与行业数据查证于2026年7月，逐条标注出处，所有数字均可在文末溯源。\n一、一笔9.2亿美元的月租金 先说一件最近的事。\n据24/7 Wall St.今年6月的报道（经Yahoo Finance转载），Google要向SpaceX支付每月9.2亿美元，租用大约11万张Nvidia GPU，合作期从2026年10月持续到2029年6月。这个租金水平，据Dwarkesh Patel在同期一篇博客文章中的测算，大约是这批卡现货价的2倍，而现货价本身，据其文中引用，比2026年2月的低点又涨了40%以上。\n如果你只看新闻标题，这条信息很容易被淹没在“存储芯片涨价”“苹果Mac涨价”这类更抓眼球的消息里。但仔细想一下会发现，这条新闻讲的其实是一件不太一样的事：苹果涨价涨的是造一台电脑的成本，Google多付的这笔钱，涨的是租一张已经造好的卡的价格。\n一个是硬件采购市场，一个是算力租赁市场。这是两件事。\n而与此同时，如果你打开任何一家大模型厂商的API价目表，看到的又是另一个方向的走势——Token调用价格，还在持续往下探底。\n三条线，三个方向。把这三条线分别拆开，看看它们各自在讲什么故事，以及它们为什么能同时成立。\n二、拆开“算力”这个词——三层价格，三个逻辑 算力价格不是一个市场，而是三个市场 “算力会不会越来越贵”这个问题之所以长期争论不清，是因为很多时候大家讨论的并不是同一个市场。实际上，“算力价格”至少包含三个层面：\n层次 近期走势 核心驱动力 硬件采购（芯片/显存） 涨 实物供给稀缺：HBM、DRAM产能被AI数据中心抢占，叠加电力瓶颈 算力租赁（GPU小时价） 涨 头部AI实验室营收增速远超算力供给增速，愿意为确定性支付溢价 Token调用（API单价） 跌 算法效率提升、开源竞争、推理优化持续压低完成同一任务所需的算力 下面按这个顺序，一层一层拆。\n三、变贵的第一条线：硬件采购——供给side的实物通胀 这条线的证据链，我在《存储通胀：苹果涨21%、美光毛利80%、华为另起炉灶》里已经详细拆过，这里只做简要回顾。\n核心逻辑：多家产业分析和机构研报（Wedbush等，经财经媒体转引）估算，AI服务器对DRAM的需求量约为普通服务器的8到10倍，这轮需求爆发叠加存储厂商主动向HBM倾斜产能，共同推高了价格。据21世纪经济报道今年3月的调查，三大存储厂商已将18%到28%的DRAM产能分配给HBM，且因为HBM良率仅50%到60%、单位容量实际消耗的产能相当于3到4颗标准DRAM，这部分产能挤占的效果被进一步放大；同期TrendForce的预测显示，2026年全球DRAM行业资本支出约613亿美元，同比增长约14%，但三星2026年DRAM产能预计仅增长约5%，扩产速度明显跟不上需求增速。\nAI时代，瓶颈从芯片扩展到整个基础设施 电力也在成为新的硬约束。据Gartner今年6月的官方预测，2026年全球数据中心用电量将达到565TWh，较2025年的447TWh增长26%，AI优化服务器的耗电占比将从上一年的约20%升至31%。美国最大电力市场PJM的容量拍卖价格也印证了这一点：据PJM官方公布及IEEFA的整理，2024/25年度的清算价为每兆瓦日28.92美元，到2025/26年度涨至269.92美元，涨幅接近10倍；最新的2026/27年度拍卖进一步涨到329.17美元，触及了监管设定的价格上限。\n这一层涨价，本质上和普通商品通胀是同一个逻辑：实物产能扩张需要两到三年周期，需求却是指数级涨上来的，供需缺口短期填不平。\n四、变贵的第二条线：算力租赁——需求增速跑赢供给增速 这条线主要素材来自Dwarkesh Patel 2026年7月29日发布的博客《Why compute might get 10x+ more expensive in coming years》。这篇东西本身是作者标注为“两小时速写”的思想实验，不是严谨的预测报告，但里面的一部分证据和推理框架，值得认真对待。\n先说最实的一块：文章开头那条Google-SpaceX的租赁交易（每月9.2亿美元、约11万张GPU），是全文唯一一条有具体交易、有第三方财经媒体信源支撑的硬数据。这条信息本身就足以说明，至少在头部实验室需要的那部分算力（不能用现货，要长期锁定、要保证数据安全和利用率）里，价格确实在涨。\n作者给出的一个推理框架是这样的：如果头部实验室的营收继续保持年化10倍增长，而算力供给年化只能做到3倍增长（这个3倍的数字，作者引用了Epoch AI一篇关于头部实验室算力使用的分析），那么中间的差额只能靠三件事的组合来填：实验室利润率上升、算力单价上升、推理占算力支出的比例上升。而实验室并不希望第三项主导——如果大部分算力都花在了跑存量模型的推理上，等于变相承认继续投入训练已经不划算了。所以差额主要落在前两项。\n3倍这个算力供给增速，作者拆成了三个乘数：摩尔定律贡献约1.4倍，新建晶圆厂贡献约1.2倍（受EUV光刻机设备供应制约，瓶颈预计持续到2030年），AI抢占先进制程晶圆份额贡献约1.8倍（预计2027年底见顶，届时AI将占N3产能的86%，目前约60%）。这三个数字都是作者自己的估算，我没能找到独立的第三方交叉验证，写在这里仅代表这篇博客的推理链条，不代表已核实的行业共识。\n接下来这部分数字，需要打个更大的问号：作者提到Anthropic推理毛利率在近两年内出现了大幅上涨，但他自己在原文脚注里明确写这是“total vibe claim”（纯粹凭感觉的说法），不是查出来的实测数据，所以这个具体数字不予采用。倒是可以提供一组真实核实过的替代数据：据《华尔街日报》2026年5月报道（经Axis Intelligence整理），Anthropic的算力成本占营收比例从今年一季度的71美分/美元，降到了二季度的56美分/美元，方向上印证了“规模扩大后单位成本占比在下降”这个判断，但幅度远没有“vibe claim”里暗示的那么夸张。\n文章里那个更出圈的“250万美元一张H100”的说法，前提是“如果一张H100真能跑出一个人类水平的软件工程师”，按当前软件工程师市场价，这张卡理论上应该能租到远超今天现货价的水平。这是一个完整的思想实验，但前提必须是AI真的达到了人类水平的工程能力，并且这个能力的边际价值不会因为供给暴增而崩塌。作者自己也承认，这个假设成不成立，目前谁也说不准——这个数字本身没有可核实的经验依据，只是作者论证逻辑的一部分，读的时候需要清楚这一点。\n这里有一个值得借用的经济学工具，叫“Alchian-Allen效应”，简单的可以理解为：当一笔固定成本被加到两种不同质量的商品上时，优质品会变得“相对更便宜”，需求会转向优质品。放到算力上理解就是——当GPU小时成本本身已经很贵，用一个能力较弱、需要消耗更多Token才能完成同样任务的模型，反而变得非常不划算。所以效率更高、能力更强的模型，能收更高的溢价，而不是被拖入单纯的价格战。这也是为什么头部模型很可能持续保持定价权，而不是随着通用能力的普及一起被打成白菜价。\n五、变便宜的第三条线：Token调用——效率通缩仍在继续 前面两条是涨价的线，这一条来看跌价的。\n以第三方定价追踪站PricePerToken.com和TokenCost.app整理的历史数据为锚点（这两个都是聚合追踪各家API定价的独立站点，不是OpenAI官方一手页面，但相互印证、数字一致）：2023年3月GPT-4发布时，每百万Token输入30美元、输出60美元；到2024年5月GPT-4o发布，降到输入5美元、输出15美元。如果以GPT-4发布价作为高位锚点，仅这一次换代就带来了约6倍的降幅，此后价格战仍在持续压低通用Token的价格。\n国产大模型这边，据中国信通院的数据（经业内文章转引，未能找到信通院原始报告链接，标注为二手引用），2026年国内大模型API平均价格较2023年下降超过90%，同期性能提升了3到5倍。同时也值得指出一个反直觉的现象：据证券日报今年的报道，2026年上半年海外部分云厂商API价格因为存储和GPU成本上涨反而在涨价，最高涨幅据报道达到463%，DeepSeek却在这个背景下于5月22日宣布旗舰模型V4-Pro永久降价75%——这说明“Token降价”并不是全球统一的必然规律，国内这轮降价更多是市场竞争策略的结果，而不是纯粹的成本下降传导。\n这条降价曲线背后的技术支撑，其实已经很熟悉了——MoE稀疏化让每次推理只激活总参数的一小部分；量化和蒸馏压缩模型体积；KV Cache优化能让同样的上下文占用直接减半，这部分逻辑在我之前那篇KV Cache文章里讲过“降税”的比喻；Prompt Caching命中和未命中的价格能相差数十倍甚至更多，据Apifox今年5月整理的中国大模型价格对比，月之暗面Kimi K2.6的缓存命中价低至0.07美元/百万Token。\n但这条降价曲线并不等于企业的AI账单在变小。恰恰相反——通用Token价格在探底，企业的AI运营总支出却在膨胀，原因是企业正在从简单问答转向Agent协作、代码生成这类更消耗Token的复杂工作流。这一点可以用Anthropic自己的数字来印证：据Anthropic自己在融资公告中披露（经VentureBeat、Simon Willison等多方转载核实），其年化营收从2025年末的约90亿美元，一路涨到2026年5月的470亿美元，公司自己的原话是“过去三年里，每一年都保持了10倍以上的年化增长”。这条数据同时说明两件事：一是Token价格确实在降，厂商靠规模和效率仍能维持业务增长；二是需求膨胀的速度，远远盖过了降价带来的成本节约。\n单位成本下降 ≠ 总成本下降 六、三条线为什么不矛盾——它们是三个不同的市场 现在可以把三条线拼在一起看了。\n硬件涨价，涨的是“造出同样1P算力”需要付出的实物成本——芯片和显存的原材料、产能都在被AI数据中心抢占。租金涨价，涨的是“确定性拿到这批算力”需要付出的溢价——头部实验室的营收增速远远跑赢了算力供给的增速，愿意为稳定的算力供应多付钱。Token降价，降的是“完成同一个任务需要消耗多少有效算力”——这是效率进步和市场竞争共同压出来的结果，目前它下降的速度，仍然快于前两条线上涨的速度。\n三条线合在一起，才能解释一个看起来矛盾的现象：为什么Token越来越便宜，企业的AI总支出却越来越大。答案不是任何一条线单独造成的，而是租金上涨叠加任务复杂度提升，盖过了效率通缩带来的降价空间。\n七、一个值得保留的自我怀疑 Dwarkesh在那篇博客里，主动提到了一个经济学史上著名的赌局——Simon-Ehrlich赌局。生态学家Paul Ehrlich在1980年押注一篮子大宗商品的价格会在十年内上涨，结果被经济学家Julian Simon赢了：市场信号和技术创新，让稀缺的资源被更高效地利用，价格反而跌了。这个赌局常被用来说明，悲观预测稀缺性的一方，历史上经常出错。\n作者补了一句很诚实的话：如果这个赌约换个十年段来打，Ehrlich其实会赢（这是他文中的原话观点，历史学界对此确实也有过重新分析，认为结果对时间窗口很敏感）。他也承认，算力和大宗商品篮子不是同一个参照系——算力供给的弹性明显更低，没法像金属那样靠新矿源或替代品快速缓解——但他仍然把这个先例摆出来，提醒自己（也提醒读者）：“未来会更稀缺”这类判断，历史上并不总是对的。\n八、你站在哪个市场，答案就不一样 拆完三条线，回到最初那个问题：算力会不会越来越贵？答案取决于你是谁。\n如果你在自建训练集群或者需要长期锁定大规模算力，你感受到的是硬件采购和算力租赁的双重上涨，这条压力短期内看不到反转的迹象。\n如果你是调用API的普通开发者，只要你的任务复杂度没有跟着膨胀，你大概率还会持续享受Token价格下降带来的红利——前提是别掉进“降价了所以随便造”的陷阱，任务复杂度一旦涨上去，账单照样会失控。\n如果你在做本地部署，显存和内存涨价正在直接推高你的入场门槛。这条我在讲统一内存架构那篇里细讲过，存储通胀正在悄悄抬高“本地AI自由”的门槛。\n写在最后 这篇文章没有打算回答“算力到底会不会越来越贵”，因为这个问题本身问错了。\n硬件采购、算力租赁、Token调用是三个独立的市场，各自的走势取决于各自独立的变量：硬件通胀能不能缓解，看存储产能爬坡的速度；租金通胀能不能持续，看头部实验室的营收增速能不能继续保持10倍量级，这本身是一个关于AI能力进步速度的问题，谁也说不准；Token通缩能不能跑赢前两者，看算法效率的红利还能挤出多少空间，以及市场竞争策略会不会持续压低价格。\n三个问题分别独立，用一句“算力会/不会越来越贵”打包回答，只会得到一个听起来斩钉截铁、实际上什么都没说清楚的结论。\n下次再有人跟你说“算力肯定会越来越贵”或者“算力肯定会越来越便宜”，你可以反问一句：你说的是哪条线？\n数据来源\nDwarkesh Patel，《Why compute might get 10x+ more expensive in coming years》，2026年7月29日：dwarkesh.com/p/why-compute-might-get-10x-more-expensive（第四节主要框架、Alchian-Allen效应、Simon-Ehrlich赌局引用均来自此文） Epoch AI，《Frontier labs don\u0026rsquo;t use most AI compute》（经Dwarkesh博客引用，原始链接）：epoch.ai/gradient-updates/frontier-labs-dont-use-most-ai-compute Joey Frenette，《Google Is Paying SpaceX Over $900 Million a Month for AI Compute》，24/7 Wall St.，2026年6月9日，经Yahoo Finance转载：finance.yahoo.com/sectors/technology/articles/google-paying-spacex-over-900-151816933.html Gartner官方新闻稿，《Gartner Says Data Center Electricity Consumption to Grow 26% in 2026》，2026年6月10日：gartner.com/en/newsroom/press-releases/2026-06-10 PJM Interconnection官方拍卖结果公告（2025/26与2026/27两次Base Residual Auction）：insidelines.pjm.com；历史数据整理另见IEEFA：ieefa.org/resources/projected-data-center-growth-spurs-pjm-capacity-prices-factor-10 21世纪经济报道，《价格飙涨、业绩翻番 三大内存厂却开始“踩刹车”》，2026年3月22日：21jingji.com Wedbush存储超级周期研报（经TradingKey转引），2026年3月24日：tradingkey.com PricePerToken.com、TokenCost.app：第三方大模型API定价追踪站，用于GPT-4/GPT-4o历史定价交叉验证（非OpenAI官方一手页面） 中国信通院国产大模型API价格数据（经CSDN博客转引，未找到信通院原始报告链接，二手引用） 证券日报，《技术突破驱动成本下降 多款国产大模型宣布降价》，2026年：stcn.com Apifox，《2026年中国大模型价格战：五大前沿API成本深度对比》，2026年5月31日：apifox.com Anthropic融资公告原始数据，经VentureBeat（2026年5月8日）与Simon Willison博客（2026年5月29日）整理转载：venturebeat.com、simonwillison.net Axis Intelligence引用《华尔街日报》2026年5月20日报道，Anthropic算力成本占营收比例数据：axis-intelligence.com/anthropic-statistics 文中价格与产业数据查证于2026年7月，产业周期变化快，具体数字请以引用来源当期口径为准。相关背景可参考本账号往期：《存储通胀：苹果涨21%、美光毛利80%、华为另起炉灶》《这4大瓶颈，困住了AI算力》《为什么CPU能一卖四，GPU却只能整卡出租？》。\n","permalink":"https://blog.onecai.site/2026/08/06/067-will-ai-compute-get-more-expensive/","summary":"\u003cblockquote\u003e\n\u003cp\u003e文中价格与行业数据查证于2026年7月，逐条标注出处，所有数字均可在文末溯源。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一一笔92亿美元的月租金\"\u003e一、一笔9.2亿美元的月租金\u003c/h2\u003e\n\u003cp\u003e先说一件最近的事。\u003c/p\u003e\n\u003cp\u003e据24/7 Wall St.今年6月的报道（经Yahoo Finance转载），Google要向SpaceX支付每月9.2亿美元，租用大约11万张Nvidia GPU，合作期从2026年10月持续到2029年6月。这个租金水平，据Dwarkesh Patel在同期一篇博客文章中的测算，大约是这批卡现货价的2倍，而现货价本身，据其文中引用，比2026年2月的低点又涨了40%以上。\u003c/p\u003e\n\u003cp\u003e如果你只看新闻标题，这条信息很容易被淹没在“存储芯片涨价”“苹果Mac涨价”这类更抓眼球的消息里。但仔细想一下会发现，这条新闻讲的其实是一件不太一样的事：\u003cstrong\u003e苹果涨价涨的是造一台电脑的成本，Google多付的这笔钱，涨的是租一张已经造好的卡的价格。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e一个是硬件采购市场，一个是算力租赁市场。这是两件事。\u003c/p\u003e\n\u003cp\u003e而与此同时，如果你打开任何一家大模型厂商的API价目表，看到的又是另一个方向的走势——Token调用价格，还在持续往下探底。\u003c/p\u003e\n\u003cp\u003e三条线，三个方向。把这三条线分别拆开，看看它们各自在讲什么故事，以及它们为什么能同时成立。\u003c/p\u003e\n\u003ch2 id=\"二拆开算力这个词三层价格三个逻辑\"\u003e二、拆开“算力”这个词——三层价格，三个逻辑\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"will-ai-compute-get-more-expensive-1.avif\"\n          alt=\"算力价格不是一个市场，而是三个市场\"/\u003e \u003cfigcaption\u003e\n             算力价格不是一个市场，而是三个市场\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e“算力会不会越来越贵”这个问题之所以长期争论不清，是因为很多时候大家讨论的并不是同一个市场。实际上，“算力价格”至少包含三个层面：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e层次\u003c/th\u003e\n          \u003cth\u003e近期走势\u003c/th\u003e\n          \u003cth\u003e核心驱动力\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e硬件采购（芯片/显存）\u003c/td\u003e\n          \u003ctd\u003e涨\u003c/td\u003e\n          \u003ctd\u003e实物供给稀缺：HBM、DRAM产能被AI数据中心抢占，叠加电力瓶颈\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e算力租赁（GPU小时价）\u003c/td\u003e\n          \u003ctd\u003e涨\u003c/td\u003e\n          \u003ctd\u003e头部AI实验室营收增速远超算力供给增速，愿意为确定性支付溢价\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eToken调用（API单价）\u003c/td\u003e\n          \u003ctd\u003e跌\u003c/td\u003e\n          \u003ctd\u003e算法效率提升、开源竞争、推理优化持续压低完成同一任务所需的算力\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e下面按这个顺序，一层一层拆。\u003c/p\u003e\n\u003ch2 id=\"三变贵的第一条线硬件采购供给side的实物通胀\"\u003e三、变贵的第一条线：硬件采购——供给side的实物通胀\u003c/h2\u003e\n\u003cp\u003e这条线的证据链，我在《存储通胀：苹果涨21%、美光毛利80%、华为另起炉灶》里已经详细拆过，这里只做简要回顾。\u003c/p\u003e\n\u003cp\u003e核心逻辑：多家产业分析和机构研报（Wedbush等，经财经媒体转引）估算，AI服务器对DRAM的需求量约为普通服务器的8到10倍，这轮需求爆发叠加存储厂商主动向HBM倾斜产能，共同推高了价格。据21世纪经济报道今年3月的调查，三大存储厂商已将18%到28%的DRAM产能分配给HBM，且因为HBM良率仅50%到60%、单位容量实际消耗的产能相当于3到4颗标准DRAM，这部分产能挤占的效果被进一步放大；同期TrendForce的预测显示，2026年全球DRAM行业资本支出约613亿美元，同比增长约14%，但三星2026年DRAM产能预计仅增长约5%，扩产速度明显跟不上需求增速。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"will-ai-compute-get-more-expensive-2.avif\"\n          alt=\"AI时代，瓶颈从芯片扩展到整个基础设施\"/\u003e \u003cfigcaption\u003e\n             AI时代，瓶颈从芯片扩展到整个基础设施\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e电力也在成为新的硬约束。据Gartner今年6月的官方预测，2026年全球数据中心用电量将达到565TWh，较2025年的447TWh增长26%，AI优化服务器的耗电占比将从上一年的约20%升至31%。美国最大电力市场PJM的容量拍卖价格也印证了这一点：据PJM官方公布及IEEFA的整理，2024/25年度的清算价为每兆瓦日28.92美元，到2025/26年度涨至269.92美元，涨幅接近10倍；最新的2026/27年度拍卖进一步涨到329.17美元，触及了监管设定的价格上限。\u003c/p\u003e\n\u003cp\u003e这一层涨价，本质上和普通商品通胀是同一个逻辑：实物产能扩张需要两到三年周期，需求却是指数级涨上来的，供需缺口短期填不平。\u003c/p\u003e\n\u003ch2 id=\"四变贵的第二条线算力租赁需求增速跑赢供给增速\"\u003e四、变贵的第二条线：算力租赁——需求增速跑赢供给增速\u003c/h2\u003e\n\u003cp\u003e这条线主要素材来自Dwarkesh Patel 2026年7月29日发布的博客《Why compute might get 10x+ more expensive in coming years》。这篇东西本身是作者标注为“两小时速写”的思想实验，不是严谨的预测报告，但里面的一部分证据和推理框架，值得认真对待。\u003c/p\u003e\n\u003cp\u003e先说最实的一块：文章开头那条Google-SpaceX的租赁交易（每月9.2亿美元、约11万张GPU），是全文唯一一条有具体交易、有第三方财经媒体信源支撑的硬数据。这条信息本身就足以说明，至少在头部实验室需要的那部分算力（不能用现货，要长期锁定、要保证数据安全和利用率）里，价格确实在涨。\u003c/p\u003e\n\u003cp\u003e作者给出的一个推理框架是这样的：如果头部实验室的营收继续保持年化10倍增长，而算力供给年化只能做到3倍增长（这个3倍的数字，作者引用了Epoch AI一篇关于头部实验室算力使用的分析），那么中间的差额只能靠三件事的组合来填：实验室利润率上升、算力单价上升、推理占算力支出的比例上升。而实验室并不希望第三项主导——如果大部分算力都花在了跑存量模型的推理上，等于变相承认继续投入训练已经不划算了。所以差额主要落在前两项。\u003c/p\u003e\n\u003cp\u003e3倍这个算力供给增速，作者拆成了三个乘数：摩尔定律贡献约1.4倍，新建晶圆厂贡献约1.2倍（受EUV光刻机设备供应制约，瓶颈预计持续到2030年），AI抢占先进制程晶圆份额贡献约1.8倍（预计2027年底见顶，届时AI将占N3产能的86%，目前约60%）。这三个数字都是作者自己的估算，我没能找到独立的第三方交叉验证，写在这里仅代表这篇博客的推理链条，不代表已核实的行业共识。\u003c/p\u003e\n\u003cp\u003e接下来这部分数字，需要打个更大的问号：作者提到Anthropic推理毛利率在近两年内出现了大幅上涨，但他自己在原文脚注里明确写这是“total vibe claim”（纯粹凭感觉的说法），不是查出来的实测数据，所以这个具体数字不予采用。倒是可以提供一组真实核实过的替代数据：据《华尔街日报》2026年5月报道（经Axis Intelligence整理），Anthropic的算力成本占营收比例从今年一季度的71美分/美元，降到了二季度的56美分/美元，方向上印证了“规模扩大后单位成本占比在下降”这个判断，但幅度远没有“vibe claim”里暗示的那么夸张。\u003c/p\u003e\n\u003cp\u003e文章里那个更出圈的“250万美元一张H100”的说法，前提是“如果一张H100真能跑出一个人类水平的软件工程师”，按当前软件工程师市场价，这张卡理论上应该能租到远超今天现货价的水平。这是一个完整的思想实验，但前提必须是AI真的达到了人类水平的工程能力，并且这个能力的边际价值不会因为供给暴增而崩塌。作者自己也承认，这个假设成不成立，目前谁也说不准——这个数字本身没有可核实的经验依据，只是作者论证逻辑的一部分，读的时候需要清楚这一点。\u003c/p\u003e\n\u003cp\u003e这里有一个值得借用的经济学工具，叫“Alchian-Allen效应”，简单的可以理解为：当一笔固定成本被加到两种不同质量的商品上时，优质品会变得“相对更便宜”，需求会转向优质品。放到算力上理解就是——当GPU小时成本本身已经很贵，用一个能力较弱、需要消耗更多Token才能完成同样任务的模型，反而变得非常不划算。所以效率更高、能力更强的模型，能收更高的溢价，而不是被拖入单纯的价格战。这也是为什么头部模型很可能持续保持定价权，而不是随着通用能力的普及一起被打成白菜价。\u003c/p\u003e\n\u003ch2 id=\"五变便宜的第三条线token调用效率通缩仍在继续\"\u003e五、变便宜的第三条线：Token调用——效率通缩仍在继续\u003c/h2\u003e\n\u003cp\u003e前面两条是涨价的线，这一条来看跌价的。\u003c/p\u003e\n\u003cp\u003e以第三方定价追踪站PricePerToken.com和TokenCost.app整理的历史数据为锚点（这两个都是聚合追踪各家API定价的独立站点，不是OpenAI官方一手页面，但相互印证、数字一致）：2023年3月GPT-4发布时，每百万Token输入30美元、输出60美元；到2024年5月GPT-4o发布，降到输入5美元、输出15美元。如果以GPT-4发布价作为高位锚点，仅这一次换代就带来了约6倍的降幅，此后价格战仍在持续压低通用Token的价格。\u003c/p\u003e\n\u003cp\u003e国产大模型这边，据中国信通院的数据（经业内文章转引，未能找到信通院原始报告链接，标注为二手引用），2026年国内大模型API平均价格较2023年下降超过90%，同期性能提升了3到5倍。同时也值得指出一个反直觉的现象：据证券日报今年的报道，2026年上半年海外部分云厂商API价格因为存储和GPU成本上涨反而在涨价，最高涨幅据报道达到463%，DeepSeek却在这个背景下于5月22日宣布旗舰模型V4-Pro永久降价75%——这说明“Token降价”并不是全球统一的必然规律，国内这轮降价更多是市场竞争策略的结果，而不是纯粹的成本下降传导。\u003c/p\u003e\n\u003cp\u003e这条降价曲线背后的技术支撑，其实已经很熟悉了——MoE稀疏化让每次推理只激活总参数的一小部分；量化和蒸馏压缩模型体积；KV Cache优化能让同样的上下文占用直接减半，这部分逻辑在我之前那篇KV Cache文章里讲过“降税”的比喻；Prompt Caching命中和未命中的价格能相差数十倍甚至更多，据Apifox今年5月整理的中国大模型价格对比，月之暗面Kimi K2.6的缓存命中价低至0.07美元/百万Token。\u003c/p\u003e\n\u003cp\u003e但这条降价曲线并不等于企业的AI账单在变小。恰恰相反——通用Token价格在探底，企业的AI运营总支出却在膨胀，原因是企业正在从简单问答转向Agent协作、代码生成这类更消耗Token的复杂工作流。这一点可以用Anthropic自己的数字来印证：据Anthropic自己在融资公告中披露（经VentureBeat、Simon Willison等多方转载核实），其年化营收从2025年末的约90亿美元，一路涨到2026年5月的470亿美元，公司自己的原话是“过去三年里，每一年都保持了10倍以上的年化增长”。这条数据同时说明两件事：一是Token价格确实在降，厂商靠规模和效率仍能维持业务增长；二是需求膨胀的速度，远远盖过了降价带来的成本节约。\u003c/p\u003e","title":"算力会越来越贵吗？三条价格线在打架"},{"content":" 本文接着「术语解构」系列往下写。前两篇《上下文窗口：标称1M的token，为什么32K就开始变笨》和《KV Cache：每读1个token，就要交一笔“显存税”》，一篇讲的是“标称窗口和有效窗口之间隔着什么”，一篇讲的是“这份窗口最后要占多少显存”。这两个问题都不是这篇要重新论证的，这一篇只问一件事：长上下文值不值得为它多付这份钱。\n我们第一次用上1M上下文，大概率都会干一件事：把PDF、聊天记录、代码仓库、会议纪要一股脑塞进去，然后问模型“帮我总结一下”。\n这件事很爽，账单也很诚实。问题是模型真的把这1M token都用上了吗？\n这个问题的答案大概率是：长上下文有价值，但它不是智力外挂。它更像一张很大的工作台，能放更多材料，不代表模型会按你的重点全部读完，也不代表中间那张关键的纸不会被忽略。贵不贵，从来不是问题，更重要的是贵得值不值。\n一、1M上下文最容易出现的三个错觉 第一个错觉：能塞进去，就等于能稳定用出来。1M token解决的是输入上限，不是注意力分配。它允许你把更多材料交给模型，但模型在这些材料里怎么找、怎么权衡、会不会漏掉中间某个关键证据，是另一件事。规格表上的上下文长度，更像仓库面积；真正决定任务结果的，是模型能不能在这片仓库里找到正确的那只箱子。\n第二个错觉：一次性塞完，就更省钱。长上下文的成本不只是在模型变贵时才出现，输入本身就在计费。以发稿前重新核对的OpenAI官方GPT-4.1价格为例：约1M上下文，输入2美元/百万token，缓存输入0.5美元/百万token，输出8美元/百万token。这几个数字保质期短，Token那篇也提过，大概一个季度就可能变。单看一次调用不吓人，30万token材料，未命中缓存的输入成本大约是0.6美元。但如果每天调用20次、每次都带30万token材料，光输入就是600万token，一天12美元，一个月大约360美元。假设每次还输出2000token，一个月输出再加大约9.6美元。这还只是每天20次的轻量用法。Agent场景里，模型可能每一轮都带着几十万token在跑，规划、检索、改写、校验、重试，十几轮之后，这笔钱会变得很具体。长上下文不是不能用，而是别把它当免费内存用。\n第三个错觉：needle测试好看，就等于复杂任务可靠。找出资料中的一句暗号，和从几十份合同里判断责任边界，不是一回事。前者像在大海里找一个发光浮标，后者要把定义、例外、补充协议、历史版本、责任条款串起来看。很多模型在简单needle测试里已经很漂亮，但一换成多针、多跳、聚合、冲突判断，成绩就没那么稳了。\n二、真正的问题：有效利用率，不是能不能装下 上一篇提到过NoLiMa和RULER这两个基准测试的名字。NoLiMa做了一件很朴素的事：把问题和答案之间的字面重合去掉，只留下需要推理才能建立的关联，比如问题问的是“和某座歌剧院有关的人是谁”，而材料里只写了这个人住在歌剧院所在的城市，没有直接提到歌剧院三个字。这种设计逼着模型真正理解，而不是靠关键词匹配蒙对。\n标称上下文 vs 有效利用率 结果是，论文测试的一批声称支持128K以上上下文的模型里，短文本（1K以内）表现都不错，但随着上下文变长，表现明显下滑。在常被引用的原始结果里，GPT-4o从短文本几乎满分的99.3%，掉到32K时的69.7%。NoLiMa后续公开结果又加入了GPT-4.1等模型，个别模型的排名和数字会变化，但主线没有变：长窗口标称长度越大，越需要单独评估有效利用率，不能只看规格表。\nRULER则是从另一个角度补刀：不满足于“找一根针”，而是让模型同时找多根针、做多跳推理、再把结果聚合起来。它的评测里能看到，模型在简单needle测试里可能接近满分，但换成更接近真实任务的组合检索后，表现会随着上下文变长出现明显下滑。\n这两组测试合起来看，32K还不到1M窗口的十分之一，但在更难的评测里，很多模型已经明显掉分。窗口越做越大，只是把能装下的上限往后推，并没有同步把能认真读完的能力往后推。所以长上下文真正要问的不是“最多能塞多少”，而是关键证据放在材料的第70%位置时，模型还能不能稳定找到它、用对它，并且解释清楚它为什么重要。\n三、什么任务是真需求 材料天然长、需要跨位置对照。合同审查是最典型的例子，A处定义了一个概念，B处写了例外情形，C处的补充协议又悄悄改过一次，最后还要结合邮件往来才能判断责任边界。这几处往往不在同一页，却要放在一起看。招股书比对、长会议纪要复盘、论文综述，这些任务都是同一类问题。重点不是总结某一份文档，而是把散落在全篇不同位置的线索串起来。\n代码仓库可以归进这一类，但有一个边界值得记住：长上下文模型在小型、结构良好的代码仓库上，表现可以匹配甚至超过检索式方案；但当仓库规模和复杂度增加，检索式方案的优势就会逐渐显现出来。换句话说，几万行、结构清楚、依赖关系不复杂，长上下文可能很舒服；一旦变成多语言、多服务、历史债务很重的大仓库，直接一股脑全塞往往不如先把相关文件和调用链找出来。\n不能提前知道哪段有用。事故调查、内部审计、客服历史追踪，这类任务都属于，你没法提前判断关键线索藏在哪一轮对话、哪一条日志、哪一次提交里。这种情况下，先做检索反而可能把真正相关的那段筛掉，给模型更完整的现场，是更保险的做法。\n材料结构稳定、可以缓存复用。固定的代码库、固定的知识库、固定的产品文档，长上下文配合前缀缓存，天生适合“同一批材料反复问不同问题”。这时候的成本结构，和每次现查现搜完全不一样。Prompt Caching那篇里算过一个例子：固定的角色设定和规则放前面、每天变化的数据放后面，缓存命中率能跑到97%以上，账单直接压缩十几倍。这种场景下，长上下文的贵，其实被摊得很薄。\n多模态长材料。长视频、长音频、扫描件这类材料，切片处理最容易丢掉时间线和跨片段的关联。比如一场两个小时的会议，前40分钟有人提出了一个约束条件，后面又绕了几轮，最后才落到行动项。如果只按时间切成小段分别摘要，模型很容易把前后这层因果关系拆散。长上下文在这里的价值，是让材料按原本的时间线和结构留在一起。厂商演示里经常会展示长视频、长音频里的针检索能力，但这块公开测试没有前面几类那么扎实，先按“值得一试、但别只信演示”的态度看待。\n四、什么是伪需求 长上下文：真需求 vs 伪需求 把不会整理材料，包装成需要1M上下文。问题其实只需要三段证据，却把三百页全塞进去问模型“你自己找”。模型可能找对，也可能找错，而且找错了你更难复查，因为你自己都没读过这三百页，拿什么去核对它的答案。这和KV Cache那篇讲过的道理是一回事：新草稿要记状态，不要抄流水账。懒得筛选材料，只是把筛选的责任和风险，一起转嫁给了模型。\n把长期记忆误认为上下文窗口。上下文是这一次请求模型能看到的材料，不是可靠的记忆库。真正靠谱的长期记忆，应该有索引、有来源、有更新时间、能处理信息冲突，而不是靠一个聊天窗口越拖越长，指望模型自己记住三个月前说过的话。窗口能装下不等于记得住，这两者是完全不同的工程问题。\n把低质量材料越堆越多。重复的、过期的、彼此矛盾的材料堆得越多，模型越容易给出一个看起来面面俱到、实际上是和稀泥的答案。长上下文不会替你清洗数据，材料的质量问题，不会因为窗口够大就自动消失。\n简单任务硬上长窗口。分类、改写、短摘要、单文档问答、结构化抽取，这些任务本来就不需要模型读很多，短上下文加检索通常更便宜、更快、也更容易复查。\n五、怎么判断自己该不该为长上下文买单 先窄化，再长上下文推理 可以用四个问题来排查：\n关键证据是不是可能分散在材料的很多个位置？ 答案是不是必须能引用原文、保留来源出处？ 这批材料会不会被反复使用，而不是问完就扔？ 错一次的代价高不高，值不值得多花钱换一次更稳的判断？ 四条里只中一条，先别急着上1M；中了两三条，可以考虑；全中了，长上下文才是一笔正经投入。\n落地的时候，更稳的流程是：先用检索或规则把材料粗筛一遍，收窄到候选片段，再把这些候选片段放进长上下文让模型做深度推理，输出时要求模型标注引用的具体位置，关键任务再做一轮反查校验，把结论倒回原文核对一遍。这不是把检索和长上下文硬凑在一起，有专门的对比研究发现，资源足够时长上下文模型整体表现更强，但检索式方案的成本优势明显，而混合方案能在接近纯长上下文效果的同时把计算成本压下来。放到实际工程里，就是别让模型一上来就读全量材料，也别指望检索一步到位。先窄化，再推理，最后反查，这条链路更像人做严肃审阅时的工作方式。\n长上下文不是越贵越好，也不是越长越聪明。它值不值，取决于你有没有把它用在真正需要全局材料的任务上。\n如果只是懒得筛材料，1M上下文只会让你更快地把钱花出去；如果任务确实需要跨文件、跨时间线、跨证据链地判断，它才真正开始值这份钱。\n窗口大小是能力上限，不是使用说明书。\n资料来源\nNoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv 2502.05167）：arxiv.org/abs/2502.05167 NoLiMa公开结果表，用于核对GPT-4.1、GPT-4o等模型数字：github.com/adobe-research/NoLiMa RULER: What\u0026rsquo;s the Real Context Size of Your Long-Context Language Models？（arXiv 2404.06654）：arxiv.org/abs/2404.06654 Retrieval-Augmented Code Generation综述，代码仓库规模与RAG/长上下文选择的发现（arXiv 2510.04905）：arxiv.org/pdf/2510.04905 Retrieval Augmented Generation or Long-Context LLMs？ 混合方案SELF-ROUTE研究（arXiv 2407.16833）：arxiv.org/abs/2407.16833 OpenAI GPT-4.1官方定价与参数页：developers.openai.com/api/docs/models/gpt-4.1 ","permalink":"https://blog.onecai.site/2026/08/05/066-is-long-context-worth-the-price/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文接着「术语解构」系列往下写。前两篇《上下文窗口：标称1M的token，为什么32K就开始变笨》和《KV Cache：每读1个token，就要交一笔“显存税”》，一篇讲的是“标称窗口和有效窗口之间隔着什么”，一篇讲的是“这份窗口最后要占多少显存”。这两个问题都不是这篇要重新论证的，这一篇只问一件事：\u003cstrong\u003e长上下文值不值得为它多付这份钱。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e我们第一次用上1M上下文，大概率都会干一件事：把PDF、聊天记录、代码仓库、会议纪要一股脑塞进去，然后问模型“帮我总结一下”。\u003c/p\u003e\n\u003cp\u003e这件事很爽，账单也很诚实。问题是模型真的把这1M token都用上了吗？\u003c/p\u003e\n\u003cp\u003e这个问题的答案大概率是：\u003cstrong\u003e长上下文有价值，但它不是智力外挂。它更像一张很大的工作台，能放更多材料，不代表模型会按你的重点全部读完，也不代表中间那张关键的纸不会被忽略\u003c/strong\u003e。贵不贵，从来不是问题，更重要的是贵得值不值。\u003c/p\u003e\n\u003ch2 id=\"一1m上下文最容易出现的三个错觉\"\u003e一、1M上下文最容易出现的三个错觉\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e第一个错觉：能塞进去，就等于能稳定用出来\u003c/strong\u003e。1M token解决的是输入上限，不是注意力分配。它允许你把更多材料交给模型，但模型在这些材料里怎么找、怎么权衡、会不会漏掉中间某个关键证据，是另一件事。规格表上的上下文长度，更像仓库面积；真正决定任务结果的，是模型能不能在这片仓库里找到正确的那只箱子。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二个错觉：一次性塞完，就更省钱\u003c/strong\u003e。长上下文的成本不只是在模型变贵时才出现，输入本身就在计费。以发稿前重新核对的OpenAI官方GPT-4.1价格为例：约1M上下文，输入2美元/百万token，缓存输入0.5美元/百万token，输出8美元/百万token。这几个数字保质期短，Token那篇也提过，大概一个季度就可能变。单看一次调用不吓人，30万token材料，未命中缓存的输入成本大约是0.6美元。但如果每天调用20次、每次都带30万token材料，光输入就是600万token，一天12美元，一个月大约360美元。假设每次还输出2000token，一个月输出再加大约9.6美元。这还只是每天20次的轻量用法。Agent场景里，模型可能每一轮都带着几十万token在跑，规划、检索、改写、校验、重试，十几轮之后，这笔钱会变得很具体。\u003cstrong\u003e长上下文不是不能用，而是别把它当免费内存用。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三个错觉：needle测试好看，就等于复杂任务可靠\u003c/strong\u003e。找出资料中的一句暗号，和从几十份合同里判断责任边界，不是一回事。前者像在大海里找一个发光浮标，后者要把定义、例外、补充协议、历史版本、责任条款串起来看。很多模型在简单needle测试里已经很漂亮，但一换成多针、多跳、聚合、冲突判断，成绩就没那么稳了。\u003c/p\u003e\n\u003ch2 id=\"二真正的问题有效利用率不是能不能装下\"\u003e二、真正的问题：有效利用率，不是能不能装下\u003c/h2\u003e\n\u003cp\u003e上一篇提到过NoLiMa和RULER这两个基准测试的名字。NoLiMa做了一件很朴素的事：把问题和答案之间的字面重合去掉，只留下需要推理才能建立的关联，比如问题问的是“和某座歌剧院有关的人是谁”，而材料里只写了这个人住在歌剧院所在的城市，没有直接提到歌剧院三个字。这种设计逼着模型真正理解，而不是靠关键词匹配蒙对。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"is-long-context-worth-the-price-1.avif\"\n          alt=\"标称上下文 vs 有效利用率\"/\u003e \u003cfigcaption\u003e\n             标称上下文 vs 有效利用率\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e结果是，论文测试的一批声称支持128K以上上下文的模型里，短文本（1K以内）表现都不错，但随着上下文变长，表现明显下滑。在常被引用的原始结果里，GPT-4o从短文本几乎满分的99.3%，掉到32K时的69.7%。NoLiMa后续公开结果又加入了GPT-4.1等模型，个别模型的排名和数字会变化，但主线没有变：长窗口标称长度越大，越需要单独评估有效利用率，不能只看规格表。\u003c/p\u003e\n\u003cp\u003eRULER则是从另一个角度补刀：不满足于“找一根针”，而是让模型同时找多根针、做多跳推理、再把结果聚合起来。它的评测里能看到，模型在简单needle测试里可能接近满分，但换成更接近真实任务的组合检索后，表现会随着上下文变长出现明显下滑。\u003c/p\u003e\n\u003cp\u003e这两组测试合起来看，32K还不到1M窗口的十分之一，但在更难的评测里，很多模型已经明显掉分。窗口越做越大，只是把能装下的上限往后推，并没有同步把能认真读完的能力往后推。所以长上下文真正要问的不是“最多能塞多少”，而是\u003cstrong\u003e关键证据放在材料的第70%位置时，模型还能不能稳定找到它、用对它，并且解释清楚它为什么重要。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"三什么任务是真需求\"\u003e三、什么任务是真需求\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e材料天然长、需要跨位置对照\u003c/strong\u003e。合同审查是最典型的例子，A处定义了一个概念，B处写了例外情形，C处的补充协议又悄悄改过一次，最后还要结合邮件往来才能判断责任边界。这几处往往不在同一页，却要放在一起看。招股书比对、长会议纪要复盘、论文综述，这些任务都是同一类问题。重点不是总结某一份文档，而是把散落在全篇不同位置的线索串起来。\u003c/p\u003e\n\u003cp\u003e代码仓库可以归进这一类，但有一个边界值得记住：长上下文模型在小型、结构良好的代码仓库上，表现可以匹配甚至超过检索式方案；但当仓库规模和复杂度增加，检索式方案的优势就会逐渐显现出来。换句话说，几万行、结构清楚、依赖关系不复杂，长上下文可能很舒服；一旦变成多语言、多服务、历史债务很重的大仓库，直接一股脑全塞往往不如先把相关文件和调用链找出来。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e不能提前知道哪段有用\u003c/strong\u003e。事故调查、内部审计、客服历史追踪，这类任务都属于，你没法提前判断关键线索藏在哪一轮对话、哪一条日志、哪一次提交里。这种情况下，先做检索反而可能把真正相关的那段筛掉，给模型更完整的现场，是更保险的做法。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e材料结构稳定、可以缓存复用\u003c/strong\u003e。固定的代码库、固定的知识库、固定的产品文档，长上下文配合前缀缓存，天生适合“同一批材料反复问不同问题”。这时候的成本结构，和每次现查现搜完全不一样。Prompt Caching那篇里算过一个例子：固定的角色设定和规则放前面、每天变化的数据放后面，缓存命中率能跑到97%以上，账单直接压缩十几倍。这种场景下，长上下文的贵，其实被摊得很薄。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e多模态长材料\u003c/strong\u003e。长视频、长音频、扫描件这类材料，切片处理最容易丢掉时间线和跨片段的关联。比如一场两个小时的会议，前40分钟有人提出了一个约束条件，后面又绕了几轮，最后才落到行动项。如果只按时间切成小段分别摘要，模型很容易把前后这层因果关系拆散。长上下文在这里的价值，是让材料按原本的时间线和结构留在一起。厂商演示里经常会展示长视频、长音频里的针检索能力，但这块公开测试没有前面几类那么扎实，先按“值得一试、但别只信演示”的态度看待。\u003c/p\u003e\n\u003ch2 id=\"四什么是伪需求\"\u003e四、什么是伪需求\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"is-long-context-worth-the-price-2.avif\"\n          alt=\"长上下文：真需求 vs 伪需求\"/\u003e \u003cfigcaption\u003e\n             长上下文：真需求 vs 伪需求\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e把不会整理材料，包装成需要1M上下文\u003c/strong\u003e。问题其实只需要三段证据，却把三百页全塞进去问模型“你自己找”。模型可能找对，也可能找错，而且找错了你更难复查，因为你自己都没读过这三百页，拿什么去核对它的答案。这和KV Cache那篇讲过的道理是一回事：\u003cstrong\u003e新草稿要记状态，不要抄流水账\u003c/strong\u003e。懒得筛选材料，只是把筛选的责任和风险，一起转嫁给了模型。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e把长期记忆误认为上下文窗口\u003c/strong\u003e。上下文是这一次请求模型能看到的材料，不是可靠的记忆库。真正靠谱的长期记忆，应该有索引、有来源、有更新时间、能处理信息冲突，而不是靠一个聊天窗口越拖越长，指望模型自己记住三个月前说过的话。窗口能装下不等于记得住，这两者是完全不同的工程问题。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e把低质量材料越堆越多\u003c/strong\u003e。重复的、过期的、彼此矛盾的材料堆得越多，模型越容易给出一个看起来面面俱到、实际上是和稀泥的答案。长上下文不会替你清洗数据，材料的质量问题，不会因为窗口够大就自动消失。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e简单任务硬上长窗口\u003c/strong\u003e。分类、改写、短摘要、单文档问答、结构化抽取，这些任务本来就不需要模型读很多，短上下文加检索通常更便宜、更快、也更容易复查。\u003c/p\u003e\n\u003ch2 id=\"五怎么判断自己该不该为长上下文买单\"\u003e五、怎么判断自己该不该为长上下文买单\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"is-long-context-worth-the-price-3.avif\"\n          alt=\"先窄化，再长上下文推理\"/\u003e \u003cfigcaption\u003e\n             先窄化，再长上下文推理\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e可以用四个问题来排查：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e关键证据是不是可能分散在材料的很多个位置？\u003c/li\u003e\n\u003cli\u003e答案是不是必须能引用原文、保留来源出处？\u003c/li\u003e\n\u003cli\u003e这批材料会不会被反复使用，而不是问完就扔？\u003c/li\u003e\n\u003cli\u003e错一次的代价高不高，值不值得多花钱换一次更稳的判断？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e四条里\u003cstrong\u003e只中一条\u003c/strong\u003e，先别急着上1M；\u003cstrong\u003e中了两三条\u003c/strong\u003e，可以考虑；\u003cstrong\u003e全中\u003c/strong\u003e了，长上下文才是一笔正经投入。\u003c/p\u003e\n\u003cp\u003e落地的时候，更稳的流程是：\u003cstrong\u003e先用检索或规则把材料粗筛一遍，收窄到候选片段，再把这些候选片段放进长上下文让模型做深度推理，输出时要求模型标注引用的具体位置，关键任务再做一轮反查校验，把结论倒回原文核对一遍\u003c/strong\u003e。这不是把检索和长上下文硬凑在一起，有专门的对比研究发现，资源足够时长上下文模型整体表现更强，但检索式方案的成本优势明显，而混合方案能在接近纯长上下文效果的同时把计算成本压下来。放到实际工程里，就是别让模型一上来就读全量材料，也别指望检索一步到位。先窄化，再推理，最后反查，这条链路更像人做严肃审阅时的工作方式。\u003c/p\u003e\n\u003cp\u003e长上下文不是越贵越好，也不是越长越聪明。它值不值，取决于你有没有把它用在真正需要全局材料的任务上。\u003c/p\u003e\n\u003cp\u003e如果只是懒得筛材料，1M上下文只会让你更快地把钱花出去；如果任务确实需要跨文件、跨时间线、跨证据链地判断，它才真正开始值这份钱。\u003c/p\u003e\n\u003cp\u003e窗口大小是能力上限，不是使用说明书。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003e资料来源\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv 2502.05167）：\u003ca href=\"https://arxiv.org/abs/2502.05167\"\u003earxiv.org/abs/2502.05167\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eNoLiMa公开结果表，用于核对GPT-4.1、GPT-4o等模型数字：\u003ca href=\"https://github.com/adobe-research/NoLiMa\"\u003egithub.com/adobe-research/NoLiMa\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eRULER: What\u0026rsquo;s the Real Context Size of Your Long-Context Language Models？（arXiv 2404.06654）：\u003ca href=\"https://arxiv.org/abs/2404.06654\"\u003earxiv.org/abs/2404.06654\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eRetrieval-Augmented Code Generation综述，代码仓库规模与RAG/长上下文选择的发现（arXiv 2510.04905）：\u003ca href=\"https://arxiv.org/pdf/2510.04905\"\u003earxiv.org/pdf/2510.04905\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eRetrieval Augmented Generation or Long-Context LLMs？ 混合方案SELF-ROUTE研究（arXiv 2407.16833）：\u003ca href=\"https://arxiv.org/abs/2407.16833\"\u003earxiv.org/abs/2407.16833\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eOpenAI GPT-4.1官方定价与参数页：\u003ca href=\"https://developers.openai.com/api/docs/models/gpt-4.1\"\u003edevelopers.openai.com/api/docs/models/gpt-4.1\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"长上下文是不是越贵越好？"},{"content":" 参数名称、默认值截至2026年7月核对。思考控制机制这半年迭代较快，如果你按本文操作，建议先去对应模型的官方文档确认一遍当前版本的参数是否还是这个名字。\n上一篇讲token价格梯队时，提过一句“看不见的思考token也在计费”。\n一、一个真实的踩坑现场 2026年4月，OpenAI开发者社区里有人发帖求助。发帖者在调用GPT-5.4时，传了reasoning_effort: \u0026quot;none\u0026quot;，想关掉思考模式——单独测试时这个参数确实有效，思考token归零。但当他在同一个请求里加上max_completion_tokens这个参数后，reasoning_effort的设置被API整体忽略，模型照常进入思考模式，把整段预算全部花在了看不见的推理过程上，最后返回一个空字符串，finish_reason标记为length`。\n翻译一下这意味着什么：你以为自己关掉了思考模式，账单却按开着算；你以为请求会给你一个答案，实际上连答案都没能生成，钱已经被思考过程花光了。\n这是社区里真实的bug反馈帖[1]。之所以拿它开头，是因为它把这篇文章要讲的核心问题，用一次意外浓缩到了极致：思考token的计费，和你看到的可见文本，从来不是一回事。\n二、先把机制讲清楚：你看不见，不代表没生成 看不见，不代表没生成 推理模型（OpenAI的o系列和开启reasoning_effort的GPT-5.x、Google Gemini的Thinking系列、Claude开启thinking参数后的模型）在给出你看到的那句回答之前，会先生成一段内部的“草稿”——业内把这部分叫reasoning tokens或thinking tokens。\n关键在于三点：\n第一，这段草稿本身也是token，一个一个生成出来的。 它不是模型“想了一下”这么抽象的说法，而是实打实占用计算、实打实计入用量的一段文本，只是大多数平台默认不把它完整展示给你。\n第二，计费按的是完整生成量，不是你看到的展示量。 Claude的官方文档写得很直白：即使思考内容被折叠、不返回给用户，依然要按内部实际生成的thinking token数计费——你在响应里看到的字数，和账单上算的输出token数，本来就不是同一个数字[2]。\n第三，思考token和最终答案，被算进同一个“输出token池”，按输出价计费。 这意味着模型越贵，“多想一会儿”的每一秒都是按这个模型最高的单价计时——这也是“思考税”这个说法的字面来源。\n举个例子方便理解（注意，这是一个用来说明比例关系的示意性推算，不是某次真实调用的实测数据）：假设一次问答，你看到的可见回复只有300个字左右，但模型在给出这句话之前，内部生成了3000个思考token，那么这次调用真正被计费的输出量，大概是3300个token左右——你以为自己在为300字付钱，实际上在为3300字付钱，多出来的十倍，你一个字都没看见。\n三、四种翻车方式：钱是怎么被“偷偷”吃掉的 思考税的四种翻车方式 思考税不是一种统一的坑，至少有四种不同的发生机制，前三种都能找到具体的真实案例。\n机制一：预算耗尽型——思考吃光配额，答案直接消失 有开发者用GPT-5-mini搭配web_search_preview工具，把max_output_tokens设成了8000，结果依然频繁收到“不完整”的响应。原因是模型把大部分预算花在了思考和搜索调用这两件事上，留给最终JSON输出的token所剩无几[3]。\n这暴露的问题很实际：工具调用和思考模式叠加时，预算消耗的速度比单独用思考模式快得多，如果还按“平时够用”的老经验设预算，很容易在这种组合场景里翻车。\n机制二：开关失灵型——你以为关了，其实没关 Qwen3.6-35B-A3B有开发者在Hugging Face反馈，设置thinking_budget试图限制思考长度，但实际不起作用[4]；另一份GitHub issue里，有人本地部署Qwen3-14B，同样遇到无法关闭思考模式的问题[5]。\n这里有个更容易被忽略的细节：Qwen的开源版模型，enable_thinking参数默认是True；只有部分商业版模型默认是False。也就是说，自己部署开源模型时，如果没有显式传参把思考模式关掉，它很可能一直是开着的——这和你调用商业API时的默认体验，可能完全相反。\n机制三：习惯性无感型——两周后才发现的账本 有人在一篇复盘文章里提到，自己跑了两周的代码审查流水线，直到某天去查用量明细里的output_tokens_details.reasoning_tokens字段，才发现每次审查平均生成了约8000个推理token，只为了产出一段大约300字的可见结果[6]。\n这类翻车最普遍，也最值得普通用户警惕——不是被平台坑了，是从来没有专门去看过那个隐藏字段，任务一直在跑，账单一直在涨，直到某次心血来潮翻明细才发现。\n机制四：累加型——Agent的每一步都在重新“动脑子” 前三种机制，都是单次调用里的问题。Agent场景不一样：读一份文件要判断一下，调一次工具要判断一下，看到工具返回结果要再判断一下，写完代码要判断能不能跑，测试失败还要判断怎么改。\n如果每一步都开着思考模式，隐藏token就在跟着每一次决策不断累加。单次调用看着不大，循环几十次之后，滚成的费用就很可观了——Agent的成本，不只来自上下文变长，还来自每一轮决策都在重新计费的“动脑子”。\n四、什么样的问题特别容易变贵 拆开看，容易在思考token上多花钱的，通常是这四类：\n判断题伪装成简单题。 “这是不是高风险客户”“这段代码有没有安全漏洞”，问题看着是个是非题，但判断过程可能要在内部比对好几条规则、排除好几种歧义，答案短，思考不短。\n开放任务。 “帮我优化这篇文章”“重构一下这个模块”，模型不知道优化到什么程度算够，容易在内部反复权衡，多想一轮又一轮。\n长上下文任务。 合同、代码库、财报，输入本身就长，模型除了要读完，还要在里面定位关键线索，这个过程本身会拉长思考。\n带工具的任务。 每次工具结果返回，模型都要重新判断下一步该怎么走，思考token跟着工具调用次数一起叠加。\n落到判断上：这些任务不是不能用推理模型，而是不能默认开最高档去处理。\n不同模型，同一个问题：思考上限要显式设置 五、六家怎么设上限：一张对比表 各家的参数名不一样，但机制是相通的：都有一个字段控制思考深度，都建议按任务复杂度显式设置，而不是用默认值糊弄过去。\n厂商/生态 控制参数 默认行为 能否完全关闭思考 OpenAI（GPT-5.x / o系列） reasoning.effort（none / low / medium / high / xhigh，具体档位视模型而定） GPT-5.1起默认none，需显式开启 部分模型可以，但max_completion_tokens同传时曾出现开关被忽略的bug Anthropic（Claude） thinking.budget_tokens（旧）→ 新模型迁移为自适应effort 默认关闭，需显式启用 可以，不传thinking参数即可 Google Gemini 2.5系列用thinkingBudget（0关闭，-1动态）；3/3.1系列改用thinkingLevel（low/medium/high） 不显式指定thinkingLevel时，Gemini 3/3.1 Pro默认走high，也就是最贵的一档[7] 2.5系列可以关闭；3系列不可完全关闭，最低只到low 阿里Qwen（DashScope/开源） enable_thinking + thinking_budget 开源版默认True，部分商业模型默认False 可以，但需按版本核实默认值 智谱GLM thinking: {type: \u0026quot;enabled\u0026quot;}（原生API）/ enable_thinking（兼容接口） 需显式启用 可以；官方文档明确写着“思考模式下，思维链按照输出Token计费”[8] DeepSeek 随模型别名路由（如推理专用别名） 思考模式绑定模型别名，非逐次开关 需换用非推理模型别名 这张表里最值得单独说一句的，是Gemini这一条。Gemini 3.1 Pro相比上一代，把思考档位从两档（low/high）扩成了三档（low/medium/high），控制粒度确实变细了；但如果你没有显式传thinking_level，API默认会走high，也就是最贵的那一档。这意味着很多什么参数都没改、只是升级了模型版本的老代码，可能在悄悄地多花钱——这条比“能不能关闭”更值得写进你的检查清单。\n另外，这张表里的具体数值（比如Gemini各代际thinking_budget的取值上限）没有写死，因为不同版本文档给出的数字并不完全一致，而且还在随版本更新变化。设置之前，建议直接去查当前调用模型对应的官方文档，不要照抄网上任何一篇文章（包括这篇）里的具体数字。\n六、怎么设置上限：实操清单 分厂商：\nOpenAI：简单任务用低档effort或直接设为none；max_output_tokens要留出思考+答案的双重空间，经验值是可见输出预期长度的3到4倍起；每次调用后检查output_tokens_details.reasoning_tokens，别只看最终文本长度。 Claude：用budget_tokens（或迁移后的effort）控制思考深度；不要以为思考内容被折叠不显示就不计费，usage里的thinking_tokens才是真实账本。 Gemini：能不思考的任务，2.5系列把thinkingBudget设成0，3/3.1系列显式传thinking_level: \u0026quot;low\u0026quot;；不管要不要思考，都建议显式传这个参数，不传就是默认最贵档。 自部署开源模型（Qwen等）：先查默认值，不要假设“没设参数=没开思考”。 通用做法：\n检查finish_reason/stop_reason：如果返回length或incomplete，但可见文本是空的，说明预算全喂给了思考过程——不是任务复杂，是设置错了。 给不同任务分模型分级：分类、抽取、改格式这类，用便宜模型或直接关闭思考；复杂推理、代码诊断、合同财务分析这类，再上推理模型。 给Agent设最大轮数、最大工具调用次数、总token预算上限，防止累加型翻车。 一条可以直接抄的硬规则：如果某个接口的隐藏推理token连续几天超过可见输出token的5倍，就该复盘一下任务拆分、模型选择和提示词边界了。 七、一个可以直接落地的三档护栏 给推理模型设三档成本护栏 把AI调用按复杂度分成三档，比逐次判断更省心：\n轻任务：分类、提取字段、改写标题、命中规则判断——默认不开深度思考，限制输出长度。\n中任务：摘要、简单代码解释、工单判断——用低到中等思考强度，记录reasoning tokens。\n重任务：代码修复、复杂合同审查、多步骤Agent——允许思考，但必须设总预算、轮数上限、失败退出条件。\n写在最后 回到开头那个GPT-5.4的案例：那位开发者不是被平台坑了，是没料到reasoning_effort和max_completion_tokens同传时会打架。多数思考税的翻车，本质都是这样——不是被多收了钱，是自己没设上限，或者设错了地方。\n推理模型确实更擅长处理复杂问题，但它不是免费的慢思考。以后看AI成本，不能只问“这个模型每百万token多少钱”，还要多问一句：这个任务，会不会让模型在背后偷偷想很久。\n你在用推理模型时踩过哪种坑？评论区聊聊。\n资料边界说明 各厂商参数名称、默认值截至2026年7月核对，思考控制机制迭代较快（尤其Claude的budget_tokens向自适应effort迁移、Gemini 3系列的thinkingLevel），发布前建议再核对一次官方文档最新版本。 文中四个案例，均来自公开开发者论坛或社区反馈帖，属于个案，不代表所有用户在所有场景下都会遇到，也不代表官方承认这是系统性问题。 第二节里“300字可见/3000思考/3300计费”这组数字是用来说明比例关系的示意性推算，不是某次真实调用的实测数据。 参考资料 Gpt-5.4 ignores reasoning_effort=“none” when max_completion_tokens is used - OpenAI Developer Community Building with extended thinking - Claude Docs GPT-5 mini returns incomplete response when using web_search_preview due to max_output_tokens limit - OpenAI Developer Community Qwen/Qwen3.6-35B-A3B · Regarding Qwen 3.6 35B-A3B reasoning/thinking mode - Hugging Face 本地部署Qwen3-14B无法关闭思考模式/thinking_budget无效 · Issue #1622 · QwenLM/Qwen3 Thinking Tokens Explained: What Reasoning Models Cost You Gemini 3 / 3.1 Pro thinking_level相关官方与社区文档，包括Google Cloud Vertex AI Gemini Thinking文档及多个第三方实测记录 GLM系列混合推理模型调用 - 阿里云百炼帮助中心 ","permalink":"https://blog.onecai.site/2026/08/04/065-reasoning-model-thinking-tax/","summary":"\u003cblockquote\u003e\n\u003cp\u003e参数名称、默认值截至2026年7月核对。思考控制机制这半年迭代较快，如果你按本文操作，建议先去对应模型的官方文档确认一遍当前版本的参数是否还是这个名字。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e上一篇讲token价格梯队时，提过一句“看不见的思考token也在计费”。\u003c/p\u003e\n\u003ch2 id=\"一一个真实的踩坑现场\"\u003e一、一个真实的踩坑现场\u003c/h2\u003e\n\u003cp\u003e2026年4月，OpenAI开发者社区里有人发帖求助。发帖者在调用GPT-5.4时，传了\u003ccode\u003ereasoning_effort: \u0026quot;none\u0026quot;\u003c/code\u003e，想关掉思考模式——单独测试时这个参数确实有效，思考token归零。但当他在同一个请求里加上\u003ccode\u003emax_completion_tokens\u003c/code\u003e这个参数后，reasoning_effort\u003ccode\u003e的设置被API整体忽略，模型照常进入思考模式，把整段预算全部花在了看不见的推理过程上，最后返回一个空字符串，\u003c/code\u003efinish_reason\u003ccode\u003e标记为\u003c/code\u003elength`。\u003c/p\u003e\n\u003cp\u003e翻译一下这意味着什么：\u003cstrong\u003e你以为自己关掉了思考模式，账单却按开着算；你以为请求会给你一个答案，实际上连答案都没能生成，钱已经被思考过程花光了。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这是社区里真实的bug反馈帖\u003csup\u003e[1]\u003c/sup\u003e。之所以拿它开头，是因为它把这篇文章要讲的核心问题，用一次意外浓缩到了极致：\u003cstrong\u003e思考token的计费，和你看到的可见文本，从来不是一回事。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二先把机制讲清楚你看不见不代表没生成\"\u003e二、先把机制讲清楚：你看不见，不代表没生成\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"reasoning-model-thinking-tax-1.avif\"\n          alt=\"看不见，不代表没生成\"/\u003e \u003cfigcaption\u003e\n             看不见，不代表没生成\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e推理模型（OpenAI的o系列和开启\u003ccode\u003ereasoning_effort\u003c/code\u003e的GPT-5.x、Google Gemini的Thinking系列、Claude开启\u003ccode\u003ethinking\u003c/code\u003e参数后的模型）在给出你看到的那句回答之前，会先生成一段内部的“草稿”——业内把这部分叫reasoning tokens或thinking tokens。\u003c/p\u003e\n\u003cp\u003e关键在于三点：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一，这段草稿本身也是token，一个一个生成出来的。\u003c/strong\u003e 它不是模型“想了一下”这么抽象的说法，而是实打实占用计算、实打实计入用量的一段文本，只是大多数平台默认不把它完整展示给你。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二，计费按的是完整生成量，不是你看到的展示量。\u003c/strong\u003e Claude的官方文档写得很直白：即使思考内容被折叠、不返回给用户，依然要按内部实际生成的thinking token数计费——你在响应里看到的字数，和账单上算的输出token数，本来就不是同一个数字\u003csup\u003e[2]\u003c/sup\u003e。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三，思考token和最终答案，被算进同一个“输出token池”，按输出价计费。\u003c/strong\u003e 这意味着模型越贵，“多想一会儿”的每一秒都是按这个模型最高的单价计时——这也是“思考税”这个说法的字面来源。\u003c/p\u003e\n\u003cp\u003e举个例子方便理解（\u003cstrong\u003e注意，这是一个用来说明比例关系的示意性推算，不是某次真实调用的实测数据\u003c/strong\u003e）：假设一次问答，你看到的可见回复只有300个字左右，但模型在给出这句话之前，内部生成了3000个思考token，那么这次调用真正被计费的输出量，大概是3300个token左右——你以为自己在为300字付钱，实际上在为3300字付钱，多出来的十倍，你一个字都没看见。\u003c/p\u003e\n\u003ch2 id=\"三四种翻车方式钱是怎么被偷偷吃掉的\"\u003e三、四种翻车方式：钱是怎么被“偷偷”吃掉的\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"reasoning-model-thinking-tax-2.avif\"\n          alt=\"思考税的四种翻车方式\"/\u003e \u003cfigcaption\u003e\n             思考税的四种翻车方式\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e思考税不是一种统一的坑，至少有四种不同的发生机制，前三种都能找到具体的真实案例。\u003c/p\u003e\n\u003ch3 id=\"机制一预算耗尽型思考吃光配额答案直接消失\"\u003e机制一：预算耗尽型——思考吃光配额，答案直接消失\u003c/h3\u003e\n\u003cp\u003e有开发者用GPT-5-mini搭配\u003ccode\u003eweb_search_preview\u003c/code\u003e工具，把\u003ccode\u003emax_output_tokens\u003c/code\u003e设成了8000，结果依然频繁收到“不完整”的响应。原因是模型把大部分预算花在了思考和搜索调用这两件事上，留给最终JSON输出的token所剩无几\u003csup\u003e[3]\u003c/sup\u003e。\u003c/p\u003e\n\u003cp\u003e这暴露的问题很实际：\u003cstrong\u003e工具调用和思考模式叠加时，预算消耗的速度比单独用思考模式快得多\u003c/strong\u003e，如果还按“平时够用”的老经验设预算，很容易在这种组合场景里翻车。\u003c/p\u003e\n\u003ch3 id=\"机制二开关失灵型你以为关了其实没关\"\u003e机制二：开关失灵型——你以为关了，其实没关\u003c/h3\u003e\n\u003cp\u003eQwen3.6-35B-A3B有开发者在Hugging Face反馈，设置\u003ccode\u003ethinking_budget\u003c/code\u003e试图限制思考长度，但实际不起作用\u003csup\u003e[4]\u003c/sup\u003e；另一份GitHub issue里，有人本地部署Qwen3-14B，同样遇到无法关闭思考模式的问题\u003csup\u003e[5]\u003c/sup\u003e。\u003c/p\u003e\n\u003cp\u003e这里有个更容易被忽略的细节：Qwen的开源版模型，\u003ccode\u003eenable_thinking\u003c/code\u003e参数默认是\u003ccode\u003eTrue\u003c/code\u003e；只有部分商业版模型默认是\u003ccode\u003eFalse\u003c/code\u003e。也就是说，\u003cstrong\u003e自己部署开源模型时，如果没有显式传参把思考模式关掉，它很可能一直是开着的\u003c/strong\u003e——这和你调用商业API时的默认体验，可能完全相反。\u003c/p\u003e\n\u003ch3 id=\"机制三习惯性无感型两周后才发现的账本\"\u003e机制三：习惯性无感型——两周后才发现的账本\u003c/h3\u003e\n\u003cp\u003e有人在一篇复盘文章里提到，自己跑了两周的代码审查流水线，直到某天去查用量明细里的\u003ccode\u003eoutput_tokens_details.reasoning_tokens\u003c/code\u003e字段，才发现每次审查平均生成了约8000个推理token，只为了产出一段大约300字的可见结果\u003csup\u003e[6]\u003c/sup\u003e。\u003c/p\u003e\n\u003cp\u003e这类翻车最普遍，也最值得普通用户警惕——不是被平台坑了，是\u003cstrong\u003e从来没有专门去看过那个隐藏字段\u003c/strong\u003e，任务一直在跑，账单一直在涨，直到某次心血来潮翻明细才发现。\u003c/p\u003e\n\u003ch3 id=\"机制四累加型agent的每一步都在重新动脑子\"\u003e机制四：累加型——Agent的每一步都在重新“动脑子”\u003c/h3\u003e\n\u003cp\u003e前三种机制，都是单次调用里的问题。Agent场景不一样：读一份文件要判断一下，调一次工具要判断一下，看到工具返回结果要再判断一下，写完代码要判断能不能跑，测试失败还要判断怎么改。\u003c/p\u003e\n\u003cp\u003e如果每一步都开着思考模式，隐藏token就在跟着每一次决策不断累加。单次调用看着不大，循环几十次之后，滚成的费用就很可观了——\u003cstrong\u003eAgent的成本，不只来自上下文变长，还来自每一轮决策都在重新计费的“动脑子”。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"四什么样的问题特别容易变贵\"\u003e四、什么样的问题特别容易变贵\u003c/h2\u003e\n\u003cp\u003e拆开看，容易在思考token上多花钱的，通常是这四类：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e判断题伪装成简单题。\u003c/strong\u003e “这是不是高风险客户”“这段代码有没有安全漏洞”，问题看着是个是非题，但判断过程可能要在内部比对好几条规则、排除好几种歧义，答案短，思考不短。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e开放任务。\u003c/strong\u003e “帮我优化这篇文章”“重构一下这个模块”，模型不知道优化到什么程度算够，容易在内部反复权衡，多想一轮又一轮。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e长上下文任务。\u003c/strong\u003e 合同、代码库、财报，输入本身就长，模型除了要读完，还要在里面定位关键线索，这个过程本身会拉长思考。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e带工具的任务。\u003c/strong\u003e 每次工具结果返回，模型都要重新判断下一步该怎么走，思考token跟着工具调用次数一起叠加。\u003c/p\u003e\n\u003cp\u003e落到判断上：这些任务不是不能用推理模型，而是\u003cstrong\u003e不能默认开最高档去处理\u003c/strong\u003e。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"reasoning-model-thinking-tax-3.avif\"\n          alt=\"不同模型，同一个问题：思考上限要显式设置\"/\u003e \u003cfigcaption\u003e\n             不同模型，同一个问题：思考上限要显式设置\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"五六家怎么设上限一张对比表\"\u003e五、六家怎么设上限：一张对比表\u003c/h2\u003e\n\u003cp\u003e各家的参数名不一样，但机制是相通的：都有一个字段控制思考深度，都建议按任务复杂度显式设置，而不是用默认值糊弄过去。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e厂商/生态\u003c/th\u003e\n          \u003cth\u003e控制参数\u003c/th\u003e\n          \u003cth\u003e默认行为\u003c/th\u003e\n          \u003cth\u003e能否完全关闭思考\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eOpenAI（GPT-5.x / o系列）\u003c/td\u003e\n          \u003ctd\u003e\u003ccode\u003ereasoning.effort\u003c/code\u003e（none / low / medium / high / xhigh，具体档位视模型而定）\u003c/td\u003e\n          \u003ctd\u003eGPT-5.1起默认none，需显式开启\u003c/td\u003e\n          \u003ctd\u003e部分模型可以，但\u003ccode\u003emax_completion_tokens\u003c/code\u003e同传时曾出现开关被忽略的bug\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eAnthropic（Claude）\u003c/td\u003e\n          \u003ctd\u003e\u003ccode\u003ethinking.budget_tokens\u003c/code\u003e（旧）→ 新模型迁移为自适应\u003ccode\u003eeffort\u003c/code\u003e\u003c/td\u003e\n          \u003ctd\u003e默认关闭，需显式启用\u003c/td\u003e\n          \u003ctd\u003e可以，不传\u003ccode\u003ethinking\u003c/code\u003e参数即可\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGoogle Gemini\u003c/td\u003e\n          \u003ctd\u003e2.5系列用\u003ccode\u003ethinkingBudget\u003c/code\u003e（0关闭，-1动态）；3/3.1系列改用\u003ccode\u003ethinkingLevel\u003c/code\u003e（low/medium/high）\u003c/td\u003e\n          \u003ctd\u003e不显式指定\u003ccode\u003ethinkingLevel\u003c/code\u003e时，Gemini 3/3.1 Pro\u003cstrong\u003e默认走high，也就是最贵的一档\u003c/strong\u003e\u003csup\u003e[7]\u003c/sup\u003e\u003c/td\u003e\n          \u003ctd\u003e2.5系列可以关闭；3系列不可完全关闭，最低只到low\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e阿里Qwen（DashScope/开源）\u003c/td\u003e\n          \u003ctd\u003e\u003ccode\u003eenable_thinking\u003c/code\u003e + \u003ccode\u003ethinking_budget\u003c/code\u003e\u003c/td\u003e\n          \u003ctd\u003e开源版默认True，部分商业模型默认False\u003c/td\u003e\n          \u003ctd\u003e可以，但需按版本核实默认值\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e智谱GLM\u003c/td\u003e\n          \u003ctd\u003e\u003ccode\u003ethinking: {type: \u0026quot;enabled\u0026quot;}\u003c/code\u003e（原生API）/ \u003ccode\u003eenable_thinking\u003c/code\u003e（兼容接口）\u003c/td\u003e\n          \u003ctd\u003e需显式启用\u003c/td\u003e\n          \u003ctd\u003e可以；官方文档明确写着“思考模式下，思维链按照输出Token计费”\u003csup\u003e[8]\u003c/sup\u003e\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeek\u003c/td\u003e\n          \u003ctd\u003e随模型别名路由（如推理专用别名）\u003c/td\u003e\n          \u003ctd\u003e思考模式绑定模型别名，非逐次开关\u003c/td\u003e\n          \u003ctd\u003e需换用非推理模型别名\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这张表里最值得单独说一句的，是Gemini这一条。Gemini 3.1 Pro相比上一代，把思考档位从两档（low/high）扩成了三档（low/medium/high），控制粒度确实变细了；但\u003cstrong\u003e如果你没有显式传\u003ccode\u003ethinking_level\u003c/code\u003e，API默认会走high，也就是最贵的那一档\u003c/strong\u003e。这意味着很多什么参数都没改、只是升级了模型版本的老代码，可能在悄悄地多花钱——这条比“能不能关闭”更值得写进你的检查清单。\u003c/p\u003e","title":"推理模型的“思考税”：为什么有的问题AI会偷偷多算你的钱？"},{"content":" 价格数据核对时间：2026年7月下旬。文中价格以官方定价页为准，第三方转述的地方我会单独标注。\n一开始我以为这篇会写成“模型又便宜了几倍”。真把几家官方价格页翻完，结论反而没那么顺口：最强的那几档没有一路降价，有的主力模型输入价还在往上走。便宜得更明显的，是平时真正拿来写代码、跑客服、做摘要、批量处理文档的那一层。\n不是所有模型都便宜了，是能干活的中间档位在往下沉。\n过去一年，价格变化最集中的地方不在旗舰档，而在主力档、性价比档、缓存命中和批处理。也就是说，模型厂商没有简单把“最强模型”打折甩卖，而是把更便宜的入口拆得越来越细。\n一、先看两张价格表 看价格表之前先统一口径：美元/百万token，输入/输出，不混人民币，不混包月订阅。表里优先用官方API列表价；如果是第三方聚合平台或媒体口径，会在后面单独说明。选型也定一条规则：每家只放它当前最常被开发者拿来干活的那一档，不拿旗舰去对标别家的性价比档，也不拿性价比档去对标别家的旗舰档。\n表1：主力档，一年对比\n厂商 一年前（2025年7月） 现在（2026年7月） 变化 Anthropic Claude Sonnet 4，$3 / $15 Claude Sonnet 5，首发价$2 / $10（8月31日后回到$3 / $15） 优惠期名义上降了约三分之一，但新tokenizer会让同样文本切出更多token，官方口径约多30%，实际省钱幅度要打折扣 OpenAI GPT-4.1，$2 / $8 GPT-5.6 Terra，$2.5 / $15 输入涨25%，输出涨近一倍 Google Gemini 2.5 Pro，$1.25 / $10 Gemini 3.1 Pro，$2 / $12 按当前价格算，输入涨60% DeepSeek DeepSeek V3，$0.27 / $1.10 DeepSeek V4-Pro，$0.435 / $0.87 输入涨61%，输出降21%，两头打平 表2：性价比档，一年对比\n厂商 一年前 现在 变化 OpenAI GPT-4o mini，$0.15 / $0.60 同一型号仍在售，价格没动过 两年持平 Google Gemini 2.5 Flash-Lite，$0.10 / $0.40 Gemini 3.1 Flash-Lite，$0.25 / $1.50 涨150%～275% DeepSeek 一直是$0.14 / $0.28 还是$0.14 / $0.28 两年零变化 阿里 Qwen Plus，约$0.26 / $0.78（第三方聚合平台低价口径） Qwen3.7 Plus，$0.40 / $1.60（官方国际区，256K以内） 官方Plus档位抬高，但不同地域和渠道价差很大 模型价格没有一起下降，真正变化的是价格结构 “性价比档”这个名字听起来该一路走低，但表2里Gemini Flash-Lite反而是涨幅最大的一行。阿里的情况也要小心看，官方国际区、国内区、香港/美国节点、第三方聚合平台的价格并不完全一样，不能只拿最低渠道价当成全网统一价。\n二、别只看标价，真实账单通常由四件事决定 同一张价格表，放两家公司账上，感受能完全不一样，问题往往不在标价本身。\n先说最容易被忽略的一点：多数模型的输出token比输入token贵好几倍，推理模型的思考token通常也按输出或生成侧计费。表面看输入价降了，真正烧钱的经常是长回答、长推理链，还有Agent那种一口气调好几轮工具的任务。\n几家都在推提示词缓存，命中价通常能比未命中低一个数量级。DeepSeek V4-Pro官方价格里，缓存命中输入是$0.003625/百万token，缓存未命中输入是$0.435/百万token，高峰时段两者正好差120倍。固定的系统提示词、长文档、代码仓库上下文，如果每次都按新内容重新塞进去，就是在主动多付钱。跟缓存类似的还有批处理，报告生成、批量打标、离线摘要这类不用秒回的活，OpenAI的Batch API和Anthropic的Message Batches都能把实时调用价打到约五折。\n便宜模型先判断任务类型，简单的直接答，复杂的才升级给贵模型。《2块钱vs1300块钱》那篇算过一笔经济账，全量走旗舰模型的话月成本就要上万美元，改路由后费用能降到十分之一，质量几乎没太明显的损失。降价潮真正改变的不是某个具体型号模型的标价，而是旗舰模型从“默认入口”变成了“最后兜底”。\n真实AI账单不是由模型标价单独决定 三、降价背后的推理成本曲线：往下压的和往上顶的 推理成本主要卡在GPU、显存带宽、并发和输出长度这几个变量上，过去一年这几个变量在往两个相反的方向同时发力。\n先说往下压的这头，MoE架构让每个token只激活一部分参数，蒸馏把大模型的能力迁移到小模型上，量化、KV Cache优化、投机解码、连续批处理（continuous batching）继续往吞吐量里挤空间。缓存命中率的提升尤其关键，靠的是软件工程，而不需要多买一张卡。训练成本还在涨，但推理成本正在被产品化地拆开。模型厂商没有把省下来的钱都体现在旗舰产品单价上，而是塞进了mini、flash、lite、batch、cache这些入口里。表1和表2为什么走向相反，原因也在这里：旗舰档更像利润池和能力展示窗口，日常档位才是拿来抢开发者入口的地方。\n再看往上顶的这头。HBM供给周期大约在24到36个月，产能扩张慢，又容易被大客户长协锁住，这是硬约束。更直接的信号是国内云厂商今年3月到4月的一轮涨价。3月11日，腾讯云调整智能体开发平台部分模型计费策略，以Tencent HY2.0 Instruct为例，输入价格从每千token0.0008元涨到0.004505元，涨幅约463%。3月18日，阿里云和百度智能云同日宣布上调AI算力、存储等产品价格，阿里云部分算力卡最高涨34%，百度AI算力相关产品上调约5%到30%。这些不是模型API单价普涨，但它说明底层算力和存储成本并没有跟着“token单价下降”同步变轻。\n更隐蔽的一层是Agent场景把单次任务的token消耗放大了。国家数据局披露过一组数：2024年初，中国日均token调用量大约为1000亿；到2026年3月，已经超过140万亿，两年多涨了1000多倍。落到具体案例上更直观。米哈游《崩坏》系列AI NPC \u0026amp; Gameplay技术团队负责人郑银河在2026阿里云峰会上分享过一次内部教训：有工程师测试多智能体协作，几十个Agent没有设置token消耗上限，连续跑了13个小时，账单烧到200万元人民币。Uber那边也有类似压力，COO Andrew Macdonald今年5月公开说，公司越来越难把AI token消耗和用户能感知的产品产出直接对应起来，内部开始反思所谓tokenmaxxing。两件事各自发生，但指向同一个问题：单价降得再快，也扛不住调用量更快地涨。\n算力供给端还有一条线要单独拎出来说。DeepSeek V4-Pro当前的并发限制明显低于V4-Flash，官方价格页也把两档模型分成不同吞吐入口。至于昇腾950系列下半年放量后会不会带来进一步降价，现在还只能按供应端观察点处理。它和我们之前拆910C vs H100那篇能接上，但不能写成已经落地的官方降价承诺。\nAI推理成本被两股力量同时拉扯 四、为什么你体感上还是觉得没便宜 模型厂家单价降了，作为消费者的我们感受却没变便宜，仔细琢磨了一下，大概是这几层原因叠在一起。\n先是调用次数变多了。以前一次问答就是一次调用，现在一条任务链路里要搜索、改写、检查、调用工具、再总结，跑好几次模型很正常。\n上下文也跟着变长了。以前几千token够用，现在动不动把几十页文档、整段日志、整个代码仓库塞进去。输入单价确实降了，但输入量涨得更快。\n再往深里想，可能任务本身也变贵了。客服问答便宜，但让Agent替你跑一整套流程就贵；摘要便宜，但自动写代码、自动修bug就贵。便宜的是token，不一定是你真正要做的那件事。\n所以“通用Token在探底、企业AI总支出反而在涨”这种听起来矛盾的说法，其实一点都不矛盾，因为单价和总账单本来就不是一回事。\n五、未来半年价格预判 Sonnet 5的$2/$10优惠价8月31日到期，9月1日恢复标准价$3/$15，这个已经公布了，不算预测。DeepSeek V4-Pro后续是否继续下调，要看高端算力供给和官方调价节奏；昇腾950系列放量是一个值得跟的变量，但现在还不能把它写成确定会降多少。\n剩下的就是猜了。主力档还会继续往下探，$0.5到$2输入、$2到$10输出这个区间会越来越挤，各家都会把常用的日常负载往这里推。旗舰档大概率不会跟着大幅降价，会继续靠可靠性、长任务、复杂代码和工具链收溢价。过去一年Opus 4.8到Opus 5这条线，价格都在$5/$25附近，这就是一个现成信号。计费颗粒度会越切越细，缓存价、长上下文溢价、推理强度档、工具调用费，会变成账单里比模型单价更重要的部分。国内这轮算力涨价如果在四季度松动，前提也不是“模型厂商想降价”，而是供需缺口真的收窄。现在证据还不够，只能当观察点。\n写在最后 这一年真正变了的，不是哪个型号的模型降了百分之多少，是整个价格结构。以前问“该用哪个最强模型”，现在更像在排一张调度表：哪些任务用便宜模型，哪些等批处理，哪些上下文必须命中缓存，哪些才值得升级到旗舰档。\n会调度模型，才真正吃到降价红利 这一年AI到底便宜了多少，得看你怎么算。按单次聊天算的话，便宜了一截。按完整工作流算，就要看你有没有把模型当成一组可以调度的资源了。不会调度，降价照样可能换来更大的账单；会调度的话，过去一年已经足够把不少AI功能从演示项目推到日常生产里。\n价格表的保质期还是一个季度左右。8月31日Sonnet 5恢复标准价、下半年950系列是否顺利放量，这两件事三个月内都会有新信号，够触发下一次更新。关注我，价格再有大变动，我会接着往下写。\n本文属于价格追踪系列，上一篇：《用AI工具，为什么有人花2块，有人花1300块？》。文中美元价格优先采用官方API列表价，不含企业协议折扣；阿里旧版Qwen Plus低价为第三方聚合平台口径，已在表中标注；人民币价格来自对应云厂商公告或媒体转述，未按统一汇率折算。\n参考资料 Anthropic：《Introducing Claude Sonnet 5》与Claude Platform Pricing，Sonnet 5首发价、9月1日后标准价及新tokenizer说明。 OpenAI：《GPT-5.6: Frontier intelligence that scales with your ambition》与GPT-5.6 Terra模型价格页，GPT-5.6 Sol/Terra/Luna定价及缓存规则。 Google AI for Developers：Gemini API Pricing与Gemini 3 Developer Guide，Gemini 2.5 Pro、Gemini 3.1 Pro Preview、Gemini 2.5/3.1 Flash-Lite价格。 DeepSeek API Docs：Models \u0026amp; Pricing，DeepSeek V4-Flash/V4-Pro缓存命中、缓存未命中、输出价格及并发限制。 Alibaba Cloud Model Studio：Model inference pricing，Qwen3.7 Plus国际区和分层定价。 腾讯云公告《智能体开发平台关于部分模型启动正式收费及价格调整的公告》，2026年3月11日。 每日经济新闻《最高涨34％！阿里云、百度智能云同时宣布：涨价》，2026年3月18日。 新华社《我国日均Token的调用量三个月增长超40% 目前已超140万亿》，2026年3月24日。 游戏葡萄《米哈游崩坏IP实战分享：为探索AI，曾一晚烧掉200万？》，2026年5月22日。 Indian Express / Tom\u0026rsquo;s Hardware对Uber COO Andrew Macdonald关于tokenmaxxing与AI支出的报道，2026年5月。 ","permalink":"https://blog.onecai.site/2026/08/03/064-model-price-drop-2026/","summary":"\u003cblockquote\u003e\n\u003cp\u003e价格数据核对时间：2026年7月下旬。文中价格以官方定价页为准，第三方转述的地方我会单独标注。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e一开始我以为这篇会写成“模型又便宜了几倍”。真把几家官方价格页翻完，结论反而没那么顺口：最强的那几档没有一路降价，有的主力模型输入价还在往上走。便宜得更明显的，是平时真正拿来写代码、跑客服、做摘要、批量处理文档的那一层。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e不是所有模型都便宜了，是能干活的中间档位在往下沉。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e过去一年，价格变化最集中的地方不在旗舰档，而在主力档、性价比档、缓存命中和批处理。也就是说，模型厂商没有简单把“最强模型”打折甩卖，而是把更便宜的入口拆得越来越细。\u003c/p\u003e\n\u003ch2 id=\"一先看两张价格表\"\u003e一、先看两张价格表\u003c/h2\u003e\n\u003cp\u003e看价格表之前先统一口径：美元/百万token，输入/输出，不混人民币，不混包月订阅。表里优先用官方API列表价；如果是第三方聚合平台或媒体口径，会在后面单独说明。选型也定一条规则：每家只放它当前最常被开发者拿来干活的那一档，不拿旗舰去对标别家的性价比档，也不拿性价比档去对标别家的旗舰档。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e表1：主力档，一年对比\u003c/strong\u003e\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e厂商\u003c/th\u003e\n          \u003cth\u003e一年前（2025年7月）\u003c/th\u003e\n          \u003cth\u003e现在（2026年7月）\u003c/th\u003e\n          \u003cth\u003e变化\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eAnthropic\u003c/td\u003e\n          \u003ctd\u003eClaude Sonnet 4，$3 / $15\u003c/td\u003e\n          \u003ctd\u003eClaude Sonnet 5，首发价$2 / $10（8月31日后回到$3 / $15）\u003c/td\u003e\n          \u003ctd\u003e优惠期名义上降了约三分之一，但新tokenizer会让同样文本切出更多token，官方口径约多30%，实际省钱幅度要打折扣\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eOpenAI\u003c/td\u003e\n          \u003ctd\u003eGPT-4.1，$2 / $8\u003c/td\u003e\n          \u003ctd\u003eGPT-5.6 Terra，$2.5 / $15\u003c/td\u003e\n          \u003ctd\u003e输入涨25%，输出涨近一倍\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGoogle\u003c/td\u003e\n          \u003ctd\u003eGemini 2.5 Pro，$1.25 / $10\u003c/td\u003e\n          \u003ctd\u003eGemini 3.1 Pro，$2 / $12\u003c/td\u003e\n          \u003ctd\u003e按当前价格算，输入涨60%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeek\u003c/td\u003e\n          \u003ctd\u003eDeepSeek V3，$0.27 / $1.10\u003c/td\u003e\n          \u003ctd\u003eDeepSeek V4-Pro，$0.435 / $0.87\u003c/td\u003e\n          \u003ctd\u003e输入涨61%，输出降21%，两头打平\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cstrong\u003e表2：性价比档，一年对比\u003c/strong\u003e\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e厂商\u003c/th\u003e\n          \u003cth\u003e一年前\u003c/th\u003e\n          \u003cth\u003e现在\u003c/th\u003e\n          \u003cth\u003e变化\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eOpenAI\u003c/td\u003e\n          \u003ctd\u003eGPT-4o mini，$0.15 / $0.60\u003c/td\u003e\n          \u003ctd\u003e同一型号仍在售，价格没动过\u003c/td\u003e\n          \u003ctd\u003e两年持平\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGoogle\u003c/td\u003e\n          \u003ctd\u003eGemini 2.5 Flash-Lite，$0.10 / $0.40\u003c/td\u003e\n          \u003ctd\u003eGemini 3.1 Flash-Lite，$0.25 / $1.50\u003c/td\u003e\n          \u003ctd\u003e涨150%～275%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeek\u003c/td\u003e\n          \u003ctd\u003e一直是$0.14 / $0.28\u003c/td\u003e\n          \u003ctd\u003e还是$0.14 / $0.28\u003c/td\u003e\n          \u003ctd\u003e两年零变化\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e阿里\u003c/td\u003e\n          \u003ctd\u003eQwen Plus，约$0.26 / $0.78（第三方聚合平台低价口径）\u003c/td\u003e\n          \u003ctd\u003eQwen3.7 Plus，$0.40 / $1.60（官方国际区，256K以内）\u003c/td\u003e\n          \u003ctd\u003e官方Plus档位抬高，但不同地域和渠道价差很大\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"model-price-drop-2026-1.avif\"\n          alt=\"模型价格没有一起下降，真正变化的是价格结构\"/\u003e \u003cfigcaption\u003e\n             模型价格没有一起下降，真正变化的是价格结构\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e“性价比档”这个名字听起来该一路走低，但表2里Gemini Flash-Lite反而是涨幅最大的一行。阿里的情况也要小心看，官方国际区、国内区、香港/美国节点、第三方聚合平台的价格并不完全一样，不能只拿最低渠道价当成全网统一价。\u003c/p\u003e","title":"模型降价潮：这一年AI到底便宜了多少？"},{"content":"先算两笔账。\n同样是2000输入token加1000输出token的一次对话，跑500次：\n用DeepSeek V4 Flash（输入0.14美元/输出0.28美元每百万token），成本约0.28美元。这时候如果某个应用收你$20/月，账面上就是71倍。\n换成Claude Sonnet 5（首发价输入$2/输出$10每百万token），同样规模500次约7美元。这时候$20/月只是不到3倍。\n同一句“10倍”，参照系不同，结论能从“离谱”摆到“合理”。这也是这篇文章想讲清楚的第一件事：判断一个AI应用贵不贵，不能只看倍数，要看它到底在用哪个价位的模型，以及这10倍里，哪些是看得见的产品成本，哪些是看不见的加价。\n一、中间商加价链条：应用卖的不是一层API 先把这条链条从良性到恶性拆开看，不要一上来就骂“套壳”。\n合理的那一层：产品能力叠加 模型API成本只是底层。上面还压着模型路由、并发池、失败重试、内容审核、RAG检索、文件解析、联网搜索、多模态工具、账单系统、客户端开发，最后还有支付通道和应用商店抽成——Apple标准佣金30%，小型开发者计划下，符合上一日历年App收益不超过100万美元等条件的开发者佣金可降到15%；Stripe美国本土卡标准费率是2.9%+30美分。这些都是真实存在、写在合同里的成本。\n拿两个真实产品对照：\nCursor卖的不是“转发一次对话”，是Agent能力、云端代码库理解、多模型路由——Pro $20/月、Pro+ $60/月、Ultra $200/月（2026年7月定价），价格分层对应的是包含的模型调用额度和优先级，不是纯粹的转发差价。\nTypingMind是另一个方向的例子：一次性买断前端功能（Standard档一次性$39，终身授权；更贵的Extended档$79、Premium档$99解锁多模型面板等更多功能），API费用你自己用自己的key去付。这个模式很适合拿来对照——它把“应用费”和“模型费”彻底切开了，你能清清楚楚看到自己到底为界面和功能付了多少钱，用得越多，$39这个门槛摊得越薄。\nAI应用加价链条 渠道成本产生的加价：国内的“中转站”生态 国内接大模型API，渠道选不同，价格差距是真实存在的，但多数属于走量折扣、支付便利和接入服务，不一定是欺诈。因为这类中转站价格变动很快，不适合引用几个月前的单一评测价。更稳妥的是看机制：如果渠道方明示模型、单价、发票、服务条款和可用性边界，价差通常属于商业服务；如果它不说明底层模型，还把低价模型包装成旗舰模型，就进入了后面要讲的风险区。\n恶性的那一层：套壳与模型偷换 这一层的数据扎实到值得单独拎出来讲。\n软件工程师Teja Kusireddy用三周时间逆向了200家拿到融资、公开宣称“自研AI”的创业公司，监控网络流量、反编译JS打包文件、比对API指纹。结果：73%的公司实际是套壳。\n最典型的案例：一家号称“革命性自然语言理解引擎”的公司，融资时讲了23次“自研模型”，反编译后发现全部技术含量就是一个系统提示词——“请假装你不是GPT-4”。他们的真实成本约每次查询0.033美元（GPT-4 API输入0.03美元/千token、输出0.06美元/千token，平均一次查询500输入+300输出token），对用户收费每次查询2.50美元，或者$299/月200次——收入约为直接模型成本的75倍。\nRAG套壳的情况更夸张：嵌入模型用OpenAI的text-embedding-ada-002，向量库用Pinecone或Weaviate，生成用GPT-4，全部原样调用第三方服务，包装成“先进神经检索+自研嵌入模型”。实际成本约0.002美元/次查询，用户实际支付0.50到2.00美元/次——收入约为直接成本的250到1000倍。调查里200家公司中，真正从零训练模型的只占7%。\n这还只是消费级应用。学术界的情况更让人意外。CISPA亥姆霍兹信息安全中心的论文《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》（arXiv 2603.01919）追踪了17个被称为“影子API”的第三方代理服务，发现它们已经被引用进187篇学术论文，其中116篇（62.03%）发表在同行评审会议或期刊，包括ACL、CVPR、ICLR等。论文揭露了三种经济欺骗手段：\n信息溢价：收旗舰版的钱，用能力相近但更便宜的旧版本模型顶替——某API标榜提供Gemini 2.0早期版本，实际用2.5版本的价差超过7倍来牟利 折扣替换：原价收费，后台把闭源大模型换成开源小模型——用户高价点名要GPT-5，指纹识别却发现后台跑的是GLM-4-9B 加价倒卖：在前两者基础上再加一层服务费 经过换算，在GPQA的1273次请求口径下，用户按官方标准费率约支付14.84美元，但实际拿到的等价token价值只有5.70到7.77美元——中间商在这个差价里就能赚走过半利润。\n这节的结论：同样一句“加价10倍”，产品能力叠加是合理的（Cursor这类），渠道成本是可以理解的（国内中转站几倍以内），但套壳偷换模型这层，价差可以从75倍一路飙到上千倍，这已经不是“贵”，而是欺诈。\n二、怎么判断一个AI应用是不是在割韭菜 给两套检查清单，一套给普通用户，一套给要认真评估的开发者/采购方。\n普通用户能自己做的5件事 它是否说清楚具体模型版本。只写“顶级模型驱动”、“GPT级智能”而不说具体模型名和额度规则的，要多留心。 它是否说清楚额度口径。“无限使用”通常不是无限token，看有没有每日限额、高峰降级、慢速队列、积分过期这些细则。 它是否把基础转发包装成高级能力。如果只是转发一次对话，却收费接近专业工具的价格，又没有项目管理、文件解析、协作、历史管理这些配套，这个溢价就站不住。 是否存在未明示的模型降级路由。你以为一直在用旗舰模型，实际大量请求被悄悄路由到便宜模型——这不一定是坏事，但应该被告知。 是否有同类的BYOK方案可对照。允许你自带API key的工具（比如上面提到的TypingMind），最容易照出“前端功能”到底值多少钱，因为模型那部分的钱是你自己直接付给厂商的。 更直接的技术侦查（来自Teja Kusireddy的调查方法） 打开浏览器DevTools的Network标签，跟应用的AI功能互动，看有没有直连api.openai.com、api.anthropic.com——中间可以加一层业务逻辑，但AI能力本身不是它自己的。响应延迟也是一个信号：官方API的延迟通常稳定在一个区间，套壳中转站的延迟经常剧烈抖动。网页源码里搜一下有没有系统提示词残留的关键词，比如“永远不要说自己是OpenAI”这类指令。营销语言也是一个粗筛：具体的技术术语大概率是真的，“先进AI引擎”“智能核心”这类模糊词往往在掩饰什么都没有。\n面向开发者/企业采购的审计标准 如果是要给生产环境或研究工作流选API，CISPA论文给出的审计协议值得参考：用LLMmap之类的指纹识别工具，通过输出的余弦距离比对判断模型真实身份——论文实测显示，被测的24个模型端点里，45.83%直接未通过指纹验证，另外12.50%表现出与官方模型的巨大偏差，合计过半的“影子API”偷换了底层模型。在高风险任务上验证更直观：官方Gemini-2.5-flash在MedQA医疗基准上准确率83.82%，影子API平均只有36.95%。这不等同于真实医疗诊断表现，但在该基准上已经显示出明显能力缺口。论文给出的最低审计门槛是：至少24次指纹探测、500样本分布测试比对p值、多次独立会话检查延迟和方差是否异常。\n三、词膨胀现象：为什么应用的真实成本比你想的大 用户一句话背后的词膨胀税 前两节讲的是纯利润，这一节讲一笔真实存在、但用户从来看不到的成本。\n你看到的是一句简单的提问，模型看到的可能是：系统提示词、角色设定、工具定义、历史对话、上传文件摘要、检索片段、格式约束、审查规则，最后才是你那句话本身。这层膨胀不是应用方故意坑你，而是为了让通用模型套上产品人设、遵守话术规范、能调用一堆功能，必须付出的真实代价。\n这个现象在学术界有正式名字——prompt bloat（提示膨胀）。论文《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》（arXiv 2505.03275）专门研究了这个问题：当一个应用能调用的外部工具越来越多，把所有工具描述一次性塞进提示词，会导致模型在一堆干扰项里越来越难找到正确的工具——这个现象和“大海捞针”测试是同一个机制，工具池越大，选对工具的准确率下降得越明显。论文设计的检索增强方案，只把和当前任务相关的工具描述注入提示词，实测能把提示词token减少约49%，同时把工具选择准确率从13.62%提升到43.13%，提升超过3倍。反过来说，没做这个优化的应用，光是“膨胀”这一项就在吃掉将近一半的无效token——这些token你不会看到，但每次调用都在计费。\n真实场景里，这类膨胀往往来自工具定义和格式约束。编程Agent、客服Agent、企业知识库助手都会把工具名称、工具描述、JSON schema、调用规则、权限说明塞进上下文。工具越多，固定提示词越厚，用户输入的那一句话反而只占很小一部分。\n图片和文件类输入也有同样的问题。Anthropic的官方视觉文档说明，一张高分辨率图片在Claude Opus 4.7及后续支持高分辨率图像的模型上最多可能消耗约4,784个token——如果一个应用的工作流里频繁塞截图、扫描件，这部分开销比你以为的“一张图”要重得多。\n这节的结论：套壳应用的加价，一部分是第一节讲的纯利润，另一部分是这里讲的、真实存在的“词膨胀税”。为了让通用模型套上产品人设、话术规范、功能调用，应用方自己也在为膨胀的提示词买单，这笔真实成本会被摊到你的订阅费里——这是套壳应用加价里唯一说得过去的部分，也是你判断“这个价格有没有道理”时该纳入的变量。\n四、缓存命中率：套壳应用没告诉你的另一层真实成本 缓存命中率决定AI应用真实成本 前缀缓存的原理专栏之前拆过：模型处理过的相同前缀，下次可以复用，命中价格能低到未命中的十分之一，甚至更低（详见《同一份材料，为什么第二次交给AI只收1/10？》）。这里不重复原理，只讲这篇独有的角度。\n套壳应用的系统提示词里，往往混杂着用户人设、时间戳、随机会话ID，或者动态注入的“你是XX产品的AI助手，今天是2026年X月X日”——这类前缀天然缓存不友好，因为前缀必须从第0个token开始逐字一致才能命中。相比你自己直调API、把系统提示词写死放在最前面，套壳应用为了做“产品化包装”往往会在提示词最前面塞一些每次都在变的内容，这本身就在持续破坏缓存命中率。\n这是套壳应用成本结构里真实存在，却从来不会写进定价页的一块：如果一个应用每次发送2万token的固定背景+1000token的用户问题，命中率从20%提到80%，足以决定这个应用是在亏钱、赚钱，还是敢卖“更高额度”的套餐。换句话说，你付的订阅费里，有一部分可能是在为它糟糕的提示词工程买单。\n五、如果你自己在做套壳产品 词膨胀和缓存命中率其实是可以同时优化的两件事：把工具定义、产品人设这些稳定内容做cache_control断点固定在前面，把免责声明和话术规范精简到必要程度，动态内容（时间、用户ID、临时参数）一律放到最后。这两件事做好，你的真实成本能降到接近官方API裸调用的水平——到那时候，你收的加价才是纯粹的“服务费”，而不是“低效税”。具体的排序方法、断点打法和监控字段，可以直接参考《同一份材料，为什么第二次交给AI只收1/10？》和《KV Cache》这两篇里的实操三步，这里不再重复。\n写在最后 同一个模型，API和应用订阅价差10倍，这件事本身不奇怪——参照系不同，结论可以从3倍摆到1000倍。真正需要警惕的，不是这个倍数本身，而是你不知道自己买到的到底是什么：是产品能力的合理叠加、渠道成本的正常折扣，还是词膨胀吃掉的真实开销，又或者是一层纯粹的欺诈加价。\n懂AI应用成本的人，不会只问“你用的是什么模型”，还会追问几句：平均一次请求消耗多少token？缓存命中率大概多少？超额之后会不会悄悄降级？哪些能力是模型原生自带的，哪些是应用自己做出来、又是否真的值这个价？\n这几个问题问下来，10倍这个数字自己就会说话。\n主要资料来源\nTeja Kusireddy逆向工程200家AI创业公司调查：https://pub.towardsai.net/i-reverse-engineered-200-ai-startups-73-are-lying-a8610acab0d3 《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》，CISPA亥姆霍兹信息安全中心：https://arxiv.org/abs/2603.01919 《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》：https://arxiv.org/abs/2505.03275 Anthropic视觉文档（图片token消耗）、Cursor官方定价页（2026年7月）、TypingMind官网定价（多信源交叉确认，2026年6-7月） Apple App Store小型开发者计划、Stripe标准费率官方说明 ","permalink":"https://blog.onecai.site/2026/08/02/063-api-vs-app-price-gap/","summary":"\u003cp\u003e先算两笔账。\u003c/p\u003e\n\u003cp\u003e同样是2000输入token加1000输出token的一次对话，跑500次：\u003c/p\u003e\n\u003cp\u003e用DeepSeek V4 Flash（输入0.14美元/输出0.28美元每百万token），成本约0.28美元。这时候如果某个应用收你$20/月，账面上就是\u003cstrong\u003e71倍\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e换成Claude Sonnet 5（首发价输入$2/输出$10每百万token），同样规模500次约7美元。这时候$20/月只是\u003cstrong\u003e不到3倍\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e同一句“10倍”，参照系不同，结论能从“离谱”摆到“合理”。这也是这篇文章想讲清楚的第一件事：\u003cstrong\u003e判断一个AI应用贵不贵，不能只看倍数，要看它到底在用哪个价位的模型，以及这10倍里，哪些是看得见的产品成本，哪些是看不见的加价。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"一中间商加价链条应用卖的不是一层api\"\u003e一、中间商加价链条：应用卖的不是一层API\u003c/h2\u003e\n\u003cp\u003e先把这条链条从良性到恶性拆开看，不要一上来就骂“套壳”。\u003c/p\u003e\n\u003ch3 id=\"合理的那一层产品能力叠加\"\u003e合理的那一层：产品能力叠加\u003c/h3\u003e\n\u003cp\u003e模型API成本只是底层。上面还压着模型路由、并发池、失败重试、内容审核、RAG检索、文件解析、联网搜索、多模态工具、账单系统、客户端开发，最后还有支付通道和应用商店抽成——Apple标准佣金30%，小型开发者计划下，符合上一日历年App收益不超过100万美元等条件的开发者佣金可降到15%；Stripe美国本土卡标准费率是2.9%+30美分。这些都是真实存在、写在合同里的成本。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e拿两个真实产品对照：\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eCursor卖的不是“转发一次对话”，是Agent能力、云端代码库理解、多模型路由——Pro $20/月、Pro+ $60/月、Ultra $200/月（2026年7月定价），价格分层对应的是包含的模型调用额度和优先级，不是纯粹的转发差价。\u003c/p\u003e\n\u003cp\u003eTypingMind是另一个方向的例子：一次性买断前端功能（Standard档一次性$39，终身授权；更贵的Extended档$79、Premium档$99解锁多模型面板等更多功能），API费用你自己用自己的key去付。这个模式很适合拿来对照——它把“应用费”和“模型费”彻底切开了，你能清清楚楚看到自己到底为界面和功能付了多少钱，用得越多，$39这个门槛摊得越薄。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"api-vs-ai-app-price-10x-1.avif\"\n          alt=\"AI应用加价链条\"/\u003e \u003cfigcaption\u003e\n             AI应用加价链条\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch3 id=\"渠道成本产生的加价国内的中转站生态\"\u003e渠道成本产生的加价：国内的“中转站”生态\u003c/h3\u003e\n\u003cp\u003e国内接大模型API，渠道选不同，价格差距是真实存在的，但多数属于走量折扣、支付便利和接入服务，不一定是欺诈。因为这类中转站价格变动很快，不适合引用几个月前的单一评测价。更稳妥的是看机制：如果渠道方明示模型、单价、发票、服务条款和可用性边界，价差通常属于商业服务；如果它不说明底层模型，还把低价模型包装成旗舰模型，就进入了后面要讲的风险区。\u003c/p\u003e\n\u003ch3 id=\"恶性的那一层套壳与模型偷换\"\u003e恶性的那一层：套壳与模型偷换\u003c/h3\u003e\n\u003cp\u003e这一层的数据扎实到值得单独拎出来讲。\u003c/p\u003e\n\u003cp\u003e软件工程师Teja Kusireddy用三周时间逆向了200家拿到融资、公开宣称“自研AI”的创业公司，监控网络流量、反编译JS打包文件、比对API指纹。结果：\u003cstrong\u003e73%的公司实际是套壳\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e最典型的案例：一家号称“革命性自然语言理解引擎”的公司，融资时讲了23次“自研模型”，反编译后发现全部技术含量就是一个系统提示词——“请假装你不是GPT-4”。他们的真实成本约每次查询0.033美元（GPT-4 API输入0.03美元/千token、输出0.06美元/千token，平均一次查询500输入+300输出token），对用户收费每次查询2.50美元，或者$299/月200次——\u003cstrong\u003e收入约为直接模型成本的75倍\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003eRAG套壳的情况更夸张：嵌入模型用OpenAI的text-embedding-ada-002，向量库用Pinecone或Weaviate，生成用GPT-4，全部原样调用第三方服务，包装成“先进神经检索+自研嵌入模型”。实际成本约0.002美元/次查询，用户实际支付0.50到2.00美元/次——\u003cstrong\u003e收入约为直接成本的250到1000倍\u003c/strong\u003e。调查里200家公司中，真正从零训练模型的只占7%。\u003c/p\u003e\n\u003cp\u003e这还只是消费级应用。学术界的情况更让人意外。CISPA亥姆霍兹信息安全中心的论文《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》（arXiv 2603.01919）追踪了17个被称为“影子API”的第三方代理服务，发现它们已经被引用进187篇学术论文，其中116篇（62.03%）发表在同行评审会议或期刊，包括ACL、CVPR、ICLR等。论文揭露了三种经济欺骗手段：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e信息溢价\u003c/strong\u003e：收旗舰版的钱，用能力相近但更便宜的旧版本模型顶替——某API标榜提供Gemini 2.0早期版本，实际用2.5版本的价差超过7倍来牟利\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e折扣替换\u003c/strong\u003e：原价收费，后台把闭源大模型换成开源小模型——用户高价点名要GPT-5，指纹识别却发现后台跑的是GLM-4-9B\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e加价倒卖\u003c/strong\u003e：在前两者基础上再加一层服务费\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e经过换算，在GPQA的1273次请求口径下，用户按官方标准费率约支付14.84美元，但实际拿到的等价token价值只有5.70到7.77美元——中间商在这个差价里就能赚走过半利润。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e这节的结论\u003c/strong\u003e：同样一句“加价10倍”，产品能力叠加是合理的（Cursor这类），渠道成本是可以理解的（国内中转站几倍以内），但套壳偷换模型这层，价差可以从75倍一路飙到上千倍，这已经不是“贵”，而是欺诈。\u003c/p\u003e\n\u003ch2 id=\"二怎么判断一个ai应用是不是在割韭菜\"\u003e二、怎么判断一个AI应用是不是在割韭菜\u003c/h2\u003e\n\u003cp\u003e给两套检查清单，一套给普通用户，一套给要认真评估的开发者/采购方。\u003c/p\u003e\n\u003ch3 id=\"普通用户能自己做的5件事\"\u003e普通用户能自己做的5件事\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e它是否说清楚具体模型版本\u003c/strong\u003e。只写“顶级模型驱动”、“GPT级智能”而不说具体模型名和额度规则的，要多留心。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e它是否说清楚额度口径\u003c/strong\u003e。“无限使用”通常不是无限token，看有没有每日限额、高峰降级、慢速队列、积分过期这些细则。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e它是否把基础转发包装成高级能力\u003c/strong\u003e。如果只是转发一次对话，却收费接近专业工具的价格，又没有项目管理、文件解析、协作、历史管理这些配套，这个溢价就站不住。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e是否存在未明示的模型降级路由\u003c/strong\u003e。你以为一直在用旗舰模型，实际大量请求被悄悄路由到便宜模型——这不一定是坏事，但应该被告知。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e是否有同类的BYOK方案可对照\u003c/strong\u003e。允许你自带API key的工具（比如上面提到的TypingMind），最容易照出“前端功能”到底值多少钱，因为模型那部分的钱是你自己直接付给厂商的。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3 id=\"更直接的技术侦查来自teja-kusireddy的调查方法\"\u003e更直接的技术侦查（来自Teja Kusireddy的调查方法）\u003c/h3\u003e\n\u003cp\u003e打开浏览器DevTools的Network标签，跟应用的AI功能互动，看有没有直连api.openai.com、api.anthropic.com——中间可以加一层业务逻辑，但AI能力本身不是它自己的。响应延迟也是一个信号：官方API的延迟通常稳定在一个区间，套壳中转站的延迟经常剧烈抖动。网页源码里搜一下有没有系统提示词残留的关键词，比如“永远不要说自己是OpenAI”这类指令。营销语言也是一个粗筛：具体的技术术语大概率是真的，“先进AI引擎”“智能核心”这类模糊词往往在掩饰什么都没有。\u003c/p\u003e\n\u003ch3 id=\"面向开发者企业采购的审计标准\"\u003e面向开发者/企业采购的审计标准\u003c/h3\u003e\n\u003cp\u003e如果是要给生产环境或研究工作流选API，CISPA论文给出的审计协议值得参考：用LLMmap之类的指纹识别工具，通过输出的余弦距离比对判断模型真实身份——论文实测显示，被测的24个模型端点里，45.83%直接未通过指纹验证，另外12.50%表现出与官方模型的巨大偏差，\u003cstrong\u003e合计过半的“影子API”偷换了底层模型\u003c/strong\u003e。在高风险任务上验证更直观：官方Gemini-2.5-flash在MedQA医疗基准上准确率83.82%，影子API平均只有36.95%。这不等同于真实医疗诊断表现，但在该基准上已经显示出明显能力缺口。论文给出的最低审计门槛是：至少24次指纹探测、500样本分布测试比对p值、多次独立会话检查延迟和方差是否异常。\u003c/p\u003e\n\u003ch2 id=\"三词膨胀现象为什么应用的真实成本比你想的大\"\u003e三、词膨胀现象：为什么应用的真实成本比你想的大\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"api-vs-ai-app-price-10x-2.avif\"\n          alt=\"用户一句话背后的词膨胀税\"/\u003e \u003cfigcaption\u003e\n             用户一句话背后的词膨胀税\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e前两节讲的是纯利润，这一节讲一笔真实存在、但用户从来看不到的成本。\u003c/p\u003e\n\u003cp\u003e你看到的是一句简单的提问，模型看到的可能是：系统提示词、角色设定、工具定义、历史对话、上传文件摘要、检索片段、格式约束、审查规则，最后才是你那句话本身。这层膨胀不是应用方故意坑你，而是为了让通用模型套上产品人设、遵守话术规范、能调用一堆功能，必须付出的真实代价。\u003c/p\u003e\n\u003cp\u003e这个现象在学术界有正式名字——\u003cstrong\u003eprompt bloat（提示膨胀）\u003c/strong\u003e。论文《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》（arXiv 2505.03275）专门研究了这个问题：当一个应用能调用的外部工具越来越多，把所有工具描述一次性塞进提示词，会导致模型在一堆干扰项里越来越难找到正确的工具——这个现象和“大海捞针”测试是同一个机制，工具池越大，选对工具的准确率下降得越明显。论文设计的检索增强方案，只把和当前任务相关的工具描述注入提示词，实测能把提示词token减少约49%，同时把工具选择准确率从13.62%提升到43.13%，提升超过3倍。反过来说，\u003cstrong\u003e没做这个优化的应用，光是“膨胀”这一项就在吃掉将近一半的无效token\u003c/strong\u003e——这些token你不会看到，但每次调用都在计费。\u003c/p\u003e","title":"同一个模型，为什么API和AI应用价格能差10倍？"},{"content":" 前两篇分别拆了缓存怎么算钱（《同一份材料，为什么第二次交给AI只收1/10？缓存计费拆解》）和这笔钱到底省在哪张显存上（《KV Cache：每读1个token，就要交一笔“显存税”》）。这一篇把两条线合到一起——问题往往不出在缓存机制本身，而出在你喂给缓存的那份提示词，正在悄悄变胖。\n一、系统提示词正在膨胀 很多团队的系统提示词，都是这样长起来的。\n一开始可能只有一句话：你是一个专业助手，请按用户要求完成任务。后来慢慢补角色设定、输出格式、禁用事项、工具说明、异常处理、合规边界、历史经验、项目背景、风格要求。半年下来，这句话变成了一份几千字的说明书。\n系统提示词是怎么变胖的 看起来很专业，像是把模型管住了。问题是，这些字每一轮都要进上下文，每一轮都可能被计费，每一轮也都可能影响缓存命中。\n这不是错觉，而且不是哪一家的孤例。\nAnthropic在2026年4月30日发过一篇官方博客《Lessons from building Claude Code: Prompt caching is everything》，作者Thariq Shihipar是Claude Code团队成员。他复盘了几个具体翻车案例：曾经把一个很详细的时间戳放进静态系统提示词，曾经让工具定义的排序变得不稳定，还改过工具参数（比如Agent工具可以调用哪些子Agent）——这些看似很小的改动，都破坏过缓存。这条材料很硬，因为不是外部用户猜测，而是做Claude Code的人自己说的。\n用户侧也能看到类似现象。anthropics/claude-code的一个GitHub issue（#45188）里，有用户报告Claude Code在2.1.89到2.1.96版本之间，首次缓存创建量从约38-52K token涨到112-119K token，5天左右涨了约7万token。作者说这让可用上下文明显变小，多步任务还没跑完就要频繁手动/compact。他还做过排除法：关掉自定义hook、拔掉候选MCP、删掉过期插件，重新测量体积都没变——说明这次膨胀来自版本本身的迭代。这是一条用户实测个案，不是Anthropic官方确认的数字，引用时需要标清楚。\nOpenAI Codex的用户也报告过类似现象（issue #19212）：只问一句“2+2等于几”，就消耗了约1.3万token。他让Codex自己估算这些开销来自哪里，得到的拆解是：系统指令、网页浏览策略、编码风格开发指令、工具schema、以及AGENTS.md和环境上下文。这同样是用户观察，不是官方统计，但说明一件事：Agent类产品的系统开销，很大一部分发生在用户输入第一个字之前。\n这不是单一厂商的问题，而是Agent工作流的共同代价。OpenRouter联合a16z在2025年12月发布的实证研究《State of AI: An Empirical 100 Trillion Token Study with OpenRouter》（Aubakirova等人，arXiv:2601.10088）分析了平台上超过100万亿token的真实调用数据，其中一个发现是：平均提示词长度从约1,500token涨到超过6,000token，涨幅接近4倍，驱动因素是工具调用和多步推理这类智能体工作流的兴起。这条数据来自OpenRouter平台的真实流量，是一手实证研究，但样本边界是“OpenRouter平台”，不代表全行业所有调用场景，引用时应保留这个限定。\n膨胀本身不一定是错误。真正的问题是，很多膨胀不是因为任务变复杂了，而是因为大家习惯把所有东西都塞进同一份不断变化的系统提示词里。\n二、膨胀为什么会拖累缓存 要理解膨胀为什么烧钱，得先理解Prompt Caching到底在缓存什么。\nClaude官方文档写得很清楚：缓存层级是tools→system→messages，某一层发生变化，这一层以及它后面的所有层都会一起失效。也就是说，工具定义一变，系统提示词和后面的对话历史都可能要重算；系统提示词一变，后面的对话历史缓存也会被连带打掉。\n缓存不认“差不多一样”，只认前缀是否逐字节一致。前面动一个地方，后面内容再长也要重新处理一遍。这时候，系统提示词越胖，一次失效的代价就越大：如果你把当前时间、随机trace、用户ID这类临时信息塞进了本该稳定的前缀里，这个前缀每一轮都不一样，缓存自然吃不到，模型还要反复处理这段越来越胖的上下文。\nPrompt Caching 只认稳定前缀 更麻烦的是，缓存写入本身也不是免费的，而且这件事正在变得更贵。Anthropic的写入计费是：5分钟有效期收标准输入价的1.25倍，1小时有效期收2倍，只有命中读取才是0.1倍。而OpenAI在2026年7月9日GA的GPT-5.6系列上，第一次对缓存写入收费——同样是标准输入价的1.25倍，最短缓存生命周期30分钟。更准确地说，OpenAI在GPT-5.6系列开始把缓存写入单独计价；Anthropic侧则早已把5分钟写入、1小时写入和缓存读取分成不同倍率。两边的共同信号是：缓存失效不再只是性能问题，而是可以在账单字段里被直接看见的成本问题。\n膨胀还会拖慢响应。前一篇《KV Cache》讲过，模型处理请求分Prefill和Decode两个阶段：Prefill阶段要把完整输入过一遍、把每个token的K和V算出来存好，这一步耗时随输入长度增长；命中缓存时，这一整段Prefill会被直接跳过。NVIDIA NIM的官方基准测试文档里也确认了同一个规律：提示词越长，首字延迟（TTFT）通常越高，因为注意力机制要先处理完整输入、建立好KV缓存，才能开始生成第一个token。用户看到第一个字之前，模型已经先读了一大堆前文——这笔延迟账，跟token计费账是并行发生的两笔账。\n一个量级参照：Claude Code官方博客提到，一次100轮的Opus长会话，不靠缓存要花50-100美元输入token费用，靠缓存能压到10-19美元，差距接近5倍。这个量级基本就是“膨胀又频繁失效”和“精简且稳定命中”之间的现实落差。\n长上下文还有一重更隐蔽的代价：不一定让模型变聪明。Chroma Research 2025年7月发布的论文《Context Rot: How Increasing Input Tokens Impacts LLM Performance》测试了18个主流模型（含GPT-4.1、Claude 4、Gemini 2.5、Qwen3等），发现即便是很简单的任务，模型表现也会随输入变长而下降，而且这种下降不均匀、因模型而异，跟“待检索信息在上下文里的位置”“是否存在语义相似的干扰内容”这些因素都有关系。换句话说，“模型看得到”和“模型能稳定用好”不是一回事——这也是很多Agent跑到后半程会变得犹豫、绕路、反复确认的原因之一：上下文还在，有效上下文已经被稀释了。\n三、怎么写“缓存友好”的提示词 原理和坑都清楚了，落地按优先级排。\n第一，稳定内容前置，动态内容殿后。工具定义、系统指令、长期规则放最前面，项目背景和少量示例次之，用户当前问题和临时参数放最后。这条前两篇已经讲过具体操作，这里不重复展开。\n第二，会过期的信息不要写回系统提示词本身。Claude Code的做法是：日期变了、文件改了，这类信息不去改静态前缀，而是作为一次性的旁路提示（\u0026lt;system-reminder\u0026gt;标签）插进当轮用户消息，静态前缀保持不动。很多团队的问题就出在这里——把“当前时间是几点”“用户在哪个页面”“本轮任务ID是什么”都拼进了系统提示词，结果每次请求的系统提示词都不一样，缓存自然命不中。\n第三，不要中途增删工具，用工具表达状态，而不是换工具集。Anthropic官方明确说过，改变工具集是最常见的缓存破坏方式之一——因为工具定义本身就在被缓存的前缀里。Claude Code给了一个具体解法：不为了切换Plan Mode就换一套工具，而是让模式切换只追加对话内容、不改动工具定义，缓存就不会因为模式切换而失效（Claude Code官方文档里唯一的例外是opusplan这种会在Plan Mode切换时连带切换模型的设置，因为模型本身也是缓存key的一部分，这种情况下确实会重建缓存，值得在配置时留意）。如果工具本身很多（比如挂了几十个MCP工具），Claude Code的做法是用defer_loading：先只发一个只有名字和一句话描述的轻量占位（stub），模型需要时再通过工具搜索去加载完整schema。这样任何用户配置了多少MCP工具，前缀里的stub都是同一套、同一个顺序，缓存不受影响——这套机制目前是官方文档里“受支持模型”的默认行为，不用额外配置。这是一条可以直接照抄的工程实践，在Anthropic的官方工具文档和Claude Code官方文档里都有单独说明。\n第四，系统提示词要定期“体检”，别只加不减。很多系统提示词变长，是因为每遇到一个坏case就往里面补一条规则，补到最后规则互相重叠甚至冲突——这既增加了缓存成本，也增加了模型要消化的负担。关于“Claude Code系统提示词从约800token砍到164token”这个具体案例，目前只查到几家科技媒体的二手报道（称2026年7月2日在AI Engineer World\u0026rsquo;s Fair上宣布），另外还有报道提到Thariq Shihipar在7月24日发布过一篇更完整的说明，讲的是围绕Claude 5系列做的六项系统提示词精简（规则改判断、示例改交互设计、前置上下文改按需加载的技能、去重、自动记忆替代手动CLAUDE.md、简单文本改用代码和评测集这类更丰富的规范），两处报道的时间和细节对不太上，没有找到Anthropic自己发布的原始页面核实。这条建议只作为方向性旁证使用——该精简就精简，不一定掉性能——不当作正文的核心证据。可以做的具体检查是：这条规则是否还在解决真实问题、是否和别的规则重复、是否只适用于极少数临时场景、能不能挪到用户消息或检索结果里去。\n第五，监控缓存命中率，而不是只看总账单。Claude Code团队会监控自己的prompt cache hit rate，命中率过低会触发SEV级别的故障报警。这个态度值得搬到自己的项目里：命中率是一个需要报警的运维指标，不是上线后就不用管的数字。具体可以盯这几个字段：cache_read_input_tokens（缓存读取量）、cache_creation_input_tokens（缓存写入量）、input_tokens/total_input_tokens（总输入量），以及TTFT（首字延迟）。只看总token不够，你需要知道这些token里有多少是缓存读取、有多少是新写入、有多少完全没进缓存。\n第六，长对话定期折叠成状态摘要，不留寒暄和流水账。这条上一篇《KV Cache》详细讲过操作方法：总结当前进展、带着总结开新会话，而不是让草稿纸和缓存前缀一起无限膨胀。这里再强调一次：折叠不只是省显存，同时也是保住缓存命中率、避开context rot的一举三得动作。\n第七，知识库不要全塞进提示词。大段背景资料优先做检索，只把和当前问题相关的少量片段放进提示词。这属于检索增强这条线的范畴，本文不展开，一句话带过。\n缓存友好的提示词结构 把以上几条落到一张表里，可以按“变化频率”给提示词分层：\n层级 内容 变化频率 缓存策略 稳定层 角色设定、工具定义（含defer_loading占位）、长期规则、输出格式 几乎不变 独立缓存断点，长期复用 半稳定层 项目背景、业务口径、少量高质量示例 偶尔变 单独断点，更新时只重建这一层 动态层 当前用户问题、临时参数、时间戳、system-reminder旁路信息 每次都变 不进入缓存前缀，放在末尾 结果层 本轮希望返回的格式和长度要求 按需变 视稳定程度归入前面对应层 写在最后 回到标题：提示词越写越长，到底是在帮AI，还是在烧钱？\n答案不取决于长度，取决于这些字有没有还在工作。帮AI理解任务的字该写——任务边界、输出格式、关键约束、必要示例，这些内容短了反而容易出错。但只是为了让AI记住上一次没变过的东西，就应该放进能被缓存接住的稳定前缀里；已经过期的时间戳、临时状态、被换掉的工具集、流水账式的历史对话，不该继续霸占系统提示词。\n而现在，这件事已经不只是工程师之间口口相传的经验了。Anthropic和OpenAI几乎在同一时间段，都开始对“重新建立一份缓存”这件事明码标价。膨胀不再是一种只有细心的人才会注意到的隐性浪费，它正在变成账单上一条越来越清楚的费用。\n好Prompt不是最厚的说明书，而是每一个字都知道自己为什么还留在上下文里的那一版。\n资料边界说明\n强可信，一手官方：\nAnthropic官方博客《Lessons from building Claude Code: Prompt caching is everything》（2026年4月30日）：缓存翻车案例、100轮会话成本对比、defer_loading机制。claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything Claude Platform官方文档《Prompt caching》：缓存层级（tools→system→messages）失效机制、写入计费倍率。platform.claude.com/docs/en/build-with-claude/prompt-caching Claude官方文档《Tool use with prompt caching》：defer_loading与工具集变更导致缓存失效的具体说明。platform.claude.com/docs/en/agents-and-tools/tool-use/tool-use-with-prompt-caching Claude Code官方文档《How Claude Code uses prompt caching》：缓存层级（system prompt/project context/conversation三层）、模式切换、defer_loading默认行为、/compact、/recap等操作对缓存的影响，缓存读取按约10%标准价计费。已于2026年7月27日核实可访问。code.claude.com/docs/en/prompt-caching OpenAI官方文档《Prompt caching in the API》：自动缓存机制、GPT-5.6系列缓存写入按1.25倍计费（2026年7月9日GA）。developers.openai.com/api/docs/guides/prompt-caching NVIDIA NIM官方基准文档《Metrics》：提示词长度与TTFT（首字延迟）的关系。docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html 中强可信，一手研究：\nChroma Research《Context Rot: How Increasing Input Tokens Impacts LLM Performance》（Kelly Hong, Anton Troynikov, Jeff Huber，2025年7月）。trychroma.com/research/context-rot OpenRouter × a16z《State of AI: An Empirical 100 Trillion Token Study with OpenRouter》（Aubakirova等，arXiv:2601.10088，2025年12月）：提示词平均长度4倍增长的数据来源，样本边界为OpenRouter平台。arxiv.org/abs/2601.10088 中可信，用户实测个案：\nGitHub issue anthropics/claude-code #45188（2026年4月）：系统提示词5天膨胀约7万token。github.com/anthropics/claude-code/issues/45188 GitHub issue openai/codex #19212（2026年4月）：单次简单问答消耗约1.3万token的系统开销拆解。github.com/openai/codex/issues/19212 谨慎使用，二手报道且细节不一致：\n“Claude Code系统提示词从约800token砍到164token”——不同媒体报道的时间（7月2日/7月24日）和事件细节存在出入，未找到Anthropic官方原始发布页，正文中仅作方向性旁证，不作为核心证据。相关报道：cryptobriefing.com/anthropic-claude-code-system-prompt-reduction、kucoin.com/news/flash/anthropic-cuts-claude-code-s-system-prompt-by-80-without-performance-loss、aiweekly.co/alerts/anthropic-deletes-80-of-claude-codes-system-prompt-for-claude-5（7月24日版本，六项精简说明）。 ","permalink":"https://blog.onecai.site/2026/08/01/062-system-prompt-bloat-cache-cost/","summary":"\u003cblockquote\u003e\n\u003cp\u003e前两篇分别拆了缓存怎么算钱（《同一份材料，为什么第二次交给AI只收1/10？缓存计费拆解》）和这笔钱到底省在哪张显存上（《KV Cache：每读1个token，就要交一笔“显存税”》）。这一篇把两条线合到一起——问题往往不出在缓存机制本身，而出在你喂给缓存的那份提示词，正在悄悄变胖。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一系统提示词正在膨胀\"\u003e一、系统提示词正在膨胀\u003c/h2\u003e\n\u003cp\u003e很多团队的系统提示词，都是这样长起来的。\u003c/p\u003e\n\u003cp\u003e一开始可能只有一句话：你是一个专业助手，请按用户要求完成任务。后来慢慢补角色设定、输出格式、禁用事项、工具说明、异常处理、合规边界、历史经验、项目背景、风格要求。半年下来，这句话变成了一份几千字的说明书。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"system-prompt-bloat-cache-cost-1.avif\"\n          alt=\"系统提示词是怎么变胖的\"/\u003e \u003cfigcaption\u003e\n             系统提示词是怎么变胖的\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e看起来很专业，像是把模型管住了。问题是，这些字每一轮都要进上下文，每一轮都可能被计费，每一轮也都可能影响缓存命中。\u003c/p\u003e\n\u003cp\u003e这不是错觉，而且不是哪一家的孤例。\u003c/p\u003e\n\u003cp\u003eAnthropic在2026年4月30日发过一篇官方博客《Lessons from building Claude Code: Prompt caching is everything》，作者Thariq Shihipar是Claude Code团队成员。他复盘了几个具体翻车案例：曾经把一个很详细的时间戳放进静态系统提示词，曾经让工具定义的排序变得不稳定，还改过工具参数（比如Agent工具可以调用哪些子Agent）——这些看似很小的改动，都破坏过缓存。这条材料很硬，因为不是外部用户猜测，而是做Claude Code的人自己说的。\u003c/p\u003e\n\u003cp\u003e用户侧也能看到类似现象。\u003ccode\u003eanthropics/claude-code\u003c/code\u003e的一个GitHub issue（#45188）里，有用户报告Claude Code在2.1.89到2.1.96版本之间，首次缓存创建量从约38-52K token涨到112-119K token，5天左右涨了约7万token。作者说这让可用上下文明显变小，多步任务还没跑完就要频繁手动\u003ccode\u003e/compact\u003c/code\u003e。他还做过排除法：关掉自定义hook、拔掉候选MCP、删掉过期插件，重新测量体积都没变——说明这次膨胀来自版本本身的迭代。这是一条用户实测个案，不是Anthropic官方确认的数字，引用时需要标清楚。\u003c/p\u003e\n\u003cp\u003eOpenAI Codex的用户也报告过类似现象（issue #19212）：只问一句“2+2等于几”，就消耗了约1.3万token。他让Codex自己估算这些开销来自哪里，得到的拆解是：系统指令、网页浏览策略、编码风格开发指令、工具schema、以及AGENTS.md和环境上下文。这同样是用户观察，不是官方统计，但说明一件事：Agent类产品的系统开销，很大一部分发生在用户输入第一个字之前。\u003c/p\u003e\n\u003cp\u003e这不是单一厂商的问题，而是Agent工作流的共同代价。OpenRouter联合a16z在2025年12月发布的实证研究《State of AI: An Empirical 100 Trillion Token Study with OpenRouter》（Aubakirova等人，arXiv:2601.10088）分析了平台上超过100万亿token的真实调用数据，其中一个发现是：平均提示词长度从约1,500token涨到超过6,000token，涨幅接近4倍，驱动因素是工具调用和多步推理这类智能体工作流的兴起。这条数据来自OpenRouter平台的真实流量，是一手实证研究，但样本边界是“OpenRouter平台”，不代表全行业所有调用场景，引用时应保留这个限定。\u003c/p\u003e\n\u003cp\u003e膨胀本身不一定是错误。真正的问题是，很多膨胀不是因为任务变复杂了，而是因为大家习惯把所有东西都塞进同一份不断变化的系统提示词里。\u003c/p\u003e\n\u003ch2 id=\"二膨胀为什么会拖累缓存\"\u003e二、膨胀为什么会拖累缓存\u003c/h2\u003e\n\u003cp\u003e要理解膨胀为什么烧钱，得先理解Prompt Caching到底在缓存什么。\u003c/p\u003e\n\u003cp\u003eClaude官方文档写得很清楚：缓存层级是tools→system→messages，某一层发生变化，这一层以及它后面的所有层都会一起失效。也就是说，工具定义一变，系统提示词和后面的对话历史都可能要重算；系统提示词一变，后面的对话历史缓存也会被连带打掉。\u003c/p\u003e\n\u003cp\u003e缓存不认“差不多一样”，只认前缀是否逐字节一致。前面动一个地方，后面内容再长也要重新处理一遍。这时候，系统提示词越胖，一次失效的代价就越大：如果你把当前时间、随机trace、用户ID这类临时信息塞进了本该稳定的前缀里，这个前缀每一轮都不一样，缓存自然吃不到，模型还要反复处理这段越来越胖的上下文。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"system-prompt-bloat-cache-cost-2.avif\"\n          alt=\"Prompt Caching 只认稳定前缀\"/\u003e \u003cfigcaption\u003e\n             Prompt Caching 只认稳定前缀\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e更麻烦的是，缓存写入本身也不是免费的，而且这件事正在变得更贵。Anthropic的写入计费是：5分钟有效期收标准输入价的1.25倍，1小时有效期收2倍，只有命中读取才是0.1倍。而OpenAI在2026年7月9日GA的GPT-5.6系列上，第一次对缓存写入收费——同样是标准输入价的1.25倍，最短缓存生命周期30分钟。更准确地说，OpenAI在GPT-5.6系列开始把缓存写入单独计价；Anthropic侧则早已把5分钟写入、1小时写入和缓存读取分成不同倍率。两边的共同信号是：缓存失效不再只是性能问题，而是可以在账单字段里被直接看见的成本问题。\u003c/p\u003e\n\u003cp\u003e膨胀还会拖慢响应。前一篇《KV Cache》讲过，模型处理请求分Prefill和Decode两个阶段：Prefill阶段要把完整输入过一遍、把每个token的K和V算出来存好，这一步耗时随输入长度增长；命中缓存时，这一整段Prefill会被直接跳过。NVIDIA NIM的官方基准测试文档里也确认了同一个规律：提示词越长，首字延迟（TTFT）通常越高，因为注意力机制要先处理完整输入、建立好KV缓存，才能开始生成第一个token。用户看到第一个字之前，模型已经先读了一大堆前文——这笔延迟账，跟token计费账是并行发生的两笔账。\u003c/p\u003e\n\u003cp\u003e一个量级参照：Claude Code官方博客提到，一次100轮的Opus长会话，不靠缓存要花50-100美元输入token费用，靠缓存能压到10-19美元，差距接近5倍。这个量级基本就是“膨胀又频繁失效”和“精简且稳定命中”之间的现实落差。\u003c/p\u003e\n\u003cp\u003e长上下文还有一重更隐蔽的代价：不一定让模型变聪明。Chroma Research 2025年7月发布的论文《Context Rot: How Increasing Input Tokens Impacts LLM Performance》测试了18个主流模型（含GPT-4.1、Claude 4、Gemini 2.5、Qwen3等），发现即便是很简单的任务，模型表现也会随输入变长而下降，而且这种下降不均匀、因模型而异，跟“待检索信息在上下文里的位置”“是否存在语义相似的干扰内容”这些因素都有关系。换句话说，“模型看得到”和“模型能稳定用好”不是一回事——这也是很多Agent跑到后半程会变得犹豫、绕路、反复确认的原因之一：上下文还在，有效上下文已经被稀释了。\u003c/p\u003e\n\u003ch2 id=\"三怎么写缓存友好的提示词\"\u003e三、怎么写“缓存友好”的提示词\u003c/h2\u003e\n\u003cp\u003e原理和坑都清楚了，落地按优先级排。\u003c/p\u003e","title":"提示词越写越长，是在帮AI还是在烧钱？"},{"content":"你可能遇到过这种情况：让一个Agent改个bug、整理一份竞品资料，或者帮你写一篇文章。你只发了一句话，等账单出来，却发现费用比想象中高很多。\n这通常不是平台多算。你看到的“一句话”，在后台已经变成了几十次模型调用。Agent要先理解任务，再查资料、读文件、调工具、看结果；发现不对，还要回头改；改完再跑一遍验证，最后才把结果总结给你。你发出去的是一句话，它执行的是一串来回。\n更麻烦的是，Agent自己也很难提前估准这次任务会花多少钱。密歇根大学、斯坦福大学等团队做过一个实验：让Agent动手前先估算自己接下来会用多少token。结果不管换哪个模型，估出来的数字普遍低于实际消耗，预测值和真实值的相关性最高也只有0.39。这笔账连模型自己都很难算准。\n这篇文章想讲清楚三件事：Agent的token到底花在哪，为什么它天然比普通对话贵得多，以及一条真实Agent任务的账单拆开后长什么样。\n一、先看懂账单里的四个科目 一次API调用里的四类Token 在讲Agent为什么贵之前，先把账单里的几个科目认清楚。不管是OpenAI还是Anthropic，API返回的用量数据里，token通常会拆成几类：\ninput tokens：你喂给模型的上下文，包括系统提示词、历史对话、工具返回内容 output tokens：模型生成出来的内容 reasoning tokens：部分模型在回答前用于内部推理的token，你看不到内容，但通常按输出token计费 cached tokens：命中缓存的重复上下文，单价比普通input低 这些都会出现在每次API调用返回的usage元数据里，是追踪用量和拆账的基本单位。\n有个细节很容易被忽略：只要请求里带了tools参数，账单的起点就已经变了。费用不一定等到工具真正调用之后才发生，工具定义本身就会进入请求上下文。哪怕这一轮模型最后没有调用任何工具，这部分内容也可能已经算进input。\nAnthropic文档里有个很直观的例子。Claude Sonnet 5只要请求里传了tools，就会多出一段tool use system prompt。如果tool_choice是auto或none，这段是354个token；如果是any或tool，也就是强制模型调用工具，这段会变成474个token。这类费用写在官方文档里，只是很多人在估Agent成本时不会把它算进去。\n二、Agent贵在反复读上下文 Agent比普通对话贵，核心原因是它常用的ReAct模式，也就是思考、行动、观察循环。这个循环有个很要命的特点：每一轮都要把前面的历史重新塞回上下文。上一轮的推理过程、工具调用记录、工具返回结果，都会跟着进入下一轮输入。\n拆开看，大概是这样：\n规划阶段，模型要读任务描述、约束条件和项目背景，先判断从哪里下手。这一步还没真正动工具，但已经开始产出推理和计划。\n工具调用阶段，工具定义、调用参数、执行结果都会进入上下文。工具返回的内容不是读完就结束，它会变成下一轮input的一部分。\n反思和重试阶段，失败日志、测试输出、之前试过的路径又会被喂回模型。排查越久，历史越厚，下一轮输入就越贵。\nAgent贵在反复读上下文 密歇根大学、斯坦福大学等团队基于OpenHands框架，跑了SWE-bench Verified里的真实编程任务。实验覆盖8个前沿模型、500个任务，每个任务独立跑4次。结果很夸张：Agentic Coding任务平均消耗约417万token，是单轮代码推理任务的约3500倍，是多轮代码聊天任务的约1200倍。输入输出token比例达到153.85，也就是模型每生成1个输出token，平均要读153个输入token。普通多轮代码聊天的这个比例只有1.33。\nAgent贵，主要贵在模型读得多。历史上下文越滚越厚，账单里最大的一块也跟着越滚越大。\n如果再叠上Plan-and-Solve这类架构，成本还会继续放大。它会先生成一份多步计划，再逐步执行每个子任务；而每个子任务里，又可能各自跑一轮完整的ReAct循环。看起来只是任务拆得更清楚了，账单上却可能变成循环套循环。\n三、一条真实轨迹里，钱花在了哪几轮 说“Agent会滚账单”还不够，直接看一条真实轨迹更清楚。\n还是上面那篇研究，里面公开了一条任务轨迹：任务编号astropy-7336，用Claude Sonnet 4.5跑，一共31轮才完成。研究者把整条轨迹按功能分成五个阶段：\n阶段 对应的工作 占总轮次 Setup（规划） 任务理解、环境初始化、复现问题 9.98% Explore（检索） 代码搜索、文件检查、根因分析 30.37% Fix（执行/反思） 代码修改、调试迭代、补丁完善 33.53% Validate（校验） 测试、回归检查 16.59% Closeout（总结） 最终检查、清理、总结输出 9.53% 一条Agent任务的31轮账单轨迹 Explore和Fix加起来接近三分之二。也就是我们平时感觉最耗时间的“查文件”和“改了又改”，确实也是Agent最容易消耗轮次的地方。\n再往细看，每一轮的成本主因会来回切换。第1轮主要贵在输出token，因为模型在做初始规划；第10轮主要贵在未缓存输入token，因为它在读测试文件、创建复现脚本；第17轮又变成输出token为主，因为模型在写调试脚本；第23轮和第28轮再次由未缓存输入主导，用在跑测试、清理临时文件；最后第31轮主要是输出token，用来生成总结。\n单轮看，输入和输出会交替成为成本大头。拉长看，输入token，尤其是反复带入的历史，才是总账单里最重的部分。即便很多历史命中了缓存，单价已经便宜很多，量一旦大到一定程度，便宜的input照样会超过高单价但数量少的output。\n下面这张表可以直接拿去套自己的Agent任务。如果手头有真实usage日志或trace数据，就把数字填进去；如果暂时没有实测数据，也可以先用公开定价做模拟账，但一定要标清楚是模拟，不要写成实测。\n阶段 模型回合 工具调用 主要Token来源 容易滚账单的原因 规划 1-2 0 任务、系统提示、项目约束 一开始就带全量规则 检索 5-10 10-30 文件内容、搜索结果、工具返回 工具结果进入下一轮上下文 执行 3-8 5-20 patch、命令输出、错误日志 每次失败都会增加历史负担 反思 2-6 0-5 失败路径、测试输出、候选方案 模型会带着前面的错误继续判断 总结 1-2 0 全部变更和验证结果 输出不多，但输入已经很厚 模型档位也会明显影响同一条轨迹的账单。OpenAI在2026年6月预览、7月正式开放的GPT-5.6系列就是一个例子：Sol每百万token输入5美元、输出30美元；Terra输入2.5美元、输出15美元；Luna输入1美元、输出6美元。同样的token轨迹套进去，最贵和最便宜相差5倍。\n所以在Agent场景里，比较务实的做法是把强模型用在规划、关键判断和最终验收上，把检索、摘要、格式转换这类任务交给便宜模型。只找低单价模型不够，更稳的做法是让不同阶段用不同档位的模型。\n四、成本经常不是线性增长 很多人会以为，某一步失败了，大不了多花一轮调用的钱。实际不是这样。\n第一次失败带来的不只是一次额外调用，还会把错误日志、已经试过的路径、更多上下文一起带进下一轮。Agent越认真排查问题，历史就越厚，下一轮输入就越贵。很多时候，最贵的不是生成答案，而是带着越来越厚的历史反复判断。\n那篇研究还发现一个挺关键的现象：token花得越多，任务不一定做得越好。准确率往往在中等花费的run上达到峰值，再继续增加花费，准确率反而下降或停滞。研究者进一步看了高花费轨迹，发现里面重复读同一个文件、重复改同一处代码的比例更高。\n这说明一部分高成本不是深度思考，而是原地打转。多跑一轮，未必就多一点进展。\n五、循环没有刹车，账单会很难看 没有刹车的Agent循环 原地打转听起来只是效率问题，但如果没有上限，它会直接变成费用事故。\n2026年5月20日的阿里云峰会上，米哈游《崩坏》系列AINPC\u0026amp;Gameplay技术团队负责人郑银河分享过一个案例：团队里一位工程师为了测试多智能体协作，周末搭了几十个Agent，没设token消耗上限就下班了。结果这些Agent陷入循环调用，几十个Agent互相等待对方输出，又互相触发下一轮调用，连续跑了13个小时，烧掉了价值200万元人民币的token。郑银河当时的说法是，如果换成独立游戏团队，这一晚上可能就撑不住了。\n海外也有类似案例。OpenClaw创始人Peter Steinberger公开过自己的账单：3人团队指挥约100个Codex智能体，30天内消耗6030亿token，发起760万次请求，OpenAI账单达到130万美元，约合人民币930万元。\n这两个案例的问题不只是模型单价高，而是循环没有边界。没有最大回合数，没有token预算上限，也没有失败后停下来重新评估的机制。Agent能力越强，这类边界就越重要。\n六、怎么把账单压下来 知道账单怎么滚起来，控制成本就不能只盯着“换便宜模型”。下面几件事更值得优先做：\n不要全流程都用最贵模型。规划和最终判断用强模型，分类、摘要、格式转换这类任务用便宜模型。 限制工具返回内容长度，不要把完整日志、整份文件、整页搜索结果都塞进下一轮上下文。 给Agent设置最大回合数和token预算，不要让它自己无限判断“还要不要继续”。 长资料先压缩成可引用摘要，再按需要回看原文。 把稳定不变的系统提示词和项目背景做成缓存，别在每轮都按全价重读。 失败之后，先让Agent用一句话说明下一步要验证什么，再决定要不要继续执行。 如果你用OpenAI Agents SDK、LangSmith这类工具搭Agent，拆账不用完全手工做。OpenAI Agents SDK的trace会记录一次Agent运行里的LLM生成、工具调用、agent handoff和guardrail检查；LangSmith会把成本拆成input、output、other几类，other里可以放工具调用、检索步骤和自定义成本。跑一次trace，基本就能看到钱花在哪。\n写在最后 回到开头那个问题：为什么你只问了一句，账单却滚起来了？\n因为单次模型调用价格只是单价。Agent成本主要看回合数、上下文厚度、工具结果长度和失败重试次数。同一个模型、同样的任务，账单可以因为这几个变量差出几十倍，甚至更多。\n所以看Agent价格，不能只看每百万token多少钱。更要看它会跑多少轮、每轮带多少上下文、失败后有没有停下来的机制。\n控制Agent成本，最后还是要管住循环本身。\n本文数据核对自：Anthropic Claude Platform官方文档（tool use pricing表，2026年7月）、arXiv 2604.22750（密歇根大学/斯坦福大学等，SWE-bench Verified实测研究）、OpenAI官方GPT-5.6发布页（2026年6月预览、7月正式开放）、LangSmith官方cost tracking文档、OpenAI Agents SDK官方tracing文档、米哈游技术负责人郑银河2026年5月20日阿里云峰会公开分享、OpenClaw创始人Peter Steinberger公开账单\n","permalink":"https://blog.onecai.site/2026/07/31/061-agent-token-billing/","summary":"\u003cp\u003e你可能遇到过这种情况：让一个Agent改个bug、整理一份竞品资料，或者帮你写一篇文章。你只发了一句话，等账单出来，却发现费用比想象中高很多。\u003c/p\u003e\n\u003cp\u003e这通常不是平台多算。你看到的“一句话”，在后台已经变成了几十次模型调用。Agent要先理解任务，再查资料、读文件、调工具、看结果；发现不对，还要回头改；改完再跑一遍验证，最后才把结果总结给你。你发出去的是一句话，它执行的是一串来回。\u003c/p\u003e\n\u003cp\u003e更麻烦的是，Agent自己也很难提前估准这次任务会花多少钱。密歇根大学、斯坦福大学等团队做过一个实验：让Agent动手前先估算自己接下来会用多少token。结果不管换哪个模型，估出来的数字普遍低于实际消耗，预测值和真实值的相关性最高也只有0.39。这笔账连模型自己都很难算准。\u003c/p\u003e\n\u003cp\u003e这篇文章想讲清楚三件事：Agent的token到底花在哪，为什么它天然比普通对话贵得多，以及一条真实Agent任务的账单拆开后长什么样。\u003c/p\u003e\n\u003ch2 id=\"一先看懂账单里的四个科目\"\u003e一、先看懂账单里的四个科目\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"agent-token-billing-1.avif\"\n          alt=\"一次API调用里的四类Token\"/\u003e \u003cfigcaption\u003e\n             一次API调用里的四类Token\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e在讲Agent为什么贵之前，先把账单里的几个科目认清楚。不管是OpenAI还是Anthropic，API返回的用量数据里，token通常会拆成几类：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003einput tokens\u003c/strong\u003e：你喂给模型的上下文，包括系统提示词、历史对话、工具返回内容\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eoutput tokens\u003c/strong\u003e：模型生成出来的内容\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ereasoning tokens\u003c/strong\u003e：部分模型在回答前用于内部推理的token，你看不到内容，但通常按输出token计费\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ecached tokens\u003c/strong\u003e：命中缓存的重复上下文，单价比普通input低\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这些都会出现在每次API调用返回的usage元数据里，是追踪用量和拆账的基本单位。\u003c/p\u003e\n\u003cp\u003e有个细节很容易被忽略：只要请求里带了tools参数，账单的起点就已经变了。费用不一定等到工具真正调用之后才发生，工具定义本身就会进入请求上下文。哪怕这一轮模型最后没有调用任何工具，这部分内容也可能已经算进input。\u003c/p\u003e\n\u003cp\u003eAnthropic文档里有个很直观的例子。Claude Sonnet 5只要请求里传了tools，就会多出一段tool use system prompt。如果tool_choice是\u003ccode\u003eauto\u003c/code\u003e或\u003ccode\u003enone\u003c/code\u003e，这段是354个token；如果是\u003ccode\u003eany\u003c/code\u003e或\u003ccode\u003etool\u003c/code\u003e，也就是强制模型调用工具，这段会变成474个token。这类费用写在官方文档里，只是很多人在估Agent成本时不会把它算进去。\u003c/p\u003e\n\u003ch2 id=\"二agent贵在反复读上下文\"\u003e二、Agent贵在反复读上下文\u003c/h2\u003e\n\u003cp\u003eAgent比普通对话贵，核心原因是它常用的ReAct模式，也就是思考、行动、观察循环。这个循环有个很要命的特点：每一轮都要把前面的历史重新塞回上下文。上一轮的推理过程、工具调用记录、工具返回结果，都会跟着进入下一轮输入。\u003c/p\u003e\n\u003cp\u003e拆开看，大概是这样：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e规划阶段\u003c/strong\u003e，模型要读任务描述、约束条件和项目背景，先判断从哪里下手。这一步还没真正动工具，但已经开始产出推理和计划。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e工具调用阶段\u003c/strong\u003e，工具定义、调用参数、执行结果都会进入上下文。工具返回的内容不是读完就结束，它会变成下一轮input的一部分。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e反思和重试阶段\u003c/strong\u003e，失败日志、测试输出、之前试过的路径又会被喂回模型。排查越久，历史越厚，下一轮输入就越贵。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"agent-token-billing-2.avif\"\n          alt=\"Agent贵在反复读上下文\"/\u003e \u003cfigcaption\u003e\n             Agent贵在反复读上下文\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e密歇根大学、斯坦福大学等团队基于OpenHands框架，跑了SWE-bench Verified里的真实编程任务。实验覆盖8个前沿模型、500个任务，每个任务独立跑4次。结果很夸张：Agentic Coding任务平均消耗约417万token，是单轮代码推理任务的约3500倍，是多轮代码聊天任务的约1200倍。输入输出token比例达到153.85，也就是模型每生成1个输出token，平均要读153个输入token。普通多轮代码聊天的这个比例只有1.33。\u003c/p\u003e\n\u003cp\u003eAgent贵，主要贵在模型读得多。历史上下文越滚越厚，账单里最大的一块也跟着越滚越大。\u003c/p\u003e\n\u003cp\u003e如果再叠上Plan-and-Solve这类架构，成本还会继续放大。它会先生成一份多步计划，再逐步执行每个子任务；而每个子任务里，又可能各自跑一轮完整的ReAct循环。看起来只是任务拆得更清楚了，账单上却可能变成循环套循环。\u003c/p\u003e\n\u003ch2 id=\"三一条真实轨迹里钱花在了哪几轮\"\u003e三、一条真实轨迹里，钱花在了哪几轮\u003c/h2\u003e\n\u003cp\u003e说“Agent会滚账单”还不够，直接看一条真实轨迹更清楚。\u003c/p\u003e\n\u003cp\u003e还是上面那篇研究，里面公开了一条任务轨迹：任务编号\u003ccode\u003eastropy-7336\u003c/code\u003e，用Claude Sonnet 4.5跑，一共31轮才完成。研究者把整条轨迹按功能分成五个阶段：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e阶段\u003c/th\u003e\n          \u003cth\u003e对应的工作\u003c/th\u003e\n          \u003cth\u003e占总轮次\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eSetup（规划）\u003c/td\u003e\n          \u003ctd\u003e任务理解、环境初始化、复现问题\u003c/td\u003e\n          \u003ctd\u003e9.98%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eExplore（检索）\u003c/td\u003e\n          \u003ctd\u003e代码搜索、文件检查、根因分析\u003c/td\u003e\n          \u003ctd\u003e30.37%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFix（执行/反思）\u003c/td\u003e\n          \u003ctd\u003e代码修改、调试迭代、补丁完善\u003c/td\u003e\n          \u003ctd\u003e33.53%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eValidate（校验）\u003c/td\u003e\n          \u003ctd\u003e测试、回归检查\u003c/td\u003e\n          \u003ctd\u003e16.59%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eCloseout（总结）\u003c/td\u003e\n          \u003ctd\u003e最终检查、清理、总结输出\u003c/td\u003e\n          \u003ctd\u003e9.53%\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"agent-token-billing-3.avif\"\n          alt=\"一条Agent任务的31轮账单轨迹\"/\u003e \u003cfigcaption\u003e\n             一条Agent任务的31轮账单轨迹\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eExplore和Fix加起来接近三分之二。也就是我们平时感觉最耗时间的“查文件”和“改了又改”，确实也是Agent最容易消耗轮次的地方。\u003c/p\u003e\n\u003cp\u003e再往细看，每一轮的成本主因会来回切换。第1轮主要贵在输出token，因为模型在做初始规划；第10轮主要贵在未缓存输入token，因为它在读测试文件、创建复现脚本；第17轮又变成输出token为主，因为模型在写调试脚本；第23轮和第28轮再次由未缓存输入主导，用在跑测试、清理临时文件；最后第31轮主要是输出token，用来生成总结。\u003c/p\u003e\n\u003cp\u003e单轮看，输入和输出会交替成为成本大头。拉长看，输入token，尤其是反复带入的历史，才是总账单里最重的部分。即便很多历史命中了缓存，单价已经便宜很多，量一旦大到一定程度，便宜的input照样会超过高单价但数量少的output。\u003c/p\u003e\n\u003cp\u003e下面这张表可以直接拿去套自己的Agent任务。如果手头有真实usage日志或trace数据，就把数字填进去；如果暂时没有实测数据，也可以先用公开定价做模拟账，但一定要标清楚是模拟，不要写成实测。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e阶段\u003c/th\u003e\n          \u003cth\u003e模型回合\u003c/th\u003e\n          \u003cth\u003e工具调用\u003c/th\u003e\n          \u003cth\u003e主要Token来源\u003c/th\u003e\n          \u003cth\u003e容易滚账单的原因\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e规划\u003c/td\u003e\n          \u003ctd\u003e1-2\u003c/td\u003e\n          \u003ctd\u003e0\u003c/td\u003e\n          \u003ctd\u003e任务、系统提示、项目约束\u003c/td\u003e\n          \u003ctd\u003e一开始就带全量规则\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e检索\u003c/td\u003e\n          \u003ctd\u003e5-10\u003c/td\u003e\n          \u003ctd\u003e10-30\u003c/td\u003e\n          \u003ctd\u003e文件内容、搜索结果、工具返回\u003c/td\u003e\n          \u003ctd\u003e工具结果进入下一轮上下文\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e执行\u003c/td\u003e\n          \u003ctd\u003e3-8\u003c/td\u003e\n          \u003ctd\u003e5-20\u003c/td\u003e\n          \u003ctd\u003epatch、命令输出、错误日志\u003c/td\u003e\n          \u003ctd\u003e每次失败都会增加历史负担\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e反思\u003c/td\u003e\n          \u003ctd\u003e2-6\u003c/td\u003e\n          \u003ctd\u003e0-5\u003c/td\u003e\n          \u003ctd\u003e失败路径、测试输出、候选方案\u003c/td\u003e\n          \u003ctd\u003e模型会带着前面的错误继续判断\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e总结\u003c/td\u003e\n          \u003ctd\u003e1-2\u003c/td\u003e\n          \u003ctd\u003e0\u003c/td\u003e\n          \u003ctd\u003e全部变更和验证结果\u003c/td\u003e\n          \u003ctd\u003e输出不多，但输入已经很厚\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e模型档位也会明显影响同一条轨迹的账单。OpenAI在2026年6月预览、7月正式开放的GPT-5.6系列就是一个例子：Sol每百万token输入5美元、输出30美元；Terra输入2.5美元、输出15美元；Luna输入1美元、输出6美元。同样的token轨迹套进去，最贵和最便宜相差5倍。\u003c/p\u003e","title":"Agent一次任务要调用几十次模型，账单是怎么滚起来的？"},{"content":" 数据核对时间：2026年7月下旬。文中标注“网络测算”的数字均非官方数据，仅供方向参考；具体以各厂商官方文档为准。\n你可能也遇到过这种情况：豆包平时用得好好的，某天突然弹出一句“今日额度已用完”。你没觉得自己做了什么特别重的操作，但服务就是停在这里了。\n免费额度看起来像一个产品规则，其实背后是一笔账。厂商每天都在算：一个免费用户最多可以消耗多少算力？这些消耗能不能被转化、数据、生态位或者广告收入补回来？一旦这笔账变了，额度就会跟着变。\n这篇文章聊的就是这件事：AI工具的免费额度到底是怎么算出来的，为什么有时会突然收紧。\n一、免费额度先看成本账 免费额度是一笔账 免费不是厂商一拍脑袋决定的。更接近真实情况的算法，大概是这样：\n免费额度上限 ≈ 厂商愿意为每个免费用户承担的成本上限 = 这个用户能带来的预期回报（数据反哺、转化概率、生态位、广告收入）− 服务这个用户的边际成本\n右边任何一个变量变了，左边的免费额度就会被重新算一遍。所以免费额度很少是一个永远不动的承诺，它更像一个会随成本和商业压力调整的预算线。\n这个成本也不轻。网络上有过一组针对豆包的粗略测算，口径不是官方数据，只能看方向：假设日活用户500万，其中30%的人每天用5次生成、转写、解析这类核心功能，日均调用量就是750万次。只算这几类基础操作，硬件成本每天就可能到六位数。这里还没把模型训练、内容安全审核、峰值并发预留的冗余算力算进去。\n所以，免费不是技术天然带来的结果，更多时候是厂商用资本、生态位或者增长目标换来的让利。融资节奏变慢、算力成本变高、商业化压力上来，免费额度就很难一直按原来的尺度给。\n二、厂商不会告诉你花了多少钱，只会改规则 厂商不会在页面上写“你今天最多只能消耗X元算力”。它会把这笔预算翻译成几种你能感知到的产品规则：几点重置、还能问多少次、还能不能用最强模型。\n第一种，是时间窗口。Claude免费版和Pro版都不简单按“每天0点重置”来算，而是用滚动的5小时窗口，再叠加每周总量。规则看起来复杂，目的其实很直接：把用户请求摊到全天，避免大家卡在同一个重置点一起涌进来。\n第二种，是按模型分层给次数。Gemini走的是这条路。综合多个独立开发者社区对Google官方限额页面的追踪，口径有差异，但方向一致：轻量级的Flash系列免费额度比较宽，可能到每天1500次请求；旗舰级的Pro系列就收得很紧，每天可能只有50次左右，每分钟请求数也被压到个位数。同样叫免费版，背后用的算力并不是同一档，越贵的模型，免费额度越少。\n第三种，是模型降级。很多人以为免费层只是“同一个模型，少给几次机会”，实际更常见的是限次再加降级。你仍然在同一个入口提问，但系统可能已经把你切到更便宜的模型、更低的推理深度，或者更弱的功能组合上。ChatGPT免费版就是类似逻辑：消息数、文件上传、图像生成分别计数，默认模型和推理能力也会受限，免费用户很难稳定使用最强推理模式。\n机制 代表产品 逻辑 滚动时间窗口 Claude免费版（5小时+每周） 平滑并发，不按自然日重置 按模型分层的固定次数 Gemini（Flash系列约1500次/天，Pro系列约50次/天） 越贵的模型，免费额度收得越紧 消息数/功能项独立计数+模型降级 ChatGPT免费版 各项功能分别限额，且默认模型和推理深度打了折扣 还有一层更隐蔽：厂商会把功能拆到免费墙和付费墙两侧，而不是简单地对整个产品收费。以豆包为例，免费层保留了大量高频但单次价值密度不高的功能，比如日常聊天、简单文案；长文档精读、批量视频生成、深度数据分析这类明显提高单次产出质量、也更耗资源的功能，则更容易被放进付费区。\n免费额度的三种产品化方式 轻度用户每天聊几句、改几段文字，基本感受不到这堵墙。会撞上它的，通常是消耗远高于平均值的重度用户。\n三、豆包为什么走到收费这一步 回头看豆包的调整，它不是一次孤立的商业新闻，更像是免费额度这笔账算到某个阶段后的结果。\n多方媒体报道显示，2026年5月4日，字节跳动旗下豆包在苹果App Store上线三档付费方案：标准版68元/月、加强版200元/月、专业版500元/月。官方口径是“基础功能永久免费+高阶增值付费”，日常聊天、简单文案、简单翻译等核心功能承诺永久免费且不限次。\n这个消息之所以引发讨论，不只是因为豆包开始收费，而是用户马上会担心：免费版会不会变慢？会不会排队？会不会把好模型藏起来？官方没有宣布免费额度缩水，但用户的反应说明了一件事，额度收紧很多时候不会写在公告里，而是慢慢体现在体验上。\n第一，用户规模已经大到不能忽略成本。据QuestMobile数据，2026年第一季度豆包月活跃用户约3.45亿。到了这个体量，单个免费用户哪怕只多消耗几分钱，乘起来也是很大的成本。\n豆包收费背后的三股压力 第二，上游成本也在变贵。2026年5月9日起，腾讯云宣布AI算力相关产品价格上调5%；阿里云部分产品价格出现上调，公开报道中的最高涨幅达到34%；智谱AI相关订阅和API价格也在年内多次调整，2月GLM Coding Plan提价超过30%，3月GLM-5-Turbo API价格上调20%，4月GLM-5.1继续提价10%。\n智谱这几次调价可以单独看一下。假如是在同一条产品线上连续上调，复合涨幅会是：\n1 1.30 × 1.20 × 1.10 ≈ 1.716 这意味着同一产品连续涨三次，理论累计涨幅会接近72%。但这里要把边界说清楚：这三次提价分别对应GLM Coding Plan、GLM-5-Turbo API、GLM-5.1，不是同一个SKU连续涨价，所以不能直接写成“同一件商品涨了72%”。更稳的说法是，这几次调价方向一致、间隔很近，反映出2026年上半年模型服务成本在收紧。\n第三，收费也是一种用户分层。豆包3.45亿月活里，大量消耗算力的深度用户只占一小部分，但他们的token消耗会远高于平均水平。三档定价的作用，就是把这部分重度用户筛出来，让高消耗和付费对应起来。绝大多数轻度用户每天聊几句、翻译几段文字，可能几乎感觉不到变化。\n免费额度收紧最常见的样子，大多不是全面砍掉免费版，而是先卡高消耗场景。ChatGPT从免费版到Go、Plus、Pro多档分层，背后也是同一条路，轻度用户尽量留住，重度用户自然进入付费层。\n写在最后 免费额度很难看成厂商的长期承诺，它更像一套会被反复重算的成本模型。算力成本涨了，用户规模大了，变现压力来了，任何一个变量变化，额度都会被重新评估。\n只不过这个过程通常不会直接告诉你。它更多会变成限速、排队、次数减少、模型降级，最后落到你的使用体验里。\n所以下次再看到一款AI工具说自己完全免费，可以换个角度看：它的用户增长和算力成本是不是越拉越开。两条曲线背离得越明显，免费额度被收紧的可能性就越高。\n数据与资料来源 以下链接为本文用到的公开资料。官方文档优先；涉及豆包付费、QuestMobile数据、阿里云和智谱调价的部分，部分来源为媒体报道或第三方测算。\nAnthropic Claude Pro用量说明：https://support.claude.com/en/articles/8325606-what-is-the-pro-plan Claude官网价格页与用量限制说明：https://claude.com/pricing Google Gemini API速率限制说明：https://ai.google.dev/gemini-api/docs/rate-limits OpenAI ChatGPT Free Tier FAQ：https://help.openai.com/en/articles/9275245-chatgpt-free-tier-faq OpenAI ChatGPT Go说明：https://help.openai.com/en/articles/11989085-what-is-chatgpt-go 豆包App Store页面：https://apps.apple.com/cn/app/%E8%B1%86%E5%8C%85-%E9%9A%8F%E6%97%B6%E5%B8%AE%E5%BF%99%E7%9A%84-ai-%E5%8A%A9%E6%89%8B/id6459478672 IT之家关于豆包三档付费订阅的报道：https://m.ithome.com/html/946236.htm QuestMobile2026年一季度AI应用洞察：https://www.questmobile.com.cn/research/report/2046482337382842370/ 腾讯云AI算力、容器服务、EMR相关产品价格调整公告：https://cloud.tencent.com/announce/detail/2254 阿里云AI算力和存储产品调价报道：https://finance.sina.com.cn/stock/relnews/2026-03-18/doc-inhrkskt7573252.shtml 智谱GLM Coding Plan价格调整报道：https://www.ithome.com/0/921/258.htm 21财经关于智谱2026年多轮调价的报道：https://m.21jingji.com/article/20260617/herald/cf85ded89035d5023752dc7d692669f6.html 智谱GLM Coding Plan套餐概览：https://docs.bigmodel.cn/cn/coding-plan/overview 豆包免费层成本测算参考，非官方数据：https://bbs.csdn.net/weixin_27064205/article/details/100174535 ","permalink":"https://blog.onecai.site/2026/07/30/060-free-tier-quota-logic/","summary":"\u003cblockquote\u003e\n\u003cp\u003e数据核对时间：2026年7月下旬。文中标注“网络测算”的数字均非官方数据，仅供方向参考；具体以各厂商官方文档为准。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e你可能也遇到过这种情况：豆包平时用得好好的，某天突然弹出一句“今日额度已用完”。你没觉得自己做了什么特别重的操作，但服务就是停在这里了。\u003c/p\u003e\n\u003cp\u003e免费额度看起来像一个产品规则，其实背后是一笔账。厂商每天都在算：一个免费用户最多可以消耗多少算力？这些消耗能不能被转化、数据、生态位或者广告收入补回来？一旦这笔账变了，额度就会跟着变。\u003c/p\u003e\n\u003cp\u003e这篇文章聊的就是这件事：AI工具的免费额度到底是怎么算出来的，为什么有时会突然收紧。\u003c/p\u003e\n\u003ch2 id=\"一免费额度先看成本账\"\u003e一、免费额度先看成本账\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"free-tier-quota-logic-1.avif\"\n          alt=\"免费额度是一笔账\"/\u003e \u003cfigcaption\u003e\n             免费额度是一笔账\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e免费不是厂商一拍脑袋决定的。更接近真实情况的算法，大概是这样：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e免费额度上限 ≈ 厂商愿意为每个免费用户承担的成本上限\n= 这个用户能带来的预期回报（数据反哺、转化概率、生态位、广告收入）− 服务这个用户的边际成本\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e右边任何一个变量变了，左边的免费额度就会被重新算一遍。所以免费额度很少是一个永远不动的承诺，它更像一个会随成本和商业压力调整的预算线。\u003c/p\u003e\n\u003cp\u003e这个成本也不轻。网络上有过一组针对豆包的粗略测算，口径不是官方数据，只能看方向：假设日活用户500万，其中30%的人每天用5次生成、转写、解析这类核心功能，日均调用量就是750万次。只算这几类基础操作，硬件成本每天就可能到六位数。这里还没把模型训练、内容安全审核、峰值并发预留的冗余算力算进去。\u003c/p\u003e\n\u003cp\u003e所以，免费不是技术天然带来的结果，更多时候是厂商用资本、生态位或者增长目标换来的让利。融资节奏变慢、算力成本变高、商业化压力上来，免费额度就很难一直按原来的尺度给。\u003c/p\u003e\n\u003ch2 id=\"二厂商不会告诉你花了多少钱只会改规则\"\u003e二、厂商不会告诉你花了多少钱，只会改规则\u003c/h2\u003e\n\u003cp\u003e厂商不会在页面上写“你今天最多只能消耗X元算力”。它会把这笔预算翻译成几种你能感知到的产品规则：几点重置、还能问多少次、还能不能用最强模型。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一种，是时间窗口\u003c/strong\u003e。Claude免费版和Pro版都不简单按“每天0点重置”来算，而是用滚动的5小时窗口，再叠加每周总量。规则看起来复杂，目的其实很直接：把用户请求摊到全天，避免大家卡在同一个重置点一起涌进来。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二种，是按模型分层给次数\u003c/strong\u003e。Gemini走的是这条路。综合多个独立开发者社区对Google官方限额页面的追踪，口径有差异，但方向一致：轻量级的Flash系列免费额度比较宽，可能到每天1500次请求；旗舰级的Pro系列就收得很紧，每天可能只有50次左右，每分钟请求数也被压到个位数。同样叫免费版，背后用的算力并不是同一档，越贵的模型，免费额度越少。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三种，是模型降级\u003c/strong\u003e。很多人以为免费层只是“同一个模型，少给几次机会”，实际更常见的是限次再加降级。你仍然在同一个入口提问，但系统可能已经把你切到更便宜的模型、更低的推理深度，或者更弱的功能组合上。ChatGPT免费版就是类似逻辑：消息数、文件上传、图像生成分别计数，默认模型和推理能力也会受限，免费用户很难稳定使用最强推理模式。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e机制\u003c/th\u003e\n          \u003cth\u003e代表产品\u003c/th\u003e\n          \u003cth\u003e逻辑\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e滚动时间窗口\u003c/td\u003e\n          \u003ctd\u003eClaude免费版（5小时+每周）\u003c/td\u003e\n          \u003ctd\u003e平滑并发，不按自然日重置\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e按模型分层的固定次数\u003c/td\u003e\n          \u003ctd\u003eGemini（Flash系列约1500次/天，Pro系列约50次/天）\u003c/td\u003e\n          \u003ctd\u003e越贵的模型，免费额度收得越紧\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e消息数/功能项独立计数+模型降级\u003c/td\u003e\n          \u003ctd\u003eChatGPT免费版\u003c/td\u003e\n          \u003ctd\u003e各项功能分别限额，且默认模型和推理深度打了折扣\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e还有一层更隐蔽：厂商会把功能拆到免费墙和付费墙两侧，而不是简单地对整个产品收费。以豆包为例，免费层保留了大量高频但单次价值密度不高的功能，比如日常聊天、简单文案；长文档精读、批量视频生成、深度数据分析这类明显提高单次产出质量、也更耗资源的功能，则更容易被放进付费区。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"free-tier-quota-logic-2.avif\"\n          alt=\"免费额度的三种产品化方式\"/\u003e \u003cfigcaption\u003e\n             免费额度的三种产品化方式\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e轻度用户每天聊几句、改几段文字，基本感受不到这堵墙。会撞上它的，通常是消耗远高于平均值的重度用户。\u003c/p\u003e\n\u003ch2 id=\"三豆包为什么走到收费这一步\"\u003e三、豆包为什么走到收费这一步\u003c/h2\u003e\n\u003cp\u003e回头看豆包的调整，它不是一次孤立的商业新闻，更像是免费额度这笔账算到某个阶段后的结果。\u003c/p\u003e\n\u003cp\u003e多方媒体报道显示，2026年5月4日，字节跳动旗下豆包在苹果App Store上线三档付费方案：标准版68元/月、加强版200元/月、专业版500元/月。官方口径是“基础功能永久免费+高阶增值付费”，日常聊天、简单文案、简单翻译等核心功能承诺永久免费且不限次。\u003c/p\u003e\n\u003cp\u003e这个消息之所以引发讨论，不只是因为豆包开始收费，而是用户马上会担心：免费版会不会变慢？会不会排队？会不会把好模型藏起来？官方没有宣布免费额度缩水，但用户的反应说明了一件事，额度收紧很多时候不会写在公告里，而是慢慢体现在体验上。\u003c/p\u003e\n\u003cp\u003e第一，用户规模已经大到不能忽略成本。据QuestMobile数据，2026年第一季度豆包月活跃用户约3.45亿。到了这个体量，单个免费用户哪怕只多消耗几分钱，乘起来也是很大的成本。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"free-tier-quota-logic-3.avif\"\n          alt=\"豆包收费背后的三股压力\"/\u003e \u003cfigcaption\u003e\n             豆包收费背后的三股压力\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e第二，上游成本也在变贵。2026年5月9日起，腾讯云宣布AI算力相关产品价格上调5%；阿里云部分产品价格出现上调，公开报道中的最高涨幅达到34%；智谱AI相关订阅和API价格也在年内多次调整，2月GLM Coding Plan提价超过30%，3月GLM-5-Turbo API价格上调20%，4月GLM-5.1继续提价10%。\u003c/p\u003e\n\u003cp\u003e智谱这几次调价可以单独看一下。假如是在同一条产品线上连续上调，复合涨幅会是：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1.30 × 1.20 × 1.10 ≈ 1.716\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e这意味着同一产品连续涨三次，理论累计涨幅会接近72%。但这里要把边界说清楚：这三次提价分别对应GLM Coding Plan、GLM-5-Turbo API、GLM-5.1，不是同一个SKU连续涨价，所以不能直接写成“同一件商品涨了72%”。更稳的说法是，这几次调价方向一致、间隔很近，反映出2026年上半年模型服务成本在收紧。\u003c/p\u003e\n\u003cp\u003e第三，收费也是一种用户分层。豆包3.45亿月活里，大量消耗算力的深度用户只占一小部分，但他们的token消耗会远高于平均水平。三档定价的作用，就是把这部分重度用户筛出来，让高消耗和付费对应起来。绝大多数轻度用户每天聊几句、翻译几段文字，可能几乎感觉不到变化。\u003c/p\u003e\n\u003cp\u003e免费额度收紧最常见的样子，大多不是全面砍掉免费版，而是先卡高消耗场景。ChatGPT从免费版到Go、Plus、Pro多档分层，背后也是同一条路，轻度用户尽量留住，重度用户自然进入付费层。\u003c/p\u003e\n\u003ch2 id=\"写在最后\"\u003e写在最后\u003c/h2\u003e\n\u003cp\u003e免费额度很难看成厂商的长期承诺，它更像一套会被反复重算的成本模型。算力成本涨了，用户规模大了，变现压力来了，任何一个变量变化，额度都会被重新评估。\u003c/p\u003e\n\u003cp\u003e只不过这个过程通常不会直接告诉你。它更多会变成限速、排队、次数减少、模型降级，最后落到你的使用体验里。\u003c/p\u003e\n\u003cp\u003e所以下次再看到一款AI工具说自己完全免费，可以换个角度看：它的用户增长和算力成本是不是越拉越开。两条曲线背离得越明显，免费额度被收紧的可能性就越高。\u003c/p\u003e","title":"模型的“免费额度”是怎么算出来的？"},{"content":" 术语解构系列·MoE路由\n文中模型参数数据查证于2026年7月，主要来自官方模型卡片、GitHub仓库或官方博客。模型规格和API价格都可能变化，具体以厂商最新发布为准。\n消费级显卡到底能不能拿来做点正经AI的活？\n这个问题不能只看显卡型号，也不能只看模型名字里那个很吓人的参数量。真正要拆成两件事：模型能不能装下，以及装下以后每生成一个token要算多少。\n很多人看到DeepSeekV3标着671B参数，Qwen3-235B-A22B标着235B参数，Qwen3-Coder-480B-A35B标着480B参数，第一反应是：这肯定不是消费级设备能碰的东西。\n但真实情况没这么简单。\n这些模型名字里还有一个更容易被忽略的后缀：A3B、A22B、A35B。它说的不是模型下载包有多大，而是每个token大约激活多少参数。\n这篇文章要讲的不是“消费级显卡能不能挑战大厂机房”，而是把这笔账拆清楚：为什么有些大模型看起来很大，跑起来却没那么夸张；为什么有些模型激活参数很小，本地还是很难装下。\n一、消费级显卡先看两笔账：装不装得下，跑不跑得动 把几个真实模型摆在一起看：\n模型 架构 总参数 激活参数 每token激活比例 DeepSeekV3/R1 MoE 671B 37B 约5.5% Qwen3-235B-A22B MoE 235B 22B 约9.4% Qwen3-Coder-480B-A35B MoE 480B 35B 约7.3% Qwen3-30B-A3B MoE 30.5B 3.3B 约10.8% Qwen3-32B（对照） 稠密 32B 32B 100% 最后一行放了一个稠密模型做对照。Qwen3-32B没有专家、没有路由，32B参数每次都参与计算，激活比例就是100%。\n这才是很多人习惯里的“参数量≈计算量”。\n但MoE模型不一样。上面几个MoE模型每次真正参与计算的参数，只占总参数的大约5%到11%。\n如果DeepSeekV3是一个671B的稠密模型，不管是显存占用还是算力消耗，都会是另一种级别。仅按FP16权重粗略算，671B参数就需要超过1TB空间。可它每个token激活的是37B参数，粗略看主要前馈计算量，更接近一个几十B激活规模的模型，而不是完整671B稠密模型。\n这就是消费级显卡选本地模型时最容易混淆的地方：总参数决定你要准备多大的显存/内存去装它，激活参数影响它每个token大概要算多少。\n消费级显卡先看两笔账 MoE（Mixture-of-Experts，混合专家）架构做的就是这件事：模型可以有很大的参数池，但每次只用其中一部分。\n二、一个类比：医院不需要让全体医生会诊 理解MoE，最直接的类比是医院分诊。\n一家大医院可能有几百名医生，覆盖内科、外科、儿科、皮肤科、精神科等几十个科室。这是医院的规模，对应模型的总参数量。\n但病人来了，医院不会让所有医生一起会诊。分诊台会先判断这个病人的情况，再派几个对口医生处理。这对应模型的激活参数量。\nMoE路由机制：不是所有专家都上场 医院的规模决定了它能覆盖多广的问题；但看一个病人要花多少医疗资源，主要取决于实际出诊的那几位医生，而不是医院挂牌的医生总数。\n这套机制翻译回模型架构，对应两个部件：\n专家（Experts）：模型里的一组前馈网络模块，可以理解成一批科室。Qwen3-30B-A3B有128个专家，Qwen3-Coder-480B-A35B有160个专家，DeepSeekV3的专家规模更大，还额外设置了所有token都会用到的共享专家。 路由器（Router/Gating Network）：一个很小的判断网络，负责给每个token打分，决定它该交给哪几个专家处理。它就是模型里的分诊台。 路由不是人工写死的规则。不是程序员规定“中文交给1号专家，代码交给2号专家”，而是模型在训练过程中自己学出来的。它会逐渐学会什么样的token该送去哪些专家。\n而且这个决策是逐层、逐token做的。同一句话里的不同字词，甚至同一个词在不同层，都可能被路由到不同的专家组合。\n三、路由器怎么决定派谁出诊？ 路由器的工作可以拆成三步。\n第一步，打分。每个token经过路由器时，路由器会对全部专家各算出一个分数，表示这个专家有多适合处理当前token。\n第二步，选择Top-K。模型只保留分数最高的K个专家，其余专家不参与这次计算。模型名里的A3B、A22B、A35B，说的就是每个token大约会激活多少参数。\n第三步，加权合并。被选中的几个专家分别处理这个token，再按路由分数把结果加权合并，作为这一层的输出。\n几个真实模型的Top-K配置如下：\n模型 专家总数 每次激活 Qwen3-30B-A3B 128 8 Qwen3-235B-A22B 128 8 Qwen3-Coder-480B-A35B 160 8 DeepSeekV3 256个路由专家+1个共享专家 8个路由专家+共享专家 这里有个容易误解的地方：A22B不是说这个模型只有22B参数，也不是说下载包只有22B大小。它说的是每个token大约激活22B参数。\n四、回到显卡：总参数和激活参数，分别决定什么 看懂路由机制后，模型名字里的两个数字就可以拆开看。\n数字 主要影响什么 典型场景 总参数量 权重能不能装下 本地部署、下载包大小、显存/内存需求 激活参数量 每个token大概要算多少 本地推理吞吐、服务成本结构、云端定价空间 如果只做一个很粗的数量级估算，可以把主要权重乘加量近似看成：\n生成1个token的主要计算量≈2×激活参数量\n这个公式不是完整推理成本公式。真实推理还要看注意力计算、KV Cache、上下文长度、batch大小、量化方式、显存带宽和推理框架。但它能帮我们先抓住一个方向：MoE模型的每token计算量，不能简单按总参数估。\n如果错把总参数当成稠密模型的计算量来估，和按激活参数估出来的差距大概是：\n模型 若按总参数当稠密模型估 按激活参数粗略估 数量级差距 DeepSeekV3 671B级 37B级 约18倍 Qwen3-Coder-480B-A35B 480B级 35B级 约13.7倍 Qwen3-235B-A22B 235B级 22B级 约10.7倍 Qwen3-30B-A3B 30.5B级 3.3B级 约9.2倍 这张表不是说某张显卡上吞吐一定能快这么多倍。它只是在比较两个估算口径：把总参数当稠密模型算，和按激活参数算，差别会有多大。\n真实速度还要看显存带宽、量化方式、上下文长度、KV Cache、batch大小和推理框架。但方向是清楚的：MoE让几百B模型的每token主要计算量，落到了几十B甚至几B这个量级。\n所以消费级显卡不是完全没有机会。它真正怕的不是“这个模型总参数听起来很大”，而是两个具体限制：量化后权重能不能装进显存/内存，推理框架能不能把激活专家这部分算得足够顺。\n五、MoE帮你省计算量，但不会自动帮你省显存 MoE省的是计算量，不是自动省显存 到这里，MoE听起来很像免费午餐：参数很多，算得却很少。\n但对本地部署用户来说，真正的痛点在另一边：\nMoE主要省的是每token计算量，不会自动省掉加载完整权重所需的显存和内存。\n原因很简单。路由器要临时决定每个token交给哪几个专家，所以专家权重通常需要提前处在可访问状态。哪怕这一次某个专家没有被选中，它的权重仍然是模型的一部分。\n回到医院的类比：医院不会因为今天骨科暂时没有病人，就把骨科医生和设备全部撤走。所有科室都要保持可用，才能应对下一秒来的病人。\n所以DeepSeekV3那671B参数，哪怕每个token只激活37B，本地部署仍然要面对671B主模型权重。Qwen3-Coder-480B-A35B同理，480B的下载包和权重加载需求，不会因为激活参数只有35B就变成35B模型。\n这也是很多人用消费级显卡跑MoE模型时最容易踩的坑：模型看起来激活参数不大，但下载包巨大；推理计算量还好，但装载权重很吃内存；单卡可能算得动激活部分，却放不下完整模型。\n维度 MoE模型 稠密模型 权重加载 主要看总参数 主要看总参数 每token主要计算量 主要看激活参数 主要看总参数 本地部署难点 装下完整专家池，并让框架高效调度 装下完整模型，并持续高吞吐计算 云端服务优势 更容易把单位token计算成本压下来 成本和总参数更直接绑定 这也解释了一个看起来矛盾的现象：MoE模型本地部署时不一定更容易装下，但在模型已经装得下、推理框架也能有效处理MoE路由和专家加载的前提下，Decode阶段可能比同等总参数的稠密模型更轻。\n关键前提是：装得下，而且框架能跑好。\n六、消费级显卡到底该怎么判断 看到MoE，或者模型名里的A3B、A22B、A35B后缀，不需要一上来就研究路由器怎么训练、专家怎么分工。先看三个问题。\n第一，量化后的完整权重能不能放进你的显存/内存？\n这是本地部署的第一道门槛。MoE不会因为每次只激活少数专家，就只下载或只加载那几个专家。总参数依然决定权重体积的大盘——你要先把完整权重放进显存、统一内存，或者通过CPU offload、多卡切分等方式让它可访问。\n第二，你的推理框架对MoE支持得好不好？\n同样一张消费级显卡，换不同量化格式、不同上下文长度、不同推理框架，体验可能差很多。MoE模型不是只看参数表就能判断速度，框架能不能高效调度专家很关键。\n第三，如果你不是本地跑，而是用云端API，价格按什么算？\n云端API不是按你的显卡配置计费。激活参数量影响的是服务商的推理成本结构。你真正付多少钱，还要看模型单价、输入token、输出token、缓存命中、调用平台和服务商定价。所以不能简单说“激活参数决定账单”，更准确的说法是：激活参数给厂商压低每token服务成本创造了空间，但最终价格仍然是商业定价。\n厂商发布模型时喜欢强调总参数量，因为这个数字最震撼，也最容易传播。但对使用者来说，还要继续追问那个更小、更关键的数字：\n这个模型每个token到底激活多少参数？\n总参数告诉你模型有多大的专家池，激活参数告诉你每次实际叫了多少专家来干活。\n写在最后 消费级显卡能不能做正经AI的活？\n可以，但它适合做的是边界清楚的本地推理、代码辅助、资料整理、离线问答、批量改写这类任务，不是拿来训练几百B模型，也不是指望所有大模型都能无脑塞进去。\nMoE把这件事拆得更清楚。它更像一个专家池，池子可以很大，但每次只叫一小部分专家出来处理当前token。\n这就是MoE真正改变的地方：它把“总参数”和“每次计算成本”之间的绑定关系松开了。\n总参数决定它装不装得下，激活参数影响它跑起来要算多少。理解了这一点，再看到“几百B参数”的发布会数字，就不要只被总参数吓住，也不要只看激活参数就以为本地随便跑。\n真正该问的是：量化后权重多大？每token激活多少？我的显卡和内存能不能放下？推理框架能不能把这套MoE结构跑好？\n本文是“术语解构”系列的一篇。上一篇聊了不同算力卡一小时能生成多少token，这一篇接着往下问：同样一张消费级显卡，遇到MoE模型，这笔账该怎么重新算。\n你现在本地跑模型用的是什么显卡？遇到过“模型看起来不大，但怎么都跑不顺”的情况吗？评论区可以说说你的配置。\n参考资料 DeepSeek-V3 GitHub仓库：671B总参数，37B激活参数。 DeepSeek-V3权重说明：主模型671B参数，36.7B激活参数，并说明MTP模块权重。 Qwen3官方博客：Qwen3-235B-A22B、Qwen3-30B-A3B参数与专家配置。 Qwen官网MoE页面：Qwen3-30B-A3B为30.5B总参数、3.3B激活参数，Qwen3-235B-A22B为235B总参数、22B激活参数。 Qwen3-Coder官方博客：Qwen3-Coder-480B-A35B为480B总参数、35B激活参数，原生256K上下文。 Qwen3-Coder模型卡：160个专家，每次激活8个专家。 DeepSeek官方API价格页：API按每百万token计费，并区分缓存命中、缓存未命中和输出token价格。 资料边界说明： 文中DeepSeekV3、Qwen3系列的总参数与激活参数数字，均交叉核对了官方GitHub仓库、模型卡和技术报告，口径一致；“生成1个token的计算量≈2×激活参数量”是忽略注意力计算、KV Cache等因素的粗略近似，仅用于建立数量级直觉，不是精确的推理成本公式。参考资料中的“Qwen官网MoE页面”（qwen.moe）经查证并非阿里官方域名，而是第三方整理的模型总览页面，数字与官方博客、HuggingFace模型卡交叉核对一致，但按来源分级应视为二手信源；DeepSeek官方API的缓存计费细则以其最新公告为准，具体价格可能随时间调整。\n","permalink":"https://blog.onecai.site/2026/07/29/059-moe-router-explained/","summary":"\u003cblockquote\u003e\n\u003cp\u003e术语解构系列·\u003cstrong\u003eMoE路由\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e文中模型参数数据查证于2026年7月，主要来自官方模型卡片、GitHub仓库或官方博客。模型规格和API价格都可能变化，具体以厂商最新发布为准。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e消费级显卡到底能不能拿来做点正经AI的活？\u003c/p\u003e\n\u003cp\u003e这个问题不能只看显卡型号，也不能只看模型名字里那个很吓人的参数量。真正要拆成两件事：\u003cstrong\u003e模型能不能装下\u003c/strong\u003e，以及\u003cstrong\u003e装下以后每生成一个token要算多少\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e很多人看到DeepSeekV3标着671B参数，Qwen3-235B-A22B标着235B参数，Qwen3-Coder-480B-A35B标着480B参数，第一反应是：这肯定不是消费级设备能碰的东西。\u003c/p\u003e\n\u003cp\u003e但真实情况没这么简单。\u003c/p\u003e\n\u003cp\u003e这些模型名字里还有一个更容易被忽略的后缀：\u003cstrong\u003eA3B、A22B、A35B\u003c/strong\u003e。它说的不是模型下载包有多大，而是每个token大约激活多少参数。\u003c/p\u003e\n\u003cp\u003e这篇文章要讲的不是“消费级显卡能不能挑战大厂机房”，而是把这笔账拆清楚：为什么有些大模型看起来很大，跑起来却没那么夸张；为什么有些模型激活参数很小，本地还是很难装下。\u003c/p\u003e\n\u003ch2 id=\"一消费级显卡先看两笔账装不装得下跑不跑得动\"\u003e一、消费级显卡先看两笔账：装不装得下，跑不跑得动\u003c/h2\u003e\n\u003cp\u003e把几个真实模型摆在一起看：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e架构\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e总参数\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e激活参数\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e每token激活比例\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeekV3/R1\u003c/td\u003e\n          \u003ctd\u003eMoE\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e671B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e37B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e约5.5%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-235B-A22B\u003c/td\u003e\n          \u003ctd\u003eMoE\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e235B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e22B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e约9.4%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-Coder-480B-A35B\u003c/td\u003e\n          \u003ctd\u003eMoE\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e480B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e35B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e约7.3%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-30B-A3B\u003c/td\u003e\n          \u003ctd\u003eMoE\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e30.5B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e3.3B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e约10.8%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-32B（对照）\u003c/td\u003e\n          \u003ctd\u003e稠密\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e32B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e32B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e100%\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e最后一行放了一个稠密模型做对照。Qwen3-32B没有专家、没有路由，32B参数每次都参与计算，激活比例就是100%。\u003c/p\u003e\n\u003cp\u003e这才是很多人习惯里的“参数量≈计算量”。\u003c/p\u003e\n\u003cp\u003e但MoE模型不一样。上面几个MoE模型每次真正参与计算的参数，只占总参数的大约5%到11%。\u003c/p\u003e\n\u003cp\u003e如果DeepSeekV3是一个671B的稠密模型，不管是显存占用还是算力消耗，都会是另一种级别。仅按FP16权重粗略算，671B参数就需要超过1TB空间。可它每个token激活的是37B参数，粗略看主要前馈计算量，更接近一个几十B激活规模的模型，而不是完整671B稠密模型。\u003c/p\u003e\n\u003cp\u003e这就是消费级显卡选本地模型时最容易混淆的地方：\u003cstrong\u003e总参数决定你要准备多大的显存/内存去装它，激活参数影响它每个token大概要算多少。\u003c/strong\u003e\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"moe-router-explained-1.avif\"\n          alt=\"消费级显卡先看两笔账\"/\u003e \u003cfigcaption\u003e\n             消费级显卡先看两笔账\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eMoE（Mixture-of-Experts，混合专家）架构做的就是这件事：模型可以有很大的参数池，但每次只用其中一部分。\u003c/p\u003e\n\u003ch2 id=\"二一个类比医院不需要让全体医生会诊\"\u003e二、一个类比：医院不需要让全体医生会诊\u003c/h2\u003e\n\u003cp\u003e理解MoE，最直接的类比是医院分诊。\u003c/p\u003e\n\u003cp\u003e一家大医院可能有几百名医生，覆盖内科、外科、儿科、皮肤科、精神科等几十个科室。这是医院的规模，对应模型的\u003cstrong\u003e总参数量\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e但病人来了，医院不会让所有医生一起会诊。分诊台会先判断这个病人的情况，再派几个对口医生处理。这对应模型的\u003cstrong\u003e激活参数量\u003c/strong\u003e。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"moe-router-explained-2.avif\"\n          alt=\"MoE路由机制：不是所有专家都上场\"/\u003e \u003cfigcaption\u003e\n             MoE路由机制：不是所有专家都上场\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e医院的规模决定了它能覆盖多广的问题；但看一个病人要花多少医疗资源，主要取决于实际出诊的那几位医生，而不是医院挂牌的医生总数。\u003c/p\u003e\n\u003cp\u003e这套机制翻译回模型架构，对应两个部件：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e专家（Experts）\u003c/strong\u003e：模型里的一组前馈网络模块，可以理解成一批科室。Qwen3-30B-A3B有128个专家，Qwen3-Coder-480B-A35B有160个专家，DeepSeekV3的专家规模更大，还额外设置了所有token都会用到的共享专家。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e路由器（Router/Gating Network）\u003c/strong\u003e：一个很小的判断网络，负责给每个token打分，决定它该交给哪几个专家处理。它就是模型里的分诊台。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e路由不是人工写死的规则。不是程序员规定“中文交给1号专家，代码交给2号专家”，而是模型在训练过程中自己学出来的。它会逐渐学会什么样的token该送去哪些专家。\u003c/p\u003e\n\u003cp\u003e而且这个决策是逐层、逐token做的。同一句话里的不同字词，甚至同一个词在不同层，都可能被路由到不同的专家组合。\u003c/p\u003e\n\u003ch2 id=\"三路由器怎么决定派谁出诊\"\u003e三、路由器怎么决定派谁出诊？\u003c/h2\u003e\n\u003cp\u003e路由器的工作可以拆成三步。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一步，打分\u003c/strong\u003e。每个token经过路由器时，路由器会对全部专家各算出一个分数，表示这个专家有多适合处理当前token。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二步，选择Top-K\u003c/strong\u003e。模型只保留分数最高的K个专家，其余专家不参与这次计算。模型名里的A3B、A22B、A35B，说的就是每个token大约会激活多少参数。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三步，加权合并\u003c/strong\u003e。被选中的几个专家分别处理这个token，再按路由分数把结果加权合并，作为这一层的输出。\u003c/p\u003e\n\u003cp\u003e几个真实模型的Top-K配置如下：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e专家总数\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e每次激活\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-30B-A3B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e128\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e8\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-235B-A22B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e128\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e8\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eQwen3-Coder-480B-A35B\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e160\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e8\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeekV3\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e256个路由专家+1个共享专家\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e8个路由专家+共享专家\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这里有个容易误解的地方：A22B不是说这个模型只有22B参数，也不是说下载包只有22B大小。它说的是每个token大约激活22B参数。\u003c/p\u003e","title":"模型标着671B参数，消费级显卡真的扛不住吗？"},{"content":" 术语解构系列·有效算力成本\n文中数据来源、查证时间见文末“资料来源”与“资料边界说明”。\n一、报价单上少写了一个分母 云厂商的算力报价页，通常只写一行数字：每卡每小时多少钱。\n这行数字回答的是，这张卡开着，一小时收你多少钱。它没有回答另一个问题：这一小时里，这张卡有多少时间、以多高效率，真正变成了你的训练吞吐、推理token和业务结果。\n这中间少写的分母，就是有效利用率。\n这里先把口径说清楚。本文说的有效利用率，不是单一监控面板里的GPU使用率，也不是MFU。它更接近一个算账口径：一张GPU的标称能力，经过工程效率、任务排布和时间满载之后，最后有多少变成了有效产出。\n上半年，这个问题被重新摆到台面上。腾讯云运营商解决方案总经理张晋在2026年MWC上海智能数据中心峰会上，给出过一个判断：相关研究数据显示，国内智算中心GPU平均利用率不足30%。他同时用一个公式拆解这个数字：\n算力生产力 = 标称算力 × 效能系数 × 满载系数\n标称算力是规格书上的数字。效能系数看GPU跑得快不快，报道中给出的平均值约0.6。满载系数看GPU跑得满不满，平均值约0.5。两个系数相乘，100%的标称算力，最终只剩下约30%的有效产出。\n30%不是单一监控指标 这不是说所有智算中心的每张GPU监控面板都只有30%。它说的是更综合的算力生产力：既包括卡有没有在工作，也包括跑起来以后有没有被网络、显存、调度、计算气泡拖慢。\n还有几条公开信息可以放在旁边看。韦乐平在2025云网智联大会上提到，国内智算中心超过280个，GPU利用率很不均衡，平均不到30%。中国信通院云大所刘如明在2025万卡AI集群建设论坛上给过一组卡时口径：2025年国内智算共算量约38亿卡时，同期用算量约14亿卡时，用算占比36.8%。另有媒体文章转引浪潮人工智能研究院测算，称我国智算中心平均算力使用率约30%。\n这些数字不是同一个指标，不能互相当作严格校验。它们共同指向的是一个趋势：很多智算资源建起来了，但还没有稳定转化成足够高的有效产出。\n作为对照，并行科技COO乔楠在媒体报道中称，公司算力利用率在90%到95%之间。这个数字是公司口径，不是行业统计，但它提供了一个头部算力运营平台的参照：同样是算力资源，经过跨区域调度和运营管理后，利用率可以和行业平均说法拉开很大差距。\n这篇文章要拆的就是这个差距。不是为了证明某个30%一定精确，而是想让读者建立一个核算习惯：GPU报价不能只看每小时多少钱，还要看这份报价背后有多少有效算力真的被用出来。\n二、同样报价，单位有效成本可能差三倍 先把公式写出来：\n单位有效算力成本 = 实例小时价 ÷ 有效利用率\n这里的有效利用率，可以是你自己业务里的GPU非空闲时间，也可以是更严格的有效吞吐口径，比如tokens/s/GPU、样本/s/GPU、每百万token成本。文章前面引用的30%，属于综合有效产出率口径。为了让账算得直观，下面先把它近似代入这个公式。\n假设某型号GPU的报价是每卡每小时100元。这个数字只是为了方便心算，不对应任何具体厂商的真实报价。\n同样报价，分母不同，成本差三倍 如果有效利用率是30%：\n1 单位有效算力成本 = 100 ÷ 30% ≈ 333元/有效GPU小时 如果有效利用率是90%：\n1 单位有效算力成本 = 100 ÷ 90% ≈ 111元/有效GPU小时 两者相除，约等于3倍。\n这就是标题里的意思。价格表上都是100元一小时，但一边只有三成有效产出，另一边接近九成有效产出，摊到每个有效GPU小时上，成本就不在一个层级。\n所以，客户比较GPU云服务器时，只看A厂每小时多少、B厂每小时多少，意义有限。真正该问的是：我的任务在这套平台上能跑到多少有效利用率？能不能排队？能不能错峰？能不能批处理？能不能被更细粒度地切分？能不能和别的任务混部？\n报价只在分子上做文章，利用率决定分母。\n这里再补一个容易混的概念：利用率不等于MFU。之前拆1P算力时讲过，MFU衡量的是模型训练实际FLOPS相对硬件峰值FLOPS的比例，回答的是卡在跑任务时算得快不快。本文讲的有效利用率，更关心资源有没有持续产生业务结果。一张卡可以MFU不低，但每天只跑几个小时；也可以一直有任务在跑，但因为通信等待、显存碎片、批量太小，单位时间产出不高。新闻稿和报价表经常把这些词混着用，读者自己算账时要先分清口径。\n三、低利用率不是浪费两个字能解释 看到30%这个数字，第一反应很容易是管理不善、资源浪费。但如果把镜头拉远一点，会发现它通常是几类结构性问题叠在一起。\n第一，峰谷负载。 之前讲DeepSeek峰谷定价时算过这笔账：GPU集群一天24小时都在产生折旧、电费、制冷和运维成本，但用户请求不是平均来的。上午和下午是高峰，凌晨大量空闲。按平均负载建集群，高峰扛不住；按峰值负载建集群，大部分时间会闲。平台用峰谷价格引导客户错峰，本质上就是在处理这条负载曲线。\n第二，采购提前量。 智算中心建设周期以季度、年计，业务需求却是逐步爬坡的。批项目、建机房、采购服务器时，往往按远期规划报规模。落地初期真实负载接不住这么多卡，生命周期前半段自然会压低平均利用率。再叠加GPU架构更新、租赁价格变化和折旧压力，运营方不能只看硬件还能不能用，还要看它在未来几年还能不能以有竞争力的成本产出算力。\n第三，工程效率。 张晋公式里的效能系数，讲的是GPU跑起来以后还有多少标称能力能释放出来。网络丢包、通信等待、显存碎片、KV Cache膨胀、Prefill和Decode阶段错配，都会让标称算力打折。它不是满载系数，但会影响最终有效产出。\n第四，资源粒度太粗。 NVIDIA在2026年一篇讨论Kubernetes GPU集群可观测性的技术博客里提到，很多平台团队看不清GPU被谁占用、占了多少显存、任务是否在排队或空闲。工程师为了避免资源争抢，习惯性申请一整张GPU，但模型经常只用到30%到50%的可用显存和计算资源。这是NVIDIA/Run:ai产品语境下的观察，不能当作全网平均利用率统计，但它说明整卡申请、实际吃不满，是GPU平台管理里足够常见的问题。\n再看海外口径。美国能源部资助、劳伦斯伯克利国家实验室发布的《2024 United States Data Center Energy Usage Report》，在做数据中心能耗建模时，把AI训练服务器的运行时间假设为80%，推理服务器假设为40%，并在2024到2028年的场景中，对训练取75%到85%、对推理取37.5%到42.5%的变化区间。\n这份报告不是云厂商GPU平均利用率统计，也不能和国内智算中心不足30%的说法直接相除。它更适合作为旁证：训练和推理的利用率结构不同，推理侧40%左右的运行时间假设，并不是离谱数字，而是已经被放进严肃能耗模型里的口径。\n所以，低利用率不是一句浪费就能打发。它背后有需求峰谷、建设提前量、调度粒度、工程效率和业务变现节奏。问题不是系统里能不能留余量，而是这部分余量最后由谁买单，客户有没有把它算进单位成本。\n四、先把报价表改成自己的核算表 回到客户或团队，第一步不是立刻喊提高利用率，而是把云厂商报价单改造成自己的成本核算表。\n如果你在用A100、H100、L20这类GPU实例，账本上不该只记每小时多少钱，至少要多记三类数字：\n项目 要看什么 实例小时价 云厂商账单上的单价 资源使用 GPU非空闲时间、显存占用、SM利用率、任务排队时间 业务产出 tokens/s、样本/s、每百万token成本、每次训练实验成本 腾讯云GPU云服务器监控文档对GPU使用率的定义是，评估负载所消耗的计算能力，即非空闲状态百分比，统计维度到单张卡。这个指标不是万能的，它替代不了MFU，也不能直接说明模型训练效率。但如果它完全没有出现在成本表里，你就只是在比较报价，没有在比较算力成本。\n这个核算表能避开一个很常见的坑：低价实例可能只是把浪费藏进了利用率里。\n假设A实例报价每小时8元，但你的任务实际只能跑到25%有效利用率，有效成本就是32元。B实例报价每小时12元，看起来贵50%，但能稳定跑到70%有效利用率，有效成本约17.1元。报价更高的B，真实算力反而更便宜。\n不把利用率算进去，低价很容易变成错觉。\n五、有了核算表，再谈怎么把成本降下来 企业能做的事大致有四类。目标不是把仪表盘上的利用率堆到100%，而是在可接受的延迟和稳定性约束下，把单位业务产出的成本压低。\n四个动作，把有效利用率拉上去 能错峰的任务就错峰。 日报、批量处理、离线分析、历史文档打标签、非实时内容生成，都不一定要挤在白天高峰。DeepSeek峰谷定价那篇讲过，高峰贵、低谷不变，本质上是把负载曲线写进账单。即使你用的平台没有峰谷价，主动错峰也能让自己的任务落进资源更空的时间段。\n能批处理的请求就批处理。 推理服务最怕请求稀疏，但又要求低延迟。适当的动态批处理，可以在不明显牺牲体验的前提下提高吞吐。内部工具、异步生成、内容审核、报表整理这类任务，不一定需要像聊天机器人一样逐字返回，批处理带来的成本改善会更明显。\n能混部的业务就混部。 在线推理对延迟敏感，负载有峰谷；离线任务对延迟不敏感，但需要持续吃算力。两类任务如果完全隔离部署，低峰时在线GPU会空着。如果能用优先级、抢占和资源隔离把它们放到同一资源池，离线任务就能填补在线服务的波谷。\n腾讯云TKE qGPU在离线混部文档里写得很直接：实时推理对资源和延迟敏感，需要尽快拿到资源，但利用率通常偏低；模型训练消耗大量GPU资源，但对短时间抑制不那么敏感。给出的方案是把在线高优先级任务和离线低优先级任务部署在同一张GPU上，用低优先级任务吃掉高优先级任务的空闲算力。\n张晋在同一场演讲里给出过一个具体的对照案例，正好把这套逻辑量化了：在核心推理集群的高强度业务混部实测中，通过腾讯TKE调度大脑和qGPU算力切分协作，综合满载率提升到85%，相当于利用率翻倍，实际运营TCO节约约50%。他还给出了另一组更大的对比——传统粗放堆砌的机房，综合算力生产率不到30%；而对效能系数和满载系数做双重优化以后，整座“Token工厂”的综合效率可以跃迁到76%。同一场演讲里，“不到30%”和“76%”构成了一个清晰的工程对照：前者描述传统粗放堆砌下的综合算力生产率，后者描述经过效能系数和满载系数双重优化后，腾讯云给出的目标/案例水平。它不是行业平均值，也不代表所有集群都能照搬。\n小红书CPU混部案例也能提供一个思路参照。它证明的是统一调度和混部可以改善资源池利用率，不等于GPU场景可以照搬同样幅度。GPU还有显存、算力隔离、通信和延迟抖动问题，落地难度更高。\n用竞价实例吃平台的低谷。 前三条是让自己的负载更均匀，这一条是利用平台负载不均匀的结果。AWS Spot Instance使用EC2闲置容量，价格相对按需实例最高可省90%，但平台需要收回容量时可能中断。Google Cloud Spot VM对很多机型、GPU、TPU提供相对按需最高91%的折扣，但资源可能被抢占。Azure Spot VM也是用较低价格使用未被使用的计算容量，代价是Azure需要容量时会驱逐虚拟机。阿里云抢占式实例的定义，是对当前闲置资源出价，直到出价低于市场价或库存不足才会被回收。\n这些产品说的是同一件事：如果你的任务能接受不确定性，愿意在平台空闲时跑，平台就愿意把闲置容量便宜卖给你。\n预留实例是另一面。阿里云预留实例券代表承诺一定使用时长以换取更低成本，但无论能否匹配到实际运行的实例，有效期内都要按付费类型支付费用。AWS Reserved Instance页面也写明，买了之后不管实例是否运行，整个预留期都要计费。\n按量、预留、Spot，本质上是三种风险分配方式。按量最贵，因为你既要灵活又不承诺长期消化容量。预留能打折，因为你承诺未来会持续使用。Spot最便宜，因为你替平台消化闲置容量，还承担中断风险。\n六、两篇文章，其实讲的是同一条负载曲线 这篇可以和峰谷定价那篇（《同一个问题，上午9点问比凌晨贵一倍：DeepSeek峰谷定价的算力账》）放在一起看。\n峰谷定价讲的是平台侧：GPU集群一天24小时都有成本，但请求分布不均匀，于是平台把负载曲线印到对外价格表上，高峰贵，低谷便宜或不变，用价格引导客户搬任务。\n这篇讲的是客户侧：同样一条负载曲线，换到自己的账本里，就是有效利用率。利用率越低，同样的硬件投入，摊到每一份有效产出上的成本越高。\n一端是平台定价，一端是客户核算。你在峰谷定价那篇看到的错峰调用，和这篇讲的提高有效利用率，做的是同一件事：让本来闲着的算力多产出一点东西。\n写在最后 云厂商挂出的每小时X元，只是标价。\n真正决定单位算力成本的，是这行标价背后那个很少写出来的分母：这张卡有多少时间、以多高效率，变成了有效产出。\n国内智算中心有效产出约三成的公开说法，头部平台90%以上利用率的公司口径，都不适合简单当作同一张统计表里的数字。但它们放在一起，足够提醒我们一件事：算力采购不能只比报价，还要比有效利用率。\n下次比较GPU云服务，除了问多少钱一小时，还可以多问一句：\n这份报价，最后会摊到多少有效GPU小时上？\n这个问题，比报价单上的小数点更接近真实成本。\n参考资料 《警惕算力泡沫：万亿投资，七成空转》，虎嗅网转载自公众号“科技四少”：https://www.huxiu.com/article/4874555.html 《“国内智算中心超280个，GPU利用率平均不到30%”》，观察者网/新浪财经转载：https://finance.sina.com.cn/roll/2025-04-24/doc-ineufnkz9220460.shtml 《腾讯云张晋：AI下半场，拼的是工程化能力》，C114通信网：https://m.c114.com.cn/w16-1313164.html 《你有万卡集群，但你有算力资产么？》，2026第三届AI算力产业大会官网，转述中国信通院云大所云计算部副主任刘如明在IDCC2025“2025万卡AI集群建设论坛”上的发言：https://www.suanliai.cn/shishiyaowen/665.html NVIDIA Technical Blog， “Get Real-Time Visibility into GPU Usage Across Kubernetes Clusters”， 2026年。 Shehabi, A. et al. 2024 United States Data Center Energy Usage Report， Lawrence Berkeley National Laboratory, LBNL-2001637。 腾讯云官方文档《qGPU在离线混部》《GPU云服务器GPU使用率监控指标说明》。 AWS官方文档《Amazon EC2 Spot Instances》《Amazon EC2 Reserved Instances》。 Google Cloud官方文档《Spot VMs》。 Microsoft Azure官方文档《Azure Spot Virtual Machines》。 阿里云官方帮助文档《创建抢占式ECI实例》《预留实例券》。 《集群CPU利用率均值一年提升25%，小红书混部技术的优解方案》，腾讯云开发者社区：https://cloud.tencent.com/developer/article/2366704 本文系列前作：《同一个问题，上午9点问比凌晨贵一倍：DeepSeek峰谷定价的算力账》《为什么CPU能一卖四，GPU却只能整卡出租？》《理解什么是“1P”算力》。 资料边界说明： 文中“国内智算中心GPU平均利用率不足30%”来自腾讯云张晋在2026年MWC上海智能数据中心峰会上的公开发言，经媒体报道转述。本文未找到腾讯云官方演讲全文或视频，具体措辞以张晋本人及腾讯云官方口径为准。张晋公式中的30%，严格说是“标称算力×效能系数×满载系数”后的综合算力生产力，不等同于单一监控指标里的GPU非空闲时间。本文在算例中把它近似作为“有效利用率”代入，是为了说明成本核算关系，不是精确财务模型。文中提到的“混部后满载率提升到85%”“综合效率跃迁至76%”，同样来自张晋这场演讲，是腾讯云在自家核心推理集群做混部优化后的实测/披露案例，代表的是优化后能达到的水平，不是行业平均水平，不能理解成所有企业混部后都能做到76%。\n韦乐平“平均不到30%”、信通院“用算占比36.8%”、浪潮人工智能研究院“约30%”和并行科技“90%到95%”，来源、统计对象和口径不同，不能互相直接相除，也不能当作同一份行业统计表。本文只把它们作为公开信息中的趋势信号使用：国内部分智算资源存在建多用少、调度不足、有效产出偏低的问题。\nLBNL能耗报告的训练/推理运行时间假设，统计对象是美国数据中心能耗建模，不等同于云厂商实际GPU平均利用率，也不能和国内智算中心不足30%的数字直接比较。NVIDIA技术博客中30%到50%的表述来自NVIDIA/Run:ai产品语境下的观察，不构成全网平均利用率统计。文中100元/30%/90%、8元/25%对12元/70%均为简化算例，报价数字不对应任何具体云厂商在特定时点的真实价格，实际报价请以官网当日信息为准。\n","permalink":"https://blog.onecai.site/2026/07/28/057-gpu-utilization-effective-compute-cost/","summary":"\u003cblockquote\u003e\n\u003cp\u003e术语解构系列·\u003cstrong\u003e有效算力成本\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e文中数据来源、查证时间见文末“资料来源”与“资料边界说明”。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一报价单上少写了一个分母\"\u003e一、报价单上少写了一个分母\u003c/h2\u003e\n\u003cp\u003e云厂商的算力报价页，通常只写一行数字：每卡每小时多少钱。\u003c/p\u003e\n\u003cp\u003e这行数字回答的是，这张卡开着，一小时收你多少钱。它没有回答另一个问题：这一小时里，这张卡有多少时间、以多高效率，真正变成了你的训练吞吐、推理token和业务结果。\u003c/p\u003e\n\u003cp\u003e这中间少写的分母，就是有效利用率。\u003c/p\u003e\n\u003cp\u003e这里先把口径说清楚。本文说的有效利用率，不是单一监控面板里的GPU使用率，也不是MFU。它更接近一个算账口径：一张GPU的标称能力，经过工程效率、任务排布和时间满载之后，最后有多少变成了有效产出。\u003c/p\u003e\n\u003cp\u003e上半年，这个问题被重新摆到台面上。腾讯云运营商解决方案总经理张晋在2026年MWC上海智能数据中心峰会上，给出过一个判断：相关研究数据显示，国内智算中心GPU平均利用率不足30%。他同时用一个公式拆解这个数字：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e算力生产力 = 标称算力 × 效能系数 × 满载系数\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e标称算力是规格书上的数字。效能系数看GPU跑得快不快，报道中给出的平均值约0.6。满载系数看GPU跑得满不满，平均值约0.5。两个系数相乘，100%的标称算力，最终只剩下约30%的有效产出。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-utilization-effective-compute-cost-v2-1.avif\"\n          alt=\"30%不是单一监控指标\"/\u003e \u003cfigcaption\u003e\n             30%不是单一监控指标\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这不是说所有智算中心的每张GPU监控面板都只有30%。它说的是更综合的算力生产力：既包括卡有没有在工作，也包括跑起来以后有没有被网络、显存、调度、计算气泡拖慢。\u003c/p\u003e\n\u003cp\u003e还有几条公开信息可以放在旁边看。韦乐平在2025云网智联大会上提到，国内智算中心超过280个，GPU利用率很不均衡，平均不到30%。中国信通院云大所刘如明在2025万卡AI集群建设论坛上给过一组卡时口径：2025年国内智算共算量约38亿卡时，同期用算量约14亿卡时，用算占比36.8%。另有媒体文章转引浪潮人工智能研究院测算，称我国智算中心平均算力使用率约30%。\u003c/p\u003e\n\u003cp\u003e这些数字不是同一个指标，不能互相当作严格校验。它们共同指向的是一个趋势：很多智算资源建起来了，但还没有稳定转化成足够高的有效产出。\u003c/p\u003e\n\u003cp\u003e作为对照，并行科技COO乔楠在媒体报道中称，公司算力利用率在90%到95%之间。这个数字是公司口径，不是行业统计，但它提供了一个头部算力运营平台的参照：同样是算力资源，经过跨区域调度和运营管理后，利用率可以和行业平均说法拉开很大差距。\u003c/p\u003e\n\u003cp\u003e这篇文章要拆的就是这个差距。不是为了证明某个30%一定精确，而是想让读者建立一个核算习惯：GPU报价不能只看每小时多少钱，还要看这份报价背后有多少有效算力真的被用出来。\u003c/p\u003e\n\u003ch2 id=\"二同样报价单位有效成本可能差三倍\"\u003e二、同样报价，单位有效成本可能差三倍\u003c/h2\u003e\n\u003cp\u003e先把公式写出来：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e单位有效算力成本 = 实例小时价 ÷ 有效利用率\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这里的有效利用率，可以是你自己业务里的GPU非空闲时间，也可以是更严格的有效吞吐口径，比如tokens/s/GPU、样本/s/GPU、每百万token成本。文章前面引用的30%，属于综合有效产出率口径。为了让账算得直观，下面先把它近似代入这个公式。\u003c/p\u003e\n\u003cp\u003e假设某型号GPU的报价是每卡每小时100元。这个数字只是为了方便心算，不对应任何具体厂商的真实报价。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-utilization-effective-compute-cost-v2-2.avif\"\n          alt=\"同样报价，分母不同，成本差三倍\"/\u003e \u003cfigcaption\u003e\n             同样报价，分母不同，成本差三倍\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e如果有效利用率是30%：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e单位有效算力成本 = 100 ÷ 30% ≈ 333元/有效GPU小时\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e如果有效利用率是90%：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e单位有效算力成本 = 100 ÷ 90% ≈ 111元/有效GPU小时\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e两者相除，约等于3倍。\u003c/p\u003e\n\u003cp\u003e这就是标题里的意思。价格表上都是100元一小时，但一边只有三成有效产出，另一边接近九成有效产出，摊到每个有效GPU小时上，成本就不在一个层级。\u003c/p\u003e\n\u003cp\u003e所以，客户比较GPU云服务器时，只看A厂每小时多少、B厂每小时多少，意义有限。真正该问的是：我的任务在这套平台上能跑到多少有效利用率？能不能排队？能不能错峰？能不能批处理？能不能被更细粒度地切分？能不能和别的任务混部？\u003c/p\u003e\n\u003cp\u003e报价只在分子上做文章，利用率决定分母。\u003c/p\u003e\n\u003cp\u003e这里再补一个容易混的概念：利用率不等于MFU。之前拆1P算力时讲过，MFU衡量的是模型训练实际FLOPS相对硬件峰值FLOPS的比例，回答的是卡在跑任务时算得快不快。本文讲的有效利用率，更关心资源有没有持续产生业务结果。一张卡可以MFU不低，但每天只跑几个小时；也可以一直有任务在跑，但因为通信等待、显存碎片、批量太小，单位时间产出不高。新闻稿和报价表经常把这些词混着用，读者自己算账时要先分清口径。\u003c/p\u003e\n\u003ch2 id=\"三低利用率不是浪费两个字能解释\"\u003e三、低利用率不是浪费两个字能解释\u003c/h2\u003e\n\u003cp\u003e看到30%这个数字，第一反应很容易是管理不善、资源浪费。但如果把镜头拉远一点，会发现它通常是几类结构性问题叠在一起。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一，峰谷负载。\u003c/strong\u003e 之前讲DeepSeek峰谷定价时算过这笔账：GPU集群一天24小时都在产生折旧、电费、制冷和运维成本，但用户请求不是平均来的。上午和下午是高峰，凌晨大量空闲。按平均负载建集群，高峰扛不住；按峰值负载建集群，大部分时间会闲。平台用峰谷价格引导客户错峰，本质上就是在处理这条负载曲线。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二，采购提前量。\u003c/strong\u003e 智算中心建设周期以季度、年计，业务需求却是逐步爬坡的。批项目、建机房、采购服务器时，往往按远期规划报规模。落地初期真实负载接不住这么多卡，生命周期前半段自然会压低平均利用率。再叠加GPU架构更新、租赁价格变化和折旧压力，运营方不能只看硬件还能不能用，还要看它在未来几年还能不能以有竞争力的成本产出算力。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三，工程效率。\u003c/strong\u003e 张晋公式里的效能系数，讲的是GPU跑起来以后还有多少标称能力能释放出来。网络丢包、通信等待、显存碎片、KV Cache膨胀、Prefill和Decode阶段错配，都会让标称算力打折。它不是满载系数，但会影响最终有效产出。\u003c/p\u003e","title":"有效算力产出只有三成时，GPU报价要重新算一遍"},{"content":"很多人想象大模型训练，会想到几千张GPU同时开跑。这个画面没错，但少了一个关键细节：这些GPU不是各干各的，而是在同一个训练节拍里一起往前走。\n每一步训练，大家都要先算完自己那份，再把结果对齐，然后一起进入下一步。一张卡慢了、断了、通信异常了，受影响的通常不是它自己那一点算力，而是整个训练作业的节奏。\n这也是为什么在大模型训练里，掉卡是个很麻烦的词。它不只是少了1/16000的算力，更可能让另外15999张卡一起等。\n一、分布式训练不是各跑各的流水线 在同步训练中，每张GPU拿到一小批训练数据，算出一份梯度。梯度可以简单理解为：模型参数下一步应该往哪个方向调整。\n问题在于，模型副本分布在很多张卡上，但训练逻辑要求这些副本保持一致。每张卡不能按自己的梯度单独更新，否则很快就会训练出一堆互相不一样的模型。\n所以同步数据并行里通常会做这样一件事：每张卡先算出自己的梯度，然后所有卡把梯度汇总、求和或求平均，得到一份全局结果，再一起更新参数。\n这个过程很像一桌人AA制。每个人先报自己花了多少钱，等所有人都报完，才能算总账和人均。如果有人迟迟不报、报错了，或者干脆走了，其他人只能等。\n同步训练：所有GPU必须一起进入下一步 大模型训练里的这种等待不是偶发插曲。只要采用同步训练，每一步参数更新都绕不开类似的同步动作。卡越多，整体算力越大，但也越容易遇到某个环节掉队。\n二、All-Reduce到底在做什么？ 刚才说的“汇总梯度、再让每张卡拿到同一份结果”，在分布式训练里最典型的通信动作叫All-Reduce。\n一句话说，All-Reduce就是每个rank都拿出一份数据，系统把这些数据做归约运算，比如求和，然后把结果放回每个rank。训练场景里，这份数据常常就是梯度。\nAll-Reduce：先汇总，再把同一份结果发回每张卡 NVIDIA NCCL官方文档对All-Reduce的描述也是这个意思：每个rank提供输入数组，经过归约后，每个rank都收到相同的输出结果。NCCL文档还强调，集合通信操作必须由每个rank用相同的数据量、相同的数据类型调用，否则结果属于未定义行为，可能hang、crash，甚至造成数据损坏。\n这里的rank可以先粗略理解成参与训练的一个计算进程，很多场景下一个rank对应一张GPU。严格说，rank和GPU不总是一一对应，但对这篇文章要解释的问题来说，这个简化足够用了。\n再看PyTorch的DistributedDataParallel。DDP在反向传播时会把梯度按bucket分组，某个bucket准备好后就触发通信，把不同进程里的梯度同步起来。PyTorch文档也提醒过，如果不同进程之间的collective调用顺序对不上，backward过程可能直接卡住。\n所以，All-Reduce的关键不是“通信很慢”这么简单，而是它有一个很强的前提：参与者要按同一套顺序、同一套形状、同一套节拍一起做事。有人掉线，或者有人走到了另一套通信流程里，整个作业就可能卡住。\n现代大模型训练当然不只用All-Reduce。FSDP、张量并行、流水线并行里还会大量出现all-gather、reduce-scatter等集合通信。但只要理解All-Reduce，就能理解同步训练为什么怕掉队。\n三、掉卡为什么会拖住几千张卡？ 理解了前面的同步逻辑，再看掉卡，就不会把它理解成“少一张卡继续跑”。\n第一种情况是直接掉卡。GPU报错、显存出现不可纠正错误、NVLink或RoCE网络异常，都可能让某个rank掉出通信队伍。集合通信等不到它，训练就可能停在某一次通信上。后面要做的不是简单跳过这张卡，而是超时检测、故障定位、重建通信组、重新调度，再从checkpoint恢复。\n这里有个容易混淆的点：超时不是NCCL自己天然帮你把训练恢复好。NCCL是底层通信库，真正的超时检测和错误处理通常还要依赖上层框架和训练系统。以PyTorch为例，ProcessGroupNCCL有watchdog机制，公开文档里提到NCCL后端默认超时时间是10分钟，其他后端默认是30分钟。也就是说，如果训练系统没有额外的监控和更快的失败处理，一次通信挂住可能会白白占住很多GPU时间。\n一张卡掉线，为什么几千张卡都要等 第二种情况是慢卡，也就是straggler。它比直接掉卡更难排查。卡没有彻底坏，任务还在跑，但它就是比其他卡慢一拍。可能是硬件状态不稳定，可能是链路异常，也可能是某个节点的系统侧问题。\n同步训练的麻烦就在这里：下一步要等所有人都到齐。一张慢卡会把所有快卡都拖到自己的节奏上。Meta在Llama 3技术报告里专门提到过这类问题：有些硬件故障会表现成慢节点，表面上像通信问题，但根因可能是某个GPU或主机组件出了问题。\n第三种情况是恢复成本。掉卡之后，训练通常不能无损地从故障那一刻继续。系统要判断故障源，决定是否剔除节点，重新拉起作业，再加载最近一次checkpoint。\ncheckpoint又有自己的两难。存得太少，故障后要回退更远，丢掉更多已经算过的token；存得太频繁，训练又会被保存模型状态这件事打断，还会占用存储和网络带宽。\n慢卡比掉卡更隐蔽 AWS的checkpoint文章给过一个直观算例：4000张加速卡的集群，如果一次同步checkpoint暂停3分钟，就相当于200个GPU-hours的集群空转。如果每30分钟做一次这样的同步checkpoint，一天会损失9600个GPU-hours。这个数字不是说所有训练都会这样，而是提醒我们：几分钟的停顿，乘上几千张卡之后，就不是小数。\n四、Llama 3的数据说明了什么？ Llama 3 405B训练：故障是日常，不是偶发 Meta训练Llama 3 405B的数据很适合拿来做参照。\n按照Meta技术报告，Llama 3 405B预训练最多用到16384张H100。每张H100是80GB HBM3显存、700W TDP。报告还披露，在一个54天的预训练窗口里，训练作业一共发生466次中断，其中47次是计划内中断，419次是非计划中断。\n这419次非计划中断里，约78%被归因于确认或疑似硬件问题，包括GPU、主机组件、静默数据损坏，以及非计划的单机维护。GPU相关问题是最大类，占所有非计划问题的58.7%。\n换算一下，54天是1296小时，419次非计划中断平均下来大约每3.1小时一次。这个平均数不能理解成故障真的每3小时均匀发生一次，但它足够说明一个事实：到了万卡规模，故障不是极端偶发事件，而是训练系统日常要处理的东西。\nMeta同一份报告里还有一句很关键的话：同步训练本身不太容错，一张GPU故障可能要求整个作业重启。即便如此，他们仍然把effective training time做到90%以上，靠的是减少启动和checkpoint时间，自动化诊断和问题处理。\n这里值得注意的是，90%以上有效训练时间并不意味着故障少。恰恰相反，它说明在故障很多的情况下，训练系统能不能快速发现、快速恢复，会直接决定最终效率。\n五、掉卡真正暴露的是训练系统能力 大模型训练拼的是系统工程 把这些机制和数据放在一起看，大模型训练最怕掉卡，不是因为硬件不能坏。任何足够大的集群都会遇到硬件故障。\n真正的问题是，同步训练把大量GPU绑在同一个节拍上。单卡故障、慢卡、通信错位、checkpoint回退，都会被集群规模放大。单看一张卡，可能只是停几分钟；放到几千张卡上，就是几千张卡一起等。\n所以，大模型训练拼的不只是GPU数量。GPU越多，单卡算力越不能解释最终效率。通信、同步、慢节点检测、checkpoint策略、故障恢复和任务调度，都会变成训练成本的一部分。\n一张卡掉线本身不可怕。更难的是系统能不能快速判断：它是真坏了，还是只是慢了；是GPU问题，还是网络问题；要不要重启整个作业，还是只需要剔除问题节点。能不能把这套判断和恢复流程做快，决定了大规模训练到底是在有效计算，还是在让昂贵的GPU排队等人。\n参考资料：\nMeta，《The Llama 3 Herd of Models》技术报告 NVIDIA，NCCL Collective Operations官方文档 PyTorch，DistributedDataParallel官方文档 与 torch.distributed官方文档 PyTorch Blog，《Flight Recorder: A New Lens for Understanding NCCL Watchdog Timeouts》 AWS Storage Blog，《Architecting scalable checkpoint storage for large-scale ML training on AWS》 ","permalink":"https://blog.onecai.site/2026/07/27/055-why-llm-training-fears-gpu-failure/","summary":"\u003cp\u003e很多人想象大模型训练，会想到几千张GPU同时开跑。这个画面没错，但少了一个关键细节：这些GPU不是各干各的，而是在同一个训练节拍里一起往前走。\u003c/p\u003e\n\u003cp\u003e每一步训练，大家都要先算完自己那份，再把结果对齐，然后一起进入下一步。一张卡慢了、断了、通信异常了，受影响的通常不是它自己那一点算力，而是整个训练作业的节奏。\u003c/p\u003e\n\u003cp\u003e这也是为什么在大模型训练里，掉卡是个很麻烦的词。它不只是少了1/16000的算力，更可能让另外15999张卡一起等。\u003c/p\u003e\n\u003ch2 id=\"一分布式训练不是各跑各的流水线\"\u003e一、分布式训练不是各跑各的流水线\u003c/h2\u003e\n\u003cp\u003e在同步训练中，每张GPU拿到一小批训练数据，算出一份梯度。梯度可以简单理解为：模型参数下一步应该往哪个方向调整。\u003c/p\u003e\n\u003cp\u003e问题在于，模型副本分布在很多张卡上，但训练逻辑要求这些副本保持一致。每张卡不能按自己的梯度单独更新，否则很快就会训练出一堆互相不一样的模型。\u003c/p\u003e\n\u003cp\u003e所以同步数据并行里通常会做这样一件事：每张卡先算出自己的梯度，然后所有卡把梯度汇总、求和或求平均，得到一份全局结果，再一起更新参数。\u003c/p\u003e\n\u003cp\u003e这个过程很像一桌人AA制。每个人先报自己花了多少钱，等所有人都报完，才能算总账和人均。如果有人迟迟不报、报错了，或者干脆走了，其他人只能等。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-1.avif\"\n          alt=\"同步训练：所有GPU必须一起进入下一步\"/\u003e \u003cfigcaption\u003e\n             同步训练：所有GPU必须一起进入下一步\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e大模型训练里的这种等待不是偶发插曲。只要采用同步训练，每一步参数更新都绕不开类似的同步动作。卡越多，整体算力越大，但也越容易遇到某个环节掉队。\u003c/p\u003e\n\u003ch2 id=\"二all-reduce到底在做什么\"\u003e二、All-Reduce到底在做什么？\u003c/h2\u003e\n\u003cp\u003e刚才说的“汇总梯度、再让每张卡拿到同一份结果”，在分布式训练里最典型的通信动作叫All-Reduce。\u003c/p\u003e\n\u003cp\u003e一句话说，All-Reduce就是每个rank都拿出一份数据，系统把这些数据做归约运算，比如求和，然后把结果放回每个rank。训练场景里，这份数据常常就是梯度。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-2.avif\"\n          alt=\"All-Reduce：先汇总，再把同一份结果发回每张卡\"/\u003e \u003cfigcaption\u003e\n             All-Reduce：先汇总，再把同一份结果发回每张卡\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eNVIDIA NCCL官方文档对All-Reduce的描述也是这个意思：每个rank提供输入数组，经过归约后，每个rank都收到相同的输出结果。NCCL文档还强调，集合通信操作必须由每个rank用相同的数据量、相同的数据类型调用，否则结果属于未定义行为，可能hang、crash，甚至造成数据损坏。\u003c/p\u003e\n\u003cp\u003e这里的rank可以先粗略理解成参与训练的一个计算进程，很多场景下一个rank对应一张GPU。严格说，rank和GPU不总是一一对应，但对这篇文章要解释的问题来说，这个简化足够用了。\u003c/p\u003e\n\u003cp\u003e再看PyTorch的DistributedDataParallel。DDP在反向传播时会把梯度按bucket分组，某个bucket准备好后就触发通信，把不同进程里的梯度同步起来。PyTorch文档也提醒过，如果不同进程之间的collective调用顺序对不上，backward过程可能直接卡住。\u003c/p\u003e\n\u003cp\u003e所以，All-Reduce的关键不是“通信很慢”这么简单，而是它有一个很强的前提：参与者要按同一套顺序、同一套形状、同一套节拍一起做事。有人掉线，或者有人走到了另一套通信流程里，整个作业就可能卡住。\u003c/p\u003e\n\u003cp\u003e现代大模型训练当然不只用All-Reduce。FSDP、张量并行、流水线并行里还会大量出现all-gather、reduce-scatter等集合通信。但只要理解All-Reduce，就能理解同步训练为什么怕掉队。\u003c/p\u003e\n\u003ch2 id=\"三掉卡为什么会拖住几千张卡\"\u003e三、掉卡为什么会拖住几千张卡？\u003c/h2\u003e\n\u003cp\u003e理解了前面的同步逻辑，再看掉卡，就不会把它理解成“少一张卡继续跑”。\u003c/p\u003e\n\u003cp\u003e第一种情况是直接掉卡。GPU报错、显存出现不可纠正错误、NVLink或RoCE网络异常，都可能让某个rank掉出通信队伍。集合通信等不到它，训练就可能停在某一次通信上。后面要做的不是简单跳过这张卡，而是超时检测、故障定位、重建通信组、重新调度，再从checkpoint恢复。\u003c/p\u003e\n\u003cp\u003e这里有个容易混淆的点：超时不是NCCL自己天然帮你把训练恢复好。NCCL是底层通信库，真正的超时检测和错误处理通常还要依赖上层框架和训练系统。以PyTorch为例，ProcessGroupNCCL有watchdog机制，公开文档里提到NCCL后端默认超时时间是10分钟，其他后端默认是30分钟。也就是说，如果训练系统没有额外的监控和更快的失败处理，一次通信挂住可能会白白占住很多GPU时间。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-3.avif\"\n          alt=\"一张卡掉线，为什么几千张卡都要等\"/\u003e \u003cfigcaption\u003e\n             一张卡掉线，为什么几千张卡都要等\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e第二种情况是慢卡，也就是straggler。它比直接掉卡更难排查。卡没有彻底坏，任务还在跑，但它就是比其他卡慢一拍。可能是硬件状态不稳定，可能是链路异常，也可能是某个节点的系统侧问题。\u003c/p\u003e\n\u003cp\u003e同步训练的麻烦就在这里：下一步要等所有人都到齐。一张慢卡会把所有快卡都拖到自己的节奏上。Meta在Llama 3技术报告里专门提到过这类问题：有些硬件故障会表现成慢节点，表面上像通信问题，但根因可能是某个GPU或主机组件出了问题。\u003c/p\u003e\n\u003cp\u003e第三种情况是恢复成本。掉卡之后，训练通常不能无损地从故障那一刻继续。系统要判断故障源，决定是否剔除节点，重新拉起作业，再加载最近一次checkpoint。\u003c/p\u003e\n\u003cp\u003echeckpoint又有自己的两难。存得太少，故障后要回退更远，丢掉更多已经算过的token；存得太频繁，训练又会被保存模型状态这件事打断，还会占用存储和网络带宽。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-4.avif\"\n          alt=\"慢卡比掉卡更隐蔽\"/\u003e \u003cfigcaption\u003e\n             慢卡比掉卡更隐蔽\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eAWS的checkpoint文章给过一个直观算例：4000张加速卡的集群，如果一次同步checkpoint暂停3分钟，就相当于200个GPU-hours的集群空转。如果每30分钟做一次这样的同步checkpoint，一天会损失9600个GPU-hours。这个数字不是说所有训练都会这样，而是提醒我们：几分钟的停顿，乘上几千张卡之后，就不是小数。\u003c/p\u003e\n\u003ch2 id=\"四llama-3的数据说明了什么\"\u003e四、Llama 3的数据说明了什么？\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-5.avif\"\n          alt=\"Llama 3 405B训练：故障是日常，不是偶发\"/\u003e \u003cfigcaption\u003e\n             Llama 3 405B训练：故障是日常，不是偶发\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eMeta训练Llama 3 405B的数据很适合拿来做参照。\u003c/p\u003e\n\u003cp\u003e按照Meta技术报告，Llama 3 405B预训练最多用到16384张H100。每张H100是80GB HBM3显存、700W TDP。报告还披露，在一个54天的预训练窗口里，训练作业一共发生466次中断，其中47次是计划内中断，419次是非计划中断。\u003c/p\u003e\n\u003cp\u003e这419次非计划中断里，约78%被归因于确认或疑似硬件问题，包括GPU、主机组件、静默数据损坏，以及非计划的单机维护。GPU相关问题是最大类，占所有非计划问题的58.7%。\u003c/p\u003e\n\u003cp\u003e换算一下，54天是1296小时，419次非计划中断平均下来大约每3.1小时一次。这个平均数不能理解成故障真的每3小时均匀发生一次，但它足够说明一个事实：到了万卡规模，故障不是极端偶发事件，而是训练系统日常要处理的东西。\u003c/p\u003e\n\u003cp\u003eMeta同一份报告里还有一句很关键的话：同步训练本身不太容错，一张GPU故障可能要求整个作业重启。即便如此，他们仍然把effective training time做到90%以上，靠的是减少启动和checkpoint时间，自动化诊断和问题处理。\u003c/p\u003e\n\u003cp\u003e这里值得注意的是，90%以上有效训练时间并不意味着故障少。恰恰相反，它说明在故障很多的情况下，训练系统能不能快速发现、快速恢复，会直接决定最终效率。\u003c/p\u003e\n\u003ch2 id=\"五掉卡真正暴露的是训练系统能力\"\u003e五、掉卡真正暴露的是训练系统能力\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"why-llm-training-fears-gpu-failure-6.avif\"\n          alt=\"大模型训练拼的是系统工程\"/\u003e \u003cfigcaption\u003e\n             大模型训练拼的是系统工程\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e把这些机制和数据放在一起看，大模型训练最怕掉卡，不是因为硬件不能坏。任何足够大的集群都会遇到硬件故障。\u003c/p\u003e\n\u003cp\u003e真正的问题是，同步训练把大量GPU绑在同一个节拍上。单卡故障、慢卡、通信错位、checkpoint回退，都会被集群规模放大。单看一张卡，可能只是停几分钟；放到几千张卡上，就是几千张卡一起等。\u003c/p\u003e\n\u003cp\u003e所以，大模型训练拼的不只是GPU数量。GPU越多，单卡算力越不能解释最终效率。通信、同步、慢节点检测、checkpoint策略、故障恢复和任务调度，都会变成训练成本的一部分。\u003c/p\u003e\n\u003cp\u003e一张卡掉线本身不可怕。更难的是系统能不能快速判断：它是真坏了，还是只是慢了；是GPU问题，还是网络问题；要不要重启整个作业，还是只需要剔除问题节点。能不能把这套判断和恢复流程做快，决定了大规模训练到底是在有效计算，还是在让昂贵的GPU排队等人。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e参考资料：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMeta，\u003ca href=\"https://arxiv.org/pdf/2407.21783\"\u003e《The Llama 3 Herd of Models》技术报告\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eNVIDIA，\u003ca href=\"https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html\"\u003eNCCL Collective Operations官方文档\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ePyTorch，\u003ca href=\"https://docs.pytorch.org/docs/stable/generated/torch.nn.parallel.DistributedDataParallel.html\"\u003eDistributedDataParallel官方文档\u003c/a\u003e 与 \u003ca href=\"https://docs.pytorch.org/docs/stable/distributed.html\"\u003etorch.distributed官方文档\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ePyTorch Blog，\u003ca href=\"https://pytorch.org/blog/flight-recorder-a-new-lens-for-understanding-nccl-watchdog-timeouts/\"\u003e《Flight Recorder: A New Lens for Understanding NCCL Watchdog Timeouts》\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eAWS Storage Blog，\u003ca href=\"https://aws.amazon.com/blogs/storage/architecting-scalable-checkpoint-storage-for-large-scale-ml-training-on-aws/\"\u003e《Architecting scalable checkpoint storage for large-scale ML training on AWS》\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"为什么大模型训练最怕“掉卡”"},{"content":"这两年看智算中心新闻，经常会看到一个很大的数字：千P、万P、多少EFLOPS。\n这个数字当然不是假的。它背后通常有真实的机房、服务器、GPU、交换机、电力和冷却系统。但它也不是一个完整答案。一个智算中心说自己有1000P，只能说明它有一批账面峰值资源，不等于这些资源在训练大模型时都能高效跑起来。\n国家数据局指导下，全国数据标准化技术委员会在2025年6月发布过一组《全国一体化算力网》技术文件征求意见稿。里面有一个很值得注意的变化：算力衡量已经不只看峰值计算能力，还要看计算负载率、网络带宽利用率、时延、丢包率、吞吐率、存储IOPS、访问延迟等指标。\n这说明，连标准口径都已经不满足于一个孤立的P数了。\n普通读者看智算中心，不需要马上钻进所有工程细节里。抓住三个数字就够了：\n这个P是什么精度算出来的？ 卡和卡之间用什么网络连起来？ 真实任务跑出了多少有效算力？ 这三个数字连起来，才比较接近一个智算中心真实的训练能力。\n峰值P数是怎么加出来的 同一张GPU，为什么能写成接近2P，也能写成接近1P P是peta的缩写。1P FLOPS，大约就是每秒1000万亿次浮点运算。一个智算中心说自己有1000P，最朴素的算法通常是：\n1 总峰值算力 = 单卡峰值算力 × 卡数 这个公式看起来很直观，麻烦在于“单卡峰值算力”本身有很多口径。\n以NVIDIA H100 SXM为例，NVIDIA官方规格页写的是：FP16/BF16 Tensor Core为1979 TFLOPS，FP8 Tensor Core为3958 TFLOPS，NVLink带宽为900GB/s。但同一个表格下面有脚注：这些带星号的Tensor Core数字是采用稀疏技术显示的，不采用稀疏技术时规格降低一半。\n也就是说，同一张H100 SXM，如果按FP16/BF16稀疏口径看，接近2P；如果按不采用稀疏的稠密口径看，大约接近1P。\n这不是文字游戏，也不是博客作者的猜测，而是官方规格表里的口径差异。\n再往下看，精度口径也会让数字变化很大。大模型训练常见的是FP16、BF16、FP8这些低精度格式；科学计算常看FP64；推理场景又经常出现INT8、INT4、FP4。它们都可能被折算成某种OPS或FLOPS，但不能直接混在一起比较。\n可以粗略记成这张表：\n精度口径 常见场景 读者需要注意什么 FP64 科学计算、高性能计算 不等于大模型训练主口径 FP32 通用单精度计算 常被用于统一折算 TF32 NVIDIA Tensor Core计算 主要是张量核心相关口径 FP16/BF16 大模型训练主力 看清是稠密还是稀疏 FP8 新一代训练和推理 不能直接和FP16数字混比 INT8 量化推理 更偏推理，不宜直接代表训练能力 INT4/FP4 更低精度推理 数字会更大，但适用任务更窄 所以，看到一个千P集群，第一反应不要是“强不强”，而是补一句：千P@什么精度？\n更严谨的写法应该像这样：\n1 2 3 1000P@FP16 dense 1000P@FP16 sparse 1000P@FP8 少了精度和稀疏口径，这个P数就只讲了一半。\n网络带宽决定这些卡能不能一起干活 训练集群的强弱，取决于GPU能不能像一个系统协同工作 大模型训练不是一张卡把自己的活干完就结束。训练过程中，GPU之间要不断同步参数、梯度、激活值和中间状态。模型越大，并行方式越复杂，通信压力越明显。\n很多时候，训练卡住的地方不在“有没有卡”，而在“这些卡能不能像一个系统一样工作”。\n可以先看三层网络。\n层级 典型案例 公开带宽口径 节点内 H100 SXM / DGX H100 H100 SXM单GPU NVLink 900GB/s；DGX H100单机8张H100，通过NVSwitch互联 节点间 DGX H100集群网络 ConnectX-7支持400Gb/s InfiniBand或400GbE 集群级 DGX H100 SuperPOD 32台DGX H100、256张H100，NVLink Network跨256张GPU，双向带宽57.6TB/s 这张表里最容易被忽略的是单位。900GB/s和400Gb/s不是一个量级，也不是同一个位置的网络。前者是GPU节点内的高速互联，后者是节点间网络接口的典型口径。GB是字节，Gb是比特，1字节等于8比特。\n训练为什么对网络这么敏感？\n可以把一个训练step想象成一群人同时跑接力。每张GPU都在算自己那部分，但下一步开始前，经常要等所有人把数据同步完。只要有一张卡慢了，整个step就要等它。\n工程里会把这种拖后腿的节点叫straggler。它可能来自网络拥塞、某条链路不稳、某台机器温度或故障、某个batch负载不均，也可能来自通信和计算没有重叠好。对训练集群来说，平均值好看还不够，尾部延迟很要命。\nMoE模型会把这个问题放大。字节跳动和北京大学等作者在MegaScale-MoE论文里提到，他们训练一个内部MoE模型时，通信在前向传播中占总时间的43.6%，在整个训练过程中占32%。这不是所有模型的通用比例，但它说明了一件事：在大规模训练里，通信开销已经不是边角料。\n所以，智算中心宣传高速网络时，读者可以多问几句：\n是节点内NVLink/NVSwitch，还是节点间InfiniBand/RoCE？ 交换网络是怎么组的，是否支持大规模多机多卡训练？ 标称400G、800G之后，压测出来的网络带宽实现率是多少？ 时延、丢包率、拥塞控制有没有指标？ 国家数据局那份《算力算效衡量技术要求》征求意见稿里，把网络资源衡量拆成了带宽、时延、抖动、丢包率等指标，还明确提到要支持PCIe、NVLink、InfiniBand/RoCE等网络协议的衡量。另一份《算力中心能力评估要求》征求意见稿里，也把网络带宽实现率单独列为传输能力指标，计算方式是压测出的网络峰值速率除以网络带宽。\n这套口径很工程化。不是看你宣传页写了多少G，而是看实际能跑出来多少。\n有效训练能力，要看任务跑出来什么 峰值P数是规格书上的能力。训练任务真正拿到多少，要看有效算力。\n这里可以借MLPerf Training的思路。MLPerf Training不是简单比较峰值FLOPS，它衡量的是系统把模型训练到目标质量所需要的墙钟时间。也就是从用户视角看：同样一个任务，多久能训练到合格结果。\n这个口径比峰值P数更贴近实际。用户付钱买算力，最终关心的不是规格表上写了多少P，而是模型训练多久、成本多少、中间会不会频繁失败。\n训练效率里还有一个常见指标，叫MFU，Model FLOPs Utilization，可以理解为模型训练实际完成的FLOPs占硬件理论峰值的比例。\nMFU不等于nvidia-smi里看到的GPU利用率。\nnvidia-smi里的GPU利用率，更多是在采样周期里有没有GPU kernel在跑。它显示90%，只能说明GPU很忙，不代表Tensor Core都在做高效的大模型训练。GPU可能忙在数据搬运、通信等待、非矩阵计算、低效kernel、显存访问、checkpoint，甚至各种调度和同步开销上。\n一个智算中心如果只说“GPU利用率很高”，但不说明训练任务、模型规模、精度、batch size、token/s、step time、MFU、失败重试和通信开销，这个数字的信息量有限。\n公开报道里也能看到这种反差。腾讯云张晋在2026年MWC上海相关演讲报道中提到，国内智算中心GPU平均利用率不足30%，并用“标称算力 × 效能系数 × 满载系数”来解释算力产出。钛媒体报道中也引用资料称，上半年国内已上线智算中心17亿卡时，实际使用5.6亿卡时，利用率32%，行业平均上架率不足60%。\n这些是媒体报道和会议转述，统计口径不一定完全一致，不能当成全国统一结论。但它们指向同一个问题：卡买回来、机架建起来、P数写出来，只是第一步。真正难的是让这些卡长期、稳定、高效地跑真实任务。\n普通人判断智算中心，看三个数字 判断智算中心是真强还是纸面强，看三个数字 如果不做采购、不做集群运维，读者没必要背所有硬件参数。判断一个智算中心是真强还是纸面强，可以抓三个数字。\n第一个数字：P数的精度口径 问清楚它说的P是FP64、FP32、FP16/BF16、FP8，还是INT8、FP4。再问一句，这个数字有没有采用稀疏口径。\n国家数据局《算力中心能力评估要求》征求意见稿里，计算能力本来就是分开看的：算力总规模按FP32折算，智能计算规模看FP16，超级计算规模看FP64，可调度计算规模又单独列出来。\n这个分法很重要。一个中心可以有很大的总算力，但如果适合大模型训练的FP16/BF16资源不够，或者很多资源不能被统一调度，对大模型用户来说就没那么有用。\n第二个数字：网络带宽实现率 只看400G、800G、NVLink不够。要看这些带宽发生在哪一层，实际压测能跑出多少，跨节点训练时有没有稳定低丢包，拓扑是不是适合大规模同步。\n节点内高速互联很重要，节点间网络同样重要。一个8卡服务器内部跑得很好，不代表128卡、1024卡训练也能线性扩展。卡数越多，网络和调度越容易暴露问题。\n第三个数字：真实任务的有效产出 最有价值的披露，不是“我们有多少P”，而是：\n某个模型训练到目标质量用了多久； 单卡或集群token/s是多少； MFU大概多少； 任务失败率、重试率、checkpoint成本如何； 可调度计算规模占总规模多少； 资源负载率和满载时长如何。 《算力中心能力评估要求》征求意见稿里把“算力总规模”和“可调度计算规模”分开写，已经把这件事讲得很清楚：采购清单上的算力，和真正能纳入调度、稳定给用户用的算力，不是一回事。\n一个披露样本：港科大广州HPC AI智算平台 正面例子可以看香港科技大学（广州）HPC AI智算平台的公开介绍。\n它对HPC三期的披露不是只写“千P”，而是同时写了：\n2025年1月上线运行； 18.933Pflops@FP64； 1078.322Pflops@FP16； 68个先进计算设备节点； 400Gb/s RoCE v2网络协议； 17PB分布式存储系统。 这份披露的价值不在于1078.322P这个数字特别漂亮，而在于它把精度口径、节点规模、网络协议、网络带宽、存储规模一起写出来了。\n读者至少能知道，这里的千P是FP16半精度AI算力，不是FP64，也不是一个没说明精度的混合数字。还能继续追问：这些节点具体是什么芯片，训练任务实际吞吐怎样，跨节点扩展效率如何。\n好的披露不是把所有问题都回答完，而是让外部读者知道该从哪里继续问。\n几种常见宣传口径，怎么拆 看到“千P智算中心”，先问精度，问稀疏口径，问是否全量投产，问可调度规模。\n看到“支持大模型训练”，问训练过什么规模的模型，有没有训练到目标质量的时间，有没有稳定性和故障恢复数据。\n看到“高速网络”，问是节点内NVLink，还是节点间InfiniBand/RoCE。标称带宽是多少，压测实现率是多少，训练高峰时丢包率和尾部延迟怎样。\n看到“国产化智算”，问芯片、通信库、训练框架、调度系统、模型适配分别到了哪一层。能跑demo和能稳定训练大模型，中间还有很长一段工程距离。\n看到“绿色算力”，问PUE、单位功耗算力输出、绿电比例、液冷方案、负载率。空置的绿色机房，经济账也未必好看。\n千P不是假数字，但它只是第一行 千P集群当然重要。它代表真实的资金投入、设备规模、机房工程和地方产业布局。没有这些硬件底座，大模型训练根本跑不起来。\n但真正值钱的从来不是PPT上的千P，而是可用的千P。\n下次再看到一个智算中心宣布自己有多少P，可以先不急着判断强不强。把三个问题问完：这个P是什么精度算出来的，卡之间怎么连起来的，真实任务跑出了多少有效算力。\n能把这三件事摊开讲的智算中心，才算把算力从采购清单变成了生产力。\n资料与数据来源 NVIDIA H100 Tensor Core GPU官方规格页：用于H100 SXM FP16/BF16、FP8、NVLink 900GB/s，以及稀疏技术脚注。https://wwwdev.nvidia.cn/data-center/h100/ NVIDIA DGX H100/H200 User Guide：用于DGX H100单机8张H100、NVSwitch、ConnectX-7网络模块等信息。https://docs.nvidia.com/dgx/dgxh100-user-guide/ NVIDIA ConnectX-7 Adapter Cards User Manual：用于ConnectX-7支持NDR 400Gb/s、400GbE等网络口径。https://networking-docs.nvidia.com/connectx7hw/introduction NVIDIA Technical Blog, Upgrading Multi-GPU Interconnectivity with the Third-Generation NVIDIA NVSwitch：用于DGX H100 SuperPOD的32台DGX H100、256张H100、1 exaflop、57.6TB/s等案例。https://developer.nvidia.com/blog/upgrading-multi-gpu-interconnectivity-with-the-third-generation-nvidia-nvswitch/ MLCommons MLPerf Training官方页面：用于“训练到目标质量所需墙钟时间”的基准口径。https://mlperf.pw/benchmarks/training/index.html 国家数据局《全国一体化算力网 算力算效衡量技术要求（征求意见稿）》：用于计算、网络、存储资源衡量指标。https://www.nda.gov.cn/sjj/ywpd/szkjyjcss/0608/ff808081-96b466bd-0197-4f0d710c-0731.pdf 国家数据局《全国一体化算力网 算力中心能力评估要求（征求意见稿）》：用于FP32/FP16/FP64、可调度计算规模、网络带宽实现率、资源负载率等指标。https://www.nda.gov.cn/sjj/ywpd/szkjyjcss/0608/ff808081-96b465bf-0197-4f0dae39-0700.pdf 香港科技大学（广州）HPC AI智算平台公开介绍：用于HPC三期1078.322Pflops@FP16、68个ACD节点、400Gb/s RoCE v2、17PB存储等披露样本。https://docs.hpc.hkust-gz.edu.cn/docs/intro/ MegaScale-MoE: Large-Scale Communication-Efficient Training of Mixture-of-Experts Models in Production：用于MoE训练通信占比、1440张NVIDIA Hopper GPU、1.41M tokens/s等论文数据。https://arxiv.org/abs/2505.11432 腾讯云张晋2026年MWC上海演讲相关报道：用于行业GPU利用率不足30% 等会议转述。https://lmtw.com/mzw/content/detail/id/255725 钛媒体《智算中心太“多”，大模型不够用了》：用于17亿卡时、5.6亿卡时、利用率32%、上架率不足60% 等媒体报道数据。https://m.thepaper.cn/newsDetail_forward_29400934 资料边界：国家数据局两份文件为征求意见稿，不等于已经正式生效的强制标准；腾讯云演讲和钛媒体数据属于公开报道与会议转述，统计口径和时间点可能不同，文中只作为行业现象参考。硬件规格、网络带宽和训练基准口径优先采用官方文档、标准组织页面和论文原文。\n","permalink":"https://blog.onecai.site/2026/07/27/056-thousand-p-ai-computing-cluster/","summary":"\u003cp\u003e这两年看智算中心新闻，经常会看到一个很大的数字：千P、万P、多少EFLOPS。\u003c/p\u003e\n\u003cp\u003e这个数字当然不是假的。它背后通常有真实的机房、服务器、GPU、交换机、电力和冷却系统。但它也不是一个完整答案。一个智算中心说自己有1000P，只能说明它有一批账面峰值资源，不等于这些资源在训练大模型时都能高效跑起来。\u003c/p\u003e\n\u003cp\u003e国家数据局指导下，全国数据标准化技术委员会在2025年6月发布过一组《全国一体化算力网》技术文件征求意见稿。里面有一个很值得注意的变化：算力衡量已经不只看峰值计算能力，还要看计算负载率、网络带宽利用率、时延、丢包率、吞吐率、存储IOPS、访问延迟等指标。\u003c/p\u003e\n\u003cp\u003e这说明，连标准口径都已经不满足于一个孤立的P数了。\u003c/p\u003e\n\u003cp\u003e普通读者看智算中心，不需要马上钻进所有工程细节里。抓住三个数字就够了：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e这个P是什么精度算出来的？\u003c/li\u003e\n\u003cli\u003e卡和卡之间用什么网络连起来？\u003c/li\u003e\n\u003cli\u003e真实任务跑出了多少有效算力？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这三个数字连起来，才比较接近一个智算中心真实的训练能力。\u003c/p\u003e\n\u003ch2 id=\"峰值p数是怎么加出来的\"\u003e峰值P数是怎么加出来的\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"thousand-p-ai-computing-cluster-1.avif\"\n          alt=\"同一张GPU，为什么能写成接近2P，也能写成接近1P\"/\u003e \u003cfigcaption\u003e\n             同一张GPU，为什么能写成接近2P，也能写成接近1P\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eP是peta的缩写。1P FLOPS，大约就是每秒1000万亿次浮点运算。一个智算中心说自己有1000P，最朴素的算法通常是：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e总峰值算力 = 单卡峰值算力 × 卡数\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e这个公式看起来很直观，麻烦在于“单卡峰值算力”本身有很多口径。\u003c/p\u003e\n\u003cp\u003e以NVIDIA H100 SXM为例，NVIDIA官方规格页写的是：FP16/BF16 Tensor Core为1979 TFLOPS，FP8 Tensor Core为3958 TFLOPS，NVLink带宽为900GB/s。但同一个表格下面有脚注：这些带星号的Tensor Core数字是采用稀疏技术显示的，不采用稀疏技术时规格降低一半。\u003c/p\u003e\n\u003cp\u003e也就是说，同一张H100 SXM，如果按FP16/BF16稀疏口径看，接近2P；如果按不采用稀疏的稠密口径看，大约接近1P。\u003c/p\u003e\n\u003cp\u003e这不是文字游戏，也不是博客作者的猜测，而是官方规格表里的口径差异。\u003c/p\u003e\n\u003cp\u003e再往下看，精度口径也会让数字变化很大。大模型训练常见的是FP16、BF16、FP8这些低精度格式；科学计算常看FP64；推理场景又经常出现INT8、INT4、FP4。它们都可能被折算成某种OPS或FLOPS，但不能直接混在一起比较。\u003c/p\u003e\n\u003cp\u003e可以粗略记成这张表：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e精度口径\u003c/th\u003e\n          \u003cth\u003e常见场景\u003c/th\u003e\n          \u003cth\u003e读者需要注意什么\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP64\u003c/td\u003e\n          \u003ctd\u003e科学计算、高性能计算\u003c/td\u003e\n          \u003ctd\u003e不等于大模型训练主口径\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP32\u003c/td\u003e\n          \u003ctd\u003e通用单精度计算\u003c/td\u003e\n          \u003ctd\u003e常被用于统一折算\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eTF32\u003c/td\u003e\n          \u003ctd\u003eNVIDIA Tensor Core计算\u003c/td\u003e\n          \u003ctd\u003e主要是张量核心相关口径\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP16/BF16\u003c/td\u003e\n          \u003ctd\u003e大模型训练主力\u003c/td\u003e\n          \u003ctd\u003e看清是稠密还是稀疏\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP8\u003c/td\u003e\n          \u003ctd\u003e新一代训练和推理\u003c/td\u003e\n          \u003ctd\u003e不能直接和FP16数字混比\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eINT8\u003c/td\u003e\n          \u003ctd\u003e量化推理\u003c/td\u003e\n          \u003ctd\u003e更偏推理，不宜直接代表训练能力\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eINT4/FP4\u003c/td\u003e\n          \u003ctd\u003e更低精度推理\u003c/td\u003e\n          \u003ctd\u003e数字会更大，但适用任务更窄\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e所以，看到一个千P集群，第一反应不要是“强不强”，而是补一句：千P@什么精度？\u003c/p\u003e\n\u003cp\u003e更严谨的写法应该像这样：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e2\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e3\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1000P@FP16 dense\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1000P@FP16 sparse\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1000P@FP8\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e少了精度和稀疏口径，这个P数就只讲了一半。\u003c/p\u003e","title":"智算中心动辄千P，真正该看的不是P数"},{"content":"一个问题：昇腾910C到底能打H100的几成？\n这个问题看着简单，实际很容易问偏。推理、小规模部署、大模型训练、千卡集群，根本不是同一场比赛。910C在每一场里的表现都不一样。\n先把结论摆在前面：如果只看公开报道里的特定推理任务，可以谈6成左右的口径；如果看大模型训练和大规模集群，答案要保守得多；如果看FP8这类前沿训练能力，差距会更明显。\n这篇文章不是要证明国产芯片行不行，而是想把一件事讲清楚：910C的价值不是无损替代H100，而是在AI基建很难稳定获得H100的现实里，提供一块可规模部署、可系统堆叠、可持续优化的算力底座。\n一、纸面参数对比表，先把口径摆正 先看硬件规格。这张表只放最核心的几项，后面每一个结论都要能回到这里。\n规格 昇腾910C NVIDIA H100 SXM FP16/BF16算力 约752-800 TFLOPS，来自Atlas 900 A3整机规格和CloudMatrix论文口径反推 约989.5 TFLOPS稠密；1,979 TFLOPS为稀疏口径 FP8算力 公开权威资料未给出可直接对标的910C单卡FP8峰值 约1,979 TFLOPS稠密；3,958 TFLOPS为稀疏口径 片上内存容量 128GB，见Atlas 900 A3和CloudMatrix相关资料 80GB HBM3 片上内存带宽 最高约3.2TB/s，见Atlas 900 A3和CloudMatrix相关资料 3.35TB/s 芯片/节点内互联 Atlas 900 A3标注D2D双向784GB/s；CloudMatrix论文给出UB平面每NPU约392GB/s单向 NVLink 900GB/s 系统形态 Atlas 900 A3最多384张NPU组成超节点 HGX/DGX H100常见为8卡节点，并可通过NVLink/NVSwitch与InfiniBand扩展 参数表不能直接给出答案 这张表后面必须加三条提醒，不然很容易被数字带偏。\n第一，H100的1979 TFLOPS和3958 TFLOPS不是稠密口径。NVIDIA官方规格表在这些Tensor Core峰值后面标了星号，说明是with sparsity，也就是带稀疏加速。要和没有明确稀疏口径的数据比较，H100的FP16/BF16稠密峰值应按约989.5 TFLOPS看，FP8稠密峰值应按约1979 TFLOPS看。\n第二，910C的单卡数据目前最稳妥的公开来源，不是华为单独发布的一张芯片规格表，而是Atlas 900 A3、CloudMatrix384这类系统级资料。Atlas 900 A3官方页写的是384张NPU、48TB片上内存、片上内存带宽最高3.2TB/s、FP16总算力307.2/288.7 PFLOPS。按这个口径反推，单NPU大约是128GB片上内存、最高3.2TB/s带宽、约800/752 TFLOPS FP16算力。\n第三，网上常见的96GB、1.8TB/s、HCCS 400GB/s等数字，有些来自分析机构、媒体或早期推断，有些可能对应不同板卡、不同可用容量或不同互联层级。它们不是完全没有参考价值，但不适合写成已经核实确认的统一官方规格。本文后面会尽量用公开来源更清楚的系统级数据，同时把推断和报道口径分开。\n如果只看FP16稠密峰值，910C和H100的差距没有很多文章写得那么夸张；如果看FP8训练、生态成熟度和大规模集群效率，参数表又会显得太乐观。这就是这篇文章要展开的地方。\n二、真实差距一：FP8，不只是一个数字 FP8是这轮AI芯片竞争里很关键的一项。它不是把精度从16位砍到8位这么简单，而是牵扯训练稳定性、损失缩放、算子实现、框架支持和模型配方。\nH100的优势不只是官方表里有FP8峰值。NVIDIA把FP8做进了Hopper架构和Transformer Engine，再配上CUDA、cuDNN、NCCL、TensorRT-LLM、Megatron等工具链和训练经验，形成的是一整套能把低精度真正用起来的工程体系。低精度训练最怕的不是算力不够，而是数值不稳定、精度对不齐、训到一半才发现收益吃不到。\n910C这一代公开资料里更确定的是FP16/BF16和INT8相关能力。华为在2025全联接大会上强调，从Ascend 950系列开始，会支持FP8、MXFP8、HiF8、MXFP4等更多低精度格式，并把互联带宽提升到2TB/s。这个信息很重要，但它不能直接算到910C头上。\n也就是说，讨论910C时不能把950的路线图提前借过来。910C已经能承担很多推理和部分训练任务，但如果场景是追求极致效率的FP8大模型训练，H100仍然有明确优势。\n三、真实差距二：互联，单卡接近不等于集群接近 单卡接近，不等于集群接近 AI训练不是一张卡跑满就结束。模型越大、并行策略越复杂，卡和卡之间的通信、同步、故障恢复就越重要。\nH100的强项在于NVLink、NVSwitch、InfiniBand和Magnum IO这套组合已经跑了很多年。单节点内，H100 SXM的NVLink带宽是900GB/s。扩到多节点时，NVIDIA生态里还有成熟的网络、通信库、调度和调优经验。\n910C这边的路线更像系统工程。华为的Atlas 900 A3通过灵衢高速互联，让384张NPU像一台逻辑计算机一样工作；CloudMatrix384论文进一步给出了384颗Ascend 910C、192颗鲲鹏CPU、统一总线网络的设计，把UB、RDMA、VPC三张网络分开处理不同流量。论文里还提到，每颗910C在UB平面可提供约392GB/s单向带宽，跨节点带宽下降不到3%，延迟增加小于1微秒。\n这些数字说明华为确实在用超节点架构补互联短板，尤其适合MoE推理、KV Cache访问、Prefill和Decode拆分这类通信很重的服务场景。但这里要注意边界：CloudMatrix论文展示的是特定系统和特定推理框架下的结果，不能直接外推成所有训练场景都能接近H100集群，也不能说910C单卡互联已经追平H100。\n更准确的说法是：H100强在成熟的通用集群范式，910C强在华为把硬件、CPU、NPU、总线、推理框架和云服务打包成一个系统后，可以在某些大模型推理场景里把效率做得很高。\n四、真实差距三：生态，CUDA的优势不是一个API CUDA的优势不是某一个API，也不是把代码里的函数名替换掉就能追平。真正难追的是CUDA、cuDNN、TensorRT、NCCL、PyTorch原生生态、调试工具、性能分析工具和开发者经验叠在一起的结果。\n昇腾这边也不是空白。CANN承担底层算子和编译，MindSpore是框架层，MindSpeed做训练加速，MindIE做推理引擎，MindCluster做集群调度。华为在2025全联接大会上还明确说，CANN编译器和虚拟指令集接口会开放，其他软件会开源，Mind系列套件也会全面开源。\n问题在于，生态不是发布一个版本就完成迁移。真正的成本在算子覆盖、精度对齐、性能调优、故障定位、长周期训练稳定性，以及团队有没有足够多踩坑经验。很多模型迁移到昇腾上可以跑起来，但要跑到接近硬件上限，仍然需要大量工程优化。\n这也是为什么910C的推理表现可以在特定场景里给人惊喜，但训练场景更难用一个百分比说清楚。推理更容易针对模型和算子做专项优化，训练对稳定性、通信、框架和调参链路的要求更长。\n五、所以，910C到底是H100的几成？ 910C到底是H100的几成，要分场景回答 到这一步，几成这个问题要分层回答，不能用一个数字打发。\n看FP16/BF16稠密峰值，910C大约可以达到H100的七成多到八成左右。这个算法是用910C约752-800 TFLOPS，对比H100稠密约989.5 TFLOPS。这里必须强调，不能拿H100带稀疏的1979 TFLOPS去比910C没有稀疏说明的数字，否则会把差距人为放大。\n看FP8训练能力，910C不能简单按纸面几成算。H100有明确的FP8 Tensor Core峰值和Transformer Engine生态，910C这一代公开资料没有给出同等清晰、可直接对标的FP8单卡口径。FP8这块更适合写成H100明确领先，而不是硬凑一个百分比。\n看公开报道里的特定推理任务，约6成左右这个说法可以引用，但要标明来源边界。Tom\u0026rsquo;s Hardware等媒体曾转述DeepSeek相关测试，称910C在推理任务中达到H100约60%的性能。这个数字对应具体模型、具体工程优化和具体测试条件，不能写成910C全面等于H100的六成。\n看CloudMatrix384这类系统级推理方案，结论又会变得更复杂。论文展示的是超节点和推理框架一起优化后的效果，某些指标可以超过已发表的H100/H800系统结果。但这是系统级方案的胜利，不是单颗910C全面胜过H100。把这两件事混在一起，文章就会失真。\n所以，更稳的结论是：910C是一颗已经能支撑国内大模型推理和部分训练需求的国产大算力芯片，但它不是H100的无损替代。单看FP16稠密峰值，它离H100并不远；看FP8、生态和通用大规模训练，它和H100仍有清晰差距；看华为超节点方案，它的真正竞争力来自系统工程，而不是单卡参数。\n结尾：这不是一场单卡战争，而是一场基础设施战争 NVIDIA的强项，是单卡、互联、软件生态同时领先，三层叠在一起才是它真正的护城河。华为的强项，是国内可规模获得、超节点级别的系统组织能力，加上全栈持续投入。\n未来中国AI算力竞争的核心，大概率不是某一代芯片能不能追平H100，而是国产算力能不能把硬件、互联、软件、模型优化、运维这几块磨合成一套可以持续迭代的系统。\n910C最值得讨论的地方，也不是它到底有H100的几成，而是它让中国AI第一次可以在不完全依赖英伟达的条件下，认真讨论大模型算力的系统工程该怎么搭。\n参考资料 NVIDIA H100官方规格页，H100 SXM Tensor Core峰值、HBM容量、带宽、NVLink带宽及with sparsity说明：https://www.nvidia.com/en-us/data-center/h100/ 华为企业业务Atlas 900 A3 SuperPoD官方页，384张NPU、48TB片上内存、FP16总算力、D2D互联、片上内存带宽等规格：https://e.huawei.com/cn/products/computing/ascend/atlas-900-a3-superpod 华为全联接大会2025徐直军演讲，Ascend 950/960/970路线图、FP8/MXFP8/HiF8支持、2TB/s互联、CANN与Mind系列开源计划：https://www.huawei.com/cn/news/2025/9/hc-xu-keynote-speech CloudMatrix384论文《Serving Large Language Models on Huawei CloudMatrix384》，384颗Ascend 910C、192颗Kunpeng CPU、UB/RDMA/VPC三平面、128GB片上内存、3.2TB/s带宽、推理评测等数据：https://www.researchgate.net/publication/392736927_Serving_Large_Language_Models_on_Huawei_CloudMatrix384 Tom\u0026rsquo;s Hardware关于DeepSeek测试910C推理性能约为H100 60%的报道：https://www.tomshardware.com/tech-industry/artificial-intelligence/deepseek-research-suggests-huaweis-ascend-910c-delivers-60-percent-nvidia-h100-inference-performance 资料边界说明： H100数据以NVIDIA官方规格为准，并区分稠密与稀疏口径。910C单卡数据优先采用Atlas 900 A3和CloudMatrix384等公开系统级资料反推，不把未经官方统一确认的96GB/1.8TB/s等口径写成确定规格。涉及DeepSeek推理性能、CloudMatrix推理效率和950系列路线图的内容，分别按媒体报道、论文测试和厂商路线图处理，不混作同一层证据。\n","permalink":"https://blog.onecai.site/2026/07/26/054-ascend-910c-vs-h100/","summary":"\u003cp\u003e一个问题：昇腾910C到底能打H100的几成？\u003c/p\u003e\n\u003cp\u003e这个问题看着简单，实际很容易问偏。推理、小规模部署、大模型训练、千卡集群，根本不是同一场比赛。910C在每一场里的表现都不一样。\u003c/p\u003e\n\u003cp\u003e先把结论摆在前面：如果只看公开报道里的特定推理任务，可以谈6成左右的口径；如果看大模型训练和大规模集群，答案要保守得多；如果看FP8这类前沿训练能力，差距会更明显。\u003c/p\u003e\n\u003cp\u003e这篇文章不是要证明国产芯片行不行，而是想把一件事讲清楚：910C的价值不是无损替代H100，而是在AI基建很难稳定获得H100的现实里，提供一块可规模部署、可系统堆叠、可持续优化的算力底座。\u003c/p\u003e\n\u003ch2 id=\"一纸面参数对比表先把口径摆正\"\u003e一、纸面参数对比表，先把口径摆正\u003c/h2\u003e\n\u003cp\u003e先看硬件规格。这张表只放最核心的几项，后面每一个结论都要能回到这里。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e规格\u003c/th\u003e\n          \u003cth\u003e昇腾910C\u003c/th\u003e\n          \u003cth\u003eNVIDIA H100 SXM\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP16/BF16算力\u003c/td\u003e\n          \u003ctd\u003e约752-800 TFLOPS，来自Atlas 900 A3整机规格和CloudMatrix论文口径反推\u003c/td\u003e\n          \u003ctd\u003e约989.5 TFLOPS稠密；1,979 TFLOPS为稀疏口径\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP8算力\u003c/td\u003e\n          \u003ctd\u003e公开权威资料未给出可直接对标的910C单卡FP8峰值\u003c/td\u003e\n          \u003ctd\u003e约1,979 TFLOPS稠密；3,958 TFLOPS为稀疏口径\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e片上内存容量\u003c/td\u003e\n          \u003ctd\u003e128GB，见Atlas 900 A3和CloudMatrix相关资料\u003c/td\u003e\n          \u003ctd\u003e80GB HBM3\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e片上内存带宽\u003c/td\u003e\n          \u003ctd\u003e最高约3.2TB/s，见Atlas 900 A3和CloudMatrix相关资料\u003c/td\u003e\n          \u003ctd\u003e3.35TB/s\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e芯片/节点内互联\u003c/td\u003e\n          \u003ctd\u003eAtlas 900 A3标注D2D双向784GB/s；CloudMatrix论文给出UB平面每NPU约392GB/s单向\u003c/td\u003e\n          \u003ctd\u003eNVLink 900GB/s\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e系统形态\u003c/td\u003e\n          \u003ctd\u003eAtlas 900 A3最多384张NPU组成超节点\u003c/td\u003e\n          \u003ctd\u003eHGX/DGX H100常见为8卡节点，并可通过NVLink/NVSwitch与InfiniBand扩展\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ascend-910c-vs-h100-1.avif\"\n          alt=\"参数表不能直接给出答案\"/\u003e \u003cfigcaption\u003e\n             参数表不能直接给出答案\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这张表后面必须加三条提醒，不然很容易被数字带偏。\u003c/p\u003e\n\u003cp\u003e第一，H100的1979 TFLOPS和3958 TFLOPS不是稠密口径。NVIDIA官方规格表在这些Tensor Core峰值后面标了星号，说明是with sparsity，也就是带稀疏加速。要和没有明确稀疏口径的数据比较，H100的FP16/BF16稠密峰值应按约989.5 TFLOPS看，FP8稠密峰值应按约1979 TFLOPS看。\u003c/p\u003e\n\u003cp\u003e第二，910C的单卡数据目前最稳妥的公开来源，不是华为单独发布的一张芯片规格表，而是Atlas 900 A3、CloudMatrix384这类系统级资料。Atlas 900 A3官方页写的是384张NPU、48TB片上内存、片上内存带宽最高3.2TB/s、FP16总算力307.2/288.7 PFLOPS。按这个口径反推，单NPU大约是128GB片上内存、最高3.2TB/s带宽、约800/752 TFLOPS FP16算力。\u003c/p\u003e\n\u003cp\u003e第三，网上常见的96GB、1.8TB/s、HCCS 400GB/s等数字，有些来自分析机构、媒体或早期推断，有些可能对应不同板卡、不同可用容量或不同互联层级。它们不是完全没有参考价值，但不适合写成已经核实确认的统一官方规格。本文后面会尽量用公开来源更清楚的系统级数据，同时把推断和报道口径分开。\u003c/p\u003e\n\u003cp\u003e如果只看FP16稠密峰值，910C和H100的差距没有很多文章写得那么夸张；如果看FP8训练、生态成熟度和大规模集群效率，参数表又会显得太乐观。这就是这篇文章要展开的地方。\u003c/p\u003e\n\u003ch2 id=\"二真实差距一fp8不只是一个数字\"\u003e二、真实差距一：FP8，不只是一个数字\u003c/h2\u003e\n\u003cp\u003eFP8是这轮AI芯片竞争里很关键的一项。它不是把精度从16位砍到8位这么简单，而是牵扯训练稳定性、损失缩放、算子实现、框架支持和模型配方。\u003c/p\u003e\n\u003cp\u003eH100的优势不只是官方表里有FP8峰值。NVIDIA把FP8做进了Hopper架构和Transformer Engine，再配上CUDA、cuDNN、NCCL、TensorRT-LLM、Megatron等工具链和训练经验，形成的是一整套能把低精度真正用起来的工程体系。低精度训练最怕的不是算力不够，而是数值不稳定、精度对不齐、训到一半才发现收益吃不到。\u003c/p\u003e","title":"华为昇腾910C到底能打H100的几成？答案不在参数表里"},{"content":"B站专门做学术论文打假的UP主“耿同学讲故事”，他的风格很上头：一本正经地扒论文里的数据造假证据，配上大量吐槽和段子，把枯燥的学术不端问题讲成了相声。\n看多了会发现一个问题：他每期都在讲不同的院长、教授、Nature子刊，但反复用的检测手法其实高度相似。只是每次都换了案例、换了段子包装，不容易一眼看出规律。\n于是我起了个念头：\n能不能把他全部投稿一次性扒下来，用本地AI帮我把这套隐藏的方法论提炼出来？\n整个过程走了三步：下载、转写、总结。除了从B站获取公开视频，后面的转写和模型分析都在本地电脑上跑完，没有调用云端AI接口。\n准备数据 本地AI内容提炼流水线 这部分其实不是文章的重点，但它决定了后面分析能不能成立。视频要先完整拿到，语音要先转成可检索的文字，最后模型才有材料可总结。\n第一步，批量下载全部投稿 先用一个基于yt-dlp的下载脚本，一次性抓取UP主视频列表页的全部视频。下载了所有的视频，在本地进行视频转音频、音频转文字操作。\n耿同学封面墙 这里有两个实际坑。\n第一个坑是B站风控。投稿列表页不带浏览器cookie直接访问，会被412拒绝。带上cookie之后，脚本才能正常拿到完整投稿列表。\n第二个坑是下载策略。脚本第一次跑的时候，我设置成自动挑选最高画质。结果在正式下载前，yt-dlp会先对整个列表里的每一条视频做一次完整探测，导致跑了很久才真正开始下载。后来改成直接指定画质，跳过这一步，效率提升明显。\n后面还有一次补漏。先前下载中断过，有些视频没下完整。这里用了yt-dlp自带的下载记录文件，也就是download archive机制：把已经下载好的视频ID写进记录文件，再次运行时自动跳过已完成的，只补齐缺的部分。\n最后，155个投稿里成功拿到153个可用视频文件。\n第二步，本地语音转文字 视频到手之后，下一步是把语音内容变成文字稿，方便后续做文本分析。\n这一步用的是本地部署的语音识别模型faster-whisper，模型是large-v3，全程跑在自己电脑上，不依赖任何在线转写服务。\n153个视频，平均单个模型推理耗时不短，累计跑了接近一整天。\n中间出了两个挺有意思的乌龙。\n一个是重复启动了两个进程。因为任务本身耗时很长，我没意识到之前已经有一个转写进程在后台跑了大半天，又手动开了一个新的。两个进程同时抢占了将近900%的CPU，电脑发烫严重，用上电风扇降温了。发现后赶紧把多余的那个关掉，只留一个继续跑。\n另一个是日志假死。Python脚本把输出重定向到文件时，默认是整块缓冲，不是写一行就刷新一次。这导致我盯着日志文件，以为转写卡在了某一集长达一个多小时。实际上程序早就往前跑了十几个文件，只是日志内容还堆在内存缓冲区里没写盘。\n后来不再盯日志，而是看实际产出的txt文件数量，才发现进度一直正常。\n这个坑挺值得记一笔：监控长时间任务，不能只看它打印了什么，得看它实际产出了什么。\n第三步，用本地模型做内容归纳 153份文字稿到手后，发现这位UP主的内容其实很杂。\n除了论文打假，他还聊考研上岸率、读博的精神状态、相亲催婚、科研生活，也有不少直播带货式的科普。我粗筛了一遍，真正逐帧分析论文造假证据的硬核内容，大概40篇左右。\n之后没有直接让模型“总结耿同学的观点”。那样很容易变成几句空话，比如“要重视学术诚信”“要加强科研监管”“要提升论文质量”。这些话都对，但没有用。\n其实真正想知道的是另一件事：\n如果把这些视频当成一个样本库，论文的“假”到底应该从哪些角度分析？\n于是就先让本地模型做关键词检索和初步聚类，重点看“造假”“撤稿”“图片重复”“数据造假”“临床”“代写”“重复实验”“原始数据”等词反复出现的位置。然后再人工抽查高频案例，避免模型把普通科普内容也混进论文打假里。\n跑完之后，一个很清楚的框架浮出来了。\n论文的“假”，不是一个点。它不是只有P图，也不是只有数据编造。真正的问题经常是一条链：图片可疑，数据异常，方法写不清，实验不可重复，结论往外跳，作者回应躲闪，最后学校和期刊再用一句“不规范”把事情盖过去。\n得出的结论 有了这批文字稿之后，真正有价值的不是复述每一期视频讲了谁，而是把反复出现的判断动作抽出来。最后我把它整理成10层，从最容易观察的图片问题，一直推到论文背后的生产链和回应方式。\n第一层，看图片 这是最直观的一层，也是耿同学视频里最常见的入口。\n同一篇论文里，图片重复出现。不同论文里，图片重复出现。图片旋转180度以后还能重合。图片翻转、裁剪、调色以后，背景噪点、组织纹理、细胞形态还能对上。\n这类问题最麻烦的地方在于，它不需要你完全懂论文的专业方向。你不一定知道这个信号通路是否成立，也不一定知道这个动物模型是否合理，但你能看出来两张图是不是同一张。\n尤其是Western blot、细胞图、组织切片、肿瘤照片这些图，背景噪点和纹理就像指纹。它们一旦对上，就很难用“巧合”解释。\n很多作者会把这类问题说成“图片误用”。但“误用”这个词只能解释一次，很难解释一串。如果一个团队的多篇论文、多个项目、多个年份反复出现图片重复，那就不是手滑，更像是一种生产方式。\n第二层，看数据 假数据常常败在随机性 图片问题最直观，但数据问题往往更致命。\n耿同学的视频里，数据统计类分析是很核心的一块。把论文里的原始数据整理出来，看小数点位数是否有跨行、跨列复制粘贴的痕迹，看某几列之间是否存在固定加减关系，看末位数字的分布是否接近随机。\n在没有固定取整规则或仪器偏好的连续测量里，真实数据的末位数字通常不该高度集中在少数几个数字上。如果大量数据都挤在某几个末位，就可以用概率论算出这种巧合发生的概率有多低。\n这类分析的杀伤力在于，它不是说“我觉得不像真的”，而是把问题转成一个统计学判断：这些小概率事件不应该同时发生。\n耿同学吐槽某些论文时，经常会说“下次用随机数生成器”。这句话听起来像玩笑，但背后是一个严肃判断：很多假数据不是因为太复杂被发现，而是因为编得太粗糙。\n真实实验数据通常有噪声。它不会那么听话。\n第三层，看常识能不能对上 有些问题不需要复杂统计，常识就能先挡一遍。\n比如测量精度是否合理，生物学机制是否说得通，实验动物和实验分组是否匹配，疾病和性别是否匹配，样本来源和结论外推是否匹配。\n这类交叉验证看起来很朴素，但很有用。\n论文最容易出问题的地方，往往是作者只盯着想要的结论，忘了现实世界还有很多约束。数据可以编，图片可以修，段落可以写得很漂亮，但常识有时候会从边角里露出来。\n第四层，看原始材料 论文出问题以后，最关键的不是作者怎么解释，而是作者能不能拿出原始材料。\n原始图片在哪里？原始表格在哪里？实验记录在哪里？样本编号在哪里？仪器输出文件在哪里？动物实验和临床研究的伦理审批在哪里？\n这些东西如果都能交代清楚，很多争议可以继续往下讨论。比如图片是否确实贴错了，统计方法是否可以修正，结论是否需要收窄。\n但如果作者只给解释，不给材料，可信度就会迅速下降。\n学术争议不是靠态度解决的。你说“我们没有造假”，这句话本身没有证据价值。真正有价值的是原始数据、实验记录和可以被第三方检查的材料。\n第五层，看实验能不能重复 耿同学反复讲过一个意思：重复实验不是万能的，但重复不出来的实验一定要警惕。\n这句话放在生命科学领域尤其刺耳。\n很多生命科学实验确实复杂。样本来源、细胞状态、动物模型、菌群结构、试剂批次、操作人员都会影响结果。问题是，复杂不能变成免死金牌。\n如果一篇论文的方法写得很模糊，关键材料拿不到，实验条件说不清，只有作者自己能做出来，别人一重复就失败，那它至少不应该被当成一个坚实结论。\n科学研究当然允许失败，允许不确定，也允许后来被推翻。但如果一篇论文从发表那天起就无法被别人验证，它就更像一次性论文。\n第六层，看方法设计有没有先天漏洞 有些论文不一定是直接伪造，但实验设计本身就撑不起结论。\n比如样本量太小，对照组不合理，排除数据没有充分理由，只展示有利结果，用相关性冒充因果性，把动物实验外推到人体，把体外细胞实验外推到临床疗效。\n这类问题更隐蔽，因为它不像图片重复那么一眼可见。\n很多论文最常见的偷换，是从“观察到一个现象”，跳到“证明了一个机制”；从“小鼠身上有效”，跳到“人类疾病有希望”；从“两个变量相关”，跳到“一个变量导致另一个变量”。\n真正读论文，不能只看摘要里的结论。要往回看它是怎么得到这个结论的。实验设计如果站不住，结论写得再热闹也没用。\n第七层，看临床证据够不够 只要涉及药物、保健品、治疗方案，证据等级就要往上提。\n细胞实验不能直接证明药效。动物实验不能直接证明人体有效。早期临床不能替代三期临床。患者反馈不能替代随机、双盲、对照试验。\n耿同学对药效类论文和药物宣传有一个很硬的判断：脱离三期临床谈药效，基本都是耍流氓。\n这句话可能有点冲，但方向是对的。\n尤其是那些打着“重大突破”“全球首个”“传统药物新机制”“治疗老年痴呆”“抗癌新方法”旗号的内容，最应该追问的是：临床证据走到哪一步了？\n有没有正式完成三期临床？样本量多大？终点是什么？是否随机、双盲、对照？是否只是附条件上市？后续验证有没有完成？\n医学论文最危险的地方，是它不只影响论文作者的名声，还会影响病人的选择。\n第八层，看论文是不是流水线产品 单篇论文可疑，可能是个案。多篇论文可疑，就要看背后的生产链。\n一些视频里提到的典型现象包括：不同单位的论文共用图片；作者之间没有交集，但数据重复；多篇论文结构高度相似；同一批肿瘤照片、细胞图、组织切片出现在不同文章里；论文工厂、代写代发、买论文、挂名署名混在一起。\n这时候，问题就不只是“某位作者有没有造假”，而是“这篇论文是怎么被生产出来的”。\n论文一旦变成商品，就会出现供应链。有人负责写，有人负责图，有人负责数据，有人负责投稿，有人负责挂名。最后论文发表出来，看起来像科研成果，其实更像一张发票。\n跨论文重复，往往比单篇论文内部错误更有杀伤力。\n第九层，看作者和成果是否匹配 论文之外，人也要看。\n比如一个本科生一年发几十篇SCI，一个硕士三年发八十多篇论文，一个没有足够学术积累的人突然成了某个领域的代表人物，一个团队长期高产但问题频出，这些都不直接证明论文造假，但它们会提高风险等级。\n科研当然有天才，也有年轻人做出很强成果。但天才也需要解释路径。\n如果一个人的成果数量、论文质量、作者位置、研究跨度和真实训练时间完全不匹配，就应该多问几句：这些论文是谁做的？实验是谁完成的？数据是谁处理的？通讯作者有没有真正把关？\n还有一种情况是头衔包装。\n院士、外籍院士、全球顶尖科学家、青年才俊、某某中心主任，这些称号有时会变成论文的保护层。读者看到头衔，就降低了警惕。\n但论文不是按头衔判真假的。头衔越大，反而越应该把证据摊开。\n第十层，看被质疑后的回应 论文被质疑以后，回应方式本身就是证据的一部分。\n一种回应是证据型回应：公开原始数据，解释每张图的来源，承认错误，申请更正或撤稿，接受独立调查。\n另一种回应是态度型回应：说质疑者不懂，强调团队声誉，发律师函，告人，骂网友，或者用“图片误用”“管理不严”“学生操作失误”一笔带过。\n前者可以让问题继续回到证据上。后者往往是在把问题从证据场拖到权力场。\n如果一篇论文真的没问题，最好的回应不是愤怒，而是把材料拿出来。\n科研不怕质疑。怕的是一被质疑，就只剩情绪和身份。\n这套框架的核心 论文打假10层检查框架 抛开每期的段子包装，耿同学这套论文打假逻辑，大致可以归纳成几层：\n图片证据类：同一张图在不同论文里重复出现，旋转或翻转后完全重合；同一只实验动物的照片，被用在两组本该不同的结果里。\n数据统计类：把论文里的原始数据整理出来，检查小数点位数、末位数字分布、跨行跨列复制粘贴痕迹，以及不同列之间不自然的数学关系。\n常识交叉验证类：用测量精度、生物学常识、疾病和样本匹配关系，去检验数据是否合理。\n外围佐证类：论文产出速度是否远超同行正常水平，是否有论文工厂模板化特征，期刊是否具备正常审稿机制，作者和成果是否匹配。\n这套框架说到底就是一件事：用统计学上的小概率事件不该成串出现，去反推数据造假。\n图片问题只是最直观的入口。真正让造假者难以解释的，是数据本身违反随机性规律，是多个独立异常同时出现，是整条证据链都不稳。\n用AI总结这类内容，最怕总结成空话 这次处理153个txt的小实验，最大的感受是：AI很适合做第一轮整理，但不能把最终判断完全交给模型。\n模型可以帮你找高频词，归纳主题，聚类案例，把“图片重复”“数据异常”“临床证据不足”“代写代发”“不可复现”这些线索拉出来。\n但模型也容易犯两个错误。\n一是把普通科普内容误判成打假内容。因为科普里也会出现“论文”“实验”“数据”“临床”这些词。\n二是把尖锐判断磨平。原视频里很具体的问题，到了模型总结里，可能变成“应加强学术规范”。这就没意思了。\n所以我最后还是做了一轮人工抽查。不是为了替模型干活，而是为了确认它抓出来的模式真的来自文本，而不是从常识里编出来。\n这个过程反而让我更确认，AI总结长内容的价值，不在于替人下结论，而在于把材料铺开，让人更快看到结构。\n写在最后 回头看整个流程，下载、转写、归纳，其实是一条可以复用的本地化内容提炼流水线。\n换成任何一个你感兴趣的博主、播客或者系列讲座，理论上都能这么跑一遍：把几十上百期零散内容，压缩成一份结构化的方法论文档。\n而且从转写到分析，没有一行文字稿经过云端AI接口。对在意隐私，或者不想依赖外部模型服务的人来说，这条路挺值得参考。\n不过这条路也有一个前提：AI只能帮你提炼结构，不能替你负责判断。\n如果以后要判断一篇论文是否可疑，我会按这个顺序看：\n先看图，有没有重复、拼接、翻转、共用背景。\n再看表，数字有没有奇怪规律，统计有没有异常。\n再看常识，测量精度、生物学机制、样本和结论能不能对上。\n再看方法，别人能不能照着做。\n再看原始数据，作者是否能交代清楚。\n再看同团队旧文，是否反复出现类似问题。\n最后看回应，是公开证据，还是用话术压过去。\n一篇论文真不真，不能只看它发在哪，也不能只看作者是谁。真正要看的，是它的证据链能不能一层层站住。\n论文的“假”，通常不是一个破绽，而是一串破绽。\n这也是我从153个视频文字稿里，最想留下来的东西。\n","permalink":"https://blog.onecai.site/2026/07/25/058-geng-tongxue-paper-fake-analysis/","summary":"\u003cp\u003eB站专门做学术论文打假的UP主“耿同学讲故事”，他的风格很上头：一本正经地扒论文里的数据造假证据，配上大量吐槽和段子，把枯燥的学术不端问题讲成了相声。\u003c/p\u003e\n\u003cp\u003e看多了会发现一个问题：他每期都在讲不同的院长、教授、Nature子刊，但反复用的检测手法其实高度相似。只是每次都换了案例、换了段子包装，不容易一眼看出规律。\u003c/p\u003e\n\u003cp\u003e于是我起了个念头：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e能不能把他全部投稿一次性扒下来，用本地AI帮我把这套隐藏的方法论提炼出来？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e整个过程走了三步：下载、转写、总结。除了从B站获取公开视频，后面的转写和模型分析都在本地电脑上跑完，没有调用云端AI接口。\u003c/p\u003e\n\u003ch2 id=\"准备数据\"\u003e准备数据\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"geng-tongxue-paper-fake-analysis-1.avif\"\n          alt=\"本地AI内容提炼流水线\"/\u003e \u003cfigcaption\u003e\n             本地AI内容提炼流水线\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这部分其实不是文章的重点，但它决定了后面分析能不能成立。视频要先完整拿到，语音要先转成可检索的文字，最后模型才有材料可总结。\u003c/p\u003e\n\u003ch3 id=\"第一步批量下载全部投稿\"\u003e第一步，批量下载全部投稿\u003c/h3\u003e\n\u003cp\u003e先用一个基于yt-dlp的下载脚本，一次性抓取UP主视频列表页的全部视频。下载了所有的视频，在本地进行视频转音频、音频转文字操作。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gengs.avif\"\n          alt=\"耿同学封面墙\"/\u003e \u003cfigcaption\u003e\n             耿同学封面墙\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这里有两个实际坑。\u003c/p\u003e\n\u003cp\u003e第一个坑是B站风控。投稿列表页不带浏览器cookie直接访问，会被412拒绝。带上cookie之后，脚本才能正常拿到完整投稿列表。\u003c/p\u003e\n\u003cp\u003e第二个坑是下载策略。脚本第一次跑的时候，我设置成自动挑选最高画质。结果在正式下载前，yt-dlp会先对整个列表里的每一条视频做一次完整探测，导致跑了很久才真正开始下载。后来改成直接指定画质，跳过这一步，效率提升明显。\u003c/p\u003e\n\u003cp\u003e后面还有一次补漏。先前下载中断过，有些视频没下完整。这里用了yt-dlp自带的下载记录文件，也就是download archive机制：把已经下载好的视频ID写进记录文件，再次运行时自动跳过已完成的，只补齐缺的部分。\u003c/p\u003e\n\u003cp\u003e最后，155个投稿里成功拿到153个可用视频文件。\u003c/p\u003e\n\u003ch3 id=\"第二步本地语音转文字\"\u003e第二步，本地语音转文字\u003c/h3\u003e\n\u003cp\u003e视频到手之后，下一步是把语音内容变成文字稿，方便后续做文本分析。\u003c/p\u003e\n\u003cp\u003e这一步用的是本地部署的语音识别模型faster-whisper，模型是large-v3，全程跑在自己电脑上，不依赖任何在线转写服务。\u003c/p\u003e\n\u003cp\u003e153个视频，平均单个模型推理耗时不短，累计跑了接近一整天。\u003c/p\u003e\n\u003cp\u003e中间出了两个挺有意思的乌龙。\u003c/p\u003e\n\u003cp\u003e一个是重复启动了两个进程。因为任务本身耗时很长，我没意识到之前已经有一个转写进程在后台跑了大半天，又手动开了一个新的。两个进程同时抢占了将近900%的CPU，电脑发烫严重，用上电风扇降温了。发现后赶紧把多余的那个关掉，只留一个继续跑。\u003c/p\u003e\n\u003cp\u003e另一个是日志假死。Python脚本把输出重定向到文件时，默认是整块缓冲，不是写一行就刷新一次。这导致我盯着日志文件，以为转写卡在了某一集长达一个多小时。实际上程序早就往前跑了十几个文件，只是日志内容还堆在内存缓冲区里没写盘。\u003c/p\u003e\n\u003cp\u003e后来不再盯日志，而是看实际产出的txt文件数量，才发现进度一直正常。\u003c/p\u003e\n\u003cp\u003e这个坑挺值得记一笔：\u003cstrong\u003e监控长时间任务，不能只看它打印了什么，得看它实际产出了什么。\u003c/strong\u003e\u003c/p\u003e\n\u003ch3 id=\"第三步用本地模型做内容归纳\"\u003e第三步，用本地模型做内容归纳\u003c/h3\u003e\n\u003cp\u003e153份文字稿到手后，发现这位UP主的内容其实很杂。\u003c/p\u003e\n\u003cp\u003e除了论文打假，他还聊考研上岸率、读博的精神状态、相亲催婚、科研生活，也有不少直播带货式的科普。我粗筛了一遍，真正逐帧分析论文造假证据的硬核内容，大概40篇左右。\u003c/p\u003e\n\u003cp\u003e之后没有直接让模型“总结耿同学的观点”。那样很容易变成几句空话，比如“要重视学术诚信”“要加强科研监管”“要提升论文质量”。这些话都对，但没有用。\u003c/p\u003e\n\u003cp\u003e其实真正想知道的是另一件事：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如果把这些视频当成一个样本库，论文的“假”到底应该从哪些角度分析？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e于是就先让本地模型做关键词检索和初步聚类，重点看“造假”“撤稿”“图片重复”“数据造假”“临床”“代写”“重复实验”“原始数据”等词反复出现的位置。然后再人工抽查高频案例，避免模型把普通科普内容也混进论文打假里。\u003c/p\u003e\n\u003cp\u003e跑完之后，一个很清楚的框架浮出来了。\u003c/p\u003e\n\u003cp\u003e论文的“假”，不是一个点。它不是只有P图，也不是只有数据编造。真正的问题经常是一条链：图片可疑，数据异常，方法写不清，实验不可重复，结论往外跳，作者回应躲闪，最后学校和期刊再用一句“不规范”把事情盖过去。\u003c/p\u003e\n\u003ch2 id=\"得出的结论\"\u003e得出的结论\u003c/h2\u003e\n\u003cp\u003e有了这批文字稿之后，真正有价值的不是复述每一期视频讲了谁，而是把反复出现的判断动作抽出来。最后我把它整理成10层，从最容易观察的图片问题，一直推到论文背后的生产链和回应方式。\u003c/p\u003e\n\u003ch3 id=\"第一层看图片\"\u003e第一层，看图片\u003c/h3\u003e\n\u003cp\u003e这是最直观的一层，也是耿同学视频里最常见的入口。\u003c/p\u003e\n\u003cp\u003e同一篇论文里，图片重复出现。不同论文里，图片重复出现。图片旋转180度以后还能重合。图片翻转、裁剪、调色以后，背景噪点、组织纹理、细胞形态还能对上。\u003c/p\u003e\n\u003cp\u003e这类问题最麻烦的地方在于，它不需要你完全懂论文的专业方向。你不一定知道这个信号通路是否成立，也不一定知道这个动物模型是否合理，但你能看出来两张图是不是同一张。\u003c/p\u003e\n\u003cp\u003e尤其是Western blot、细胞图、组织切片、肿瘤照片这些图，背景噪点和纹理就像指纹。它们一旦对上，就很难用“巧合”解释。\u003c/p\u003e\n\u003cp\u003e很多作者会把这类问题说成“图片误用”。但“误用”这个词只能解释一次，很难解释一串。如果一个团队的多篇论文、多个项目、多个年份反复出现图片重复，那就不是手滑，更像是一种生产方式。\u003c/p\u003e\n\u003ch3 id=\"第二层看数据\"\u003e第二层，看数据\u003c/h3\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"geng-tongxue-paper-fake-analysis-2.avif\"\n          alt=\"假数据常常败在随机性\"/\u003e \u003cfigcaption\u003e\n             假数据常常败在随机性\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e图片问题最直观，但数据问题往往更致命。\u003c/p\u003e\n\u003cp\u003e耿同学的视频里，数据统计类分析是很核心的一块。把论文里的原始数据整理出来，看小数点位数是否有跨行、跨列复制粘贴的痕迹，看某几列之间是否存在固定加减关系，看末位数字的分布是否接近随机。\u003c/p\u003e\n\u003cp\u003e在没有固定取整规则或仪器偏好的连续测量里，真实数据的末位数字通常不该高度集中在少数几个数字上。如果大量数据都挤在某几个末位，就可以用概率论算出这种巧合发生的概率有多低。\u003c/p\u003e\n\u003cp\u003e这类分析的杀伤力在于，它不是说“我觉得不像真的”，而是把问题转成一个统计学判断：这些小概率事件不应该同时发生。\u003c/p\u003e\n\u003cp\u003e耿同学吐槽某些论文时，经常会说“下次用随机数生成器”。这句话听起来像玩笑，但背后是一个严肃判断：很多假数据不是因为太复杂被发现，而是因为编得太粗糙。\u003c/p\u003e\n\u003cp\u003e真实实验数据通常有噪声。它不会那么听话。\u003c/p\u003e\n\u003ch3 id=\"第三层看常识能不能对上\"\u003e第三层，看常识能不能对上\u003c/h3\u003e\n\u003cp\u003e有些问题不需要复杂统计，常识就能先挡一遍。\u003c/p\u003e\n\u003cp\u003e比如测量精度是否合理，生物学机制是否说得通，实验动物和实验分组是否匹配，疾病和性别是否匹配，样本来源和结论外推是否匹配。\u003c/p\u003e\n\u003cp\u003e这类交叉验证看起来很朴素，但很有用。\u003c/p\u003e\n\u003cp\u003e论文最容易出问题的地方，往往是作者只盯着想要的结论，忘了现实世界还有很多约束。数据可以编，图片可以修，段落可以写得很漂亮，但常识有时候会从边角里露出来。\u003c/p\u003e\n\u003ch3 id=\"第四层看原始材料\"\u003e第四层，看原始材料\u003c/h3\u003e\n\u003cp\u003e论文出问题以后，最关键的不是作者怎么解释，而是作者能不能拿出原始材料。\u003c/p\u003e\n\u003cp\u003e原始图片在哪里？原始表格在哪里？实验记录在哪里？样本编号在哪里？仪器输出文件在哪里？动物实验和临床研究的伦理审批在哪里？\u003c/p\u003e\n\u003cp\u003e这些东西如果都能交代清楚，很多争议可以继续往下讨论。比如图片是否确实贴错了，统计方法是否可以修正，结论是否需要收窄。\u003c/p\u003e\n\u003cp\u003e但如果作者只给解释，不给材料，可信度就会迅速下降。\u003c/p\u003e\n\u003cp\u003e学术争议不是靠态度解决的。你说“我们没有造假”，这句话本身没有证据价值。真正有价值的是原始数据、实验记录和可以被第三方检查的材料。\u003c/p\u003e\n\u003ch3 id=\"第五层看实验能不能重复\"\u003e第五层，看实验能不能重复\u003c/h3\u003e\n\u003cp\u003e耿同学反复讲过一个意思：重复实验不是万能的，但重复不出来的实验一定要警惕。\u003c/p\u003e\n\u003cp\u003e这句话放在生命科学领域尤其刺耳。\u003c/p\u003e\n\u003cp\u003e很多生命科学实验确实复杂。样本来源、细胞状态、动物模型、菌群结构、试剂批次、操作人员都会影响结果。问题是，复杂不能变成免死金牌。\u003c/p\u003e\n\u003cp\u003e如果一篇论文的方法写得很模糊，关键材料拿不到，实验条件说不清，只有作者自己能做出来，别人一重复就失败，那它至少不应该被当成一个坚实结论。\u003c/p\u003e\n\u003cp\u003e科学研究当然允许失败，允许不确定，也允许后来被推翻。但如果一篇论文从发表那天起就无法被别人验证，它就更像一次性论文。\u003c/p\u003e\n\u003ch3 id=\"第六层看方法设计有没有先天漏洞\"\u003e第六层，看方法设计有没有先天漏洞\u003c/h3\u003e\n\u003cp\u003e有些论文不一定是直接伪造，但实验设计本身就撑不起结论。\u003c/p\u003e","title":"从153个视频到一套方法论：我用本地AI复盘论文打假"},{"content":"三年前，一张旗舰显卡要加价才能买到。\n三年后，同一张卡挂上二手平台，买家问的第一句话往往不是性能怎么样，而是：挖过矿吗？还有没有保？同价位的新卡能不能打？\n没人怀疑它还能不能亮机。真正的问题是，它还值不值这个价。\n显卡的寿命很容易被误解。很多人一说寿命，脑子里想的是风扇坏没坏、显存爆没爆、还能不能开机。可市场给显卡定价时，看的是另一套东西：同价位有没有更新的卡，软件还支不支持新特性，保修还剩多少，拿它赚钱的窗口期还剩多久。\n所以，三年后显卡不值钱，通常不是它坏了，是价格先死了。\n一、显卡身上有四种寿命 一张显卡身上有四种寿命 一张显卡至少有四种寿命。\n物理寿命，看风扇、电容、显存颗粒、供电模块还能不能稳定工作。这是最朴素的坏没坏。\n性能寿命，看同价位新卡出来以后，它还算不算快。显卡自己不会因为过了三年就自动变慢，但别人会变快。\n软件寿命，看新驱动、新编码器、新游戏特性、新模型推理框架还支不支持它。AI场景里尤其明显，有些卡不是慢一点，而是显存不够、算子不合适、部署链路不再优先照顾。\n资产寿命，看账面上、云市场里、二手平台上，它还能不能卖出一个说得过去的价格。\n这四种寿命不是同步结束的。物理寿命常常最长，资产寿命常常最短。一张显卡还能跑游戏、还能剪视频、还能跑小模型，但市场已经不愿意为它的过去溢价买单。\n二、新卡一出，旧旗舰就失去旗舰身份 RTX 4090 与 RTX 5090 改变旧旗舰价格锚 先看最容易理解的消费级例子：RTX 4090和RTX 5090。\nNVIDIA官方规格里，RTX 4090是24GB GDDR6X，显存带宽1008GB/s，起售价1599美元，Tensor Core AI算力标为1321 AI TOPS。RTX 5090是32GB GDDR7，显存带宽1792GB/s，起售价1999美元，AI TOPS标到3352。\n这些数字不应该被简单理解成游戏性能直接翻了多少倍。AI TOPS是特定计算口径下的理论指标，和游戏帧率、本地模型吞吐、真实工作负载之间还有一段距离。可它对二手价格有一个很实际的影响：新旗舰出现后，旧旗舰的价格锚会被拔掉。\n旧卡不再只和自己当年的发售价比较。它会被拿去和新一代中高端卡、同代二手旗舰、云端按小时租用的GPU放在一起算账。\n买家不会因为你当年原价甚至加价买它，就继续按当年的旗舰身份给它估值。二手市场只关心现在这笔钱能买到什么。\n显卡不是古董。它不会因为曾经贵就保值，它会被新一代的显存容量、带宽、功耗、驱动周期和软件特性重新定价。\n三、三年这个时间点，卡在几个现实边界上 显卡三年后为什么变成一个价格坎 三年不是一个精确的技术报废点，但它确实很敏感。\n消费级显卡这边，保修是一个很硬的边界。NVIDIA对自家Founders Edition显卡的保修期是三年，并且条款明确写着，这个保修只覆盖原始购买者，不延伸给二手购买者。不同AIB品牌会有自己的政策，但对二手买家来说，保修确定性下降这件事本身就会压价。\n产品迭代也是一个边界。旗舰显卡通常不会每年换代，但两三年足够让一代新架构、新显存、新DLSS或新编码器进场。到了这个时间点，旧旗舰往往还很强，但它已经不再代表最新体验。\n还有一个容易被忽略的边界：心理账户。\n第一年，买家愿意为旗舰溢价买单，因为它代表最新。第二年，价格开始回到理性区间。第三年以后，买家开始把它当旧卡看，哪怕性能还不错，也会把风险折进去：风扇寿命、显存温度、矿卡嫌疑、保修缺口、未来软件支持。\n这就是为什么很多显卡不是坏了才掉价，而是在确定性变差的时候掉价。\n四、数据中心GPU也在算同一笔账 消费级显卡贬值还只是个人买卖。到了数据中心GPU，这件事会变成财报问题。\n一张H100、H200、B200或同级AI加速卡，不是几千块的配件。它是云厂商和大模型公司资产负债表上的大额硬件。问题就变成了：这些GPU该按几年折旧？\n微软2025年年报里，计算机设备的估计使用寿命是2到6年。Alphabet公开说明，服务器和网络设备通常按6年折旧，并会持续评估技术过时、计划用途和利用率。Meta在2025年把多数服务器和网络资产的估计使用寿命延长到5.5年。Oracle在2025财年把服务器和网络设备使用寿命从5年延到6年。\n但亚马逊给了一个反方向信号。它2024年把服务器寿命从5年延到6年，随后又从2025年开始，把一部分服务器和网络设备从6年缩回5年，理由是技术发展加快，尤其是AI和机器学习领域。\n这些披露放在一起看，比单独看某家公司更有意思：大公司并没有一个统一答案。有人相信服务器可以用得更久，有人开始承认一部分硬件会更快过时。\n数据中心 GPU 的账面寿命和经济寿命 这里要分清两个词。\n折旧年限是会计核算方法，用来把硬件成本分摊进财报。经济寿命看的是这张卡还能不能以有竞争力的价格提供算力。前者可以是五年、六年，后者可能被新架构、新能耗比、新租赁价格提前压缩。\n公司账上可以慢慢折，市场心里会提前折。\n五、AI给旧卡续了命，也给旧卡设了新门槛 AI 让旧卡续命，也让旧卡台阶式失效 AI让显卡市场变得更复杂了。\n以前很多人看显卡，主要看游戏帧率。现在本地大模型玩家会先看显存。24GB的RTX 3090、RTX 4090，哪怕不是最新架构，只要能装下模型和KV Cache，就还有很强的二手需求。\n这也是为什么有些老卡在游戏玩家眼里已经不新了，在AI玩家眼里还很有用。显存容量给它续了一次命。\n但AI也让旧卡更容易台阶式失效。\n游戏里从80帧掉到60帧，用户还能忍。模型部署里，如果显存从刚好够变成不够，体验就不是慢一点，而是跑不起来。新模型上下文更长、量化方案变了、推理框架优先适配新架构，都会让一张旧卡突然从可用变成尴尬。\n所以AI不是单纯让所有显卡更保值。它只是让一部分旧卡因为大显存获得第二春，同时也把市场从看帧率推到看显存、带宽、算子支持、能耗和部署成本。\n六、二手市场最怕的不是旧，是不确定 二手显卡的价格，很多时候不是按性能打折，而是按不确定性打折。\n有没有挖过矿，买家不知道。显存长期温度高不高，买家不知道。风扇轴承还剩多少寿命，买家不知道。上一任用户有没有拆修、烤机、刷BIOS，买家也不知道。\n卖家说一切正常，买家只能把风险折进价格里。\n保修也是同一个逻辑。原始购买者手里还有发票、有售后入口，二手买家手里未必有。哪怕卡本身没问题，只要售后确定性下降，价格就会下降。\n这也是为什么同一型号显卡，有发票、箱说全、成色好、来源清楚的卡，会比来路不明的卡贵。它贵的不是那一点纸盒和贴纸，而是少了一层风险。\n七、三年后它不值钱，不是因为不能用 回到开头的问题：为什么一张显卡三年后就不值钱了？\n它们不会在三年后集体报废。多数显卡只要散热正常、供电稳定、使用环境不恶劣，用五年甚至更久都不稀奇。\n真正变化的是它所在的市场位置。\n新卡出来后，它的性能锚变了。保修快到期或不再覆盖二手买家后，它的风险锚变了。AI工作负载变化后，它的软件门槛变了。云厂商和资本市场重新计算GPU折旧后，它的资产故事也变了。\n三年这个数字之所以显得像个坎，是因为它刚好卡在几条曲线交叉的位置：一代新架构大概率已经出现，保修确定性开始下降，旧旗舰溢价消失，市场开始用剩余价值给它定价。\n一张显卡真正的价格寿命，从市场愿意为它的性能付溢价开始，到只愿意为它的剩余价值出价结束。\n资料来源\nNVIDIA GeForce RTX 4090官方规格与起售价：https://www.nvidia.com/en-us/geforce/graphics-cards/40-series/rtx-4090/ NVIDIA GeForce RTX 5090官方规格与起售价：https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/ NVIDIA RTX 50系列发布信息：https://nvidianews.nvidia.com/news/nvidia-blackwell-geforce-rtx-50-series-opens-new-world-of-ai-computer-graphics NVIDIA显卡保修条款：https://www.nvidia.com/en-us/support/warranty/graphics-cards/ Microsoft 2025 Annual Report：https://www.microsoft.com/investor/reports/ar25/index.html Alphabet投资者关系折旧说明：https://alphabet2025ir.q4web.com/investor/faqs-and-general-information/ Meta 2025 Form 10-K：https://www.sec.gov/Archives/edgar/data/1326801/000162828026025534/meta-12312025x10kars.htm Oracle 2025 Form 10-K：https://www.sec.gov/Archives/edgar/data/1341439/000095017025087926/orcl-20250531.htm Amazon 2024 Form 10-K披露的服务器寿命调整：https://www.sec.gov/Archives/edgar/data/1018724/000101872425000004/amzn-20241231.htm ","permalink":"https://blog.onecai.site/2026/07/25/053-gpu-lifespan-three-years-v2/","summary":"\u003cp\u003e三年前，一张旗舰显卡要加价才能买到。\u003c/p\u003e\n\u003cp\u003e三年后，同一张卡挂上二手平台，买家问的第一句话往往不是性能怎么样，而是：挖过矿吗？还有没有保？同价位的新卡能不能打？\u003c/p\u003e\n\u003cp\u003e没人怀疑它还能不能亮机。真正的问题是，它还值不值这个价。\u003c/p\u003e\n\u003cp\u003e显卡的寿命很容易被误解。很多人一说寿命，脑子里想的是风扇坏没坏、显存爆没爆、还能不能开机。可市场给显卡定价时，看的是另一套东西：同价位有没有更新的卡，软件还支不支持新特性，保修还剩多少，拿它赚钱的窗口期还剩多久。\u003c/p\u003e\n\u003cp\u003e所以，\u003cstrong\u003e三年后显卡不值钱，通常不是它坏了，是价格先死了。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"一显卡身上有四种寿命\"\u003e一、显卡身上有四种寿命\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-lifespan-three-years-v2-1.avif\"\n          alt=\"一张显卡身上有四种寿命\"/\u003e \u003cfigcaption\u003e\n             一张显卡身上有四种寿命\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e一张显卡至少有四种寿命。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e物理寿命\u003c/strong\u003e，看风扇、电容、显存颗粒、供电模块还能不能稳定工作。这是最朴素的坏没坏。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e性能寿命\u003c/strong\u003e，看同价位新卡出来以后，它还算不算快。显卡自己不会因为过了三年就自动变慢，但别人会变快。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e软件寿命\u003c/strong\u003e，看新驱动、新编码器、新游戏特性、新模型推理框架还支不支持它。AI场景里尤其明显，有些卡不是慢一点，而是显存不够、算子不合适、部署链路不再优先照顾。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e资产寿命\u003c/strong\u003e，看账面上、云市场里、二手平台上，它还能不能卖出一个说得过去的价格。\u003c/p\u003e\n\u003cp\u003e这四种寿命不是同步结束的。物理寿命常常最长，资产寿命常常最短。一张显卡还能跑游戏、还能剪视频、还能跑小模型，但市场已经不愿意为它的过去溢价买单。\u003c/p\u003e\n\u003ch2 id=\"二新卡一出旧旗舰就失去旗舰身份\"\u003e二、新卡一出，旧旗舰就失去旗舰身份\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-lifespan-three-years-v2-2.avif\"\n          alt=\"RTX 4090 与 RTX 5090 改变旧旗舰价格锚\"/\u003e \u003cfigcaption\u003e\n             RTX 4090 与 RTX 5090 改变旧旗舰价格锚\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e先看最容易理解的消费级例子：RTX 4090和RTX 5090。\u003c/p\u003e\n\u003cp\u003eNVIDIA官方规格里，RTX 4090是24GB GDDR6X，显存带宽1008GB/s，起售价1599美元，Tensor Core AI算力标为1321 AI TOPS。RTX 5090是32GB GDDR7，显存带宽1792GB/s，起售价1999美元，AI TOPS标到3352。\u003c/p\u003e\n\u003cp\u003e这些数字不应该被简单理解成游戏性能直接翻了多少倍。AI TOPS是特定计算口径下的理论指标，和游戏帧率、本地模型吞吐、真实工作负载之间还有一段距离。可它对二手价格有一个很实际的影响：新旗舰出现后，旧旗舰的价格锚会被拔掉。\u003c/p\u003e\n\u003cp\u003e旧卡不再只和自己当年的发售价比较。它会被拿去和新一代中高端卡、同代二手旗舰、云端按小时租用的GPU放在一起算账。\u003c/p\u003e\n\u003cp\u003e买家不会因为你当年原价甚至加价买它，就继续按当年的旗舰身份给它估值。二手市场只关心现在这笔钱能买到什么。\u003c/p\u003e\n\u003cp\u003e显卡不是古董。它不会因为曾经贵就保值，它会被新一代的显存容量、带宽、功耗、驱动周期和软件特性重新定价。\u003c/p\u003e\n\u003ch2 id=\"三三年这个时间点卡在几个现实边界上\"\u003e三、三年这个时间点，卡在几个现实边界上\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-lifespan-three-years-v2-3.avif\"\n          alt=\"显卡三年后为什么变成一个价格坎\"/\u003e \u003cfigcaption\u003e\n             显卡三年后为什么变成一个价格坎\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e三年不是一个精确的技术报废点，但它确实很敏感。\u003c/p\u003e\n\u003cp\u003e消费级显卡这边，保修是一个很硬的边界。NVIDIA对自家Founders Edition显卡的保修期是三年，并且条款明确写着，这个保修只覆盖原始购买者，不延伸给二手购买者。不同AIB品牌会有自己的政策，但对二手买家来说，保修确定性下降这件事本身就会压价。\u003c/p\u003e\n\u003cp\u003e产品迭代也是一个边界。旗舰显卡通常不会每年换代，但两三年足够让一代新架构、新显存、新DLSS或新编码器进场。到了这个时间点，旧旗舰往往还很强，但它已经不再代表最新体验。\u003c/p\u003e\n\u003cp\u003e还有一个容易被忽略的边界：心理账户。\u003c/p\u003e\n\u003cp\u003e第一年，买家愿意为旗舰溢价买单，因为它代表最新。第二年，价格开始回到理性区间。第三年以后，买家开始把它当旧卡看，哪怕性能还不错，也会把风险折进去：风扇寿命、显存温度、矿卡嫌疑、保修缺口、未来软件支持。\u003c/p\u003e\n\u003cp\u003e这就是为什么很多显卡不是坏了才掉价，而是在确定性变差的时候掉价。\u003c/p\u003e\n\u003ch2 id=\"四数据中心gpu也在算同一笔账\"\u003e四、数据中心GPU也在算同一笔账\u003c/h2\u003e\n\u003cp\u003e消费级显卡贬值还只是个人买卖。到了数据中心GPU，这件事会变成财报问题。\u003c/p\u003e\n\u003cp\u003e一张H100、H200、B200或同级AI加速卡，不是几千块的配件。它是云厂商和大模型公司资产负债表上的大额硬件。问题就变成了：这些GPU该按几年折旧？\u003c/p\u003e\n\u003cp\u003e微软2025年年报里，计算机设备的估计使用寿命是2到6年。Alphabet公开说明，服务器和网络设备通常按6年折旧，并会持续评估技术过时、计划用途和利用率。Meta在2025年把多数服务器和网络资产的估计使用寿命延长到5.5年。Oracle在2025财年把服务器和网络设备使用寿命从5年延到6年。\u003c/p\u003e\n\u003cp\u003e但亚马逊给了一个反方向信号。它2024年把服务器寿命从5年延到6年，随后又从2025年开始，把一部分服务器和网络设备从6年缩回5年，理由是技术发展加快，尤其是AI和机器学习领域。\u003c/p\u003e\n\u003cp\u003e这些披露放在一起看，比单独看某家公司更有意思：大公司并没有一个统一答案。有人相信服务器可以用得更久，有人开始承认一部分硬件会更快过时。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-lifespan-three-years-v2-4.avif\"\n          alt=\"数据中心 GPU 的账面寿命和经济寿命\"/\u003e \u003cfigcaption\u003e\n             数据中心 GPU 的账面寿命和经济寿命\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这里要分清两个词。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e折旧年限\u003c/strong\u003e是会计核算方法，用来把硬件成本分摊进财报。\u003cstrong\u003e经济寿命\u003c/strong\u003e看的是这张卡还能不能以有竞争力的价格提供算力。前者可以是五年、六年，后者可能被新架构、新能耗比、新租赁价格提前压缩。\u003c/p\u003e\n\u003cp\u003e公司账上可以慢慢折，市场心里会提前折。\u003c/p\u003e\n\u003ch2 id=\"五ai给旧卡续了命也给旧卡设了新门槛\"\u003e五、AI给旧卡续了命，也给旧卡设了新门槛\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"gpu-lifespan-three-years-v2-5.avif\"\n          alt=\"AI 让旧卡续命，也让旧卡台阶式失效\"/\u003e \u003cfigcaption\u003e\n             AI 让旧卡续命，也让旧卡台阶式失效\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eAI让显卡市场变得更复杂了。\u003c/p\u003e","title":"一张显卡的寿命：为什么三年后它就不值钱了？"},{"content":"发布会上，厂商介绍自己产品说：“这张卡有20P算力。”\n台下鼓掌，媒体标题写“史上最强”。\n但如果你去翻这张卡的官方数据表，会在某些Tensor Core算力项目旁边发现一个不起眼的星号（*），点开脚注可能写着一句话：这些数字采用稀疏（with sparsity）口径，不开稀疏时规格减半。\n也就是说，发布会现场说的“20P”，实际稠密算力可能只有10P，甚至更低。这不是哪家厂商偷偷作弊，而是官方规格表里公开写明、但作为读者很容易忽略的口径差异。稀疏算力到底是怎么把数字翻倍的，各家发布会都是怎么报的，你自己该怎么一眼识别。\n一、稀疏矩阵：先搞懂“挑重点做事”是什么意思 2:4 结构化稀疏到底在跳过什么 想象一张100道题的试卷，你负责批改。\n如果学生认认真真答满了100道题，你就得老老实实判100道。这叫稠密（dense）——矩阵里的每一个格子都有实际数值，硬件必须逐一参与计算，一个都不能少。\n但现在硬件支持一种更规整的做法：如果模型权重已经满足每连续4个数里，至少2个是0，硬件就可以跳过这些0，只处理剩下的非零值。于是同样一张卡，理论吞吐量能翻一倍。这套规则在业内有个专门的名字，叫 2:4结构化稀疏（structured sparsity）：每4个权重里，至少2个被清零，硬件按这个固定模式压缩权重，再用专门的稀疏Tensor Core路径做乘加运算。\n这里有个关键点很容易被忽略：试卷本身还是100道题，矩阵的规模一点没变。稀疏拿到的“2倍算力”，本质上是“跳过一半计算量”换来的相对加速比，而不是芯片真的凭空多长出一倍的晶体管。而且，这活儿不是白捡的——想让权重乖乖满足“每4个里至少2个是0”这个苛刻条件，通常需要专门用稀疏化训练或剪枝去“驯服”模型，很多实际生产模型并不会做这一步，也就吃不到这个加速。这也是为什么行业里有个粗暴但好用的经验：只要数据表里出现“稀疏”字样，这个数字大概率要打对折才是普通任务能拿到的真实水平。\n二、稀疏vs稠密算力对照表：以H100、B200为例 这套“稀疏=稠密两倍”的写法，其实不是从H100、B200才开始的，往前翻一代就能找到源头。NVIDIA官方A100规格页上，同一类Tensor Core算力经常以稠密和稀疏两个口径出现：比如BF16/FP16可以看到312 TFLOPS和624 TFLOPS这一组数字，脚注专门标注了“With sparsity”。也就是说，从Ampere架构这一代开始，“稀疏峰值”就已经是NVIDIA官方规格表里的正式口径了，H100、Blackwell只是把这套写法延续了下去。\n不用猜，直接看NVIDIA自己的官方规格页怎么写。H100 SXM的BF16/FP16 Tensor Core写成1979 TFLOPS，FP8写成3958 TFLOPS，脚注说明这些数字采用稀疏技术显示，不采用稀疏技术时规格降低一半。换成稠密口径，H100 SXM的BF16/FP16大约是989.5 TFLOPS，FP8大约是1979 TFLOPS。到了Blackwell一代，NVIDIA GB200 NVL72的规格表延续同样的写法，直接把sparse和dense并排列出，GB200 Grace Blackwell Superchip的NVFP4张量算力写成“40 | 20 PFLOPS”，脚注同样注明稠密规格是稀疏规格的一半——这里的40 PFLOPS是稀疏口径，20 PFLOPS才是稠密口径，而且它背后其实叠了两层变化：一层是从FP16/FP8换到更激进的FP4（精度每降一档，算力翻一倍），另一层才是稀疏本身。两层叠在一起，喊出来的最大数字很容易比一张卡在常规模型里能用上的算力高很多。\n不止NVIDIA一家这么标。AMD Instinct系列的官方规格页也会把“普通峰值”和“结构化稀疏峰值”分开列：8卡MI300X平台的FP16矩阵算力，官方给的是稠密约10.5 PFLOPS、带结构化稀疏约20.9 PFLOPS；更新的MI355X单卡上，FP16/BF16矩阵算力是稠密2.5 PFLOPS、稀疏5 PFLOPS，INT8则是稠密约5 POPS、稀疏约10.1 POPS。可以看到，AMD的倍率关系和NVIDIA完全一致，都是稀疏正好翻一倍，只是AMD官方页面通常把两栏都摆在明面上，读者不用扒脚注就能看到对比。\n稀疏算力 vs 稠密算力，为什么总是 2× 芯片 / 精度 稠密算力（真实基线） 稀疏算力（发布会/宣传常用） 倍率 A100 SXM · BF16/FP16 312 TFLOPS 624 TFLOPS 2× H100 · FP16/BF16 约990 TFLOPS 约1980 TFLOPS 2× H100 · FP8 约1980 TFLOPS 约3960 TFLOPS 2× B200 SXM · FP8/FP6 约4.5 PFLOPS 约9 PFLOPS 2× B200 SXM · FP4 约9 PFLOPS 约18 PFLOPS 2× GB200 Grace Blackwell Superchip · NVFP4 20 PFLOPS 40 PFLOPS 2× AMD MI300X（8卡平台）· FP16 约10.5 PFLOPS 约20.9 PFLOPS 2× AMD MI355X（单卡）· FP16/BF16 2.5 PFLOPS 5 PFLOPS 2× 这里要提醒一句：稀疏加速不是“想用就用”。2:4结构化稀疏要求每连续4个权重里至少2个为零，模型通常需要经过剪枝和微调，才能满足这个模式并尽量恢复精度。不做这一步，硬件的稀疏加速路径就用不上。所以对很多直接部署、没有专门做稀疏化处理的生产模型来说，实际更接近表格左边那一列，稠密算力。\n三、各家发布会，常用哪种口径？ 不同厂商如何呈现 dense / sparse 算力 NVIDIA：明牌打稀疏，但脚注写得清清楚楚。 从A100那代开始，NVIDIA就把“稀疏”当成官方精度阶梯的正式一环写进数据表，发布会喊的都是打满buff后的数字，但官方PDF里从来没藏着不给稠密数字——脚注一直都在，只是没人细看。这算是“阳谋”：数字最好看，但证据也留在纸面上。\nAMD：两栏都摆在明面上，反而更好读。 AMD Instinct系列的官方规格页习惯把“普通峰值”和“带结构化稀疏峰值”并排列出，不用翻脚注就能直接对比。不过要注意，AMD在对外做竞品对比图（比如拿MI300X对比H100）时，用的同样是稀疏口径，这一点和NVIDIA是一致的——两家比拼的“更强”，往往都是稀疏对稀疏。\nIntel Gaudi：干脆不把稀疏当成主打卖点。 Intel Gaudi系列的公开资料更常强调FP8、BF16相比上一代提升了多少，以及网络、显存这些系统层面的特性，“稀疏”没有被当作首页最核心的标签来讲。这提醒我们一件事：不是所有厂商都爱打稀疏这张牌，读到Gaudi这类页面时，重点应该先看精度和系统口径，不要把所有的“翻倍”都自动脑补成稀疏在起作用。\n国产芯片：公开资料里较少直接拆出dense / sparse两栏，不能主动脑补。 从公开的路线图和评测材料看，国内不少芯片发布页面会直接报FP16、FP8、FP4或INT8算力，但不一定像NVIDIA、AMD那样，把稠密和稀疏两栏拆得很清楚。比如2026年7月华为在世界人工智能大会（WAIC）上真机首秀的Atlas 950 SuperPoD超节点，官方对外公布的是1024卡规模、1 EFLOPS FP8、2 EFLOPS FP4，以及256TB全局统一内存编址空间——这个页面强调的是超节点规模、低精度格式和互联架构，公开文本里没有把这些数字拆成“稠密 / 稀疏”两种口径。\n遇到这种情况，最稳妥的做法是按页面标出的这个数字直接理解，既不要自己主动打对折，也不要脑补成“这背后一定还有个稀疏翻倍版本”——没有证据支持的方向，宁可不脑补，对文章里没写清楚的一方也不要替它下结论。换句话说：同样是“没标注稀疏”的数字，含义可能是不一样的——有的是因为产品资料压根不讲这件事，有的是因为功能、软件栈、应用场景还没展开说明。这个格局本身在快速变化，后续型号什么时候开始正式打“稀疏”这张牌，值得持续关注，读者看到具体型号时最好还是按下面的自查方法过一遍，而不是直接套用“国产=稠密”这个印象。\n通用规律：越靠近推理场景（FP8/FP4/INT8），厂商越爱强调稀疏；越靠近训练和科学计算（FP16/FP32/FP64），稀疏这张牌用得越少。 原因也很直接——训练阶段模型权重本身很少满足2:4稀疏的苛刻条件，稀疏加速在训练里能落地的场景有限；反而是推理阶段，配合量化和裁剪，更容易凑出这个“每4个里2个是0”的结构。\n四、读者怎么在参数表里一眼识别？ 读显卡参数表的 6 步自查法 最简单的办法是先问自己四个问题：这是FP16/BF16、FP8还是FP4？这是稠密还是稀疏？这是单卡还是整机、整柜？这是理论峰值还是模型实测吞吐？ 只要这四个问题里有任何一个答不上来，这个数字基本上就只是用来挂在PPT上好看的，先别急着拿来做判断依据。\n想再细一点，可以按这几步快速自查：\n先找“sparsity / 稀疏 / 2:4”这几个字。只要数据表任何角落出现这几个词，不管是不是加了星号，都要先确认这个数字是不是打了2倍buff之后的口径。 看是不是并排列了两个数字。规范一点的数据表通常会把稠密和稀疏两栏并排列出来。比如GB200官方表格把NVFP4写成40 | 20 PFLOPS，挑小的那个当作稠密基线。 认精度。FP4 \u0026lt; FP8 \u0026lt; FP16/BF16 \u0026lt; TF32 \u0026lt; FP32 \u0026lt; FP64，精度每降一档，理论算力大致翻一倍。发布会如果拿最激进的FP4/INT4数字去和别家的FP16数字比，这已经不是稀疏的问题了，是连精度基准都没对齐。 两把尺子叠加算总账。如果一个数字同时踩中了“更低精度”和“开启稀疏”两个buff，相对于稠密FP16基线，理论上限可能被放大4倍左右——这也是“2P算力”实际到手可能只有1P甚至更低的常见来源。 对训练场景多一份警惕。凡是宣传“能训练XX亿参数大模型”却只报了稀疏/低精度数字的，建议直接打对折甚至打两折去理解，因为训练阶段真正吃满稀疏加速的场景并不多，实际有效算力（MFU）通常还要再打折扣。 确认这是单卡还是整机整柜。看到platform、rack、NVL72、8-GPU这类字样，先搞清楚这是把好几张卡加总之后的数字，不是单卡本身的算力——单卡数字和整柜数字放在一起比，本身就不是一回事。 说到底，“稀疏算力”不是骗局，它是真实存在的硬件能力，前提是你的模型愿意为它做专门的适配。但对大多数人来说，脱离“是否稀疏、什么精度”去谈一个孤零零的算力数字，基本等于没说——先问清楚这个“P”是哪个“P”，才是看懂一张显卡参数表的第一步。\n主要参考资料 NVIDIA官方技术博客对结构化稀疏（2:4模式）原理的介绍：https://developer.nvidia.com/blog/structured-sparsity-in-the-nvidia-ampere-architecture-and-applications-in-search-engines/ NVIDIA A100官方产品规格页：https://www.nvidia.com/en-gb/data-center/a100/ NVIDIA H100官方产品规格页：https://www.nvidia.com/en-us/data-center/h100/ NVIDIA GB200 NVL72官方产品规格页：https://www.nvidia.com/en-us/data-center/gb200-nvl72/ AMD Instinct MI300X平台官方规格页：https://www.amd.com/en/products/accelerators/instinct/mi300/platform.html AMD Instinct MI355X官方产品规格页：https://www.amd.com/en/products/accelerators/instinct/mi350/mi355x.html 华为官网：昇腾950超节点（Atlas 950 SuperPoD）WAIC 2026真机首秀报道：https://www.huawei.com/cn/news/2026/7/atlas-950-superpod ","permalink":"https://blog.onecai.site/2026/07/24/052-sparse-vs-dense-compute/","summary":"\u003cp\u003e发布会上，厂商介绍自己产品说：“这张卡有20P算力。”\u003c/p\u003e\n\u003cp\u003e台下鼓掌，媒体标题写“史上最强”。\u003c/p\u003e\n\u003cp\u003e但如果你去翻这张卡的官方数据表，会在某些Tensor Core算力项目旁边发现一个不起眼的星号（*），点开脚注可能写着一句话：\u003cstrong\u003e这些数字采用稀疏（with sparsity）口径，不开稀疏时规格减半。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e也就是说，发布会现场说的“20P”，实际稠密算力可能只有10P，甚至更低。这不是哪家厂商偷偷作弊，而是官方规格表里公开写明、但作为读者很容易忽略的口径差异。\u003cstrong\u003e稀疏算力到底是怎么把数字翻倍的，各家发布会都是怎么报的，你自己该怎么一眼识别。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"一稀疏矩阵先搞懂挑重点做事是什么意思\"\u003e一、稀疏矩阵：先搞懂“挑重点做事”是什么意思\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"sparse-vs-dense-compute-1.avif\"\n          alt=\"2:4 结构化稀疏到底在跳过什么\"/\u003e \u003cfigcaption\u003e\n             2:4 结构化稀疏到底在跳过什么\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e想象一张100道题的试卷，你负责批改。\u003c/p\u003e\n\u003cp\u003e如果学生认认真真答满了100道题，你就得老老实实判100道。这叫\u003cstrong\u003e稠密（dense）\u003c/strong\u003e——矩阵里的每一个格子都有实际数值，硬件必须逐一参与计算，一个都不能少。\u003c/p\u003e\n\u003cp\u003e但现在硬件支持一种更规整的做法：如果模型权重已经满足\u003cstrong\u003e每连续4个数里，至少2个是0\u003c/strong\u003e，硬件就可以跳过这些0，只处理剩下的非零值。于是同样一张卡，理论吞吐量能翻一倍。这套规则在业内有个专门的名字，叫 \u003cstrong\u003e2:4结构化稀疏（structured sparsity）\u003c/strong\u003e：每4个权重里，至少2个被清零，硬件按这个固定模式压缩权重，再用专门的稀疏Tensor Core路径做乘加运算。\u003c/p\u003e\n\u003cp\u003e这里有个关键点很容易被忽略：\u003cstrong\u003e试卷本身还是100道题，矩阵的规模一点没变\u003c/strong\u003e。稀疏拿到的“2倍算力”，本质上是“跳过一半计算量”换来的相对加速比，而不是芯片真的凭空多长出一倍的晶体管。而且，这活儿不是白捡的——想让权重乖乖满足“每4个里至少2个是0”这个苛刻条件，通常需要专门用稀疏化训练或剪枝去“驯服”模型，很多实际生产模型并不会做这一步，也就吃不到这个加速。这也是为什么行业里有个粗暴但好用的经验：\u003cstrong\u003e只要数据表里出现“稀疏”字样，这个数字大概率要打对折才是普通任务能拿到的真实水平。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二稀疏vs稠密算力对照表以h100b200为例\"\u003e二、稀疏vs稠密算力对照表：以H100、B200为例\u003c/h2\u003e\n\u003cp\u003e这套“稀疏=稠密两倍”的写法，其实不是从H100、B200才开始的，往前翻一代就能找到源头。NVIDIA官方A100规格页上，同一类Tensor Core算力经常以稠密和稀疏两个口径出现：比如BF16/FP16可以看到312 TFLOPS和624 TFLOPS这一组数字，脚注专门标注了“With sparsity”。也就是说，从Ampere架构这一代开始，“稀疏峰值”就已经是NVIDIA官方规格表里的正式口径了，H100、Blackwell只是把这套写法延续了下去。\u003c/p\u003e\n\u003cp\u003e不用猜，直接看NVIDIA自己的官方规格页怎么写。H100 SXM的BF16/FP16 Tensor Core写成1979 TFLOPS，FP8写成3958 TFLOPS，脚注说明这些数字采用稀疏技术显示，不采用稀疏技术时规格降低一半。\u003cem\u003e\u003cstrong\u003e换成稠密口径\u003c/strong\u003e\u003c/em\u003e，H100 SXM的BF16/FP16大约是989.5 TFLOPS，FP8大约是1979 TFLOPS。到了Blackwell一代，NVIDIA GB200 NVL72的规格表延续同样的写法，直接把sparse和dense并排列出，GB200 Grace Blackwell Superchip的NVFP4张量算力写成“40 | 20 PFLOPS”，脚注同样注明稠密规格是稀疏规格的一半——这里的40 PFLOPS是稀疏口径，20 PFLOPS才是稠密口径，而且它背后其实叠了两层变化：一层是从FP16/FP8换到更激进的FP4（精度每降一档，算力翻一倍），另一层才是稀疏本身。两层叠在一起，喊出来的最大数字很容易比一张卡在常规模型里能用上的算力高很多。\u003c/p\u003e\n\u003cp\u003e不止NVIDIA一家这么标。AMD Instinct系列的官方规格页也会把“普通峰值”和“结构化稀疏峰值”分开列：8卡MI300X平台的FP16矩阵算力，官方给的是稠密约10.5 PFLOPS、带结构化稀疏约20.9 PFLOPS；更新的MI355X单卡上，FP16/BF16矩阵算力是稠密2.5 PFLOPS、稀疏5 PFLOPS，INT8则是稠密约5 POPS、稀疏约10.1 POPS。可以看到，AMD的倍率关系和NVIDIA完全一致，都是稀疏正好翻一倍，只是AMD官方页面通常把两栏都摆在明面上，读者不用扒脚注就能看到对比。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"sparse-vs-dense-compute-2.avif\"\n          alt=\"稀疏算力 vs 稠密算力，为什么总是 2×\"/\u003e \u003cfigcaption\u003e\n             稀疏算力 vs 稠密算力，为什么总是 2×\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth style=\"text-align: center\"\u003e芯片 / 精度\u003c/th\u003e\n          \u003cth style=\"text-align: center\"\u003e稠密算力（真实基线）\u003c/th\u003e\n          \u003cth style=\"text-align: center\"\u003e稀疏算力（发布会/宣传常用）\u003c/th\u003e\n          \u003cth style=\"text-align: center\"\u003e倍率\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eA100 SXM · BF16/FP16\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e312 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e624 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eH100 · FP16/BF16\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约990 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约1980 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eH100 · FP8\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约1980 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约3960 TFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eB200 SXM · FP8/FP6\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约4.5 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约9 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eB200 SXM · FP4\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约9 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约18 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eGB200 Grace Blackwell Superchip · NVFP4\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e20 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e40 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eAMD MI300X（8卡平台）· FP16\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约10.5 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约20.9 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eAMD MI355X（单卡）· FP16/BF16\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2.5 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e5 PFLOPS\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e2×\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这里要提醒一句：稀疏加速不是“想用就用”。2:4结构化稀疏要求每连续4个权重里至少2个为零，模型通常需要经过剪枝和微调，才能满足这个模式并尽量恢复精度。不做这一步，硬件的稀疏加速路径就用不上。所以对很多直接部署、没有专门做稀疏化处理的生产模型来说，实际更接近表格左边那一列，稠密算力。\u003c/p\u003e","title":"显卡的“稀疏算力”是怎么把数字吹一倍的？"},{"content":"上一篇聊完“1P算力”到底是什么，初次接触这个概念，可能还会常被问到一句话：\n“那这1P，跑起来是不是真的能打满？”\n答案可能有点扎心：大概率打不满，而且差得不少。 一个标称1P（FP16）的顶级AI卡，真正拿去训练大模型时，能稳定发挥出0.3P到0.5P，就已经算是业内的好成绩了。\n更让人困惑的是：打开 nvidia-smi 看，GPU利用率不低，风扇在转，功耗上去了，账单更是一秒没停。但模型每秒吃进去的token，就是比按峰值算出来的少一大截。这中间差掉的0.5P到0.7P，去哪儿了？\n一、先认识这个词：MFU MFU，全称 Model FLOPs Utilization，模型算力利用率。这个词是Google在2022年的PaLM论文里正式提出并普及开的，计算公式如下：\nMFU = 模型每秒真正完成的理论计算量 ÷ 硬件每秒的理论峰值计算量\n它问的不是“GPU忙不忙”，而是一件更直接与成本相关的问题：你花钱买来的理论峰值算力里，有多少真的变成了模型前向和反向传播里的有效数学计算。\n这里有个容易搞混的地方：MFU算的是“训练模型真正需要的那部分计算”跑了多快，不包括为了省显存而做的“重计算”（rematerialization，也叫activation checkpointing）。那部分计算确实发生了，但只是拿计算换显存，并不产出“新的模型进展”。业内还有个更宽松的指标叫硬件算力利用率（HFU），会把这部分也算进去，数字自然更好看一些。\nPaLM论文里正好给了一组可以直接对比的数字：PaLM 540B的MFU是46.2%，HFU是57.8%，两者相差11.6个百分点。这11.6个百分点，就是重计算占用掉、但没有直接产出“新模型进展”的那部分算力——PaLM团队为了拿到更高的可行batch size，主动选择了用重计算换显存，这笔账在HFU里被算成“有效利用”，但在MFU里被刨除了。同一次训练，换一个统计口径，利用率数字能差出十几个百分点。这也是为什么看到“算力利用率”这个词时，第一件事该问的是：这个数字算的是MFU还是HFU？ 两者不是一回事，混着比较容易被数字表面的高低误导。也就是说，MFU算的是一笔“最不掺水”的账。\nGPU利用率 ≠ MFU GPU utilization ≠ MFU 第一次接触这个话题时会犯一个错：把 nvidia-smi 里的 GPU utilization 当成了MFU。\nNVIDIA官方文档对 utilization.gpu 的定义是：在采样周期内，有一个或多个kernel正在GPU上执行的时间占比。也就是说，只要有kernel在跑，它就可能显示“很忙”，但这不代表Tensor Core被充分喂满，更不代表这些计算都在实实在在地推进模型训练。\n这有点像餐厅后厨：灯一直亮着，不代表每口锅都在高效出菜。有人在切菜，有人在等外卖单，有人在找调料，后厨确实没闲着，但出菜速度还是上不去。MFU看的是出菜速度，GPU utilization只是看后厨灯亮没亮。\n二、真实世界的数字长什么样 通过几个业内公开的训练案例，感受一下差距：\n模型/系统 硬件 MFU GPT-3 V100 约21.3% Gopher TPU 约32.5% Megatron-Turing NLG 530B A100 约30.2% PaLM 540B TPU v4（6144卡） 约46.2%（HFU约57.8%） Llama 3 405B 最高16K张H100 约38%–43%（BF16） NVIDIA Megatron-Core 弱扩展基准 H100集群 约42%–50%（模型变大MFU会升高） MegaScale（字节，175B模型，12288卡） GPU 约55.2% DeepSeek-V3（671B MoE，FP8） H800 约21%–23%（不同估算口径） 公开训练案例里的 MFU PaLM之所以被反复拿出来当标杆，是因为它把MFU这个概念系统化了，46.2%在当时是相当亮眼的跃升，代表着“标称1P的卡，实际发挥出了0.46P”。\n从这些公开案例看，训练大模型能稳定做到35%–45%已经不差，50%以上基本可以算很强的系统工程成绩。\nNVIDIA自己公布的Megatron-Core基准也印证了这一点：不同规模GPT模型的弱扩展测试里，MFU大多落在42%到50%之间。但一旦强扩展到更多GPU、通信开销暴露出来，MFU会从47%掉到42%。卡越多，越难打满。\nDeepSeek-V3也很值得看。它是第一个大规模用FP8混合精度训练的模型，官方披露了671B总参数、37B激活参数、14.8T训练token和2.788M H800 GPU小时，但没有直接披露MFU。表里的21%–23%，是第三方基于公开数据和不同峰值口径做的估算。这个数字不是在说DeepSeek团队工程能力差，恰恰相反，他们把跨节点MoE通信几乎做到了“计算通信完全重叠”，是公开资料里工程最激进的方案之一。它更适合说明另一件事：精度越低、峰值算力翻得越高，MFU这个分母变大后，数字反而更难看。\nDeepSeek-V3：FP8 让峰值变大，也让 MFU 分母更敏感 三、怎么估算：一个粗略但好用的公式 如果是dense Transformer训练，业内常用的近似是：每个token大约需要 6 × 参数量 的FLOPs（前向约2倍参数量，反向约4倍参数量）。用这个数乘上每秒处理的token数，就能估出模型每秒完成了多少理论计算量，再除以“GPU数量 × 单卡峰值FLOPs”，就是MFU。这个公式主要适合dense Transformer的粗估；MoE、超长上下文和特殊attention结构，要按具体架构再修正。\n比如一张标称1P的卡，如果训练时实际只贡献了300 TFLOPS的有效模型计算，那MFU就是30%；如果是400 TFLOPS，就是40%。这比单看GPU utilization更接近训练成本的真相。\n四、那0.5P到底去哪了？ 标称 1P 到有效0.3P–0.5P，中间漏在哪里 1. 模型或batch喂不满卡 模型太小、batch太小、序列太短，矩阵乘法（GEMM）规模不够大，kernel启动和内存访问的固定开销就会显得突出。反直觉的是：大模型有时反而更容易把算力吃满，因为GEMM更大、算术强度更高，这也是Megatron-Core基准里“模型变大MFU会升高”的原因。\n2. 内存墙：算得快，喂不饱 GPU的计算核心和显存之间搬数据的速度（显存带宽）跟不上计算速度，是最常见的瓶颈。attention、LayerNorm、embedding、optimizer这些操作很多时候更像在“搬数据”而不是在“做数学”，算力核心经常处于空转等待的状态。\n3. 通信开销：卡越多，越“聊得慢” 大模型训练要动用成千上万张卡协同工作，需要频繁做all-reduce、all-gather、reduce-scatter同步梯度，尤其是MoE架构还要处理跨节点专家路由。这些通信时间会实打实地挤占计算时间。DeepSeek-V3的技术报告里提到，他们专门拿出132个流处理器（SM）里的20个常驻处理通信，才接近做到计算通信完全重叠。如果粗略按SM数量线性折算，20/132约等于15%。这部分资源常驻通信后，留给模型计算的账面空间会先少一截。\n4. 流水线气泡与硬件不稳定 千卡、万卡级别的同步训练有个“木桶效应”：只要有一张卡慢了（掉队者，straggler），或者流水线并行里某个环节没排满（气泡，pipeline bubble），整个集群都得等它。\n更现实的是硬件故障率。Meta的Llama 3 405B论文提到，用最高16384张H100训练，54天预训练快照里一共发生了466次job interruption，其中419次是非预期中断，约78%和已确认或疑似的硬件问题有关。训练到这个规模，MFU不只是kernel优化问题，也是网络、调度、故障恢复和运维问题。大规模训练里，失败不是偶发事件，而是系统的一部分。\n5. 标称口径本身有差异 有些卡的宣传数字用了FP8，有些用了稀疏性，有些用的是Tensor Core理想峰值。如果实际训练跑的是BF16，或者kernel没有吃到对应的精度和稀疏条件，就不能直接拿最高宣传数字当分母。用错峰值，算出来的心理落差会更大。\n五、MFU 的真实用法：把规格书拉回训练现场 别只看峰值，看训练现场 买卡时看峰值FLOPs，只能知道天花板有多高。训练时看MFU，才知道你现在站在几楼。\n举个例子：一家公司说自己有10,000P算力，但真实训练MFU只有30%，那有效模型算力大概就是3,000P。另一家公司标称只有7,000P，但MFU做到45%，有效模型算力反而接近3,150P。硬件数量不是全部，软件栈、并行策略、网络拓扑和运维能力会直接改变这笔账的含金量。 这也是为什么大模型公司越来越像基础设施公司：把1P变成0.45P还是只能变成0.25P，到了万卡规模，几个百分点的MFU提升，可能就是几百万美元级别的差别。\n对大多数团队来说，MFU也有一个很实际的用法：别一上来就迷信更贵的卡。 如果当前训练MFU只有15%到25%，可以先看batch大小、序列长度、数据加载管线、混合精度设置、FlashAttention、编译优化、通信overlap和并行切分策略。很多时候，先把系统调顺，比直接再买一批卡更划算。\n但也别把MFU当成唯一目标。为了追高MFU把batch调到不利于收敛，或者为了减少checkpoint牺牲可靠性，最后可能只是让数字好看。一个比较稳的判断框架是：nvidia-smi 告诉你GPU有没有在忙，tokens/s告诉你模型吐得快不快，MFU告诉你买来的峰值算力有多少变成了有效训练。训练是否稳定收敛、故障恢复得快不快，也要放在一起看。一个MFU 70%但训练发散的任务，价值远不如一个MFU 35%但稳定收敛的任务。\n写在最后 回到开头的问题：标称1P的卡，实际训练时大概率只有0.3P到0.5P在真正干活，中间被内存带宽、通信开销、硬件故障、生态成熟度和标称口径这几层现实“税收”啃掉了一半左右。\n这不是哪家厂商在忽悠，而是大规模分布式训练这件事本身的物理与工程现实。从GPT-3的21%到PaLM的46%，再到MegaScale公开案例里的55%，过去几年大家一直在朝这道“打满”的题努力。每提升几个百分点，背后都是实打实的系统工程突破。\n真正贵的不是那0.7P没有瞬间跑满，真正贵的是你不知道它丢在了哪里。\n下次再看到“XX P级智算中心”这种宣传，别急着按峰值算训练能力，先问一句：它的MFU是多少？\n数据来源：\nPaLM: Scaling Language Modeling with Pathways（Chowdhery et al.， 2022）——PaLM 540B MFU 46.2%、GPT-3 21.3%、Gopher 32.5%、Megatron-Turing NLG 530B 30.2% 数据出处 https://ar5iv.labs.arxiv.org/html/2204.02311\nThe Llama 3 Herd of Models（Meta, 2024）——Llama 3 405B MFU 38%-43%、54天466次job interruption数据 https://ar5iv.labs.arxiv.org/html/2407.21783\nNVIDIA Megatron-Core 性能基准页面——弱/强扩展测试下42%-50%的MFU区间 https://developer.nvidia.com/megatron-core\nGoogle MaxText 文档——MFU 定义与计算公式 https://maxtext.readthedocs.io/en/latest/reference/performance_metrics.html\nNVIDIA H100 官方规格——BF16/FP16 Tensor Core峰值在带稀疏性时为1979 TFLOPS，FP8 Tensor Core峰值在带稀疏性时为3958 TFLOPS，非稀疏口径通常约为一半 https://www.nvidia.com/en-us/data-center/h100/\nNVIDIA nvidia-smi 文档——GPU utilization 指标定义 https://docs.nvidia.com/deploy/nvidia-smi/index.html\nDeepSeek-V3 Technical Report / Hugging Face 模型页——671B MoE架构、37B激活参数、H800 GPU小时数、FP8训练细节 https://huggingface.co/deepseek-ai/DeepSeek-V3\nWhat is the MFU for DeepSeek-V3 training？（Medium，第三方复现估算，MFU约21.4%） https://medium.com/@dlrover/what-is-the-mfu-for-deepseek-v3-training-0d9ea4d42eb4\nWhat went into training DeepSeek-R1？（Epoch AI，独立估算MFU约23%） https://epoch.ai/gradient-updates/what-went-into-training-deepseek-r1\nDeepSeek V3 \u0026amp; R1 Demystified（Kai Xiang，20/132 SM 用于通信的算力折算） https://kaimit.github.io/deepseek-demystified/\nDecoding GPU Efficiency: Part 1 The FLOPs Fallacy（Clockwork，MegaScale 55.2%、行业MFU共识数字） https://clockwork.io/blog/decoding-gpu-efficiency-part-1-the-flops-fallacy/\n","permalink":"https://blog.onecai.site/2026/07/23/051-mfu-explained/","summary":"\u003cp\u003e上一篇聊完“1P算力”到底是什么，初次接触这个概念，可能还会常被问到一句话：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e“\u003cstrong\u003e那这1P，跑起来是不是真的能打满？\u003c/strong\u003e”\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e答案可能有点扎心：\u003cstrong\u003e大概率打不满，而且差得不少。\u003c/strong\u003e 一个标称1P（FP16）的顶级AI卡，真正拿去训练大模型时，能稳定发挥出0.3P到0.5P，就已经算是业内的好成绩了。\u003c/p\u003e\n\u003cp\u003e更让人困惑的是：打开 \u003ccode\u003envidia-smi\u003c/code\u003e 看，GPU利用率不低，风扇在转，功耗上去了，账单更是一秒没停。但模型每秒吃进去的token，就是比按峰值算出来的少一大截。这中间差掉的0.5P到0.7P，去哪儿了？\u003c/p\u003e\n\u003ch2 id=\"一先认识这个词mfu\"\u003e一、先认识这个词：MFU\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eMFU\u003c/strong\u003e，全称 Model FLOPs Utilization，模型算力利用率。这个词是Google在2022年的PaLM论文里正式提出并普及开的，计算公式如下：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eMFU = 模型每秒真正完成的理论计算量 ÷ 硬件每秒的理论峰值计算量\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e它问的不是“GPU忙不忙”，而是一件更直接与成本相关的问题：\u003cstrong\u003e你花钱买来的理论峰值算力里，有多少真的变成了模型前向和反向传播里的有效数学计算。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这里有个容易搞混的地方：MFU算的是“训练模型真正需要的那部分计算”跑了多快，不包括为了省显存而做的“重计算”（rematerialization，也叫activation checkpointing）。那部分计算确实发生了，但只是拿计算换显存，并不产出“新的模型进展”。业内还有个更宽松的指标叫\u003cstrong\u003e硬件算力利用率（HFU）\u003c/strong\u003e，会把这部分也算进去，数字自然更好看一些。\u003c/p\u003e\n\u003cp\u003ePaLM论文里正好给了一组可以直接对比的数字：PaLM 540B的MFU是46.2%，HFU是57.8%，两者相差11.6个百分点。这11.6个百分点，就是重计算占用掉、但没有直接产出“新模型进展”的那部分算力——PaLM团队为了拿到更高的可行batch size，主动选择了用重计算换显存，这笔账在HFU里被算成“有效利用”，但在MFU里被刨除了。同一次训练，换一个统计口径，利用率数字能差出十几个百分点。这也是为什么看到“算力利用率”这个词时，第一件事该问的是：\u003cstrong\u003e这个数字算的是MFU还是HFU？\u003c/strong\u003e 两者不是一回事，混着比较容易被数字表面的高低误导。也就是说，MFU算的是一笔“最不掺水”的账。\u003c/p\u003e\n\u003ch3 id=\"gpu利用率--mfu\"\u003eGPU利用率 ≠ MFU\u003c/h3\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"mfu-explained-1.avif\"\n          alt=\"GPU utilization ≠ MFU\"/\u003e \u003cfigcaption\u003e\n             GPU utilization ≠ MFU\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e第一次接触这个话题时会犯一个错：把 \u003ccode\u003envidia-smi\u003c/code\u003e 里的 GPU utilization 当成了MFU。\u003c/p\u003e\n\u003cp\u003eNVIDIA官方文档对 \u003ccode\u003eutilization.gpu\u003c/code\u003e 的定义是：在采样周期内，有一个或多个kernel正在GPU上执行的时间占比。也就是说，只要有kernel在跑，它就可能显示“很忙”，但这不代表Tensor Core被充分喂满，更不代表这些计算都在实实在在地推进模型训练。\u003c/p\u003e\n\u003cp\u003e这有点像餐厅后厨：灯一直亮着，不代表每口锅都在高效出菜。有人在切菜，有人在等外卖单，有人在找调料，后厨确实没闲着，但出菜速度还是上不去。\u003cstrong\u003eMFU看的是出菜速度，GPU utilization只是看后厨灯亮没亮。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二真实世界的数字长什么样\"\u003e二、真实世界的数字长什么样\u003c/h2\u003e\n\u003cp\u003e通过几个业内公开的训练案例，感受一下差距：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth style=\"text-align: center\"\u003e模型/系统\u003c/th\u003e\n          \u003cth style=\"text-align: center\"\u003e硬件\u003c/th\u003e\n          \u003cth style=\"text-align: center\"\u003eMFU\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eGPT-3\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eV100\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约21.3%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eGopher\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eTPU\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约32.5%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eMegatron-Turing NLG 530B\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eA100\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约30.2%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003e\u003cstrong\u003ePaLM 540B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eTPU v4（6144卡）\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e\u003cstrong\u003e约46.2%（HFU约57.8%）\u003c/strong\u003e\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eLlama 3 405B\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e最高16K张H100\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约38%–43%（BF16）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eNVIDIA Megatron-Core 弱扩展基准\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eH100集群\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约42%–50%（模型变大MFU会升高）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eMegaScale（字节，175B模型，12288卡）\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eGPU\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约55.2%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: center\"\u003eDeepSeek-V3（671B MoE，FP8）\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003eH800\u003c/td\u003e\n          \u003ctd style=\"text-align: center\"\u003e约21%–23%（不同估算口径）\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"mfu-explained-2.avif\"\n          alt=\"公开训练案例里的 MFU\"/\u003e \u003cfigcaption\u003e\n             公开训练案例里的 MFU\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003ePaLM之所以被反复拿出来当标杆，是因为它把MFU这个概念系统化了，46.2%在当时是相当亮眼的跃升，代表着“标称1P的卡，实际发挥出了0.46P”。\u003c/p\u003e","title":"MFU：为什么标称1P的卡，实际只有0.3P在干活？"},{"content":"开篇把这届WAIC的信号总结成“系统”的五层，硬件篇算了Atlas 950的算力口径和真实代价，上一篇生态篇拆了芯片到大模型的协同。按系列地图，这一篇转到机器人——“系统工程”竞争最直观、也最极端的战场。\n一、机器人开始“上岗”了 今年世博展览馆外的路口，多了几位不会疲劳的“交警”。\n人形交通管理机器人在路口执勤，识别红绿灯信号、疏导车流。走进展馆，机器人在做论坛讲解、展区导览、安保检票；再往里走，有机器人在现场炒沙拉，有机器人一板一眼地演示潮汕功夫茶的冲泡流程，有机器人和观众打乒乓球，还有机器人在模拟药房里做智能分拣配送。\n如果说前几届WAIC，机器人还主要待在玻璃展柜里，做几个预设好的固定动作，那么今年最直观的变化是：它们开始离开展台，进入真实或准真实的工作场景。执勤、讲解、检票、分拣——这些都不是“表演”，而是有明确任务目标、需要实时感知和决策的工作。具身智能，正在走出演示厅。\n二、一组官方数据：一年翻了一倍多 WAIC 2026 具身智能繁荣面 先看整体的繁荣面。本届WAIC的官方统计口径是：\n具身智能参展企业超200家，而2025年这个数字是80余家——一年时间翻了一倍多； 展出具身智能终端208款； 现场真机超300台。 顺带说明一下口径：开篇提过具身智能馆“314件展品”，那是另一个展品统计口径；这里的“208款终端、300余台真机”是媒体报道中更常见的一套口径。——展品件数、终端款数、真机台数是三个不同的计数单位，放在一起看趋势没问题，直接混用会出错。\n200多家企业、300多台真机同台，在全球机器人相关展会上也已经是很少见的密度。单看这组数字，得出一个结论：具身智能行业正在爆发式增长。\n这个结论没错。但它只是故事的一半。另一半，藏在展台背后的落地案例和一个更冷的数字里。\n三、真正的看点不是真机数量，是落地案例 比“300台真机”更值得关注的，是这次集中亮相的一批真实场景落地案例。挑几个有代表性的：\n智元机器人：第15000台通用具身机器人下线。 WAIC前夕，智元披露第15000台通用具身机器人量产下线。把这个节点放进本届WAIC的语境里看，它是最有“量产”意味的信号之一。15000台意味着什么？至少意味着供应链、产线、品控这套体系已经跑起来了，机器人不再只是实验室里一台一台手工调出来的样机，而是开始进入按批次交付的阶段。\n优必选：工业场景里的自主作业方案。 不是“工厂里摆了几台机器人”，而是机器人在工厂环境里自主完成搬运、分拣、协作、自主换电等任务。工厂是目前对机器人最友好也最严苛的场景——环境相对结构化，但对稳定性和节拍的要求是按秒计算的。\n它石智航：精密线束装配。 线束是柔性件，形态不固定、受力会变形，一直是机器人操作的行业难点。敢把这个场景拿出来现场演示，本身就是技术自信的信号。\n傅利叶：康养样板间。 把机器人放进养老康复场景，考验的不只是运动控制，还有人机交互的安全性和容错性——面对的是行动不便的老人，出错的代价完全不同。\n商汤：零售与服务场景机器人。 商超、门店、导览、补货这些场景看起来比工业产线“轻”，实际更杂：人流不确定、货架不标准、环境经常变化，机器人要理解空间、商品、人和任务之间的关系。背后仍然是系统集成，只是换了一种考法。\n梅卡曼德：多场景应用方案。 路线更务实——不从通用人形讲万能故事，而是从机器视觉、抓取、定位、分拣、上下料这些确定任务切进去。越接近生产，客户越不听故事，只看这道工序能不能跑稳。\n这些案例的共同点是：都在回答“机器人能不能干活、能不能批量干活”，而不是“机器人能不能表演”。\n四、转折：2744家企业，红利只先落到少数头部 目前具身智能相关企业到底有多少家，不同统计口径的差距很大——少则数千家，多则上万家，取决于“相关”的边界划在哪里。企查查曾披露，截至2025年底，我国在业存续具身智能相关企业为2744家；到2026年4月，这个数字又变成2861家。本文引用2744家，是为了使用一个常见的历史截面口径，不把它当成当前全行业的精确总数。\n再看参展侧，这次真正来到WAIC现场的，是200多家。能拿到真实市场流量、实际订单和场景验证机会的公司，则明显更少。按现场观察和多方反馈，这个范围大概率还集中在少数头部企业。这里说的是观察性判断，不是审计数字，边界说明放在文末。\n把这三层放在一起看，结构就出来了：\n几千家：注册口径下的相关玩家； 200多家：能拿出产品、进入WAIC现场展示的公司； 少数头部：真正拿到订单、场景和数据闭环机会的公司。 参展数量在快速增长，红利却在向头部集中。原因也不复杂：机器人这个行业的门槛，不是某一项技术的门槛，而是系统集成的门槛。做一台能动的机器人，需要硬件；让它聪明，需要算法；让算法有效，需要数据；让它能批量交付，需要供应链；支撑以上所有环节走到量产，还需要持续的资金。\n这五条线，每一条单独拎出来，行业里都有不少公司能做好；但把五条线同时握在手里、串成闭环的，很少。\n五条线里最容易被低估、也最能解释头部集中的，是数据这一条。这里值得停下来，拆一个概念：数据飞轮。\n具身智能的数据飞轮为什么更难启动 大模型的数据飞轮大家已经很熟悉：模型好→用户多→数据多→模型更好。但很少有人注意到，具身智能的数据飞轮，启动难度比大模型高出几个数量级。原因很简单：LLM的预训练数据可以从互联网上爬——文本、代码、图片，人类几十年的数字化积累摆在那里，动辄十几万亿token，获取的边际成本趋近于零。而机器人需要的操作数据——怎么抓起一根会变形的线束、怎么端一杯水不洒出来、施加多大力矩能拧紧而不拧断——这些数据在互联网上不存在，只存在于物理世界，只能靠真机一条一条采。\n量级差距有多大？一个经典参照：Google的RT-1项目，动用13台机器人、采了17个月，攒下约13万条操作轨迹。13万条演示轨迹，对比十几万亿token的语料——中间隔着七八个数量级。遥操作采一条轨迹要几十秒到几分钟，一名采集员一天满打满算产出几百条，每条数据的成本是以“元”计的，而爬取网页文本的成本是以“分”甚至更低计的。\n而且这些数据不只是贵，还天然带着场景壁垒：最有价值的操作数据来自客户现场、设备运行、失败案例、维护记录和工艺参数——这些东西不在公开渠道流通，谁拿到了场景，谁才有机会持续拿到这条数据管道。\n理解了这一点，再回头看智元的15000台，含义就变了：那不只是15000台产品，更是15000个部署在真实场景里的数据采集终端。头部公司的循环是：有落地场景→真机采集真实数据→模型迭代更快→拿下更多订单→数据入口更多。长尾公司则连第一个环节都进不去——没有场景，飞轮的第一圈就转不起来；数据攒不下，算法差距只会越拉越大；没有订单量，供应链拿不到好价格；没有量产故事，融资越来越难。\n数据飞轮的马太效应，就是“2744家里只有个位数”的底层机制。\n五、这恰恰是“系统工程”论点最有力的佐证 机器人是系统工程竞争最极端的样本 这个系列前几篇的核心论点其实是同一个：AI的竞争已经从单点技术竞争，转向系统工程竞争。硬件篇讲的是算力系统的真实代价——峰值算力之外，拼的是互联、功耗、利用率和单位Token成本的整体效率；生态篇讲的是芯片到大模型的协同，拼的是软硬件适配和开发者生态的厚度。\n机器人把这个逻辑推到了极致。因为它是目前唯一一个同时考验硬件、算法、数据、供应链和资金五个维度的赛道——大模型公司至少不用管产线良率，芯片公司至少不用自己收集操作数据，而机器人公司哪一环都躲不掉。\n还有一个容易被忽略的对比：机器人是没有“兜底层”的AI。大模型应用做得不好，还能靠界面、流程、提示词和人工兜底补一补；软件可以先发版再迭代、线上灰度、出问题回滚。机器人不行——它在物理世界里干活，任何一处短板都直接暴露：关节不稳，动作就变形；感知不准，抓取就失败。一旦进入客户现场，还要面对物理损耗、零部件一致性、安装调试、现场维护和安全责任。模型出错是一次错误回答，机器人出错可能是一次停线、一次损坏，甚至一次安全事故。系统工程的每一环，在这里都是硬约束。\n所以，具身智能红利向头部集中，不一定说明行业出了问题，更像是系统工程竞争的自然结果：门槛越综合，头部越集中。这不是对“系统工程”论点的反驳，恰恰是最直观的证明。\n说句公道话，这不等于长尾企业没有机会。机器人行业足够复杂，单一巨头吃不掉所有场景，药房分拣、线束装配、康复训练、仓储搬运、电力巡检、农业采摘这些垂直场景，都可能长出专门的公司。但要看清：垂直场景不是低门槛机会——它不是把通用机器人换个外壳，而是要真正吃透一个行业的工艺、成本、现场流程和客户的采购逻辑。看起来是大家一起上桌，实际上淘汰赛已经开始了。\n六、量产爬坡≠盈利 第15000台下线是一个里程碑，但制造业早就教过我们一课：下线仪式和赚钱之间，隔着漫长的产能爬坡期（ramp-up）。最著名的案例是特斯拉Model 3：2017年就办了首批下线仪式，之后却陷入长达一年左右的“产能地狱”，周产量从每周几百台艰难爬向5000台的目标，马斯克一度睡在工厂里。下线证明的是“能造出来”，爬坡决定的是“能不能便宜地、稳定地、大批量地造出来”。\n爬坡期真正的敌人，是良率。这里可以算两笔账。\n机量产爬坡不等于盈利，良率会指数级放大成本 第一笔账：整机良率是连乘出来的。一台人形机器人有几十个关节模组、上千个零部件，从零件到整机要过上百道装配和调试工序。假设每道工序的良率都做到99.5%——单看已经相当不错——100道工序连乘下来，整机直通率只有0.995^100≈61%。也就是说，每投产10台，就有约4台不能一次直通、需要返工或报废。想让整机直通率达到90%，每道工序都得做到99.9%。良率从来不是“及格就行”的指标，而是一个指数级放大的杠杆。\n第二笔账：良率直接改写单台成本。用一个极简模型：实际单台成本≈物料成本÷良率（这里把不良品简化为报废；现实中多数是返工，物料损失会小一些，但额外的工时和产线占用成本同样在涨）。假设一台机器人的物料成本是15万元：良率90%时，实际单台成本约16.7万；良率只有61%时，就变成约24.6万——同一张BOM表，差出近10万元。这就是为什么两家公司卖同样配置、同样定价的机器人，可以一家在赚钱、一家在流血。\n良率之外，一家宣布量产的公司还有一串更硬的问题要回答：客户是真的买单，还是停留在试点采购？交付之后能不能稳定运行，故障率和维护成本会不会吃掉毛利？核心零部件能不能稳定供给、成本能不能持续下降？以及最终极的一问——机器人到底替代了什么岗位、帮客户省了多少钱、多久回本？这些问题不解决，量产数字越大，压力反而越大。\n还要小心一个类比陷阱：机器人的爬坡，不能简单套用新能源汽车或智能手机的故事。手机和汽车的使用场景相对标准，机器人面对的是工厂、商超、医院、药房、家庭、户外——每个场景的物理条件都不一样，而且不是卖一台机器就结束，而是要把机器接进客户现有的系统里。特斯拉的产能地狱只能类比“造出来”这一半，“用起来”这一半，机器人比汽车难得多。\n所以，量产解决的是“能不能造出来”，盈利要回答的是“造出来之后，单位经济模型是否成立”。这和硬件篇算Atlas 950时的结论是同一个逻辑：铭牌数字（下线台数、峰值算力）只证明能力存在，单位成本（单台整机成本、单位Token成本）才决定商业上成不成立。目前即便是头部公司，大多也还处在“用融资换规模、用规模换数据、用数据换下一轮融资”的阶段。产能和良率，仍然是横在所有玩家面前的真实瓶颈。\n换句话说：行业已经完成了从“演示”到“量产”的惊险一跃，但从“量产”到“盈利”的第二跃，才刚刚起跳。\n七、延伸：机器人的下一站，是“物理智能” 本届主论坛上有一个观点值得记下来。在《物理智能：从幻觉到现实》的演讲中，复旦大学苏昊提出：语言只是现实世界的投影，大模型没有真正经历物理世界。它可以说出杯子会掉、会碎，却没有感受过重量、摩擦、碰撞和力的反馈。\n这句话点破了当前具身智能的天花板：今天的机器人大脑，很大程度上是把语言模型的能力“嫁接”到了物理世界，但一个从文本里学出来的模型，并不真正“懂”一杯水有多重、一根线束会怎么变形、抓哪里更稳、推多大力合适。而这些恰恰是干活的机器人每一秒都要处理的问题。这与第四节的数据困境是同一枚硬币的两面：物理经验没有现成语料，只能靠真机交互一点点攒。机器人要真正进入工作场景，必须在感知、触觉、控制、仿真和真实交互数据之间建立闭环——具身智能的下一站，不只是更大的模型，而是更完整的物理经验。\n如果说这一届WAIC证明了系统集成能力决定谁能量产，那么物理智能可能决定下一届WAIC上，谁的机器人真正好用。这也许是长尾玩家为数不多的换道超车机会——也可能，只是头部玩家的下一道护城河。\n参考资料 RT-1: Robotics Transformer for Real-World Control at Scale（13台机器人、17个月、约13万条轨迹的原始出处）：https://arxiv.org/abs/2212.06817 Tesla Q1 2018 Update（Model 3产能爬坡期周产量数据）：https://ir.tesla.com DoNews《WAIC 2026：200余家厂商300台具身智能机器人实景上岗》（参展企业80余家增至200余家、具身智能终端208款、真机超300台）：https://www.donews.com/news/detail/4/6638039.html 企查查相关统计转载《具身智能迎万亿级大风口！企查查：具身智能相关企业超2800家》（2744家、2861家口径）：https://finance.sina.com.cn/stock/zqgd/2026-04-27/doc-inhvxtqy9028715.shtml 复旦大学新闻《苏昊：物理智能的使命，是把人还给人》（WAIC 2026主论坛《物理智能：从幻觉到现实》演讲）：https://news.fudan.edu.cn/2026/0717/c47a149901/page.htm 资料边界说明： 本文的参展企业数、终端款数、真机台数来自大会期间公开报道；具身智能企业总数在不同统计口径下从数千家到上万家不等，2744家是企查查披露的截至2025年底在业存续口径，未做穿透核实；“红利向少数头部集中”来自现场观察、公开报道和行业反馈，属于观察性判断而非可审计数据。智元、优必选、它石智航、傅利叶等公司的落地案例信息来自展会现场展示与厂商披露，未经第三方验证。良率与单台成本两笔账为示意性推算，用于说明连乘效应和成本杠杆的量级，不对应任何具体厂商的真实产线数据。\n","permalink":"https://blog.onecai.site/2026/07/22/050-robot-demo-to-mass-production-waic2026/","summary":"WAIC 2026上具身智能参展企业一年翻倍、真机超300台，但2744家公司里真正吃到红利的只有个位数——从数据飞轮的启动成本和整机良率的连乘账，看机器人为什么是系统工程竞争最极端的样本。","title":"机器人从“演示”到“量产”：2744家公司里，吃到红利的为什么只有个位数"},{"content":"一、先讲一个今年最好的“芯模协同”案例 今年4月24日，DeepSeek发布V4系列（V4-Pro和V4-Flash），总参数1.6万亿，原生支持100万token上下文。这次发布有一个容易被忽略、但比跑分更重要的细节：昇腾实现了Day0适配——模型发布当天，昇腾超节点全系列产品就完成了支持验证。\n更关键的是适配的深度。V4这一代的核心架构创新，是CSA（压缩稀疏注意力）与HCA（重度压缩注意力）的混合交错设计：CSA把每4个token的KV合并成1条再做稀疏筛选，HCA更激进，128:1压缩后直接做全量密集注意力，两种层在网络里隔层交替。配套的还有KV缓存混合精度存储、异构KV缓存管理这些工程细节。这不是“拿一个现成模型移植到另一块芯片上”，而是注意力机制的设计本身就考虑了目标硬件的计算与访存特性——DeepSeek官方文档也确认，细粒度专家并行（EP）方案同时在英伟达GPU和昇腾NPU上完成了验证。\nCSA/HCA混合注意力与硬件协同 再加上一个价格信号：DeepSeek官方明确表示，预计下半年昇腾950超节点批量上市后，V4-Pro的价格还会大幅下调——而在此之前，V4-Pro已经把75%的限时折扣转成了永久价格，输入$0.435/百万token、输出$0.87/百万token。芯片的量产节奏，直接写进了大模型的降价路线图。这就是2026年本届WAIC上被反复引用的“芯模协同”叙事的由来。\n这个案例确实好。但正因为它太好了，在这一篇里做一件相反的事：给这个叙事踩一脚刹车，看看“能跑起来”和“生态护城河”之间，到底还隔着多少东西。\n二、“生态协同”和“单纯能跑”，不是一回事 “单纯能跑” 指的是：模型权重能加载、算子能执行、推理结果数值正确、benchmark能出分。这件事的技术门槛真实存在，但它是一次性的、可以靠攻坚团队突击完成的。厂商发布会上的“完成适配”，绝大多数指的是这一层。\n“生态协同” 指的是另一回事：主流框架原生支持、算子库覆盖长尾场景、编译器能自动优化而不是靠人肉调优、出了问题有工具能定位、社区里搜得到答案、第三方开发者愿意在没有厂商驻场支持的情况下自己把系统跑起来。这一层没有发布会，只有日复一日的issue、PR和版本迭代。\n打个比方：前者相当于一辆车通过了出厂测试，后者相当于全国有加油站、有4S店、有二手市场、有路边随处能找到的修车铺。买车的人真正依赖的是后者，但发布会只会展示前者。\n三、生态成熟度的批判性检验清单 如果你想判断一个算力生态到底走到了哪一步，媒体通稿帮不了你。下面这份清单是一个可用的检验框架，每一条都对应一个媒体很少报道、但工程团队天天面对的现实。\n1. 推理适配 ≠ 后训练适配 ≠ 完整预训练 这是三件难度完全不同的事。推理适配只需要前向计算正确、吞吐达标，新闻里说的“已完成适配”绝大多数停在这一层。后训练适配的战线立刻拉长：LoRA微调、SFT、RLHF/DPO、模型量化、蒸馏、检查点格式转换——每一项背后都是一批工具链要重新适配，反向传播、优化器状态、混合精度全链路都不能出错。而完整预训练——几千甚至上万张卡、连续运行数周到数月、checkpoint稳定保存、通信不掉链、编译器和调度器不抽风、节点故障后还能恢复续训——是对整个软硬件栈的终极压力测试。“DeepSeek能在昇腾上跑推理”是事实，但它不等于“昇腾已经能扛起大模型的全生命周期”。V4本身的预训练在什么硬件上完成，官方技术报告里写得很清楚，这个信息差值得每个读者自己去核对，而不是从“适配成功”四个字里自行脑补。\n2. CANN对CUDA：目前是“补课”，还不是“超越” 很多人把CUDA理解成一个开发工具，实际上它更像一整套AI操作系统：编译器、Runtime、驱动、算子库、数学库、通信库（NCCL）、Profiling与Debug工具，再加上庞大的第三方生态，共同构成了今天AI开发最成熟的软件平台。CANN是华为对标这套体系的异构计算架构，覆盖图编译、算子融合、内存优化、并行策略。客观地说，CANN这几年进步的斜率很陡。但要认清生态位关系：CUDA有近二十年的积累，全球几乎所有AI论文的参考实现默认写给它，PyTorch的每一个新特性第一时间在它上面验证。CANN目前做的大部分工作，本质是把CUDA生态里已经存在的能力补齐，让开发者迁移时少踩坑——这是必要且艰难的补课，但补课和超越是两个阶段，混为一谈对谁都没好处。\n3. 框架适配深度、算子库完整度、编译器成熟度——开发者体验的核心，却几乎没人报道 通常我们看到的是“模型快不快”，而工程团队关心的是另一串问题：PyTorch支持是否完整、动态图有没有暗坑？算子库对主流模型结构覆盖良好，但碰到一个论文里的新算子、一个非标准的attention变体，是不是要自己写Ascend C算子？编译时间是否稳定，图编译器在偏离标准路径后的性能悬崖有多陡？OOM了能不能快速定位到是哪层、哪个张量？PyTorch在昇腾上的支持走的是torch_npu插件路线，而不是上游原生后端，这意味着版本跟随总有时间差。这些才是决定一个工程团队愿不愿意长期使用这套平台的核心，但它们无法浓缩成一条新闻标题，于是在公共讨论里近乎不存在。\n4. 迁移成本：从英伟达搬到昇腾，工程团队要付出什么 一次真实的迁移，账单大致包括：环境与驱动栈重建、依赖库逐个排查替换、自定义算子重写、数值精度逐层对齐（同一个模型在两种硬件上输出不完全一致是常态，定位差异来源可能耗掉数周）、性能重新调优（在A卡上调好的并行策略在N卡上未必最优，反之亦然）、以及CI/CD和监控体系的重做。对一个中型团队，这不是“改几行代码”，而是以人月为单位的工程投入。厂商的迁移工具能覆盖多少比例，剩下的长尾要靠多少驻场工程师填，这才是采购决策里真正该问的问题。说到底，企业真正要算的从来不是采购价，而是未来三年的总体拥有成本（TCO）——这些迁移账单不会因为芯片便宜就自动消失，只有当迁移成本持续下降、生态摩擦持续减少，价格优势才能真正转化为规模化部署优势。这一点，正是第一篇TCO讨论在生态层面的延伸。\n5. 看不见的软件基建：调试、稳定性、可观测性 profiler好不好用？训练到第37天集群里一块卡静默出错，能不能快速定位到是哪个节点、哪层通信？日志和监控指标的粒度够不够做根因分析？长时间运行的稳定性MTBF是多少？这些“看不见”的能力，恰恰是生态是否真正成熟的试金石——因为它们无法靠一次发布会攻坚补齐，只能靠大规模真实负载长年累月磨出来。CUDA生态里的Nsight、NCCL调试经验、无数StackOverflow问答，都是二十年真实故障喂出来的。这个过程没有捷径。\n6. 一个容易被忽略的风险：低价的另一面是什么？ 客户在享受“75%降价”和国产算力补贴红利的同时，值得冷静问一句： 我是否正在被绑定进一个相对封闭的技术栈？ 如果两年后需要迁回，或者迁向第三种硬件，成本几何？当模型迁移困难、工具替换困难、开发接口差异越拉越大，新平台同样会形成新的锁定效应（Vendor Lock-in）——锁定从来不是靠合同条款实现的，而是靠迁移成本的自然堆积。开源兼容是这个问题的部分答案，但只是部分：开源降低了“理论上可迁移”的门槛，却不自动消除上面第4条列出的那些实际工程成本。开源是生态成长的必要条件，不是生态成熟的终点 ——能否持续维护、能否快速跟进主流框架、社区是否足够活跃、能否切实降低企业迁移成本，这四件事才是开源之后真正的考题。\n能跑起来 ≠ 生态成熟 三点五、两个可验证的背景事实 需要注意区分的是“这次WAIC的新进展”和“更早就存在、这次只是被反复提及的背景”。有两件事属于后者，容易被当成新料：\n第一，CANN的开源不是WAIC的新闻。“CANN全面开源开放”早在2025年8月的昇腾生态大会上就已官宣。本届WAIC上它被反复提及，是作为既成事实的背景板，不是新进展。\n第二，vLLM-Ascend是一个可以自己去看的观察对象。 它是GitHub上真实、持续更新的开源项目（vllm-project/vllm-ascend），有独立的安装文档、发布说明和中文社区支持；同类的还有torch_npu、MindSpore等。与其空泛地说“华为在做生态”，不如定期去看这些仓库：issue的响应速度、版本跟随上游主线的时间差、支持的模型列表增长曲线——生态成熟度不需要相信谁的判断，它是可以被持续观测的。\n四、换个视角：本届WAIC的Agent产品群像，在争夺什么？ 把镜头从芯片层拉高，本届WAIC（7月17日—20日，上海，1100余家企业、超300款产品全球首发）最密集的火力，其实集中在另一个层面——调度层。\n扫一眼产品群像：努比亚发布了AI智能体手机（联合豆包），倪飞的表态很直白——AI手机的下半场要从“功能叠加”走向“原生智能体”；阶跃星辰拿出了全球首个智能体原生操作系统Step AOS，配套的智能体手机STEPX Neo拿了“镇馆之宝”；MiniMax展出了6月开源的M3——原生多模态、百万token上下文，配合MiniMax Code能直接完成编程和调研报告；百度这边，“芯云模体”全栈矩阵发布升级，通用智能体“百度搭子”同样入选“镇馆之宝”，主打自然语言下达任务后自主拆解、调用工具、一站式交付。\nAgent调度层：AI时代的安卓/iOS 之争 这些产品形态各异，但争的是同一个位置：未来竞争的不只是模型，而是谁来调度模型——那个理解用户意图、拆解任务、调度底层能力的入口。这个逻辑我们并不陌生——移动互联网时代，安卓和iOS真正建立优势，不是因为内核更先进，而是因为它们掌握了应用生态和开发者入口，硬件厂商再强也要按平台的规则玩。现在同样的剧本在AI上重演：芯片和模型是底层能力，但谁掌握了Agent调度层，谁就掌握了流量分发和价值分配的规则制定权。这也是为什么手机厂商、模型厂商、云厂商会同时挤进这条赛道。\n五、Token经济：给“生态能力”一个可量化的商业指标 本届WAIC把“Token经济”列为核心议题之一，这是把前面所有讨论收拢到一起的那根线。\n“Token正在成为AI商业的新语言”——这个判断值得认真对待。往下拆会发现，越来越多AI企业本质上在做同一件事：卖Token。算力厂商在卖Token（把单位Token的生产成本压到比客户自建更低，靠规模和降本获利），云平台在卖Token，大模型厂商无论表面上卖API还是卖订阅、本质也是在卖Token，Agent平台还是在卖Token。于是竞争焦点变得非常朴素：谁能更便宜地生产Token、谁能让市场消耗更多Token、谁能把Token消耗转化成实际收入。\n这就和第一篇讨论的TCO与单位Token成本接上了。生态能力听起来抽象，但它最终会沉淀为一个可以算的数字：同样一个模型、同样的服务质量，在你这套软硬件栈上，每百万token的全摊成本是多少？ DeepSeek把V4-Pro压到输出$0.87/百万token并预告随昇腾950量产继续下调，就是在用价格公开宣示自己这套协同栈的单位Token成本曲线。生态成熟度的所有细节——算子效率、编译器优化、集群稳定性、故障率——最后都会算进这个数字里。Token单价，就是生态能力的财务报表。\n单位Token成本构成瀑布图 六、结论：适配成功是起点，不是终点 回到标题的问题。\n一个旗舰模型能在国产芯片上完成Day0适配，甚至在架构设计阶段就做了协同优化——这是真实的、值得肯定的进展，它证明这条路走得通。但“走得通”是生态建立的起点，不是终点。一颗优秀的芯片，可以解决算力问题；一个成熟的生态，才能解决产业问题。\n真正的护城河要回答的是另一组问题：能不能规模化地跑？能不能低成本地跑？能不能在没有攻坚团队驻场的情况下，让千千万万普通开发者稳定地跑？推理之后能不能扛后训练、扛完整预训练？工具链、可观测性、社区这些看不见的基建，能不能经受住大规模真实负载的长期磨损？\nCUDA的护城河不是某一次成功适配挖出来的，是二十年里无数开发者的时间沉淀出来的。国产生态要走的也是同一条路——没有捷径，但好消息是，这条路现在肉眼可见地有人在走，而且走的速度不慢。 我们要做的，是既不因为一次成功适配就宣布护城河已成，也不因为差距真实存在就否认斜率的意义。说到底，AI产业真正的护城河，从来不是一块芯片，而是一整套能够长期、低成本、稳定运转的系统工程。\n资料来源 DeepSeek-V4技术报告（官方，含CSA/HCA架构与预训练细节）：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf 《读懂DeepSeek V4技术报告（二）：Hybrid Attention（CSA+HCA）》，知乎：https://zhuanlan.zhihu.com/p/2031146581542580917 《DeepSeek V4正式发布，昇腾超节点系列产品全面支持》，昇腾CANN开发者社区（Day0适配、芯模协同）：https://cann.csdn.net/69eaff630a2f6a37c5a5cad4.html 《DeepSeek-V4昇腾首发｜基于CANN的训推优化实践》，鲲鹏昇腾开发者社区（CANN全链路优化、950PR/DT整网方案）：https://hwcomputing.csdn.net/69eb344254b52172bc6fc7fa.html DeepSeek V4发布报道（细粒度EP在英伟达GPU与昇腾NPU双验证；官方预告昇腾950超节点批量上市后V4-Pro价格下调），新浪科技：https://www.sina.cn/news/detail/5291558486413456.html 《DeepSeek V4 Pro永久降价75%：旗舰推理模型进入白菜价时代》，博客园（$0.435/$0.87永久价、缓存命中价格）：https://www.cnblogs.com/itech/p/20131311 WAIC 2026前瞻报道（努比亚AI智能体手机、阶跃Agent操作系统、百度芯云模体、Token经济议题、300余款全球首发），智通财经/中财网：https://www.cfi.net.cn/newspage.aspx?id=20260713000158 《WAIC首日探展》，界面新闻（阶跃Step AOS、STEPX Neo获“镇馆之宝”、大会规模数据）：https://finance.sina.cn/stock/jdts/2026-07-17/detail-iniickaz8201285.d.html 《2026 WAIC多款AI应用亮相“镇馆之宝”》，网易（百度搭子入选“镇馆之宝”、MiniMax M3多模态与百万上下文）：https://www.163.com/dy/article/L22IL7QJ0511U82T.html vLLM-Ascend开源项目，GitHub：https://github.com/vllm-project/vllm-ascend “CANN全面开源开放”官宣于2025年8月昇腾计算产业发展峰会（背景事实，链接待补华为官方新闻稿） ","permalink":"https://blog.onecai.site/2026/07/21/049-ai-ecosystem-moat-waic2026/","summary":"\u003ch2 id=\"一先讲一个今年最好的芯模协同案例\"\u003e一、先讲一个今年最好的“芯模协同”案例\u003c/h2\u003e\n\u003cp\u003e今年4月24日，DeepSeek发布V4系列（V4-Pro和V4-Flash），总参数1.6万亿，原生支持100万token上下文。这次发布有一个容易被忽略、但比跑分更重要的细节：\u003cstrong\u003e昇腾实现了Day0适配\u003c/strong\u003e——模型发布当天，昇腾超节点全系列产品就完成了支持验证。\u003c/p\u003e\n\u003cp\u003e更关键的是适配的深度。V4这一代的核心架构创新，是CSA（压缩稀疏注意力）与HCA（重度压缩注意力）的混合交错设计：CSA把每4个token的KV合并成1条再做稀疏筛选，HCA更激进，128:1压缩后直接做全量密集注意力，两种层在网络里隔层交替。配套的还有KV缓存混合精度存储、异构KV缓存管理这些工程细节。这不是“拿一个现成模型移植到另一块芯片上”，而是\u003cstrong\u003e注意力机制的设计本身就考虑了目标硬件的计算与访存特性\u003c/strong\u003e——DeepSeek官方文档也确认，细粒度专家并行（EP）方案同时在英伟达GPU和昇腾NPU上完成了验证。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ai-ecosystem-moat-waic2026-1.avif\"\n          alt=\"CSA/HCA混合注意力与硬件协同\"/\u003e \u003cfigcaption\u003e\n             CSA/HCA混合注意力与硬件协同\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e再加上一个价格信号：DeepSeek官方明确表示，预计下半年昇腾950超节点批量上市后，V4-Pro的价格还会大幅下调——而在此之前，V4-Pro已经把75%的限时折扣转成了永久价格，输入$0.435/百万token、输出$0.87/百万token。\u003cstrong\u003e芯片的量产节奏，直接写进了大模型的降价路线图\u003c/strong\u003e。这就是2026年本届WAIC上被反复引用的“芯模协同”叙事的由来。\u003c/p\u003e\n\u003cp\u003e这个案例确实好。但正因为它太好了，在这一篇里做一件相反的事：\u003cstrong\u003e给这个叙事踩一脚刹车，看看“能跑起来”和“生态护城河”之间，到底还隔着多少东西。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二生态协同和单纯能跑不是一回事\"\u003e二、“生态协同”和“单纯能跑”，不是一回事\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e“单纯能跑”\u003c/strong\u003e 指的是：模型权重能加载、算子能执行、推理结果数值正确、benchmark能出分。这件事的技术门槛真实存在，但它是一次性的、可以靠攻坚团队突击完成的。厂商发布会上的“完成适配”，绝大多数指的是这一层。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e“生态协同”\u003c/strong\u003e 指的是另一回事：主流框架原生支持、算子库覆盖长尾场景、编译器能自动优化而不是靠人肉调优、出了问题有工具能定位、社区里搜得到答案、第三方开发者愿意在没有厂商驻场支持的情况下自己把系统跑起来。这一层没有发布会，只有日复一日的issue、PR和版本迭代。\u003c/p\u003e\n\u003cp\u003e打个比方：前者相当于一辆车通过了出厂测试，后者相当于全国有加油站、有4S店、有二手市场、有路边随处能找到的修车铺。\u003cstrong\u003e买车的人真正依赖的是后者，但发布会只会展示前者。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"三生态成熟度的批判性检验清单\"\u003e三、生态成熟度的批判性检验清单\u003c/h2\u003e\n\u003cp\u003e如果你想判断一个算力生态到底走到了哪一步，媒体通稿帮不了你。下面这份清单是一个可用的检验框架，每一条都对应一个媒体很少报道、但工程团队天天面对的现实。\u003c/p\u003e\n\u003ch3 id=\"1-推理适配--后训练适配--完整预训练\"\u003e1. 推理适配 ≠ 后训练适配 ≠ 完整预训练\u003c/h3\u003e\n\u003cp\u003e这是三件难度完全不同的事。\u003cstrong\u003e推理适配\u003c/strong\u003e只需要前向计算正确、吞吐达标，新闻里说的“已完成适配”绝大多数停在这一层。\u003cstrong\u003e后训练适配\u003c/strong\u003e的战线立刻拉长：LoRA微调、SFT、RLHF/DPO、模型量化、蒸馏、检查点格式转换——每一项背后都是一批工具链要重新适配，反向传播、优化器状态、混合精度全链路都不能出错。而\u003cstrong\u003e完整预训练\u003c/strong\u003e——几千甚至上万张卡、连续运行数周到数月、checkpoint稳定保存、通信不掉链、编译器和调度器不抽风、节点故障后还能恢复续训——是对整个软硬件栈的终极压力测试。\u003cstrong\u003e“DeepSeek能在昇腾上跑推理”是事实，但它不等于“昇腾已经能扛起大模型的全生命周期”\u003c/strong\u003e。V4本身的预训练在什么硬件上完成，官方技术报告里写得很清楚，这个信息差值得每个读者自己去核对，而不是从“适配成功”四个字里自行脑补。\u003c/p\u003e\n\u003ch3 id=\"2-cann对cuda目前是补课还不是超越\"\u003e2. CANN对CUDA：目前是“补课”，还不是“超越”\u003c/h3\u003e\n\u003cp\u003e很多人把CUDA理解成一个开发工具，实际上它更像\u003cstrong\u003e一整套AI操作系统\u003c/strong\u003e：编译器、Runtime、驱动、算子库、数学库、通信库（NCCL）、Profiling与Debug工具，再加上庞大的第三方生态，共同构成了今天AI开发最成熟的软件平台。CANN是华为对标这套体系的异构计算架构，覆盖图编译、算子融合、内存优化、并行策略。客观地说，CANN这几年进步的斜率很陡。但要认清生态位关系：CUDA有近二十年的积累，全球几乎所有AI论文的参考实现默认写给它，PyTorch的每一个新特性第一时间在它上面验证。\u003cstrong\u003eCANN目前做的大部分工作，本质是把CUDA生态里已经存在的能力补齐，让开发者迁移时少踩坑\u003c/strong\u003e——这是必要且艰难的补课，但补课和超越是两个阶段，混为一谈对谁都没好处。\u003c/p\u003e\n\u003ch3 id=\"3-框架适配深度算子库完整度编译器成熟度开发者体验的核心却几乎没人报道\"\u003e3. 框架适配深度、算子库完整度、编译器成熟度——开发者体验的核心，却几乎没人报道\u003c/h3\u003e\n\u003cp\u003e通常我们看到的是“模型快不快”，而工程团队关心的是另一串问题：PyTorch支持是否完整、动态图有没有暗坑？算子库对主流模型结构覆盖良好，但碰到一个论文里的新算子、一个非标准的attention变体，是不是要自己写Ascend C算子？编译时间是否稳定，图编译器在偏离标准路径后的性能悬崖有多陡？OOM了能不能快速定位到是哪层、哪个张量？PyTorch在昇腾上的支持走的是torch_npu插件路线，而不是上游原生后端，这意味着版本跟随总有时间差。\u003cstrong\u003e这些才是决定一个工程团队愿不愿意长期使用这套平台的核心，但它们无法浓缩成一条新闻标题，于是在公共讨论里近乎不存在。\u003c/strong\u003e\u003c/p\u003e\n\u003ch3 id=\"4-迁移成本从英伟达搬到昇腾工程团队要付出什么\"\u003e4. 迁移成本：从英伟达搬到昇腾，工程团队要付出什么\u003c/h3\u003e\n\u003cp\u003e一次真实的迁移，账单大致包括：环境与驱动栈重建、依赖库逐个排查替换、自定义算子重写、数值精度逐层对齐（同一个模型在两种硬件上输出不完全一致是常态，定位差异来源可能耗掉数周）、性能重新调优（在A卡上调好的并行策略在N卡上未必最优，反之亦然）、以及CI/CD和监控体系的重做。对一个中型团队，这不是“改几行代码”，\u003cstrong\u003e而是以人月为单位的工程投入\u003c/strong\u003e。厂商的迁移工具能覆盖多少比例，剩下的长尾要靠多少驻场工程师填，这才是采购决策里真正该问的问题。说到底，\u003cstrong\u003e企业真正要算的从来不是采购价，而是未来三年的总体拥有成本（TCO）\u003c/strong\u003e——这些迁移账单不会因为芯片便宜就自动消失，只有当迁移成本持续下降、生态摩擦持续减少，价格优势才能真正转化为规模化部署优势。这一点，正是第一篇TCO讨论在生态层面的延伸。\u003c/p\u003e\n\u003ch3 id=\"5-看不见的软件基建调试稳定性可观测性\"\u003e5. 看不见的软件基建：调试、稳定性、可观测性\u003c/h3\u003e\n\u003cp\u003eprofiler好不好用？训练到第37天集群里一块卡静默出错，能不能快速定位到是哪个节点、哪层通信？日志和监控指标的粒度够不够做根因分析？长时间运行的稳定性MTBF是多少？\u003cstrong\u003e这些“看不见”的能力，恰恰是生态是否真正成熟的试金石\u003c/strong\u003e——因为它们无法靠一次发布会攻坚补齐，只能靠大规模真实负载长年累月磨出来。CUDA生态里的Nsight、NCCL调试经验、无数StackOverflow问答，都是二十年真实故障喂出来的。这个过程没有捷径。\u003c/p\u003e\n\u003ch3 id=\"6-一个容易被忽略的风险低价的另一面是什么\"\u003e6. 一个容易被忽略的风险：低价的另一面是什么？\u003c/h3\u003e\n\u003cp\u003e客户在享受“75%降价”和国产算力补贴红利的同时，值得冷静问一句： \u003cstrong\u003e我是否正在被绑定进一个相对封闭的技术栈？\u003c/strong\u003e 如果两年后需要迁回，或者迁向第三种硬件，成本几何？当模型迁移困难、工具替换困难、开发接口差异越拉越大，新平台同样会形成新的锁定效应（Vendor Lock-in）——锁定从来不是靠合同条款实现的，而是靠迁移成本的自然堆积。开源兼容是这个问题的部分答案，但只是部分：开源降低了“理论上可迁移”的门槛，却不自动消除上面第4条列出的那些实际工程成本。\u003cstrong\u003e开源是生态成长的必要条件，不是生态成熟的终点\u003c/strong\u003e ——能否持续维护、能否快速跟进主流框架、社区是否足够活跃、能否切实降低企业迁移成本，这四件事才是开源之后真正的考题。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ai-ecosystem-moat-waic2026-2.avif\"\n          alt=\"能跑起来 ≠ 生态成熟\"/\u003e \u003cfigcaption\u003e\n             能跑起来 ≠ 生态成熟\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"三点五两个可验证的背景事实\"\u003e三点五、两个可验证的背景事实\u003c/h2\u003e\n\u003cp\u003e需要注意区分的是“这次WAIC的新进展”和“更早就存在、这次只是被反复提及的背景”。有两件事属于后者，容易被当成新料：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一，CANN的开源不是WAIC的新闻。\u003c/strong\u003e“CANN全面开源开放”早在2025年8月的昇腾生态大会上就已官宣。本届WAIC上它被反复提及，是作为既成事实的背景板，不是新进展。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二，vLLM-Ascend是一个可以自己去看的观察对象。\u003c/strong\u003e 它是GitHub上真实、持续更新的开源项目（vllm-project/vllm-ascend），有独立的安装文档、发布说明和中文社区支持；同类的还有torch_npu、MindSpore等。与其空泛地说“华为在做生态”，不如定期去看这些仓库：issue的响应速度、版本跟随上游主线的时间差、支持的模型列表增长曲线——\u003cstrong\u003e生态成熟度不需要相信谁的判断，它是可以被持续观测的\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2 id=\"四换个视角本届waic的agent产品群像在争夺什么\"\u003e四、换个视角：本届WAIC的Agent产品群像，在争夺什么？\u003c/h2\u003e\n\u003cp\u003e把镜头从芯片层拉高，本届WAIC（7月17日—20日，上海，1100余家企业、超300款产品全球首发）最密集的火力，其实集中在另一个层面——\u003cstrong\u003e调度层\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e扫一眼产品群像：努比亚发布了AI智能体手机（联合豆包），倪飞的表态很直白——AI手机的下半场要从“功能叠加”走向“原生智能体”；阶跃星辰拿出了全球首个智能体原生操作系统Step AOS，配套的智能体手机STEPX Neo拿了“镇馆之宝”；MiniMax展出了6月开源的M3——原生多模态、百万token上下文，配合MiniMax Code能直接完成编程和调研报告；百度这边，“芯云模体”全栈矩阵发布升级，通用智能体“百度搭子”同样入选“镇馆之宝”，主打自然语言下达任务后自主拆解、调用工具、一站式交付。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ai-ecosystem-moat-waic2026-3.avif\"\n          alt=\"Agent调度层：AI时代的安卓/iOS 之争\"/\u003e \u003cfigcaption\u003e\n             Agent调度层：AI时代的安卓/iOS 之争\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这些产品形态各异，但争的是同一个位置：\u003cstrong\u003e未来竞争的不只是模型，而是谁来调度模型\u003c/strong\u003e——那个理解用户意图、拆解任务、调度底层能力的入口。这个逻辑我们并不陌生——移动互联网时代，安卓和iOS真正建立优势，不是因为内核更先进，而是因为它们掌握了应用生态和开发者入口，硬件厂商再强也要按平台的规则玩。现在同样的剧本在AI上重演：芯片和模型是底层能力，但\u003cstrong\u003e谁掌握了Agent调度层，谁就掌握了流量分发和价值分配的规则制定权\u003c/strong\u003e。这也是为什么手机厂商、模型厂商、云厂商会同时挤进这条赛道。\u003c/p\u003e\n\u003ch2 id=\"五token经济给生态能力一个可量化的商业指标\"\u003e五、Token经济：给“生态能力”一个可量化的商业指标\u003c/h2\u003e\n\u003cp\u003e本届WAIC把“Token经济”列为核心议题之一，这是把前面所有讨论收拢到一起的那根线。\u003c/p\u003e\n\u003cp\u003e“Token正在成为AI商业的新语言”——这个判断值得认真对待。往下拆会发现，越来越多AI企业本质上在做同一件事：\u003cstrong\u003e卖Token\u003c/strong\u003e。算力厂商在卖Token（把单位Token的生产成本压到比客户自建更低，靠规模和降本获利），云平台在卖Token，大模型厂商无论表面上卖API还是卖订阅、本质也是在卖Token，Agent平台还是在卖Token。于是竞争焦点变得非常朴素：\u003cstrong\u003e谁能更便宜地生产Token、谁能让市场消耗更多Token、谁能把Token消耗转化成实际收入\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这就和第一篇讨论的TCO与单位Token成本接上了。生态能力听起来抽象，但它最终会沉淀为一个可以算的数字：\u003cstrong\u003e同样一个模型、同样的服务质量，在你这套软硬件栈上，每百万token的全摊成本是多少？\u003c/strong\u003e DeepSeek把V4-Pro压到输出$0.87/百万token并预告随昇腾950量产继续下调，就是在用价格公开宣示自己这套协同栈的单位Token成本曲线。生态成熟度的所有细节——算子效率、编译器优化、集群稳定性、故障率——最后都会算进这个数字里。\u003cstrong\u003eToken单价，就是生态能力的财务报表。\u003c/strong\u003e\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ai-ecosystem-moat-waic2026-4.avif\"\n          alt=\"单位Token成本构成瀑布图\"/\u003e \u003cfigcaption\u003e\n             单位Token成本构成瀑布图\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"六结论适配成功是起点不是终点\"\u003e六、结论：适配成功是起点，不是终点\u003c/h2\u003e\n\u003cp\u003e回到标题的问题。\u003c/p\u003e\n\u003cp\u003e一个旗舰模型能在国产芯片上完成Day0适配，甚至在架构设计阶段就做了协同优化——这是真实的、值得肯定的进展，它证明这条路走得通。\u003cstrong\u003e但“走得通”是生态建立的起点，不是终点。一颗优秀的芯片，可以解决算力问题；一个成熟的生态，才能解决产业问题。\u003c/strong\u003e\u003c/p\u003e","title":"从芯片到大模型——生态协同能力才是护城河"},{"content":"上一篇说到，这次WAIC真正的信号不是某个数字漂不漂亮，而是“系统”能不能跑通。这一篇就从系列里分量最重的硬件说起——昇腾950超节点，7月17日真机首秀，展台前排的队伍绕了一圈，还拿下了大会Superior超越赛道的SAIL最高奖。\n先把两个“Atlas 950”分清楚 1024卡展示配置 vs 8192卡路线图 写这篇之前，先得澄清一个容易混淆、而且第一版也没分清楚的地方：WAIC现场展出的真机，和华为路线图里讲的满配版本，根本不是同一个规模。\n现场展出的昇腾950超节点，官方口径是“业界最大1024卡规模”：FP8算力1 EFLOPS，FP4算力2 EFLOPS，256TB全局统一内存编址空间，TB级NPU互联带宽，3微秒级RTT时延，走的是“灵衢互联协议”（也就是UnifiedBus）。需要说清楚的是，真机公开展示不等于已经实现大规模商业交付——目前能确认的是这套1024卡系统完整亮相并给出了这些技术指标，至于实际客户部署数量、长期运行稳定性、有效算力利用率和单位Token成本，还需要后续商业项目和第三方测试来验证，这里先按“WAIC 2026公开展示的1024卡配置”这个更准确的说法来称呼它，而不是直接说它是“当前已商用交付的版本”。\n而华为此前在路线图里讲过的Atlas 950 SuperPoD满配版要大得多：8192颗昇腾950DT芯片，160个机柜（128个计算柜、32个互联柜），占地约1000平方米，FP8算力8 EFLOPS、FP4算力16 EFLOPS，整机内存1152TB，总互联带宽16PB/s，计划2026年第四季度上市。\nWAIC现场真机 路线图满配版 规模 1024卡 8192卡 FP8算力 1 EFLOPS 8 EFLOPS FP4算力 2 EFLOPS 16 EFLOPS 内存 256TB 1152TB 状态 已首秀，公开展示配置 路线图规划，2026 Q4上市 两者规模正好相差8倍，可以看作同一条技术路线下的两个系统规模，但不能混用参数，更不能把满配版的路线图数据直接写成WAIC现场真机的数据。后面所有对比英伟达的“6.7倍”“56.8倍”这类数字，说的都是满配版对NVL144，不是现场这台1024卡真机——这个区分如果不讲清楚，后面的分析就会站不住脚，这也正是很多参数稿容易写乱的地方。\n对比英伟达：先弄清楚在跟谁比 “Atlas 950算力是英伟达NVL144的6.7倍”这个说法，最早来自华为2025年公布路线图时给出的对比，当时的完整说法是：总算力约6.7倍、内存容量约15倍、互联带宽约62倍。\n对比对象 世代 规模 华为给出的说法 NVL144 2025年路线图对比基线 144颗GPU/机架 满配版算力约为其6.7倍，内存约15倍，互联带宽约62倍 NVL576（Rubin Ultra） 下一代，预计2027年下半年上市 576颗GPU/机架，FP8训练5 EFLOPS 满配版8 EFLOPS对比其5 EFLOPS，多项指标称保持优势 为什么6.7倍不能直接理解成芯片快6.7倍 但这里有个值得注意的地方：“NVL144”这个名字，英伟达自己这一年也在往不同方向延伸。 2025年9月英伟达发布了专攻长上下文推理和视频生成的Rubin CPX，对应的机架级方案就叫“Vera Rubin NVL144 CPX”——单机架AI算力同样标称8 EFLOPS（NVFP4精度），配100TB高速内存，预计2026年底上市。也就是说，“NVL144”这个名字下面，英伟达自己这一年就有不止一种配置，华为2025年发布会上用来做基线的那个“NVL144”，不能不加说明地直接套到2026年所有叫这个名字的新配置上。产品代际、系统定位和精度口径都在变化，“6.7倍”更适合理解成一个特定时间点、特定对比对象、特定厂商口径下的路线图数字，而不是一句可以永久成立的结论。\n精度、口径与一个不该轻易下的除法 第一个问题，是精度不能随便横向比。 FP8、FP4这类低精度格式，在不同厂商、不同芯片上的实现方式不完全一样，理论峰值（铭牌数字）和模型实际跑起来的有效吞吐，从来都是两回事。更严谨的表述应该是“按华为公布的系统规格口径，满配版峰值总算力约为其选定NVL144比较方案的6.7倍”，而不是“第三方测试证明Atlas 950比英伟达快6.7倍”——这两句话看着差不多，但严谨程度完全不同。\n第二个问题，是“超节点”和“单机架”这两个统计单位本身不对等。 满配版Atlas 950 SuperPoD是可以跨160个机柜组网的超节点概念，NVL576描述的是单机架内的Scale-up方案，拿两者的总算力直接做除法，多少有点关公战秀才的意味。\n第三个问题，是在这个系列第一版里犯过的一个错误，这次专门纠正一下。 原来的推导是：满配版用8192颗芯片，NVL144是144颗，芯片数量是56.8倍，但总算力只多出6.7倍，所以昇腾单芯片效率明显落后。这个除法看起来直观，但并不严谨——原因在于两边的“芯片”未必是同一层级的计算单元：一张加速卡可能对应一颗芯片，也可能包含多个计算Die；一个GPU封装本身也可能由多颗芯粒组成；再加上稀疏计算口径、低精度格式、功耗限制、产品定位都可能不同。8192除以144，只能说明系统内加速器数量存在差异，不能在缺少统一规格和实测数据的情况下，直接得出单芯片性能相差多少倍这个结论。要严谨比较单芯片能力，至少需要统一精度、稀疏口径、功耗范围、模型、Batch Size、上下文长度和有效算力定义——目前公开资料还不足以完成这样的比较。\n这套数字真正想说明的，不是昇腾单芯片已经反超英伟达，而是华为在尝试证明：当单芯片能力暂时难以完全对齐时，可以通过互联、内存和系统架构，把更多芯片组织成一台逻辑计算机，用“系统规模”重新定义比较单位。\n至于“领先两年”这个说法，也值得拆开看：满配版号称2026年Q4就能规模化交付，而Rubin Ultra要到2027年下半年才上市，这个时间差是真实的。但“领先”到底指产品可交付的时间、公开发布的时间，还是路线图规划的时间，三者混在一起讲，是发布会常见的话术陷阱。\n系统工程，华为自己也是这么说的 现场工作人员被问到这次能拿下SAIL最高奖的原因时，给出的答案是“架构创新、系统工程，以及商用能力的超越和领先”——注意，这句话是华为自己讲的，不是媒体总结出来的角度。能支撑起1024卡规模、256TB统一内存编址的，核心是高密设计和光电互联这类“看起来不如EFLOPS好传播”的工程细节，而不是单颗芯片又快了多少。\nAI系统工程到底包括什么 这也不是华为第一次做超节点：上一代昇腾384超节点已经“商用落地750多套”，覆盖互联网、运营商、金融、教育、医疗、交通、制造等多个行业——950超节点不是从零起步的新故事，而是有真实商用基础的延续。\n往技术里再拆一层：为什么芯片数量堆得越多，反而越考验互联和内存？大模型训练和推理正卡在两堵墙上。一堵是内存墙——芯片计算单元的速度增长很快，但数据从内存搬到计算单元的速度没有同步跟上，尤其在Decode阶段，系统要不断读取模型权重和KV Cache，计算单元可能没被占满，瓶颈反而出现在内存带宽。另一堵是通信墙——模型越大，需要参与计算的设备越多，设备间交换的数据也越多，如果互联带宽和时延跟不上，加芯片数量带来的收益会越来越低。Atlas 950真正想验证的，就是能不能用UnifiedBus、统一内存编址和光电互联，把大量芯片组织成一个效率可接受的计算域——这件事如果真能在实际业务里跑通，意义可能比某一代单芯片峰值性能更大。\n比EFLOPS更该问的：真实代价是什么 峰值算力之外，一套系统能不能商业落地，还要看这些：\n维度 需要关注的问题 功耗与供电 1024卡乃至8192卡规模的超节点，数据中心的电力和制冷能不能跟上 液冷散热 液冷已被行业称为“新建大型算力中心标配”，但方案成熟度和成本仍待验证 单位功耗产出 每瓦特能换来多少有效Token，而不是铭牌峰值 训练中断率 大规模集群实际能压到多低的中断率，恢复机制是否成熟 单位Token成本 真正有商业意义的算力，是能持续、稳定、低成本交付的Token，不是铭牌上的EFLOPS 采购成本与TCO 一次性采购价之外，五年总拥有成本（含电费、运维）才是客户真正要算的账 迁移与运维成本 客户从其他平台迁移过来之后，开发和维护成本会不会不降反升 华为目前公开了满配版的卡数、机柜数量、算力、内存和互联带宽，但尚未公布满载功耗、平均算力利用率、PUE、单位Token能耗和成本、长时间运行故障率这类能支撑起完整TCO比较的数据——在这些数据公开之前，不能仅凭8 EFLOPS或6.7倍，就判断哪套系统的经济性更好。这也是为什么“6.7倍算力”这类数字，只是这篇文章的开场白，而不是结论。\n不止一代芯片：三年四芯与自研HBM 华为轮值董事长徐直军此前披露的路线图显示，这不是单点产品，而是一整条自研链路，而且按大模型推理的两个阶段分了工：Prefill阶段要一次性处理用户输入的大量Token，偏并行计算和高吞吐；Decode阶段要逐Token生成内容，对内存带宽、访问延迟和并发调度更敏感——把两种负载分开优化，是这份路线图背后的设计逻辑。\n产品 时间 定位 昇腾950PR 2026年Q1已推出 优化推理Prefill、推荐业务 昇腾950DT 本次WAIC真机首秀 偏训练和Decode 昇腾960 预计2027年Q4 下一代 昇腾970 时间待定 远期规划 更关键的是首次公布的两款自研HBM：HiBL 1.0（128GB、1.6TB/s，面向Prefill）和HiZQ 2.0（144GB、4TB/s，面向Decode/训练）。高带宽内存长期是国产芯片最卡脖子的一环，如果自研HBM能顺利量产，意味着“芯片—内存—互联—软件”这条链路在往自主可控的方向补齐，这比某一代芯片跑多快更能说明问题。\n生态愿不愿意为它改架构 硬件之外，华为这次也在反复强调CANN异构计算架构已经开源，并适配openEuler、PyTorch、vLLM、Triton、TileLang、verl等主流开源项目和工具链，目标是降低开发者迁移门槛——但“支持某个框架”和“拥有成熟生态”不是一回事，这是“系统工程”里最容易被忽略、却决定硬件能不能真正落地的一层，下一篇会专门展开。\n这里先说一个最直接的例子：DeepSeek-V4的官方技术报告首次同时验证了昇腾NPU和英伟达GPU两条路径，其中部分模型架构是针对昇腾推理协同设计的——新的注意力机制（HCA/CSA）、MoE量化方案、专家并行通信设计。这种深度适配比“能跑起来”难得多。直接体现在价格上：DeepSeek-V4-Pro的API价格永久下调到原价的四分之一；订单端，字节跳动被曝已经拿下昇腾950超节点近一半的产能。这两件事放在一起看，说明真机首秀这个时间点，Atlas 950背后已经站着愿意真金白银下注、也愿意为它改模型架构的客户。但“能运行”“经过优化”“形成成熟生态”是三个不同阶段，目前看到的更多是前两个阶段的进展，这个分寸下一篇细讲。\n出海订单和出口管制的拉锯 昇腾950已经拿到韩国约2000片、马来西亚约3000台AI服务器的采购意向，俄罗斯、拉美地区也有批量采购动作。但几乎同一时间，美国商务部发布指导意见，认定昇腾910B、910C以及即将推出的910D违反出口管制，要求全球范围内禁止使用，个人和企业违规使用最高面临刑事指控（此前合法采购的原始昇腾910不受影响）。芯片能不能真正在海外站稳脚跟，这层博弈比参数本身更复杂，后面治理篇会专门展开。\n不止华为一家在打这场仗 这次同台亮相的国产芯片阵营，比想象中更大：\n企业 这次带来的产品 阿里 真武M890×磐久AL128超节点，首次公开展示 东方算芯 首发DF1000芯片 中兴 联合多家国产厂商推出Matrix超节点 壁仞科技 新品同台展示 沐曦股份 新品同台展示 十余家企业同时把“超节点”级别产品摆上台面，液冷也被明确称为“新建大型算力中心标配”。华泰证券把2026年定义为“国产超节点元年”，预测2028年国内市场规模3414亿元，年复合增速194%。\n（以下产业链梳理仅为公开报道整理，不构成投资建议。）这波真机首秀也带火了一批A股“概念股”，包括光模块（中际旭创、华工科技）、高速连接器（华丰科技、航天电器、意华股份）、液冷散热（高澜股份、川润股份）、服务器整机（紫光股份、浪潮信息、华勤技术）等，资金关注的已经不是昇腾这一个点，而是一整条协同产业链能不能跑起来。\nAtlas 950的优势和风险 把前面这些信息收一收，基于目前公开信息，优势主要在三点：系统规模足够大，1024卡公开展示加8192卡路线图，说明华为在尝试构建超大规模统一互联域；强调自主系统链路，从芯片、灵衢互联、内存到CANN软件栈，正在补齐完整的AI基础设施链条；也适合国内在高端GPU供应受限背景下，对可持续获得的国产计算平台的真实需求。\n风险同样清晰：峰值指标目前主要来自厂商披露，独立第三方基准测试还没跟上；满配系统仍停留在路线图阶段，能否按期交付、交付多少、运行效果如何都待观察；系统成本尚不透明，功耗、散热、机房改造、维护和软件迁移都会影响真实的总拥有成本；软件生态仍是长期任务，CUDA的优势积累了近二十年，不是一次真机首秀能补齐的；系统规模越大，故障管理和任务恢复的复杂度也会被放大。\n真正值得盯的，不是这场发布会说了什么，而是接下来几个月：1024卡到8192卡的满配版能不能如期在Q4批量交付、自研HBM能不能量产、除了字节还有多少大厂愿意迁移核心业务。这几个问题的答案，比任何一次真机首秀都更接近真相。国产算力真正的分水岭，不是“能不能替代”，而是能不能做到“值得使用”——也就是能不能稳定、经济地把这套系统变成持续的Token产出。\n下一篇转到软件这一侧：DeepSeek和昇腾的协同适配，是不是就等于国产AI生态已经跑通了。\n参考资料 华为昇腾950超节点真机首次公开亮相，昇腾384超节点已商用落地750多套 - IT之家 WAIC上的算力重器：华为昇腾950超节点真机现身 - 新浪财经 华为昇腾950超节点亮相：1024卡，FP4算力2EFLOPS！- 电子工程专辑 WAIC2026探展｜斩获大会SAIL最高奖的昇腾950超节点真机首次亮相引爆会场 - 网易 华为昇腾950超节点真机首次公开亮相！业界最大1024卡规模 - 金融界 Huawei Atlas 950 SuperPoD claims 6.7x more computing power than Nvidia NVL144 - Huawei Central NVIDIA Unveils Rubin CPX: A New Class of GPU Designed for Massive-Context Inference - NVIDIA Newsroom 英伟达突然发布新GPU！单机架AI性能暴涨6500%，100TB大内存，专攻长上下文推理 - 与非网 Nvidia\u0026rsquo;s Rubin Ultra NVL576 rack expected to be 600kW, coming second half of 2027 - Data Center Dynamics 资料边界说明： 本文涉及的Atlas 950及满配版规格主要来自华为公开披露，属于产品规格和路线图信息，不等同于独立第三方性能测试；英伟达NVL144、NVL144 CPX、NVL576/Rubin Ultra相关数据同样来自厂商公开披露。涉及尚未正式交付的产品，最终规格、上市时间和实际性能都可能发生变化。\n","permalink":"https://blog.onecai.site/2026/07/20/048-atlas-950-superpod-system-engineering/","summary":"\u003cp\u003e上一篇说到，这次WAIC真正的信号不是某个数字漂不漂亮，而是“系统”能不能跑通。这一篇就从系列里分量最重的硬件说起——昇腾950超节点，7月17日真机首秀，展台前排的队伍绕了一圈，还拿下了大会Superior超越赛道的SAIL最高奖。\u003c/p\u003e\n\u003ch2 id=\"先把两个atlas-950分清楚\"\u003e先把两个“Atlas 950”分清楚\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"atlas-950-superpod-system-engineering-1.avif\"\n          alt=\"1024卡展示配置 vs 8192卡路线图\"/\u003e \u003cfigcaption\u003e\n             1024卡展示配置 vs 8192卡路线图\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e写这篇之前，先得澄清一个容易混淆、而且第一版也没分清楚的地方：\u003cstrong\u003eWAIC现场展出的真机，和华为路线图里讲的满配版本，根本不是同一个规模。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e现场展出的昇腾950超节点，官方口径是“业界最大1024卡规模”：FP8算力\u003cstrong\u003e1 EFLOPS\u003c/strong\u003e，FP4算力\u003cstrong\u003e2 EFLOPS\u003c/strong\u003e，256TB全局统一内存编址空间，TB级NPU互联带宽，3微秒级RTT时延，走的是“灵衢互联协议”（也就是UnifiedBus）。需要说清楚的是，\u003cstrong\u003e真机公开展示不等于已经实现大规模商业交付\u003c/strong\u003e——目前能确认的是这套1024卡系统完整亮相并给出了这些技术指标，至于实际客户部署数量、长期运行稳定性、有效算力利用率和单位Token成本，还需要后续商业项目和第三方测试来验证，这里先按“WAIC 2026公开展示的1024卡配置”这个更准确的说法来称呼它，而不是直接说它是“当前已商用交付的版本”。\u003c/p\u003e\n\u003cp\u003e而华为此前在路线图里讲过的\u003cstrong\u003eAtlas 950 SuperPoD满配版\u003c/strong\u003e要大得多：8192颗昇腾950DT芯片，160个机柜（128个计算柜、32个互联柜），占地约1000平方米，FP8算力8 EFLOPS、FP4算力16 EFLOPS，整机内存1152TB，总互联带宽16PB/s，计划2026年第四季度上市。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003c/th\u003e\n          \u003cth\u003eWAIC现场真机\u003c/th\u003e\n          \u003cth\u003e路线图满配版\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e规模\u003c/td\u003e\n          \u003ctd\u003e1024卡\u003c/td\u003e\n          \u003ctd\u003e8192卡\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP8算力\u003c/td\u003e\n          \u003ctd\u003e1 EFLOPS\u003c/td\u003e\n          \u003ctd\u003e8 EFLOPS\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFP4算力\u003c/td\u003e\n          \u003ctd\u003e2 EFLOPS\u003c/td\u003e\n          \u003ctd\u003e16 EFLOPS\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e内存\u003c/td\u003e\n          \u003ctd\u003e256TB\u003c/td\u003e\n          \u003ctd\u003e1152TB\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e状态\u003c/td\u003e\n          \u003ctd\u003e已首秀，公开展示配置\u003c/td\u003e\n          \u003ctd\u003e路线图规划，2026 Q4上市\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e两者规模正好相差8倍，可以看作同一条技术路线下的两个系统规模，但不能混用参数，更不能把满配版的路线图数据直接写成WAIC现场真机的数据。后面所有对比英伟达的“6.7倍”“56.8倍”这类数字，说的都是满配版对NVL144，不是现场这台1024卡真机——这个区分如果不讲清楚，后面的分析就会站不住脚，这也正是很多参数稿容易写乱的地方。\u003c/p\u003e\n\u003ch2 id=\"对比英伟达先弄清楚在跟谁比\"\u003e对比英伟达：先弄清楚在跟谁比\u003c/h2\u003e\n\u003cp\u003e“Atlas 950算力是英伟达NVL144的6.7倍”这个说法，最早来自华为2025年公布路线图时给出的对比，当时的完整说法是：总算力约6.7倍、内存容量约15倍、互联带宽约62倍。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e对比对象\u003c/th\u003e\n          \u003cth\u003e世代\u003c/th\u003e\n          \u003cth\u003e规模\u003c/th\u003e\n          \u003cth\u003e华为给出的说法\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eNVL144\u003c/td\u003e\n          \u003ctd\u003e2025年路线图对比基线\u003c/td\u003e\n          \u003ctd\u003e144颗GPU/机架\u003c/td\u003e\n          \u003ctd\u003e满配版算力约为其6.7倍，内存约15倍，互联带宽约62倍\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eNVL576（Rubin Ultra）\u003c/td\u003e\n          \u003ctd\u003e下一代，预计2027年下半年上市\u003c/td\u003e\n          \u003ctd\u003e576颗GPU/机架，FP8训练5 EFLOPS\u003c/td\u003e\n          \u003ctd\u003e满配版8 EFLOPS对比其5 EFLOPS，多项指标称保持优势\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"atlas-950-superpod-system-engineering-2.avif\"\n          alt=\"为什么6.7倍不能直接理解成芯片快6.7倍\"/\u003e \u003cfigcaption\u003e\n             为什么6.7倍不能直接理解成芯片快6.7倍\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e但这里有个值得注意的地方：\u003cstrong\u003e“NVL144”这个名字，英伟达自己这一年也在往不同方向延伸。\u003c/strong\u003e 2025年9月英伟达发布了专攻长上下文推理和视频生成的Rubin CPX，对应的机架级方案就叫“Vera Rubin NVL144 CPX”——单机架AI算力同样标称\u003cstrong\u003e8 EFLOPS（NVFP4精度）\u003c/strong\u003e，配\u003cstrong\u003e100TB\u003c/strong\u003e高速内存，预计2026年底上市。也就是说，“NVL144”这个名字下面，英伟达自己这一年就有不止一种配置，华为2025年发布会上用来做基线的那个“NVL144”，不能不加说明地直接套到2026年所有叫这个名字的新配置上。产品代际、系统定位和精度口径都在变化，“6.7倍”更适合理解成一个特定时间点、特定对比对象、特定厂商口径下的路线图数字，而不是一句可以永久成立的结论。\u003c/p\u003e\n\u003ch2 id=\"精度口径与一个不该轻易下的除法\"\u003e精度、口径与一个不该轻易下的除法\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e第一个问题，是精度不能随便横向比。\u003c/strong\u003e FP8、FP4这类低精度格式，在不同厂商、不同芯片上的实现方式不完全一样，理论峰值（铭牌数字）和模型实际跑起来的有效吞吐，从来都是两回事。更严谨的表述应该是“按华为公布的系统规格口径，满配版峰值总算力约为其选定NVL144比较方案的6.7倍”，而不是“第三方测试证明Atlas 950比英伟达快6.7倍”——这两句话看着差不多，但严谨程度完全不同。\u003c/p\u003e","title":"理解Atlas 950的“6.7倍算力”：它说明了什么，又没有说明什么"},{"content":"从Atlas 950真机首秀说起，整理这届WAIC里芯片、生态、机器人、治理、资本五条线为什么会在同一周里集中爆发，以及接下来这个系列打算怎么拆。\n现场两个画面 常说“这届WAIC参展企业创纪录、展品超过3000件”，但这类描述读完基本等于没读——真正值得记下来的信号是什么呢？\nAtlas 950 SuperPoD集群(图片来自网络) 7月17日上午，上海世博展览馆华为展台前排起了长队，大家排队不是为了摸新手机，是为了看一台线缆密布、占地极大的“大家伙”——Atlas 950 SuperPoD，第一次以真机形态出现。往展馆深处走，具身智能馆更热闹，314件机器人展品挤在一起，有的在拧螺丝，有的在叠衣服，有的干脆站着一动不动等观众合影。\n这两个画面单拎出来，都能写成一条“国产黑科技又上新”的热搜。但连起来看，会得到一个更值得记住的判断：\n真正决定胜负的，不再是某一项技术有没有反超，而是能不能把硬件、供应链、软件生态、机器人量产、全球化部署、规则制定权拧成一套跑得通的系统。\n会期里几家媒体不约而同的判断 这不是自己脑补的角度。会期这几天转下来，把几家平时报道立场都不太一样的媒体判断整理了一下：\n澎湃新闻：标题直接是《告别参数竞赛，AI全链路商业化》，文章里把“集群协同调度、软硬件一体化适配、全生命周期成本控制”列为新的竞争壁垒，单卡参数不再是唯一门槛。 第一财经：把国产算力的这次转折定义为“迈入系统时代”，原话是“决定AI系统能力的关键因素，正从单颗芯片性能逐渐转向整个计算系统的组织效率”。 钛媒体：总结的“六个趋势”里第一条就写着——“\u0026lsquo;最强模型\u0026rsquo;不再是唯一赢家，竞争重心已从参数规模转向如何把模型整合进完整产品体系”。 网易科技：干脆用了“国产算力告别单打，生态组队加速落地”这样的标题，把“单打”和“组队”直接对立起来。 四家媒体报道立场、擅长的领域都不太一样，却在同一周里几乎异口同声，说明这不是哪家媒体的一家之言，而是这届大会自己“长”出来的共识。\n“系统”拆开是哪五层 拆开看，“系统”具体是五层叠在一起，每一层都对应着这次会场上一个具体的例子：\nAI竞争的五层系统 第一层，芯片本身够不够快。 这是最容易被拿来做标题的一层——“8 EFLOPS”“6.7倍算力”这类数字，但恰恰是最容易掺水、也最不该单独拿出来看的一层。\n第二层，能不能把几千颗芯片高效互联成一台“大计算机”。 华为这次的说法是8192颗昇腾950DT芯片通过UnifiedBus 2.0连成一个逻辑统一体，但芯片数量堆得越多，互联架构跟不上，理论峰值和实际吞吐之间的差距只会越拉越大。\n华为昇腾950超节点(图片来自网络) 第三层，有没有软件生态和大模型愿意为它专门改架构。 DeepSeek-V4的技术报告里提到部分模型架构是“针对昇腾推理协同设计”的，这种深度适配比单纯“能跑起来”难得多，也是这一层真正的门槛。\n第四层，机器人这类硬件产品能不能从展会演示走到工厂真交付。 具身智能馆里314件展品看着热闹，但全行业2744家具身智能企业里，这次真正参展的只有200家，能拿到真实市场流量的更是只有个位数——门槛在这一层体现得最直接。\n第五层，能不能把订单和规则谈到海外去，又不撞上出口管制这堵墙。 昇腾950这次拿到了韩国、马来西亚等地的采购意向，但美国商务部同一时间发布指导意见，认定昇腾910B/910C/910D违反出口管制、全球范围禁止使用——这一层已经不只是技术问题。\n任何一层掉链子，前面攒的优势都可能白费，这也是“系统”这个词比“参数”更适合形容这次WAIC的原因。\n系列地图：接下来六篇分别讲什么 接下来这个系列，就沿着这五层往下拆，一篇看一个维度：\n篇目 核心问题 硬件篇 Atlas 950的参数该怎么看，“6.7倍算力”背后藏着什么口径问题 生态篇 DeepSeek和昇腾的协同适配，是不是等于国产生态已经跑通 机器人篇 从“演示”到“量产”，为什么这个赛道正迅速分化成极少数头部玩家 治理篇 中国牵头成立的WAICO，为什么是“全球首个AI政府间国际组织”这么重的分量 资本篇 二级市场这波“概念股”行情，钱到底在为什么投票 收官篇 给国产算力路线出五道题，作为未来一年的验证清单 WAIC 2026系列地图 为什么是现在写 之所以是现在写，是因为这几条线这次第一次挤在同一个时间点集中爆发。光是芯片这一层，同台亮相的就不止华为一家：\n企业 这次带来的产品 华为 Atlas 950 SuperPoD，8192颗昇腾950DT芯片真机首秀 阿里 真武M890×磐久AL128超节点，首次公开展示 东方算芯 首发DF1000芯片 中兴 联合多家国产厂商推出Matrix超节点 壁仞科技 新品同台展示 沐曦股份 新品同台展示 十余家企业同时把“超节点”级别的产品摆上台面，华泰证券干脆把2026年定义为“国产超节点元年”。与此同时，DeepSeek和字节跳动的适配、锁单消息几乎同步曝出；机器人企业一边宣布量产下线，一边被曝出行业头部效应加剧；中国牵头成立的世界人工智能合作组织（WAICO）又把这一切拉高到了国家层面的博弈——这些信号单看都不算新鲜，但同时挤在一周之内发生，就值得多写几篇，慢慢拆。\n下一篇从硬件开始：Atlas 950到底强在哪，又有哪些数字经不起细看。\n","permalink":"https://blog.onecai.site/2026/07/19/047-waic-2026-ai-system-engineering/","summary":"\u003cp\u003e从Atlas 950真机首秀说起，整理这届WAIC里芯片、生态、机器人、治理、资本五条线为什么会在同一周里集中爆发，以及接下来这个系列打算怎么拆。\u003c/p\u003e\n\u003ch2 id=\"现场两个画面\"\u003e现场两个画面\u003c/h2\u003e\n\u003cp\u003e常说“这届WAIC参展企业创纪录、展品超过3000件”，但这类描述读完基本等于没读——真正值得记下来的信号是什么呢？\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"waic-2026-ai-system-engineering-1.avif\"\n          alt=\"Atlas 950 SuperPoD集群(图片来自网络)\"/\u003e \u003cfigcaption\u003e\n             Atlas 950 SuperPoD集群(图片来自网络)\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e7月17日上午，上海世博展览馆华为展台前排起了长队，大家排队不是为了摸新手机，是为了看一台线缆密布、占地极大的“大家伙”——Atlas 950 SuperPoD，第一次以真机形态出现。往展馆深处走，具身智能馆更热闹，314件机器人展品挤在一起，有的在拧螺丝，有的在叠衣服，有的干脆站着一动不动等观众合影。\u003c/p\u003e\n\u003cp\u003e这两个画面单拎出来，都能写成一条“国产黑科技又上新”的热搜。但连起来看，会得到一个更值得记住的判断：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e真正决定胜负的，不再是某一项技术有没有反超，而是能不能把硬件、供应链、软件生态、机器人量产、全球化部署、规则制定权拧成一套跑得通的系统。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"会期里几家媒体不约而同的判断\"\u003e会期里几家媒体不约而同的判断\u003c/h2\u003e\n\u003cp\u003e这不是自己脑补的角度。会期这几天转下来，把几家平时报道立场都不太一样的媒体判断整理了一下：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e澎湃新闻\u003c/strong\u003e：标题直接是《告别参数竞赛，AI全链路商业化》，文章里把“集群协同调度、软硬件一体化适配、全生命周期成本控制”列为新的竞争壁垒，单卡参数不再是唯一门槛。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e第一财经\u003c/strong\u003e：把国产算力的这次转折定义为“迈入系统时代”，原话是“决定AI系统能力的关键因素，正从单颗芯片性能逐渐转向整个计算系统的组织效率”。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e钛媒体\u003c/strong\u003e：总结的“六个趋势”里第一条就写着——“\u0026lsquo;最强模型\u0026rsquo;不再是唯一赢家，竞争重心已从参数规模转向如何把模型整合进完整产品体系”。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e网易科技\u003c/strong\u003e：干脆用了“国产算力告别单打，生态组队加速落地”这样的标题，把“单打”和“组队”直接对立起来。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e四家媒体报道立场、擅长的领域都不太一样，却在同一周里几乎异口同声，说明这不是哪家媒体的一家之言，而是这届大会自己“长”出来的共识。\u003c/p\u003e\n\u003ch2 id=\"系统拆开是哪五层\"\u003e“系统”拆开是哪五层\u003c/h2\u003e\n\u003cp\u003e拆开看，“系统”具体是五层叠在一起，每一层都对应着这次会场上一个具体的例子：\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"waic-2026-ai-system-engineering-3.avif\"\n          alt=\"AI竞争的五层系统\"/\u003e \u003cfigcaption\u003e\n             AI竞争的五层系统\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e第一层，芯片本身够不够快。\u003c/strong\u003e 这是最容易被拿来做标题的一层——“8 EFLOPS”“6.7倍算力”这类数字，但恰恰是最容易掺水、也最不该单独拿出来看的一层。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二层，能不能把几千颗芯片高效互联成一台“大计算机”。\u003c/strong\u003e 华为这次的说法是8192颗昇腾950DT芯片通过UnifiedBus 2.0连成一个逻辑统一体，但芯片数量堆得越多，互联架构跟不上，理论峰值和实际吞吐之间的差距只会越拉越大。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"waic-2026-ai-system-engineering-2.avif\"\n          alt=\"华为昇腾950超节点(图片来自网络)\"/\u003e \u003cfigcaption\u003e\n             华为昇腾950超节点(图片来自网络)\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e第三层，有没有软件生态和大模型愿意为它专门改架构。\u003c/strong\u003e DeepSeek-V4的技术报告里提到部分模型架构是“针对昇腾推理协同设计”的，这种深度适配比单纯“能跑起来”难得多，也是这一层真正的门槛。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第四层，机器人这类硬件产品能不能从展会演示走到工厂真交付。\u003c/strong\u003e 具身智能馆里314件展品看着热闹，但全行业2744家具身智能企业里，这次真正参展的只有200家，能拿到真实市场流量的更是只有个位数——门槛在这一层体现得最直接。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第五层，能不能把订单和规则谈到海外去，又不撞上出口管制这堵墙。\u003c/strong\u003e 昇腾950这次拿到了韩国、马来西亚等地的采购意向，但美国商务部同一时间发布指导意见，认定昇腾910B/910C/910D违反出口管制、全球范围禁止使用——这一层已经不只是技术问题。\u003c/p\u003e\n\u003cp\u003e任何一层掉链子，前面攒的优势都可能白费，这也是“系统”这个词比“参数”更适合形容这次WAIC的原因。\u003c/p\u003e\n\u003ch2 id=\"系列地图接下来六篇分别讲什么\"\u003e系列地图：接下来六篇分别讲什么\u003c/h2\u003e\n\u003cp\u003e接下来这个系列，就沿着这五层往下拆，一篇看一个维度：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e篇目\u003c/th\u003e\n          \u003cth\u003e核心问题\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e硬件篇\u003c/td\u003e\n          \u003ctd\u003eAtlas 950的参数该怎么看，“6.7倍算力”背后藏着什么口径问题\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e生态篇\u003c/td\u003e\n          \u003ctd\u003eDeepSeek和昇腾的协同适配，是不是等于国产生态已经跑通\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e机器人篇\u003c/td\u003e\n          \u003ctd\u003e从“演示”到“量产”，为什么这个赛道正迅速分化成极少数头部玩家\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e治理篇\u003c/td\u003e\n          \u003ctd\u003e中国牵头成立的WAICO，为什么是“全球首个AI政府间国际组织”这么重的分量\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e资本篇\u003c/td\u003e\n          \u003ctd\u003e二级市场这波“概念股”行情，钱到底在为什么投票\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e收官篇\u003c/td\u003e\n          \u003ctd\u003e给国产算力路线出五道题，作为未来一年的验证清单\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"waic-2026-ai-system-engineering-4.avif\"\n          alt=\"WAIC 2026系列地图\"/\u003e \u003cfigcaption\u003e\n             WAIC 2026系列地图\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"为什么是现在写\"\u003e为什么是现在写\u003c/h2\u003e\n\u003cp\u003e之所以是现在写，是因为这几条线这次第一次挤在同一个时间点集中爆发。光是芯片这一层，同台亮相的就不止华为一家：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e企业\u003c/th\u003e\n          \u003cth\u003e这次带来的产品\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e华为\u003c/td\u003e\n          \u003ctd\u003eAtlas 950 SuperPoD，8192颗昇腾950DT芯片真机首秀\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e阿里\u003c/td\u003e\n          \u003ctd\u003e真武M890×磐久AL128超节点，首次公开展示\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e东方算芯\u003c/td\u003e\n          \u003ctd\u003e首发DF1000芯片\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e中兴\u003c/td\u003e\n          \u003ctd\u003e联合多家国产厂商推出Matrix超节点\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e壁仞科技\u003c/td\u003e\n          \u003ctd\u003e新品同台展示\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e沐曦股份\u003c/td\u003e\n          \u003ctd\u003e新品同台展示\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e十余家企业同时把“超节点”级别的产品摆上台面，华泰证券干脆把2026年定义为“国产超节点元年”。与此同时，DeepSeek和字节跳动的适配、锁单消息几乎同步曝出；机器人企业一边宣布量产下线，一边被曝出行业头部效应加剧；中国牵头成立的世界人工智能合作组织（WAICO）又把这一切拉高到了国家层面的博弈——这些信号单看都不算新鲜，但同时挤在一周之内发生，就值得多写几篇，慢慢拆。\u003c/p\u003e","title":"WAIC 2026最大的信号：AI竞争不再只看芯片，而是看系统"},{"content":"7月15日，xAI 把 Grok Build（也就是 grok 命令行工具）的源码放到了 GitHub 上，仓库地址 xai-org/grok-build。README 第一句话说得很直接：“SpaceXAI\u0026rsquo;s coding agent harness and TUI”——xAI 内部把这套东西挂在 SpaceXAI 名下。\n这篇文章不打算复述“xAI 又开源了什么”这种通稿式的内容，而是把仓库拆开看：代码从哪来、架构怎么分层、这次开源发生在什么时间点、以及“开源”这两个字在这里到底是什么意思。\n一、代码溯源：codex 和 opencode 的血在这里 仓库根目录的 THIRD-PARTY-NOTICES 文件里有一句话写得很清楚：这个仓库包含 “in-tree source ports”，明确点名了 openai/codex 和 sst/opencode 的工具实现。更具体的说明放在 crates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md 里——这是给 codex 和 opencode 移植代码专门写的一份notice，里面附带了完整的许可证文本和 Apache 协议 §4（b） 要求的“变更声明”。\nApache 2.0 的 §4（b） 条款要求：如果你修改了一份 Apache 许可的文件，必须在文件里注明“这份文件被修改过”。换句话说，xAI 不是简单引用了这两个项目的接口或者协议，而是直接拿了源码进来改，改完之后按协议要求留了痕迹。\n这一点值得说清楚的是它的性质——这不是抄袭，因为 codex 和 opencode 本身也是开源项目，License 允许这么做；但它说明一件事：xAI 在 agent 的“工具层”（terminal 执行、文件编辑、代码搜索这些具体能力）上，没有从零设计，而是站在两个已经跑通的开源实现上做二次开发。这是效率选择，不是能力缺陷，但也说明 coding agent 这个赛道走到今天，底层工具调用的实现已经开始趋同——大家在复用相近的工具层模式，只是壳不一样。\n如果想验证到底改了多少，值得做的事情是把 xai-grok-tools crate 里的具体文件和 codex/opencode 对应源文件拉出来做 diff，而不是只看 NOTICE 文件的自述。我实际 clone 了三个仓库做了一遍：\n1 2 3 git clone --depth 1 https://github.com/xai-org/grok-build.git git clone --depth 1 https://github.com/openai/codex.git git clone --depth 1 https://github.com/sst/opencode.git 第一个坑就很说明问题：NOTICE 里写的 codex 对应路径是 codex-rs/core/src/tools/handlers/，但当前 codex 仓库里这块逻辑早已经被重构进了独立的 codex-rs/apply-patch/ crate——说明 codex 自己这段时间也在重构，NOTICE 里的路径只是移植当时的快照，不是实时对应关系。重新定位之后，seek_sequence.rs（模糊行匹配算法，apply_patch 用来在文件里定位要替换的代码块）这个文件很值得拿出来讲：xAI 版本的文档注释里写的是——\n1 //! Ported verbatim from `codex-rs/apply-patch/src/seek_sequence.rs`. “逐字移植”。但实际跑一遍 diff：\n1 2 3 4 5 6 7 8 9 10 - /// Special cases handled defensively: - /// • Empty `pattern` → returns `Some(start)` (no-op match) - /// • `pattern.len() \u0026gt; lines.len()` → returns `None` (cannot match, avoids - /// out‑of‑bounds panic that occurred pre‑2025‑04‑12) - pub(crate) fn seek_sequence( + /// # Edge cases + /// + /// - Empty `pattern` → returns `Some(start)` (no-op match). + /// - `pattern.len() \u0026gt; lines.len()` → returns `None`. + pub fn seek_sequence( 三处实际差异：\n文档注释被完全重写成更详细的 rustdoc 格式（原来几行简短说明，展开成分点列举） 函数可见性从 pub(crate) 改成了 pub——意味着这个函数被暴露给了 crate 外部调用 更关键的一处：原始版本只有三轮渐进式匹配（精确匹配 → 忽略行尾空白 → 忽略首尾空白），xAI 版本在此基础上加了第四轮“Unicode normalise”，把智能引号、长破折号这类 Unicode 标点统一归一化成 ASCII 等价字符再匹配——这是一处真实的功能扩展，不是纯粹的搬运。 “注释里写着逐字移植，代码却被扩了一轮新的匹配策略”——这个细节比笼统地说“移植了codex的代码”更有说服力，也更能说明问题：xAI 拿来的不是黑盒依赖，而是真正读懂、改过、还敢往里加东西的代码。\nGrok Build 工具层源码移植路径 二、架构设计：五层分工，和同类产品同源 仓库的 crates 目录透出了整个系统的分层：\nxai-grok-pager —— TUI 本体：滚动区、输入框、弹窗渲染 xai-grok-pager-bin —— 组合根，负责把上面这层编译成最终的 xai-grok-pager 二进制（对外发布时改名叫 grok） xai-grok-shell —— agent 运行时，包含 leader/stdio/headless 三种入口 xai-grok-tools —— 工具实现层，也就是上面说的 codex/opencode 移植代码所在地 xai-grok-workspace —— 宿主机文件系统、版本控制、执行环境、checkpoint 管理 这套“TUI 层 / runtime 层 / 工具层 / 工作区抽象层”的四段式分工，和 Claude Code、Codex CLI 的架构骨架几乎是同一套模板——这倒不是巧合，而是因为 coding agent 这类产品的功能边界本来就相对固定：理解代码库、调用工具、管理长任务、和终端交互，四件事对应四层。\n语言选择上，整个仓库 99.6% 是 Rust。这和 Claude Code（Node/TS 生态）路线不同，换来的是分发上的优势——单一二进制、无运行时依赖，跨平台打包更简单，这也是为什么 README 里的安装方式是一条 curl | bash，不需要用户先装 Node。\n另外仓库还支持 ACP（Agent Client Protocol），也就是可以被外部编辑器当作后端嵌入调用。这是一个正在形成共识的协议方向——如果 agent 层能通过统一协议对接任意编辑器，“用哪个模型”和“在哪个界面里用”会进一步解耦，这也是 OpenCode 这类“模型无关”工具能快速做大的原因之一。\nGrok Build 四层/五 crate 架构 三、生态位置：一次“半开放”的公关动作 这里有一个容易被忽略的时间线细节：7月14日，安全研究者披露 Grok Build 存在把用户代码仓库过量上传到 Google Cloud 的问题，xAI 随后表示会删除已上传的数据；7月15日，也就是隐私事件曝光的第二天，Grok Build 的源码就上了 GitHub。\n这个先后顺序值得写进文章里，但表述要克制——不必断言二者存在因果关系，只需要把两个时间点摆在一起，让读者自己判断“开源是不是也是一次信任重建”。\n再看开源的“程度”：仓库采用 Apache-2.0 协议，但 CONTRIBUTING.md 明确写着“不接受外部贡献”。这是一种越来越常见的模式——代码可读、可编译、可审计，但治理权完全留在公司内部，社区没有并入代码的通道。这和 sst/opencode 这种真正由社区驱动、目前已经有 16 万+ star 的项目，是两种完全不同的“开源”。\n对比一下同赛道几个选手当前的开放程度，能画出一张清晰的坐标：\n项目 协议 是否接受外部 PR 语言 Claude Code 闭源 不适用 TS/Node Codex CLI （OpenAI） 开源 是 — sst/opencode 开源，社区驱动 是 — Grok Build Apache-2.0，只读式开源 否 Rust Grok Build 这次的开源更接近“展示代码”而不是“共建代码”——放出源码是为了可审计、可自行编译（对隐私敏感的企业客户来说，这一点确实有实际价值），但不是为了吸纳社区力量。\n四、具体数字：这是一份“刚同步出来的镜像” 刚刚查看仓库，当前的数字很能说明问题：97 个 star，3 个 fork，commit 历史只有 1 条。\n1 条 commit 历史意味着这不是一个逐步演进、保留开发历史的仓库，而是从 xAI 内部 monorepo 里定期同步（sync）出来的一份切片——README 原文写的是“periodically synced from the SpaceXAI monorepo”。也就是说，外部永远看不到这个工具真实的迭代过程，每次看到的都是内部某个时间点的快照。\n结合公开信息里的时间线：\n2026年1月：Grok Build 首次在代码痕迹中被发现，xAI 公开预告 2026年5月14–15日：面向 SuperGrok Heavy / X Premium Plus 订阅者（$300/月）开放早期 beta 2026年5月21日：接入 OpenCode，订阅用户可免 API key 直接使用 2026年7月14日：安全研究者披露过量上传代码仓库到 Google Cloud 2026年7月15日：源码开源 从“$300/月订阅制专属工具”到“任何人可读源码自行编译”，中间经历了两个月，隐私事件至少构成了这次开源被解读的直接背景——这条时间线本身就是这篇文章最硬的论据，不需要额外加论证。\nGrok Build 从订阅制 beta 到开源镜像的时间线 五、认证与分发：细节里的产品逻辑 安装方式很简单——一条 curl -fsSL https://x.ai/cli/install.sh | bash，二进制装完后首次启动会打开浏览器走 OAuth 认证，绑定 SuperGrok 或 X Premium 账号。这一步和 Claude Code 的账号绑定流程几乎一样，说明订阅制 CLI 工具在“认证换用量”这件事上已经趋于标准化：源码可以开放，但账号体系和计费闸口始终攥在自己手里——这也解释了为什么“开源”和“限制订阅”在 Grok Build 身上可以并存而不矛盾。\n小结：Grok Build 的开源，本质上是“代码可读 + 治理不放权 + 计费不松口”的组合。它的价值对开发者来说是真实的——可以看到一份成熟 coding agent 的生产级 Rust 实现，尤其是工具调用层直接复用了 codex 和 opencode 的既有方案，省去了大量重复造轮子的过程；但对“开源生态”这三个字而言，这更像是一次公关动作，时间点也恰好卡在一次隐私风波之后的第二天。\n","permalink":"https://blog.onecai.site/2026/07/18/046-grok-build-open-source-code-lineage/","summary":"\u003cp\u003e7月15日，xAI 把 Grok Build（也就是 \u003ccode\u003egrok\u003c/code\u003e 命令行工具）的源码放到了 GitHub 上，仓库地址 xai-org/grok-build。README 第一句话说得很直接：“SpaceXAI\u0026rsquo;s coding agent harness and TUI”——xAI 内部把这套东西挂在 SpaceXAI 名下。\u003c/p\u003e\n\u003cp\u003e这篇文章不打算复述“xAI 又开源了什么”这种通稿式的内容，而是把仓库拆开看：代码从哪来、架构怎么分层、这次开源发生在什么时间点、以及“开源”这两个字在这里到底是什么意思。\u003c/p\u003e\n\u003ch2 id=\"一代码溯源codex-和-opencode-的血在这里\"\u003e一、代码溯源：codex 和 opencode 的血在这里\u003c/h2\u003e\n\u003cp\u003e仓库根目录的 \u003ccode\u003eTHIRD-PARTY-NOTICES\u003c/code\u003e 文件里有一句话写得很清楚：这个仓库包含 “in-tree source ports”，明确点名了 \u003cstrong\u003eopenai/codex\u003c/strong\u003e 和 \u003cstrong\u003esst/opencode\u003c/strong\u003e 的工具实现。更具体的说明放在 \u003ccode\u003ecrates/codegen/xai-grok-tools/THIRD_PARTY_NOTICES.md\u003c/code\u003e 里——这是给 codex 和 opencode 移植代码专门写的一份notice，里面附带了完整的许可证文本和 Apache 协议 §4（b） 要求的“变更声明”。\u003c/p\u003e\n\u003cp\u003eApache 2.0 的 §4（b） 条款要求：如果你修改了一份 Apache 许可的文件，必须在文件里注明“这份文件被修改过”。换句话说，xAI 不是简单引用了这两个项目的接口或者协议，而是\u003cstrong\u003e直接拿了源码进来改\u003c/strong\u003e，改完之后按协议要求留了痕迹。\u003c/p\u003e\n\u003cp\u003e这一点值得说清楚的是它的性质——这不是抄袭，因为 codex 和 opencode 本身也是开源项目，License 允许这么做；但它说明一件事：xAI 在 agent 的“工具层”（terminal 执行、文件编辑、代码搜索这些具体能力）上，没有从零设计，而是站在两个已经跑通的开源实现上做二次开发。这是效率选择，不是能力缺陷，但也说明 coding agent 这个赛道走到今天，底层工具调用的实现已经开始趋同——大家在复用相近的工具层模式，只是壳不一样。\u003c/p\u003e\n\u003cp\u003e如果想验证到底改了多少，值得做的事情是把 \u003ccode\u003exai-grok-tools\u003c/code\u003e crate 里的具体文件和 codex/opencode 对应源文件拉出来做 diff，而不是只看 NOTICE 文件的自述。我实际 clone 了三个仓库做了一遍：\u003c/p\u003e","title":"xAI开源Grok Build,代码里的codex/opencode血统藏不住"},{"content":" 本文是「术语解构」系列之一。上一篇《上下文窗口：标称 1M 的 token，为什么 32K 就开始变笨》讲了模型“读不进去”的问题，结尾留了：KV Cache 出场一次，就吃掉了 64GB 显存。这一篇兑现承诺，拆这张“草稿纸”。\n先纠正上一篇的一个数字。当时写的是：一个32B模型在1M上下文满载时，仅KV Cache就需要64GB以上显存。\n在这篇中把公式摆出来，你会发现“以上”两个字有多克制——按Qwen3-32B的公开架构参数算，是256GB。\n一台24GB的MBP，别说1M，把上下文开到128K，光这张草稿纸就要32GB，模型本体还没算，机器已经装不下了。\n这就是本地部署时候都遇到过的两个现象的共同根源：上下文长度往大调，内存肉眼可见地飙升；对话越聊越长，生成越来越慢。\n今天来看：KV Cache到底是什么、这笔显存账怎么算、以及行业和你各自能拿它怎么办。\n一、KV Cache是什么：不是优化技巧，是生成机制本身 没有 KV Cache 时，每生成一个 token 都要重算全部前文；有 KV Cache 时，把 K/V 草稿纸存下来复用。 之前在显存篇讲过大模型推理分两个阶段：Prefill（把你的输入一次性读完）和Decode（一个token一个token地往外吐）。\n问题出在Decode阶段。当Transformer生成每一个新token时，都要通过注意力机制“回看”前面所有的token。而回看的原材料，是每个token在每一层算出来的两组向量：K（Key）和V（Value）。\n现在做一道选择题。生成第1000个token时，前面999个token的K和V从哪来？\n方案A：现算。把前文999个token从头再过一遍模型。生成下一个token时，再过一遍1000个。每个字都要重算全部前文——计算量随长度平方增长，长对话会慢到不可用。 方案B：存下来。第一次算出来的K和V留在显存里，之后每个新token直接查表。代价是：这些向量得一直占着显存。 方案B就是KV Cache。它不是某种可开可关的“缓存加速”，而是所有主流推理框架的默认工作方式——没有它，长文本生成在算力上根本不成立。\n所以KV Cache的本质一句话就能说清：拿显存换算力。草稿纸这个比喻的准确之处在于——你可以不打草稿，但那样每一步都得心算全部前文；打草稿快得多，只是纸会越用越厚。\n它和模型权重还有一个关键区别：权重一次加载、所有请求共用一份；KV Cache 是每个会话、每段上下文各有一份，而且随长度一路长大。这个区别，是理解后面所有账目的钥匙。\n二、算一笔明细账：显存税的税率是多少 KV Cache 显存占用：随上下文线性膨胀，与内容无关 这笔账有公式，而且不难：\n每个token的KV Cache=2（K和V两份）× 层数 × KV 头数 × 每头维度 × 每参数字节数\n拿两个公开架构参数的模型代进去（FP16 精度，每参数 2 字节）：\n模型 层数 KV 头数 每头维度 每 token 占用 32K 上下文 128K 上下文 1M 上下文 Qwen3-8B 36 8 128 144 KB 4.5 GB 18 GB 144 GB Qwen3-32B 64 8 128 256 KB 8 GB 32 GB 256 GB 注意表格里几个扎眼的地方：\n第一，税率是固定的，按长度线性征收。每读进一个token，Qwen3-32B 就要交256KB显存税——不管这个token是《三体》正文还是标点符号。上下文翻倍，草稿纸严格翻倍。这和上一篇讲的注意力计算量平方增长不同：计算量决定你等多久，KV Cache 决定你装不装得下。\n第二，8B 的小模型也逃不掉。很多人以为小模型省显存，模型本体确实省——Qwen3-8B 量化后5GB左右就能装下。但把上下文开到128K，KV Cache要18GB，是模型本体的三倍多。长上下文场景里，草稿纸才是大头。\n第三，存在一个交叉点。Qwen3-32B的4-bit量化权重约18～20GB。按256KB/token 算，上下文到7～8万token 附近，草稿纸就比模型本体还大了。过了这个点，你的显存主要不是在装模型，是在装草稿。\n第四，并发是这笔税的放大器。上面算的都是单个用户。按表格，一个Qwen3-32B会话开32K上下文，草稿纸8GB——单看不算离谱。但8个用户同时挂着，就是 64GB，权重还是那一份，缓存按会话数复制。这解释了很多部署时的错觉：自己压测时一个人、一段上下文，觉得机器绰绰有余；真实用户进来，多轮对话、长文档、长任务同时挂着，显存突然就不够了。为什么长上下文 API 那么贵（上一篇的第二笔账）？现在你看到了成本端的实体：机房里的显存，一大半在给草稿纸交房租。\n第五，它还拖慢生成速度，而且两个阶段慢得不一样。Prefill 阶段吃计算：输入越长，把整段上下文的K/V 算出来写进缓存的时间越久——这就是长文档丢进去后“先卡一下”的那段等待。Decode阶段吃带宽：每生成一个token，除了读一遍模型权重，还要把整个KV Cache读一遍。上下文10万token时，每个字都背着几十GB的读取量。这就是“越聊越慢”的物理解释——不是模型累了，是草稿纸太厚，翻一遍越来越费时间。\n把这几条合起来，是四个本地部署玩家迟早撞上的“不代表”：\n模型文件装得进显存，不代表长上下文跑得起来 单人聊天能跑，不代表多开几个会话还能跑 8K配置很舒服，不代表64K只是慢一点 Prefill 扛过去了，不代表Decode能一直稳 上一篇讲的是长上下文会让模型变笨；这一篇讲的是更硬的一层——很多时候还没轮到它变笨，显存已经先不够了。\n三、行业怎么驯服它：四条路线 驯服 KV Cache 的四条路线：少存、压缩、存粗、管好。 256GB的账单摆在那里，整个行业这几年在KV Cache上下的功夫，比在“把窗口标大”上实在得多。四条路线，按思路分：\n路线一：少存几份——MQA和GQA。\n原始的多头注意力（MHA）里，每个注意力头都存一份自己的K和 V。以 Llama 2的7B 为例：32层 × 32头，每token要交 512KB。\n后来发现，K和V不需要每个头独一份——多个查询头共享一组KV就够了，质量损失很小。这就是GQA（分组查询注意力）。\n上面表格里Qwen3的“KV 头数 8”就是它：64个查询头共享8组KV，草稿纸直接砍到MHA的1/8。极端版本MQA只留1组。\n现在几乎找不到不用GQA的新模型。没有这一刀，前面表格里所有数字乘以8——长上下文根本走不到发布会那一步。\n路线二：压缩了再存——DeepSeek的MLA。\nGQA是少存几份，MLA（多头潜在注意力）更激进：把K和V压缩成一个低维向量存起来，用的时候再解压展开。DeepSeek-V2论文给出的数字是KV Cache削减93%，压到MHA的约1/15。\n这个架构一路沿用到V3和V4。上一篇讲过厂商在长上下文位置设收费闸门，而DeepSeek的API定价一直是行业地板价——MLA省下来的显存房租，就是底气的一部分。架构上的一个选择，最后会体现在价目表上。\n路线三：存粗一点——KV Cache量化。\n模型权重能量化，草稿纸一样能。K和V从FP16降到8-bit，占用直接减半；降到4-bit，只剩 1/4。代价是精度损失——8-bit基本无感，4-bit在长文本任务上开始可感（尤其V的量化更敏感）。\n这条路线对本地部署用户最实惠，下一节展开。\n路线四：管理得更聪明——PagedAttention和滑动窗口。\nvLLM的论文揭了一个短：传统推理框架给每个请求预留最大长度的连续显存，实际用不满的部分全浪费——实测浪费率60%～80%。PagedAttention借鉴操作系统的分页内存，把KV Cache切成小块按需分配，浪费降到4%以下。同样的显存，能多服务好几倍的并发——这是推理服务这两年降价的技术底牌之一。\n另一个思路是滑动窗口注意力：草稿纸只保留最近N个token，更早的直接扔。Mistral、Gemma都在部分层用了这个设计。省是真省，代价也直白——扔掉的部分，模型是真的“忘了”。\n最后还有一条兜底路线：卸载（Offload）——显存装不下，就把一部分缓存搬到内存甚至磁盘，用的时候再搬回来。容量问题缓解了，速度账立刻难看：Decode每个token都要读缓存，而PCIe搬运不是免费的。这条路线的定位是“能跑总比跑不了强”，不是常规方案。\n四、说句公道话：草稿纸也可以是资产 为了不把KV Cache写成纯反派，补一个反方向的视角。\n既然这张草稿纸算一次这么贵，那算完别扔，存下来卖二手，是不是一门生意？\n是的，这就是各家API的Prompt Caching（提示词缓存）：你的system prompt、背景材料这些每次请求都一样的前缀，第一次算完后KV Cache被存下来，下次命中直接复用，Prefill阶段整个跳过。严格区分一下这两个词：KV Cache是一次会话内部的运行时缓存，解决“生成时不重算前文”；Prompt Caching是把这份缓存跨请求持久化，解决“不同请求不重算相同前缀”。省的都是重复计算，省的位置不同。厂商省了算力，把折扣分你一部分——DeepSeek缓存命中的价格能低到未命中的几十分之一。\n我自己的A股分析Agent就是靠这个把账单打下来的：固定的角色和规则放前缀，每天变的行情数据放后缀，缓存命中率能跑到97%以上。这套计费机制里的门道（写入费、精确前缀匹配、什么场景反而亏钱），值得单独一篇拆解，先按下不表。\n所以对KV Cache完整的评价是：它是长上下文的成本，也是重复上下文的折扣券。贵的是第一次，会用的人不付第二次全款。\n五、落地：三个场景的操作建议 场景一：本地部署——上下文长度是你手动签的显存支票。\n这是最直接能省出真金白银（显存）的地方。关键认知：llama.cpp和LM Studio会按你设置的上下文长度，把KV Cache显存提前划走——不管你实际用不用得到。把context length拉满再抱怨内存爆，等于签了张空头支票怪银行。\n两个具体动作：\n按需设置上下文长度，别拉满。日常问答8K够用，代码和长文任务再上32K。按第二节的表格，Qwen3-32B级别的模型从128K降到 32K，立省24GB——在24GB的Mac上，这是能跑和不能跑的区别。 打开KV Cache量化。llama.cpp用--cache-type-k q8_0 --cache-type-v q8_0（V的量化需要同时开启Flash Attention），LM Studio在模型加载设置里也有对应开关。8-bit让同样的上下文只吃一半显存，日常任务质量无感。 场景二：API调用——把不变的放前面。\nPrompt Caching的命中条件是前缀精确匹配。所以写提示词时养成习惯：system prompt、规则、示例这些不变的部分放最前面，每次变化的用户内容放最后。顺序反了，缓存一次都命中不了，每次都付全款。\n场景三：长对话和Agent——定期换草稿纸，而且新草稿要记“状态”，不要抄“流水账”。\n聊了几个小时的会话越来越慢、越来越贵（每一轮都背着全部历史的KV Cache），这时候最有效的操作不是换模型，是让模型总结当前进展，带着总结开个新会话。草稿纸从10 万token换成2千token，速度、价格、还有上一篇讲的“中间盲区”问题，一次全解决。\n总结时有个讲究：模型需要的是状态，不是聊天记录原文。一份好的交接摘要长这样——目标是什么、已确认的事实和约束有哪些、试过哪些失败路径、下一步做什么。寒暄、重复尝试、已废弃的方案，清掉。Agent场景尤其要注意：工具输出、日志、报错会一轮轮塞回上下文，KV Cache在你没盯着的时候就涨起来了，定期把它们沉淀成状态表，是最便宜的“降税”手段。\n顺带再回应上一篇评论区问到的一个问题——“多长的上下文是安全的”。现在可以给出完整答案：这个问题有两个上限，取较小值。能力上限看上一篇（有效窗口远小于标称，任务越复杂缩水越狠）；硬件上限看这一篇的公式（显存减去模型本体，除以每 token 税率）。云端API只受第一个约束，本地部署两个都躲不开。\n一句话总结这篇：上下文窗口是“能装多少”的承诺，KV Cache是这份承诺的账单——按token计价，用显存支付。\n数据来源\nQwen3 官方技术报告（层数 / KV 头数等架构参数）：arxiv.org/abs/2505.09388 Qwen3-32B / Qwen3-8B 模型卡（Hugging Face）：huggingface.co/Qwen/Qwen3-32B ｜ huggingface.co/Qwen/Qwen3-8B DeepSeek-V2 论文（MLA 架构与 KV Cache 削减 93% 数据）：arxiv.org/abs/2405.04434 vLLM《Efficient Memory Management for Large Language Model Serving with PagedAttention》论文（显存碎片浪费 60%～80% 与 \u0026lt;4% 数据）：arxiv.org/abs/2309.06180 llama.cpp 官方仓库与文档（--cache-type-k / --cache-type-v 等 KV 量化参数）：github.com/ggml-org/llama.cpp DeepSeek API 定价页（缓存命中折扣）：api-docs.deepseek.com ","permalink":"https://blog.onecai.site/2026/07/16/044-kv-cache-vram-bottleneck/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文是「术语解构」系列之一。上一篇《上下文窗口：标称 1M 的 token，为什么 32K 就开始变笨》讲了模型“读不进去”的问题，结尾留了：KV Cache 出场一次，就吃掉了 64GB 显存。这一篇兑现承诺，拆这张“草稿纸”。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e先纠正上一篇的一个数字。当时写的是：一个32B模型在1M上下文满载时，仅KV Cache就需要\u003cstrong\u003e64GB以上\u003c/strong\u003e显存。\u003c/p\u003e\n\u003cp\u003e在这篇中把公式摆出来，你会发现“以上”两个字有多克制——按Qwen3-32B的公开架构参数算，是\u003cstrong\u003e256GB\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e一台24GB的MBP，别说1M，把上下文开到\u003cstrong\u003e128K\u003c/strong\u003e，光这张草稿纸就要\u003cstrong\u003e32GB\u003c/strong\u003e，模型本体还没算，机器已经装不下了。\u003c/p\u003e\n\u003cp\u003e这就是本地部署时候都遇到过的两个现象的共同根源：\u003cstrong\u003e上下文长度往大调，内存肉眼可见地飙升；对话越聊越长，生成越来越慢。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e今天来看：KV Cache到底是什么、这笔显存账怎么算、以及行业和你各自能拿它怎么办。\u003c/p\u003e\n\u003ch2 id=\"一kv-cache是什么不是优化技巧是生成机制本身\"\u003e一、KV Cache是什么：不是优化技巧，是生成机制本身\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"kv-cache-vram-bottleneck-1.avif\"\n          alt=\"没有 KV Cache 时，每生成一个 token 都要重算全部前文；有 KV Cache 时，把 K/V 草稿纸存下来复用。\"/\u003e \u003cfigcaption\u003e\n             没有 KV Cache 时，每生成一个 token 都要重算全部前文；有 KV Cache 时，把 K/V 草稿纸存下来复用。\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e之前在显存篇讲过大模型推理分两个阶段：\u003cstrong\u003ePrefill\u003c/strong\u003e（把你的输入一次性读完）和\u003cstrong\u003eDecode\u003c/strong\u003e（一个token一个token地往外吐）。\u003c/p\u003e\n\u003cp\u003e问题出在Decode阶段。当Transformer生成每一个新token时，都要通过注意力机制“回看”前面所有的token。而回看的原材料，是每个token在每一层算出来的两组向量：\u003cstrong\u003eK\u003c/strong\u003e（Key）和\u003cstrong\u003eV\u003c/strong\u003e（Value）。\u003c/p\u003e\n\u003cp\u003e现在做一道选择题。生成第1000个token时，前面999个token的K和V从哪来？\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e方案A：现算\u003c/strong\u003e。把前文999个token从头再过一遍模型。生成下一个token时，再过一遍1000个。每个字都要重算全部前文——计算量随长度平方增长，长对话会慢到不可用。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e方案B：存下来\u003c/strong\u003e。第一次算出来的K和V留在显存里，之后每个新token直接查表。代价是：这些向量得一直占着显存。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e方案B就是KV Cache。它不是某种可开可关的“缓存加速”，而是所有主流推理框架的默认工作方式——\u003cstrong\u003e没有它，长文本生成在算力上根本不成立。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e所以KV Cache的本质一句话就能说清：\u003cstrong\u003e拿显存换算力\u003c/strong\u003e。草稿纸这个比喻的准确之处在于——你可以不打草稿，但那样每一步都得心算全部前文；打草稿快得多，只是纸会越用越厚。\u003c/p\u003e\n\u003cp\u003e它和模型权重还有一个关键区别：\u003cstrong\u003e权重一次加载、所有请求共用一份；KV Cache 是每个会话、每段上下文各有一份，而且随长度一路长大\u003c/strong\u003e。这个区别，是理解后面所有账目的钥匙。\u003c/p\u003e\n\u003ch2 id=\"二算一笔明细账显存税的税率是多少\"\u003e二、算一笔明细账：显存税的税率是多少\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"kv-cache-vram-bottleneck-2.avif\"\n          alt=\"KV Cache 显存占用：随上下文线性膨胀，与内容无关\"/\u003e \u003cfigcaption\u003e\n             KV Cache 显存占用：随上下文线性膨胀，与内容无关\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这笔账有公式，而且不难：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e每个token的KV Cache=2（K和V两份）× 层数 × KV 头数 × 每头维度 × 每参数字节数\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e拿两个公开架构参数的模型代进去（FP16 精度，每参数 2 字节）：\u003c/p\u003e","title":"KV Cache：每读1个token，就要交一笔“显存税”"},{"content":"最近把2024到2026年这三年里，AI直接面对客户的新闻放在一起看，发现了一个很有意思的矛盾。\n一边，AI已经在真实商业场景里大规模直接服务客户了。Klarna的AI客服上线30天处理了230万次对话，相当于700名全职客服的工作量；到2025年三季度，这个数字涨到了853人，每年节省约6000万美元。京东的数据显示，2026年一季度数字人累计服务商家突破7万家，头部商家的数字人开播率达到80%。\n另一边，监管在同一时间段里连续画出硬红线。国家卫健委明确规定，严禁使用人工智能自动生成处方；2026年5月，国家药监局发布《处方药网络零售合规指南》，严禁AI替代药师审方；2026年2月1日施行的《直播电商监督管理办法》规定，AI数字人直播如果出现违法违规行为，由直播间运营者承担全部责任。\n同样是AI，为什么一边可以直接面对几百万客户，另一边连一张处方单都不能碰？\n这三年的案例和法规拼在一起，答案已经很清楚了：决定AI能不能直接商用的，从来不是它的能力够不够强，而是它出错之后，责任能不能找到人。\n而“签字”，就是责任找到人的那个动作。\n一、签字的本质：不是流程，是责任的锚点 AI说错话，责任仍然回到公司和签字人 商业合同、审计报告、诊断书、处方单，这些东西的本质是确定性承诺——签字的那个人在声明：“我为此负责，出了错你可以来找我。”换句话说，签字从来不是在声明“这是我亲手做的”，而是在声明“我审过，我认可，我愿意承担后果”。\n而大语言模型是一个概率系统。它的每一次输出都是概率采样的结果，哪怕做到99%的准确率，放到日均一万次调用的场景里，就是每天100次错误。错误率可以用工程手段压低，但永远不会归零。\n所以真正的问题从来不是“如何消灭错误”，而是“错误发生的时候，责任流向哪里”。\n来看三个案例：\n案例一：加拿大航空，812加元。2024年2月，加航官网的聊天机器人向一位乘客错误承诺了丧亲票价可以事后退款。乘客索赔，加航的辩护理由堪称经典：聊天机器人是一个“独立实体”，应该为自己的话负责。不列颠哥伦比亚省民事仲裁庭直接驳回，判加航赔偿约812加元。金额很小，但它确立了一个原则：AI说的话，在法律上就是公司说的话。\n案例二：纽约律师，5000美元。2023年，两名律师用ChatGPT写诉状，引用了6个不存在的判例，被纽约南区法院罚款5000美元。注意被罚的是谁——是签字提交诉状的律师，不是OpenAI。签字的人兜底，这正是签字制度在正常运转。\n案例三：德勤澳大利亚，44万澳元。2025年7月，德勤给澳大利亚就业与劳资关系部交付了一份约44万澳元的报告；8月，悉尼大学学者发现其中含有AI编造的学术引用和一段虚构的联邦法院判词；德勤在修订版中承认制作过程使用了AzureOpenAIGPT-4o，并在10月确认退还尾款。这个案例最有价值的地方在于：连四大会计师事务所的多层审核体系都会失守，而失守之后，承担金钱和商誉损失的，仍然是德勤这个法人——不是模型。\n三个案例，三个不同的行业，同一个结论：AI可以生成99%的工作量，但那1%出错时的责任，无法转移给一个没有法律人格、没有资产、无法被惩罚的系统。\n二、Klarna的完整弧线：AI直接面客的天花板在哪里 Klarna是最值得完整讲的案例，因为它在两年半里，把“激进上线”和“翻车回调”两章都演完了。\n上半场，效率神话。2024年2月，Klarna上线与OpenAI合作开发的AI客服。30天内处理230万次对话，自动化了67%的客户对话，问题解决时长从11分钟降到2分钟以内，客户满意度与真人客服持平。效率数字后来还在涨：到2025年三季度，AI承担的工作量相当于853名客服，年节省约6000万美元，NPS达到73。\n下半场，公开回调。2025年5月，Klarna宣布重新招聘真人客服。CEO公开承认，成本驱动的自动化带来了“更低的质量”，并承诺客户“想找真人时，永远能找到真人”。原因有三条：复杂争议、欺诈申诉、困难客户案例上，AI的解决质量明显下降；模型偶尔会对费率、政策、付款条款给出自信但错误的回答——在金融行业，关于钱的错误回答是合规问题，不只是满意度问题；而当初“替代700人”的说法本身也有水分——那是增长期避免新招的人数，不是裁掉的人数。\n行业事后复盘时指出了一个关键点：Klarna的场景几乎是AI最容易吃下的客服负载——结构化数据、已认证的用户、有限且高频的意图集合。把它的成功直接推广到复杂B2B支持、医疗服务或保险理赔，是范畴错误。\nKlarna不是孤例。Gartner预测，到2027年，50%原本计划大幅削减客服人力的组织将放弃该计划。2026年的行业标准已经收敛成一个混合模型：AI处理70%到85%的量，人处理最难的15%到30%。Klarna自己也承认，约30%的工单仍然要转到人工。换个说法：成熟的AI商用，不是把人拿掉，而是把人挪到更关键的位置——AI处理高频，人处理例外、争议和判断。\n从这些案例里，可以提炼出适合AI直接面客的五个特征：高频低风险、意图有限、数据结构化、错误可逆、有人工兜底。订单查询错了可以重查，退款发错了可以撤销——错误可逆，所以AI可以直接上。\n还有一条反直觉但重要的工程结论：在受监管的场景里，50%自动化率配98%准确率，好过75%自动化率配90%准确率。正确的做法是按风险给问题分层，只对低风险层全自动，而不是追求一个漂亮的总自动化率。\n但请注意，即使在Klarna这种“成功”场景里，责任一秒钟都没有转移给AI。AI说错了费率，赔钱的是Klarna；直播新规写得更直白——AI数字人违规，运营者担全责。\n所以严格来说，“AI直接商用”这个说法本身就不成立——真实存在的是：AI直接交付，法人直接担责。\n三、一条光谱：什么决定AI能站多靠前 AI面客的风险光谱 把所有场景排在一条光谱上，规律就出来了。\n光谱左端，完全放开：订单查询、物流跟踪、夜间数字人直播讲解。特征是单次错误的责任成本接近零——说错了重说，发错了重发。\n光谱中间，混合模式：Klarna式的分层路由。AI吃下高频简单问题，低置信度和高风险问题带着上下文转人工。这是2026年绝大多数商业场景的现实形态。\n光谱右端，绝对禁区：处方、审方、诊疗决策、高风险金融决策。中国的监管在这一端写得非常具体——医师本人接诊、处方由接诊医师本人开具、审方必须由药师完成。欧盟AIAct也把生物识别、关键基础设施、教育、就业、信贷评分等列为高风险，核心义务就是人工监督（humanoversight）。\n《处方药网络零售合规指南》里还有一个容易被忽略的细节：除了严禁AI替代审方，它还要求“审方数量控制在合理范围”。这半句话堵住了最后一个漏洞——名义上人签字、实际上人只是橡皮图章。一个药师一天“审核”一万张处方，那个签字就是假的。监管要的不是签字这个动作，是签字背后真实发生的审查。\n决定一个场景落在光谱哪个位置的变量，只有一个：单次错误的责任成本。查错一个订单，成本是几分钟；审错一张处方，成本可能是一条命。责任成本越高的场景，人的签字就越不可替代。\n落到操作层面，这条光谱可以压缩成一个三分法：低风险任务，AI自动做；中风险任务，AI先做、人来确认；高风险任务，AI只能辅助，最终决定必须由人做出。再具体一点：凡是咨询、查询、解释、预约、状态更新，可以大胆交给AI；凡是诊断、裁决、承诺、授权、处罚、拒赔、拒贷、录取、解雇，最后都必须有一个人签字负责。\n四、两种造假：当署名和能力对不上号 两种AI造假：遥控与包壳 理解了“能力、署名、责任必须对齐”这个框架，就能看穿当下AI行业的两种典型造假——它们正好是同一枚硬币的两面。\n在讲造假之前，先说一种更普遍、更隐蔽的姿态：不愿讲清楚边界。很多AI产品的问题不是能力不够，而是宣传和免责各说一套——宣传时是“智能体、无人值守、端到端解决问题”，真出了问题又变成“AI只是辅助工具，最终责任在用户”。这套说法的危险在于它想同时占住两头：拿走自动化的估值，只留下辅助工具的责任。诚实的做法只有两种：如果AI只是辅助，就明确标注哪些内容由AI生成、哪些经过人工确认、什么时候转人工；如果AI能自动执行，就说明它能调用哪些接口、权限和金额上限是多少、风险动作要不要二次确认、日志能不能追溯。一个既不敢开放能力、又不愿承认自己只是辅助的系统，大概率不是产品成熟，而是包装过度。\n而下面这两种，就是包装过度的极端形态。\n第一种：能力在人，署名给AI——遥控机器人。\n1770年，肯佩伦的下棋机器人“土耳其人”轰动欧洲宫廷，秘密是柜子里藏着一个真人棋手。今天一些发布会上的“AI机器人”在结构上一模一样：观众看到的是具身智能，柜子里藏的是一个握手柄的操作员，区别只是柜子从木头变成了无线电。最著名的例子是特斯拉2024年10月的“We,Robot”发布会——Optimus现场调酒、聊天、猜拳，事后彭博社援引知情人士证实：行走是AI自主完成的，但与来宾的对话和大量互动由远程员工操控，起因是发布会前三周才决定让Optimus参展、软件来不及准备。特斯拉全程未主动说明这一点，摩根士丹利分析师在研报中直接写明机器人“依赖遥操作”。自主的行走和遥控的对话混在一起、不加区分地展示——这正是问题所在。\n这种表演在经济上是负生产力：AI商用的全部价值在于监督比——一个人能看住几台机器。而遥控机器人的监督比是1:1，一台机器背后站着一个操作员，成本结构比直接雇人更贵、更慢、更不可靠。需要澄清的是，遥操作本身是正当的技术环节——采集训练数据、做安全兜底、明示的娱乐竞技都没有问题。遥控不可耻，隐瞒遥控才可耻。判断标准只有一条：观众是否被明确告知“此刻是人在操作”。还有一种更恶劣的变体：宣传时说这是AI机器人，出了事故又说“当时是人工操作”——宣传时让AI署名，出事时让操作员担责，把署名和担责硬生生拆开。而商业社会全部制度设计的目的，恰恰是防止这两样东西被拆开。\n第二种：能力不存在，署名给AI——包壳蹭概念。\n这个现象有个现成的英文词，AI-washing，仿照“漂绿”（greenwashing）造的。产品没变，文案变了：关键词匹配改叫“AI客服”，传感器加阈值判断的电饭煲改叫“AI电饭煲”，价格翻倍。最极端的案例是Builder.ai——号称用AI让开发应用“像点披萨一样简单”，拿到微软投资、累计融资超过4.5亿美元、估值一度超过10亿美元，2025年5月进入破产程序。其实早在2019年《华尔街日报》就报道过，它的大部分编码工作由人类工程师而非AI完成；而压垮它的最后一击，是彭博曝出的循环交易虚增收入——2024年销售额向债权人夸大了约300%。它是包壳和遥控的合体：既蹭壳，壳里藏着人，账上还藏着假数字。\n监管的处罚已经落地。美国SEC在2024年3月开出首批AI-washing罚单，两家投资顾问公司因虚假宣称使用AI合计被罚40万美元。注意处罚的落点——罚的仍然是在宣传材料上签字的法人和高管。监管的逻辑一以贯之：谁署名，谁担责。\n四个拆穿包壳的问题：\n第一，关掉AI它还能用吗？真AI产品的AI是承重墙，假AI产品的AI是贴纸。\n第二，它的输出会随输入变化吗？让“AI客服”回答一个话术库里没有的问题，三秒现原形。\n第三，它敢开放什么权限、留下什么日志？真正跑在生产环境里的AI产品，说得清自己能调用哪些接口、失败时怎么复盘、高风险时怎么转人工；只活在演示视频里的产品，这几个问题一问就哑。\n第四，也是终极检验：公司愿意为AI的输出承担什么责任？真把AI当核心能力的公司，会在服务协议里认真定义AI输出的责任边界；蹭壳的公司，宣传页上全是AI，合同里一个字都不敢提。\n宣传里的AI浓度和合同里的AI浓度之差，就是包壳的厚度。\n五、结论：签字环节不是遗留物，是前提条件 把全文的逻辑收拢成一张图：\n签字制度解决的是“AI有能力、没责任”的空洞——能力在AI，责任必须锚在人身上； 遥控造假制造的是“AI没能力、有署名”的幻觉——能力在人，功劳记给了AI； 包壳蹭概念更进一步——能力根本不存在，署名照给AI。 市场和监管这三年做的其实是同一件事：强制“能力、署名、责任”三者对齐。\n直播新规的“显著标识”管的是署名，SEC的罚单管的是能力造假，处方审方的禁令管的是责任。\n最后说一个经济学视角。律师、审计师、医生的高收费里，很大一块买的不是他们的产出，而是他们的执照、他们的职业保险、他们可以被追责的资产。AI把产出的边际成本打到接近零，但责任的价格一分钱都没降。\n所以“最后需要人签字”不是AI时代的过渡状态，更不是即将被淘汰的遗留物——它是AI商用的前提条件。AI商用的真实形态从来不是“AI直接交付”，而是“AI生产，人签收”。而那个签字的位置，正在成为AI时代价值上升最快的岗位。\n参考来源 监管文件（中国）\n国家卫生健康委《互联网诊疗监管细则（试行）》（国卫医发〔2022〕2号）：其他人员、人工智能软件等不得冒用、替代医师本人提供诊疗服务；处方应由接诊医师本人开具，严禁使用人工智能等自动生成处方。相关解读见科技日报《AI不能替代医生直接进行诊疗决策》：https://www.ncsti.gov.cn/kjdt/kjrd/yyjk_kjrd/202502/t20250227_196974.html 国家药监局《处方药网络零售合规指南》（2026年5月发布）：“严禁AI替代审方、重复使用处方，审方数量控制在合理范围”。报道见光明网：https://m.gmw.cn/2026-05/25/content_1304470337.htm；新浪财经：https://finance.sina.com.cn/jjxw/2026-05-27/doc-inhzhxzw9376834.shtml 国家市场监督管理总局、国家互联网信息办公室《直播电商监督管理办法》（2026年2月1日施行）：AI生成的人物图像、视频从事直播电商须显著标识并持续提示；AI直播违法违规由直播间运营者承担全部责任。解读见：https://zhuanlan.zhihu.com/p/2038221585249784127 监管文件（欧盟/美国）\n欧盟《人工智能法案》（Regulation（EU）2024/1689）：禁止性条款自2025年2月2日起适用；生物识别、关键基础设施、教育、就业等高风险领域规则经2026年5月“AIOmnibus”政治协议调整后，将自2027年12月2日起适用。欧盟委员会官方页面：https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai 美国SEC首批AI-washing处罚（2024年3月18日）：投资顾问公司Delphia与GlobalPredictions因虚假宣称使用AI合计被罚40万美元。见SEC新闻稿2024-36。 司法案例\n加拿大航空聊天机器人案：Moffattv.AirCanada,2024BCCRT149（不列颠哥伦比亚省民事仲裁庭，2024年2月），判赔812.02加元，驳回“聊天机器人为独立实体”抗辩。 律师虚构判例案：Matav.Avianca,Inc.，No.22-cv-1461（美国纽约南区联邦法院，2023年6月），涉案律师因提交ChatGPT编造的6个判例被罚款5,000美元。 德勤澳大利亚报告事件：合同2024年12月签订、金额约43.9万澳元，报告2025年7月发布于DEWR官网；2025年8月澳大利亚金融评论报（AFR）率先报道错误，悉尼大学学者ChrisRudge识别出虚构文献与编造的联邦法院判词；修订版披露使用AzureOpenAIGPT-4o，10月确认退还尾款。Fortune（2025年10月7日）：https://fortune.com/2025/10/07/deloitte-ai-australia-government-report-hallucinations-technology-290000-refund/；CFODive退款确认（2025年10月21日）：https://www.cfodive.com/news/deloitte-refunds-60k-report-ai-errors-australian-government-accounting/803321/；事件档案（AIIncidentDatabase#1193）：https://incidentdatabase.ai/cite/1193/ Klarna案例数据\nKlarna官方新闻稿（2024年2月）：AI助手首月处理230万次对话、自动化三分之二客服对话、解决时长从11分钟降至2分钟以内。https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/ Klarna2025年Q3投资者更新数据（853名客服工作量、年省约6000万美元、NPS73）及2025年5月重新招聘真人客服、CEO公开表态，综合分析见Twig：https://www.twig.so/blog/how-klarna-is-revolutionizing-customer-support-with-ai Klarna回调过程与原因复盘：https://www.digitalapplied.com/blog/klarna-reverses-ai-layoffs-replacing-700-workers-backfired 行业数据\nGartner预测（到2027年，50%原计划大幅削减客服人力的组织将放弃该计划）及Ada平台70%平均自动解决率，见AIBusinessMagazine2026案例汇编：https://www.aibmag.com/ai-business-case-studies-and-real-world-enterprise-use-cases/ai-replacing-customer-service-2026-case-studies/ 京东数字人数据（2026年Q1累计服务商家超7万家、头部商家开播率80%）：艾瑞咨询×京东《2026数字人电商直播白皮书》（2026年4月），https://www.163.com/dy/article/KR6EUT6U05118VBB.html；行业观察见腾讯新闻：https://view.inews.qq.com/a/20260508A024VK00 IDC《中国2024年AI数字人市场份额报告》（2025年6月）：2024年中国AI数字人市场规模41.2亿元，同比增长85.3%，预测2026年达102.4亿元。转引见：https://www.sohu.com/a/1046895368_122456835 其他事件\n特斯拉“We,Robot”发布会遥操作报道：彭博社（2024年10月14日，EdLudlow\u0026amp;DavidWelch）援引知情人士证实互动由远程员工操控、行走为AI自主，https://www.bloomberg.com/news/articles/2024-10-14/tesla-s-optimus-robots-were-remotely-operated-at-cybercab-event；TechCrunch汇总报道（含摩根士丹利分析师AdamJonas研报“reliedontele-ops”及现场机器人承认“由人类协助”的视频），https://techcrunch.com/2024/10/14/tesla-optimus-bots-were-controlled-by-humans-during-the-we-robot-event/ Builder.ai破产：彭博社（2025年5月20日）报道其进入破产程序、债权人ViolaCredit划扣3700万美元，https://www.bloomberg.com/news/articles/2025-05-20/microsoft-backed-builder-ai-to-enter-insolvency-proceedings；TechCrunch同日报道（累计融资超4.5亿美元、估值曾超10亿美元、获微软投资），https://techcrunch.com/2025/05/20/once-worth-over-1b-microsoft-backed-builder-ai-is-running-out-of-money/；《华尔街日报》2019年8月最早报道其编码工作主要由人类工程师完成；彭博2025年报道其与印度公司VerSe通过互开发票循环交易虚增收入、2024年销售额向债权人夸大约300%；全程复盘见RestofWorld：https://restofworld.org/2025/builderai-ai-explainer-bankrupt/ ","permalink":"https://blog.onecai.site/2026/07/15/043-ai-commercial-use-human-signature-responsibility/","summary":"\u003cp\u003e最近把2024到2026年这三年里，AI直接面对客户的新闻放在一起看，发现了一个很有意思的矛盾。\u003c/p\u003e\n\u003cp\u003e一边，AI已经在真实商业场景里大规模直接服务客户了。Klarna的AI客服上线30天处理了230万次对话，相当于700名全职客服的工作量；到2025年三季度，这个数字涨到了\u003cstrong\u003e853人\u003c/strong\u003e，每年节省约6000万美元。京东的数据显示，2026年一季度数字人累计服务商家突破7万家，头部商家的数字人开播率达到80%。\u003c/p\u003e\n\u003cp\u003e另一边，监管在同一时间段里连续画出硬红线。国家卫健委明确规定，严禁使用人工智能自动生成处方；2026年5月，国家药监局发布《处方药网络零售合规指南》，严禁AI替代药师审方；2026年2月1日施行的《直播电商监督管理办法》规定，AI数字人直播如果出现违法违规行为，由直播间运营者承担全部责任。\u003c/p\u003e\n\u003cp\u003e同样是AI，为什么一边可以直接面对几百万客户，另一边连一张处方单都不能碰？\u003c/p\u003e\n\u003cp\u003e这三年的案例和法规拼在一起，答案已经很清楚了：\u003cstrong\u003e决定AI能不能直接商用的，从来不是它的能力够不够强，而是它出错之后，责任能不能找到人。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e而“签字”，就是责任找到人的那个动作。\u003c/p\u003e\n\u003ch2 id=\"一签字的本质不是流程是责任的锚点\"\u003e一、签字的本质：不是流程，是责任的锚点\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"ai-commercial-use-human-signature-responsibility-1.avif\"\n         alt=\"AI说错话，责任仍然回到公司和签字人\"/\u003e \u003cfigcaption\u003e\n            AI说错话，责任仍然回到公司和签字人\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e商业合同、审计报告、诊断书、处方单，这些东西的本质是\u003cstrong\u003e确定性承诺\u003c/strong\u003e——签字的那个人在声明：“我为此负责，出了错你可以来找我。”换句话说，签字从来不是在声明“这是我亲手做的”，而是在声明“\u003cstrong\u003e我审过，我认可，我愿意承担后果\u003c/strong\u003e”。\u003c/p\u003e\n\u003cp\u003e而大语言模型是一个\u003cstrong\u003e概率系统\u003c/strong\u003e。它的每一次输出都是概率采样的结果，哪怕做到99%的准确率，放到日均一万次调用的场景里，就是每天100次错误。错误率可以用工程手段压低，但永远不会归零。\u003c/p\u003e\n\u003cp\u003e所以真正的问题从来不是“如何消灭错误”，而是“错误发生的时候，责任流向哪里”。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e来看三个案例：\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e案例一：加拿大航空，812加元\u003c/strong\u003e。2024年2月，加航官网的聊天机器人向一位乘客错误承诺了丧亲票价可以事后退款。乘客索赔，加航的辩护理由堪称经典：聊天机器人是一个“独立实体”，应该为自己的话负责。不列颠哥伦比亚省民事仲裁庭直接驳回，判加航赔偿约812加元。金额很小，但它确立了一个原则：\u003cstrong\u003eAI说的话，在法律上就是公司说的话。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e案例二：纽约律师，5000美元\u003c/strong\u003e。2023年，两名律师用ChatGPT写诉状，引用了6个不存在的判例，被纽约南区法院罚款5000美元。注意被罚的是谁——是签字提交诉状的律师，不是OpenAI。签字的人兜底，这正是签字制度在正常运转。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e案例三：德勤澳大利亚，44万澳元\u003c/strong\u003e。2025年7月，德勤给澳大利亚就业与劳资关系部交付了一份约44万澳元的报告；8月，悉尼大学学者发现其中含有AI编造的学术引用和一段虚构的联邦法院判词；德勤在修订版中承认制作过程使用了AzureOpenAIGPT-4o，并在10月确认退还尾款。这个案例最有价值的地方在于：连四大会计师事务所的多层审核体系都会失守，而失守之后，承担金钱和商誉损失的，仍然是德勤这个法人——不是模型。\u003c/p\u003e\n\u003cp\u003e三个案例，三个不同的行业，同一个结论：\u003cstrong\u003eAI可以生成99%的工作量，但那1%出错时的责任，无法转移给一个没有法律人格、没有资产、无法被惩罚的系统。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二klarna的完整弧线ai直接面客的天花板在哪里\"\u003e二、Klarna的完整弧线：AI直接面客的天花板在哪里\u003c/h2\u003e\n\u003cp\u003eKlarna是最值得完整讲的案例，因为它在两年半里，把“激进上线”和“翻车回调”两章都演完了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e上半场，效率神话\u003c/strong\u003e。2024年2月，Klarna上线与OpenAI合作开发的AI客服。30天内处理230万次对话，自动化了67%的客户对话，问题解决时长从11分钟降到2分钟以内，客户满意度与真人客服持平。效率数字后来还在涨：到2025年三季度，AI承担的工作量相当于853名客服，年节省约6000万美元，NPS达到73。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e下半场，公开回调\u003c/strong\u003e。2025年5月，Klarna宣布重新招聘真人客服。CEO公开承认，成本驱动的自动化带来了“更低的质量”，并承诺客户“想找真人时，永远能找到真人”。原因有三条：复杂争议、欺诈申诉、困难客户案例上，AI的解决质量明显下降；模型偶尔会对费率、政策、付款条款给出自信但错误的回答——在金融行业，关于钱的错误回答是合规问题，不只是满意度问题；而当初“替代700人”的说法本身也有水分——那是增长期避免新招的人数，不是裁掉的人数。\u003c/p\u003e\n\u003cp\u003e行业事后复盘时指出了一个关键点：Klarna的场景几乎是AI最容易吃下的客服负载——\u003cstrong\u003e结构化数据、已认证的用户、有限且高频的意图集合\u003c/strong\u003e。把它的成功直接推广到复杂B2B支持、医疗服务或保险理赔，是范畴错误。\u003c/p\u003e\n\u003cp\u003eKlarna不是孤例。Gartner预测，到2027年，50%原本计划大幅削减客服人力的组织将放弃该计划。2026年的行业标准已经收敛成一个混合模型：\u003cstrong\u003eAI处理70%到85%的量，人处理最难的15%到30\u003c/strong\u003e%。Klarna自己也承认，约30%的工单仍然要转到人工。换个说法：成熟的AI商用，不是把人拿掉，而是把人挪到更关键的位置——AI处理高频，人处理例外、争议和判断。\u003c/p\u003e\n\u003cp\u003e从这些案例里，可以提炼出适合AI直接面客的五个特征：\u003cstrong\u003e高频低风险、意图有限、数据结构化、错误可逆、有人工兜底\u003c/strong\u003e。订单查询错了可以重查，退款发错了可以撤销——错误可逆，所以AI可以直接上。\u003c/p\u003e\n\u003cp\u003e还有一条反直觉但重要的工程结论：在受监管的场景里，\u003cstrong\u003e50%自动化率配98%准确率，好过75%自动化率配90%准确率\u003c/strong\u003e。正确的做法是按风险给问题分层，只对低风险层全自动，而不是追求一个漂亮的总自动化率。\u003c/p\u003e\n\u003cp\u003e但请注意，即使在Klarna这种“成功”场景里，\u003cstrong\u003e责任一秒钟都没有转移给AI\u003c/strong\u003e。AI说错了费率，赔钱的是Klarna；直播新规写得更直白——AI数字人违规，运营者担全责。\u003c/p\u003e\n\u003cp\u003e所以严格来说，“AI直接商用”这个说法本身就不成立——真实存在的是：\u003cstrong\u003eAI直接交付，法人直接担责。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"三一条光谱什么决定ai能站多靠前\"\u003e三、一条光谱：什么决定AI能站多靠前\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"ai-commercial-use-human-signature-responsibility-2.avif\"\n         alt=\"AI面客的风险光谱\"/\u003e \u003cfigcaption\u003e\n            AI面客的风险光谱\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e把所有场景排在一条光谱上，规律就出来了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e光谱左端，完全放开\u003c/strong\u003e：订单查询、物流跟踪、夜间数字人直播讲解。特征是单次错误的责任成本接近零——说错了重说，发错了重发。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e光谱中间，混合模式\u003c/strong\u003e：Klarna式的分层路由。AI吃下高频简单问题，低置信度和高风险问题带着上下文转人工。这是2026年绝大多数商业场景的现实形态。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e光谱右端，绝对禁区\u003c/strong\u003e：处方、审方、诊疗决策、高风险金融决策。中国的监管在这一端写得非常具体——医师本人接诊、处方由接诊医师本人开具、审方必须由药师完成。欧盟AIAct也把生物识别、关键基础设施、教育、就业、信贷评分等列为高风险，核心义务就是人工监督（humanoversight）。\u003c/p\u003e\n\u003cp\u003e《处方药网络零售合规指南》里还有一个容易被忽略的细节：除了严禁AI替代审方，它还要求“审方数量控制在合理范围”。这半句话堵住了最后一个漏洞——\u003cstrong\u003e名义上人签字、实际上人只是橡皮图章\u003c/strong\u003e。一个药师一天“审核”一万张处方，那个签字就是假的。监管要的不是签字这个动作，是签字背后真实发生的审查。\u003c/p\u003e\n\u003cp\u003e决定一个场景落在光谱哪个位置的变量，只有一个：\u003cstrong\u003e单次错误的责任成本\u003c/strong\u003e。查错一个订单，成本是几分钟；审错一张处方，成本可能是一条命。责任成本越高的场景，人的签字就越不可替代。\u003c/p\u003e\n\u003cp\u003e落到操作层面，这条光谱可以压缩成一个三分法：\u003cstrong\u003e低风险任务，AI自动做；中风险任务，AI先做、人来确认；高风险任务，AI只能辅助，最终决定必须由人做出\u003c/strong\u003e。再具体一点：凡是咨询、查询、解释、预约、状态更新，可以大胆交给AI；凡是诊断、裁决、承诺、授权、处罚、拒赔、拒贷、录取、解雇，最后都必须有一个人签字负责。\u003c/p\u003e\n\u003ch2 id=\"四两种造假当署名和能力对不上号\"\u003e四、两种造假：当署名和能力对不上号\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"ai-commercial-use-human-signature-responsibility-3.avif\"\n         alt=\"两种AI造假：遥控与包壳\"/\u003e \u003cfigcaption\u003e\n            两种AI造假：遥控与包壳\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e理解了“能力、署名、责任必须对齐”这个框架，就能看穿当下AI行业的两种典型造假——它们正好是同一枚硬币的两面。\u003c/p\u003e\n\u003cp\u003e在讲造假之前，先说一种更普遍、更隐蔽的姿态：\u003cstrong\u003e不愿讲清楚边界\u003c/strong\u003e。很多AI产品的问题不是能力不够，而是宣传和免责各说一套——宣传时是“智能体、无人值守、端到端解决问题”，真出了问题又变成“AI只是辅助工具，最终责任在用户”。这套说法的危险在于它想同时占住两头：拿走自动化的估值，只留下辅助工具的责任。诚实的做法只有两种：如果AI只是辅助，就明确标注哪些内容由AI生成、哪些经过人工确认、什么时候转人工；如果AI能自动执行，就说明它能调用哪些接口、权限和金额上限是多少、风险动作要不要二次确认、日志能不能追溯。一个既不敢开放能力、又不愿承认自己只是辅助的系统，大概率不是产品成熟，而是包装过度。\u003c/p\u003e\n\u003cp\u003e而下面这两种，就是包装过度的极端形态。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一种：能力在人，署名给AI——遥控机器人。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e1770年，肯佩伦的下棋机器人“土耳其人”轰动欧洲宫廷，秘密是柜子里藏着一个真人棋手。今天一些发布会上的“AI机器人”在结构上一模一样：观众看到的是具身智能，柜子里藏的是一个握手柄的操作员，区别只是柜子从木头变成了无线电。最著名的例子是特斯拉2024年10月的“We,Robot”发布会——Optimus现场调酒、聊天、猜拳，事后彭博社援引知情人士证实：行走是AI自主完成的，但与来宾的对话和大量互动由远程员工操控，起因是发布会前三周才决定让Optimus参展、软件来不及准备。特斯拉全程未主动说明这一点，摩根士丹利分析师在研报中直接写明机器人“依赖遥操作”。自主的行走和遥控的对话混在一起、不加区分地展示——这正是问题所在。\u003c/p\u003e\n\u003cp\u003e这种表演在经济上是负生产力：AI商用的全部价值在于监督比——一个人能看住几台机器。而遥控机器人的监督比是1:1，一台机器背后站着一个操作员，成本结构比直接雇人更贵、更慢、更不可靠。需要澄清的是，遥操作本身是正当的技术环节——采集训练数据、做安全兜底、明示的娱乐竞技都没有问题。\u003cstrong\u003e遥控不可耻，隐瞒遥控才可耻\u003c/strong\u003e。判断标准只有一条：观众是否被明确告知“此刻是人在操作”。还有一种更恶劣的变体：宣传时说这是AI机器人，出了事故又说“当时是人工操作”——宣传时让AI署名，出事时让操作员担责，把署名和担责硬生生拆开。而商业社会全部制度设计的目的，恰恰是防止这两样东西被拆开。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二种：能力不存在，署名给AI——包壳蹭概念。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这个现象有个现成的英文词，AI-washing，仿照“漂绿”（greenwashing）造的。产品没变，文案变了：关键词匹配改叫“AI客服”，传感器加阈值判断的电饭煲改叫“AI电饭煲”，价格翻倍。最极端的案例是Builder.ai——号称用AI让开发应用“像点披萨一样简单”，拿到微软投资、累计融资超过4.5亿美元、估值一度超过10亿美元，2025年5月进入破产程序。其实早在2019年《华尔街日报》就报道过，它的大部分编码工作由人类工程师而非AI完成；而压垮它的最后一击，是彭博曝出的循环交易虚增收入——2024年销售额向债权人夸大了约300%。它是包壳和遥控的合体：既蹭壳，壳里藏着人，账上还藏着假数字。\u003c/p\u003e\n\u003cp\u003e监管的处罚已经落地。美国SEC在2024年3月开出首批AI-washing罚单，两家投资顾问公司因虚假宣称使用AI合计被罚40万美元。注意处罚的落点——\u003cstrong\u003e罚的仍然是在宣传材料上签字的法人和高管\u003c/strong\u003e。监管的逻辑一以贯之：谁署名，谁担责。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e四个拆穿包壳的问题：\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e第一，关掉AI它还能用吗？真AI产品的AI是承重墙，假AI产品的AI是贴纸。\u003c/p\u003e\n\u003cp\u003e第二，它的输出会随输入变化吗？让“AI客服”回答一个话术库里没有的问题，三秒现原形。\u003c/p\u003e\n\u003cp\u003e第三，它敢开放什么权限、留下什么日志？真正跑在生产环境里的AI产品，说得清自己能调用哪些接口、失败时怎么复盘、高风险时怎么转人工；只活在演示视频里的产品，这几个问题一问就哑。\u003c/p\u003e\n\u003cp\u003e第四，也是终极检验：\u003cstrong\u003e公司愿意为AI的输出承担什么责任\u003c/strong\u003e？真把AI当核心能力的公司，会在服务协议里认真定义AI输出的责任边界；蹭壳的公司，宣传页上全是AI，合同里一个字都不敢提。\u003c/p\u003e\n\u003cp\u003e宣传里的AI浓度和合同里的AI浓度之差，就是包壳的厚度。\u003c/p\u003e\n\u003ch2 id=\"五结论签字环节不是遗留物是前提条件\"\u003e五、结论：签字环节不是遗留物，是前提条件\u003c/h2\u003e\n\u003cp\u003e把全文的逻辑收拢成一张图：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e签字制度\u003c/strong\u003e解决的是“AI有能力、没责任”的空洞——能力在AI，责任必须锚在人身上；\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e遥控造假\u003c/strong\u003e制造的是“AI没能力、有署名”的幻觉——能力在人，功劳记给了AI；\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e包壳蹭概念\u003c/strong\u003e更进一步——能力根本不存在，署名照给AI。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e市场和监管这三年做的其实是同一件事：\u003cstrong\u003e强制“能力、署名、责任”三者对齐。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e直播新规的“显著标识”管的是署名，SEC的罚单管的是能力造假，处方审方的禁令管的是责任。\u003c/p\u003e\n\u003cp\u003e最后说一个经济学视角。律师、审计师、医生的高收费里，很大一块买的不是他们的产出，而是他们的执照、他们的职业保险、他们可以被追责的资产。AI把产出的边际成本打到接近零，但责任的价格一分钱都没降。\u003c/p\u003e\n\u003cp\u003e所以“最后需要人签字”不是AI时代的过渡状态，更不是即将被淘汰的遗留物——\u003cstrong\u003e它是AI商用的前提条件\u003c/strong\u003e。AI商用的真实形态从来不是“AI直接交付”，而是“AI生产，人签收”。而那个签字的位置，正在成为AI时代价值上升最快的岗位。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"参考来源\"\u003e参考来源\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e监管文件（中国）\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e国家卫生健康委《互联网诊疗监管细则（试行）》（国卫医发〔2022〕2号）：其他人员、人工智能软件等不得冒用、替代医师本人提供诊疗服务；处方应由接诊医师本人开具，严禁使用人工智能等自动生成处方。相关解读见科技日报《AI不能替代医生直接进行诊疗决策》：https://www.ncsti.gov.cn/kjdt/kjrd/yyjk_kjrd/202502/t20250227_196974.html\u003c/li\u003e\n\u003cli\u003e国家药监局《处方药网络零售合规指南》（2026年5月发布）：“严禁AI替代审方、重复使用处方，审方数量控制在合理范围”。报道见光明网：https://m.gmw.cn/2026-05/25/content_1304470337.htm；新浪财经：https://finance.sina.com.cn/jjxw/2026-05-27/doc-inhzhxzw9376834.shtml\u003c/li\u003e\n\u003cli\u003e国家市场监督管理总局、国家互联网信息办公室《直播电商监督管理办法》（2026年2月1日施行）：AI生成的人物图像、视频从事直播电商须显著标识并持续提示；AI直播违法违规由直播间运营者承担全部责任。解读见：https://zhuanlan.zhihu.com/p/2038221585249784127\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e监管文件（欧盟/美国）\u003c/strong\u003e\u003c/p\u003e\n\u003col start=\"4\"\u003e\n\u003cli\u003e欧盟《人工智能法案》（Regulation（EU）2024/1689）：禁止性条款自2025年2月2日起适用；生物识别、关键基础设施、教育、就业等高风险领域规则经2026年5月“AIOmnibus”政治协议调整后，将自2027年12月2日起适用。欧盟委员会官方页面：https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai\u003c/li\u003e\n\u003cli\u003e美国SEC首批AI-washing处罚（2024年3月18日）：投资顾问公司Delphia与GlobalPredictions因虚假宣称使用AI合计被罚40万美元。见SEC新闻稿2024-36。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e司法案例\u003c/strong\u003e\u003c/p\u003e","title":"AI干完了853个人的活，为什么签字的还得是人？"},{"content":" 本文是术语解构系列文章。\n2023 年，一组研究人员测试了 GPT-4。\n他们问：“汤姆·克鲁斯的母亲是谁？”模型答出了 Mary Lee Pfeiffer。\n换一个对话窗口，再问：“Mary Lee Pfeiffer 的儿子是谁？”模型却没能答出汤姆·克鲁斯。\n同一条亲属关系，正着问会，反着问不会。\n这不是研究者偶然截到的一次翻车。在一组包含 1000 位名人的测试中，GPT-4 回答“某位名人的父母是谁”时，正确率达到 79%；换成父母的名字，反过来问“他或她的孩子是谁”，成功率降到 33%。后一个数字还是在每道题可以尝试 10 次、答对一次就算成功的宽松标准下得到的。\n这个结果很容易让人得出结论：大模型根本不懂亲属关系，不过是在顺着常见词语往下接。\n另一项实验却展示了不同的一面。一个只有约 2500 万参数的小型 GPT，只接受“预测下一步棋”的训练，内部逐渐形成了一个可以被读出、也能影响落子判断的黑白棋棋盘。\n一个实验暴露了知识调用的单向性，一个实验发现了结构化的内部表征。它们并不互相否定，而是拼出了一幅更接近现实的图景：预测下一个 token 可能逼出某种理解，但这种理解并不完整，也不等同于人类的理解。\n“预测”和“理解”不在同一个层面 “大模型是在理解语言，还是在预测下一个 token？”这个问题把两件不同层面的事放在了一起。\n预测下一个 token，描述的是模型接受了什么训练，又怎样逐步生成文本。给定前文后，模型计算接下来不同 token 出现的概率，再选择其中一个继续生成。这里的 token 可能是一个字、一个词，也可能只是词的一部分。\n理解则可以指几种不同的东西。它可能指模型能否解释、区分、迁移和运用一个概念，也可能指模型内部是否形成了与概念和关系对应的结构。再往前走一步，“理解”还可能包含人的身体经验、自我意识和主观感受。\n这三个问题不能靠一句“它只是在预测”一起回答。\n考试可以帮助说明其中的区别。考高分是目标，学生可能真的掌握了知识，也可能只背过题库。只看分数，不容易区分两者；检查他能否换一种方式解释、能否解决新题，再观察他怎样组织知识，证据会更充分。\n语言模型面对的预测任务同样有简单和复杂之分。“今天天气真……”后面接“好”，记住常见搭配就可能答对。若要补全一部侦探小说最后的“凶手是……”，模型需要处理人物关系、动机、时间线和前文线索。最终输出依然是几个 token，完成预测所需的内部计算已经复杂得多。\n预测不自动等于理解，也不自动排除理解。关键要看模型为了完成预测，学到了什么。\n预测棋步时，模型内部出现了棋盘 黑白棋实验适合回答一个具体问题：只从序列中预测下一步，模型会不会学到序列背后没有直接写出的状态？\n2023 年，Kenneth Li 等人在 ICLR 发表了 Othello-GPT 研究。研究人员用大量黑白棋对局记录训练一个小型 GPT。模型看到的只有落子序列，比如 E3、D3、C4。它没有收到棋盘图片、格子相邻关系或黑白棋规则说明，训练任务只有一个，预测下一步可能落在哪里。\nOthello-GPT：只看落子序列，也可能形成棋盘表征 训练后，模型预测非法落子的错误率降到很低。研究人员又删掉一种开局对应的训练数据，再用这部分棋局测试，模型依然能够较好地预测合法落子。这个结果说明，简单背下训练棋谱不足以解释模型的表现。\n更关键的证据来自模型内部。\n研究人员在中间层激活上训练了一个小分类器，也就是“探针”，尝试读出棋盘每个位置当前是黑子、白子还是空格。探针能够以很低的错误率还原棋盘状态。后续研究换用“我方棋子、对方棋子、空格”这套坐标后，还发现相关信息可以被线性读取。\n能读出棋盘，只能证明内部包含相关信息。它有没有真的参与下一步预测，还需要因果证据。\n研究人员随后直接修改模型内部对某个格子的表示，相当于在它的“脑内棋盘”上翻转一枚棋子。修改后，模型预测的合法落子也随之变化，而且变化方向符合新棋盘的规则。这表明棋盘状态不只是被动留在激活中的痕迹，它参与了模型的计算。\n改动内部棋盘，预测结果随之改变 这个实验足以反驳一种过于简单的说法：序列预测只能记住表面搭配，不可能形成隐藏状态的内部表示。\n它的边界也很清楚。黑白棋是封闭的合成环境，棋盘固定、规则稳定、合法状态可以精确计算。自然语言连接的是一个开放、含混且不断变化的世界。文本里既有事实，也有错误、隐喻和偏见。从一个棋盘状态表征，不能直接推出通用语言模型已经建立了完整的现实世界模型。\n黑白棋实验说明这种内部结构可以出现。它没有证明这种结构在所有语言任务中都会出现，也没有证明模型因此拥有意识。\n模型学到关系，却不一定能反过来调用 逆转诅咒展示的是另一种限制。\n名人问答无法直接证明问题出在训练，因为研究者不知道 GPT-4 的预训练数据究竟怎样描述过这些人物。论文的核心实验因此使用了完全虚构的人名和作品。\n研究人员微调 GPT-3 和 Llama-1，让模型学习这样的事实：\nUriah Hawthorne 是《Abyssal Melodies》的作曲者。\n训练后，模型可以根据 Uriah Hawthorne 说出他的身份。研究人员换一个方向提问：“谁创作了《Abyssal Melodies》？”模型的准确率却接近于零，给正确名字的概率也没有显著高于随机名字。\n论文测试了不同模型、参数规模、训练设置和改写方式，还在训练集中加入了一些双向表达作为示范。这些尝试都没有让模型把新学到的单向事实自动推广到反方向。《逆转诅咒》原论文将它概括为自回归语言模型的一种方向性泛化失败。\n逆转诅咒：学会 A→B，不一定自动学会 B→A 这里需要保留两个限定。\n一方面，如果“A 是 B”直接出现在当前上下文里，模型通常可以推导出“B 是 A”。逆转诅咒关注的是模型从训练中吸收一个事实后，能否在没有原句提示的情况下反向调用，不代表模型在所有场景下都无法处理对称关系。\n另一方面，这项实验观察到了知识学习和提取的方向性，却没有完全揭示知识在参数中的存储格式。把它形容成“单行道”很直观，但仍然是一种比喻，不能据此断言模型内部只有一条简单的条件概率连线。\n后续的反向训练研究通过改变训练文本的方向缓解了这个问题，也进一步说明训练方式会影响关系能否被双向调用。反向训练研究提供了一种改进办法，并没有把所有自回归模型永久判定为只能单向记忆。\n两个实验讲的是同一件事 Othello-GPT 和逆转诅咒研究的任务不同，很难被摆成一场“理解”和“不理解”的对决。\n黑白棋实验告诉我们，预测任务可能促使模型形成结构化、可干预的内部表征。逆转诅咒告诉我们，模型学到的信息仍可能受表达顺序和训练方向影响，无法像人期待的那样稳定调用。\n它们共同反对两个极端判断。\n“大模型只是概率鹦鹉”忽略了模型能够抽象、迁移并形成内部结构。概率学习不是对能力的否定，复杂的统计学习完全可能产生有功能的概念表示。\n“大模型已经像人一样真正理解”也缺少证据。内部存在棋盘或关系表征，不代表模型能在所有形式、所有场景中稳定运用，更不代表它拥有人的身体经验、持续生活和主观感受。\n为了避免把这些问题混在一起，可以把“理解”分成三个层次。\n生成机制：它怎样说出下一句话 大模型通过预测下一个 token 逐步生成文本。这是明确的技术事实，却只说明输出怎样产生。\n功能性理解：它能不能解释和运用 如果模型能识别关系、换一种方式解释概念、把规则迁移到新任务，并且内部存在支持这些行为的表征，我们可以谨慎地说，它表现出某种功能性理解。\n这种理解不是全有或全无。模型可能理解句法，却误判现实条件；能解释一个概念，换一种呈现形式后又失败；能完成局部推理，却无法长期保持一致。逆转诅咒就是这类不完整性的一个例子。\n主观理解：它是否知道自己懂了 人知道“烫”，不仅因为见过这个字。热水带来的疼痛、缩手的动作、对危险的记忆，都参与了这个概念。大模型可以描述烫伤，也可以安慰受伤的人，目前没有可靠证据表明它像人一样经历疼痛。\n探针和内部干预可以告诉我们模型有没有形成某种表征，以及这种表征是否参与计算。它们无法直接测出模型是否拥有意识、自我或主观体验。塞尔的“中文房间”因此没有被工程工具彻底解决，只是其中关于内部计算的一部分开始能够被测量。\n流畅不能证明意识，失误也不能证明毫无理解 大模型很容易诱发两种错觉。\n它写出流畅、体贴、像是深思熟虑的回答时，我们会把语言表现自动解释成内心体验。它在一个简单关系上出错时，我们又会觉得前面的能力全是伪装。\n判断功能性理解，需要比“说得像不像人”更强的证据。换一种措辞还能不能答对，放到陌生任务中能不能迁移，改变内部状态会不会因果性地改变行为，这些测试比一段漂亮对话更可靠。\n至于主观体验，目前没有一种公认方法可以只根据模型输出确认它。把功能性理解和意识分开，不会削弱黑白棋实验的意义，也不会掩盖逆转诅咒暴露的问题。\n回到最初的问题 大模型是在理解语言，还是在预测下一个 token？\n它确实通过预测下一个 token 学习和生成。复杂预测有时会促使模型形成概念、关系和任务状态的内部表征，并用这些表征完成解释、迁移和推理。这可以被称为一种有限的功能性理解。\n它的理解方式与人不同，也远没有人的理解稳定。模型缺少人的身体经验和连续生活，学到的关系可能受表达顺序影响，内部表征也可能在新场景中突然失灵。流畅语言不足以证明它拥有意识。\n听到“大模型只是在预测下一个 token”时，最需要警惕的是那个“只”。预测描述了模型从哪里出发，没有替我们回答它最终学到了什么。\n更有价值的问题是：它形成了什么结构，这些结构支持哪些能力，又会在什么条件下失效。\n你更关心大模型的哪一种“理解”：能不能正确完成任务，内部有没有形成概念，还是它有没有主观体验？\n参考资料 Kenneth Li, Aspen K. Hopkins, David Bau, Fernanda Viégas, Hanspeter Pfister, Martin Wattenberg. Emergent World Representations: Exploring a Sequence Model Trained on a Synthetic Task. ICLR 2023. Neel Nanda, Andrew Lee, Martin Wattenberg. Emergent Linear Representations in World Models of Self-Supervised Sequence Models. 2023. Lukas Berglund, Meg Tong, Max Kaufmann, Mikita Balesni, Asa Cooper Stickland, Tomasz Korbak, Owain Evans. The Reversal Curse: LLMs trained on “A is B” fail to learn “B is A”. ICLR 2024. Olga Golovneva, Zeyuan Allen-Zhu, Jason Weston, Sainbayar Sukhbaatar. Reverse Training to Nurse the Reversal Curse. EMNLP 2024. John Searle. Minds, Brains, and Programs. Behavioral and Brain Sciences, 1980. ","permalink":"https://blog.onecai.site/2026/07/14/042-next-token-prediction-vs-understanding/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文是术语解构系列文章。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e2023 年，一组研究人员测试了 GPT-4。\u003c/p\u003e\n\u003cp\u003e他们问：“汤姆·克鲁斯的母亲是谁？”模型答出了 Mary Lee Pfeiffer。\u003c/p\u003e\n\u003cp\u003e换一个对话窗口，再问：“Mary Lee Pfeiffer 的儿子是谁？”模型却没能答出汤姆·克鲁斯。\u003c/p\u003e\n\u003cp\u003e同一条亲属关系，正着问会，反着问不会。\u003c/p\u003e\n\u003cp\u003e这不是研究者偶然截到的一次翻车。在一组包含 1000 位名人的测试中，GPT-4 回答“某位名人的父母是谁”时，正确率达到 79%；换成父母的名字，反过来问“他或她的孩子是谁”，成功率降到 33%。后一个数字还是在每道题可以尝试 10 次、答对一次就算成功的宽松标准下得到的。\u003c/p\u003e\n\u003cp\u003e这个结果很容易让人得出结论：大模型根本不懂亲属关系，不过是在顺着常见词语往下接。\u003c/p\u003e\n\u003cp\u003e另一项实验却展示了不同的一面。一个只有约 2500 万参数的小型 GPT，只接受“预测下一步棋”的训练，内部逐渐形成了一个可以被读出、也能影响落子判断的黑白棋棋盘。\u003c/p\u003e\n\u003cp\u003e一个实验暴露了知识调用的单向性，一个实验发现了结构化的内部表征。它们并不互相否定，而是拼出了一幅更接近现实的图景：预测下一个 token 可能逼出某种理解，但这种理解并不完整，也不等同于人类的理解。\u003c/p\u003e\n\u003ch2 id=\"预测和理解不在同一个层面\"\u003e“预测”和“理解”不在同一个层面\u003c/h2\u003e\n\u003cp\u003e“大模型是在理解语言，还是在预测下一个 token？”这个问题把两件不同层面的事放在了一起。\u003c/p\u003e\n\u003cp\u003e预测下一个 token，描述的是模型接受了什么训练，又怎样逐步生成文本。给定前文后，模型计算接下来不同 token 出现的概率，再选择其中一个继续生成。这里的 token 可能是一个字、一个词，也可能只是词的一部分。\u003c/p\u003e\n\u003cp\u003e理解则可以指几种不同的东西。它可能指模型能否解释、区分、迁移和运用一个概念，也可能指模型内部是否形成了与概念和关系对应的结构。再往前走一步，“理解”还可能包含人的身体经验、自我意识和主观感受。\u003c/p\u003e\n\u003cp\u003e这三个问题不能靠一句“它只是在预测”一起回答。\u003c/p\u003e\n\u003cp\u003e考试可以帮助说明其中的区别。考高分是目标，学生可能真的掌握了知识，也可能只背过题库。只看分数，不容易区分两者；检查他能否换一种方式解释、能否解决新题，再观察他怎样组织知识，证据会更充分。\u003c/p\u003e\n\u003cp\u003e语言模型面对的预测任务同样有简单和复杂之分。“今天天气真……”后面接“好”，记住常见搭配就可能答对。若要补全一部侦探小说最后的“凶手是……”，模型需要处理人物关系、动机、时间线和前文线索。最终输出依然是几个 token，完成预测所需的内部计算已经复杂得多。\u003c/p\u003e\n\u003cp\u003e预测不自动等于理解，也不自动排除理解。关键要看模型为了完成预测，学到了什么。\u003c/p\u003e\n\u003ch2 id=\"预测棋步时模型内部出现了棋盘\"\u003e预测棋步时，模型内部出现了棋盘\u003c/h2\u003e\n\u003cp\u003e黑白棋实验适合回答一个具体问题：只从序列中预测下一步，模型会不会学到序列背后没有直接写出的状态？\u003c/p\u003e\n\u003cp\u003e2023 年，Kenneth Li 等人在 ICLR 发表了 Othello-GPT 研究。研究人员用大量黑白棋对局记录训练一个小型 GPT。模型看到的只有落子序列，比如 E3、D3、C4。它没有收到棋盘图片、格子相邻关系或黑白棋规则说明，训练任务只有一个，预测下一步可能落在哪里。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"next-token-prediction-vs-understanding-1.avif\"\n         alt=\"Othello-GPT：只看落子序列，也可能形成棋盘表征\"/\u003e \u003cfigcaption\u003e\n            Othello-GPT：只看落子序列，也可能形成棋盘表征\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e训练后，模型预测非法落子的错误率降到很低。研究人员又删掉一种开局对应的训练数据，再用这部分棋局测试，模型依然能够较好地预测合法落子。这个结果说明，简单背下训练棋谱不足以解释模型的表现。\u003c/p\u003e\n\u003cp\u003e更关键的证据来自模型内部。\u003c/p\u003e\n\u003cp\u003e研究人员在中间层激活上训练了一个小分类器，也就是“探针”，尝试读出棋盘每个位置当前是黑子、白子还是空格。探针能够以很低的错误率还原棋盘状态。后续研究换用“我方棋子、对方棋子、空格”这套坐标后，还发现相关信息可以被线性读取。\u003c/p\u003e\n\u003cp\u003e能读出棋盘，只能证明内部包含相关信息。它有没有真的参与下一步预测，还需要因果证据。\u003c/p\u003e\n\u003cp\u003e研究人员随后直接修改模型内部对某个格子的表示，相当于在它的“脑内棋盘”上翻转一枚棋子。修改后，模型预测的合法落子也随之变化，而且变化方向符合新棋盘的规则。这表明棋盘状态不只是被动留在激活中的痕迹，它参与了模型的计算。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"next-token-prediction-vs-understanding-2.avif\"\n         alt=\"改动内部棋盘，预测结果随之改变\"/\u003e \u003cfigcaption\u003e\n            改动内部棋盘，预测结果随之改变\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e这个实验足以反驳一种过于简单的说法：序列预测只能记住表面搭配，不可能形成隐藏状态的内部表示。\u003c/p\u003e\n\u003cp\u003e它的边界也很清楚。黑白棋是封闭的合成环境，棋盘固定、规则稳定、合法状态可以精确计算。自然语言连接的是一个开放、含混且不断变化的世界。文本里既有事实，也有错误、隐喻和偏见。从一个棋盘状态表征，不能直接推出通用语言模型已经建立了完整的现实世界模型。\u003c/p\u003e\n\u003cp\u003e黑白棋实验说明这种内部结构可以出现。它没有证明这种结构在所有语言任务中都会出现，也没有证明模型因此拥有意识。\u003c/p\u003e\n\u003ch2 id=\"模型学到关系却不一定能反过来调用\"\u003e模型学到关系，却不一定能反过来调用\u003c/h2\u003e\n\u003cp\u003e逆转诅咒展示的是另一种限制。\u003c/p\u003e\n\u003cp\u003e名人问答无法直接证明问题出在训练，因为研究者不知道 GPT-4 的预训练数据究竟怎样描述过这些人物。论文的核心实验因此使用了完全虚构的人名和作品。\u003c/p\u003e","title":"大模型只是在预测下一个token吗？两个实验给出了一幅更复杂的图景"},{"content":" 本文为「术语解构」系列。\n一、账单上差了 50 倍的两行数字 打开 DeepSeek 的官方定价页，V4-Flash 这个模型的输入价格写了两行：\n输入（缓存命中）：0.02 元 / 百万 tokens 输入（缓存未命中）：1 元 / 百万 tokens 同样是把 100 万个 token 喂给同一个模型，价格差了 50 倍。V4-Pro 更夸张：命中 0.025 元，未命中 3 元，差 120 倍。\n这不是 DeepSeek 独有的玩法。Anthropic 的 Claude，缓存读取按标准输入价的 10% 计费——Sonnet 4.6 的输入从 3 美元/百万降到 0.3 美元/百万。OpenAI 的 GPT-5.5，输入 5 美元/百万，缓存输入 0.5 美元/百万，同样是 1/10。\n也就是说，2026 年主流大模型 API 的账单上，“你输入了多少 token”已经不是决定性变量了。决定性变量是：这些 token 里，有多少是模型“见过”的。\n这个“见过”的判定机制，就是今天要拆的术语——前缀缓存（Prefix Caching），以及它背后的计费逻辑。\n二、模型凭什么给你打一折：前缀缓存的极简原理 大模型处理你的提示词，不是“读一遍文字”这么轻松。每个 token 进来，模型都要为它计算一大堆注意力中间结果（专业名词叫 KV Cache，键值缓存），存在显存里，供后续生成使用。提示词越长，这一步烧的算力越多——这也是为什么长提示词的首字响应总是慢半拍。\n前缀缓存的思路很直接：如果这次请求的开头部分，和之前某次请求的开头一模一样，那这部分的中间结果就不用重算了，直接复用上次存下来的。\n打个比方。我整理邮票贴片时，前 30 页已经排定、贴好、写完说明的部分，不会因为要加第 31 页就全部拆掉重排——只有新的那一页需要动手。模型也一样：相同的前缀直接翻到“上次整理好的位置”，只算新增的后缀。\n但这里有一条铁律，也是整篇文章最重要的一句话：\n前缀必须从第 0 个 token 开始一模一样。差一个字，从那个字开始往后全部重算。\n前缀缓存如何判断缓存命中 Anthropic 官方文档的表述是“缓存命中要求提示片段 100% 精确匹配”。DeepSeek 的机制同样是从第一个 token 开始逐段比对前缀。没有“大致相似”，没有“意思差不多”，只有逐字节一致。\n至于 KV Cache 在显存里到底长什么样、为什么它是长上下文的最大瓶颈、DeepSeek 靠什么把它压缩到别家的十分之一——这些留给下一篇《KV Cache》专门拆，今天我们只盯住账单。\n三、三家计费模式对比：自动派、手动派，和正在换阵营的 OpenAI 三家厂商对缓存的收费设计完全不同，背后是三种产品哲学。先上核对过的官方数据（2026 年 7 月 12 日）：\n厂商 / 模型 标准输入 缓存写入 缓存读取 读取折扣 触发方式 DeepSeek V4-Flash 1 元/百万 免费 0.02 元/百万 1/50 全自动 DeepSeek V4-Pro 3 元/百万 免费 0.025 元/百万 1/120 全自动 Claude Sonnet 4.6 $3/百万 $3.75（5 分钟）/ $6（1 小时） $0.30/百万 1/10 手动打断点 Claude Opus 4.8 $5/百万 $6.25 / $10 $0.50/百万 1/10 手动打断点 GPT-5.5 $5/百万 免费 $0.50/百万 1/10 自动（≥1024 token） GPT-5.6-sol $5/百万 $6.25 $0.50/百万 1/10 自动 （注：Claude 现已同时支持自动缓存模式；GPT-5.6 为新一代命名，见下文。）\n大模型 API 的三种缓存计费模式 自动派（DeepSeek、OpenAI 旧款）：什么都不用改。系统自动识别请求之间的公共前缀，命中了就按折扣价计费，写入不收钱。DeepSeek 甚至把缓存落到了硬盘上，早上建立的上下文，隔了几个小时还能命中。代价是“尽力而为”——命中与否你无法强制。\n手动派（Anthropic）：你要在请求里显式打 cache_control 标记（俗称缓存断点），告诉系统“缓存到这里为止”。写入要加价：5 分钟有效期收 1.25 倍，1 小时有效期收 2 倍。看起来吃亏，算一笔账就知道不亏：多付的写入费是 0.25 倍，而每次命中省 0.9 倍——只要缓存被读一次，就已经回本。5 分钟有效期还有个隐藏福利：每次命中会免费续期，高频调用场景下缓存实际上永不过期。\n正在换阵营的 OpenAI：这是我核对官方定价页时发现的一个新细节。GPT-5.5 和 5.4 的定价表里，“缓存写入”一列是空的（不收费）；但 2026 年 7 月刚全面开放的 GPT-5.6 系列（sol / terra / luna 三档），定价表里出现了独立的缓存写入列，费率正好是输入价的 1.25 倍——和 Anthropic 一模一样。自动派的代表开始向手动派的计费结构靠拢，这说明“写入收费 + 深度读取折扣”可能会成为行业标准答案。\n那厂商为什么敢打一折甚至打到 1/120？因为缓存命中的部分，真的几乎不花钱。命中时最烧算力的预填充（prefill）环节被整段跳过，数据从缓存直接加载——边际成本本来就比正常推理低一个数量级。DeepSeek 把这个环节的价格打到极致，本质上是把自家架构上的成本优势（KV Cache 压缩到传统方案的 10%，下篇细讲）直接让渡给开发者，同时精准打击没有同类压缩能力的对手：你跟，可能亏钱；不跟，丢客户。\n换个角度看，这个巨大的价差还是厂商在用价格杠杆训练开发者：把提示词写成“缓存友好”的结构，你省钱，厂商省算力，双赢。\n四、三个最容易踩的坑：标题这句话其实不严谨 “同样一段话，第二次问只收 1/10”——这是大多数人对缓存计费的直觉理解，但严格来说有三处不准确。搞懂这三处，你就超过了 90% 只看过定价表的人。\n坑一：便宜的不是“同样的问题”，是“同样的前缀”。\n你今天问“帮我总结这份财报”，明天再问一模一样的“帮我总结这份财报”，未必命中缓存——如果你的系统提示词里有任何变化，或者对话历史不同，前缀就对不上。反过来，两次问题完全不同，但系统提示词、工具定义、知识库这些开头部分一致，照样命中。缓存看的是开头，不是问题本身。\n最经典的翻车姿势：有人在系统提示词开头塞了一行“当前时间：2026-07-12 14:23:07”。这个前缀每秒都在变，缓存命中率直接归零——每次请求都付全价（Anthropic 用户还要额外付 1.25 倍的写入费），写进去的缓存永远没机会被读出来。Anthropic 官方文档专门把这个案例写进了“常见错误”一节。\n坑二：缓存有时效。\nAnthropic 默认 5 分钟，可加钱升到 1 小时；OpenAI 不做保证；DeepSeek 因为落了硬盘，有效期最长，但官方同样注明“尽力而为，不做保证”。如果你的调用频率是“每 7 分钟一次”，撞上 5 分钟有效期，就会出现最惨的情况：每次都付写入费，每次都过期，一次读取都没有。\n坑三：短提示词根本不缓存。\nOpenAI 要求前缀至少 1024 token 才启用自动缓存；Anthropic 各模型的最低门槛从 512 到 4096 token 不等（Sonnet 4.6 是 1024）。一句“你是一个乐于助人的助手”加一个短问题，享受不到任何折扣。这个门槛设计也合理：太短的前缀，缓存管理本身的开销比省下的算力还贵。\n五、实操三步：把命中率从 30% 做到 95% 以上 原理和坑都清楚了，落地就三步。\n第一步：重排提示词——稳的在前，变的在后。\n提高AI缓存命中率的提示词排列方法 按变化频率排序：工具定义（几乎不变）→ 系统提示词（很少变）→ 知识库/few-shot 例子（偶尔变）→ 对话历史（每轮追加但不修改）→ 用户本轮输入（每次都变）。所有会变的东西，包括时间戳、请求 ID、随机数，一律移到最后。光这一步，自动派（DeepSeek/OpenAI）就开始命中了，一行代码不用改。\n第二步：手动派打好断点。\n用 Claude 的话，把 cache_control 打在“最后一个跨请求不变的块”上，而不是最后一个块上。Anthropic 允许一个请求最多 4 个断点，可以把“工具定义”和“知识库”分开缓存——工具几个月不动，知识库每天更新，各缓存各的。\n第三步：盯住命中率字段。\n三家的 API 响应里都带缓存统计：DeepSeek 是 prompt_cache_hit_tokens 和 prompt_cache_miss_tokens，Anthropic 是 cache_read_input_tokens 和 cache_creation_input_tokens，OpenAI 是 cached_tokens。把“缓存读取 / 总输入”做成监控指标，长期低于 50% 就回头查前两步。\n做到位是什么效果？先看社区里的极端案例：一位开发者用 DeepSeek API 跑 Web 开发，单日消耗约 8900 万 tokens，缓存命中率 98.07%，总费用 4.39 元人民币。开源项目 DeepSeek-Reasonix 把整个 Agent 循环围绕缓存稳定性重新设计，单日 4.35 亿输入 tokens，命中率 99.82%，实际花费 1.38 美元——同样的量不走缓存要 61 美元。\n再贴一份我自己的账单。我有一个每天定时运行的 A 股分析 Agent：AKShare 拉行情数据，DeepSeek V4-Flash 做分析，结果推送到飞书。它的提示词结构天然缓存友好——固定的角色设定和分析规则在前面，每次变化的行情数据在最后。\n过去 30 天（6 月 13 日至 7 月 12 日），DeepSeek 后台的数字是：700 次 API 请求，33,676,238 个 tokens，总消费 5.73 元。\nDeepSeek 平台用量后台截图 算一笔反事实的账：这 3367 万 tokens，哪怕全部按最便宜的“缓存未命中输入”1 元/百万计价——连一个 2 元/百万的输出 token 都不算——也要 33.7 元。实际账单 5.73 元，差了近 6 倍。这个差额只有一个来源：大部分输入前缀命中了 0.02 元/百万的缓存价。\n单日数据看得更清楚。用量最大的一天是 6 月 14 日，后台的逐项拆解是：\n输入（命中缓存）：16,670,976 tokens 输入（未命中缓存）：449,817 tokens 输出：108,912 tokens 输入侧命中率 97.4%。按官方定价核算当日成本：命中部分 0.33 元，未命中部分 0.45 元，输出 0.22 元，合计约 1 元——和消费曲线上那根 1 元的峰精确吻合。如果这 1712 万输入 tokens 全按未命中计价，当天要花 17.3 元：同一天，同样的调用，缓存把账单压缩了 17 倍。\nDeepSeek 后台 6 月 14 日 tokens 拆解截图 这份账单里还有个反直觉的细节：当天最贵的一项，不是那 1667 万个命中 token（3 毛 3），而是区区 45 万个未命中 token（4 毛 5）。决定账单的不是你喂了多少 token，而是有多少 token 没命中。\n我没有为这个结果做过任何专门优化，只是恰好把“稳的放前面、变的放后面”这个结构做对了。换句话说：缓存折扣不是需要努力争取的优惠，而是结构做错了才会错过的默认待遇。\n顺带一提，缓存不只省钱，还救延迟：命中时预填充被跳过，DeepSeek 给过一组数据，128K 的长提示词高度命中缓存时，首 token 延迟从 13 秒压到 500 毫秒。对 Agent 类应用来说，这个收益不比省钱小。\n写在最后 回到标题的问题：同样一段话，第二次问为什么只收 1/10 的钱？\n因为模型第一次处理时算出的中间结果被存了下来，第二次直接复用，最贵的计算环节整段跳过——厂商把省下的算力，以 1/10（DeepSeek 甚至 1/50、1/120）的价格差返还给你。而能不能拿到这个折扣，只取决于一件事：你的前缀，从第 0 个 token 开始，是否一模一样。\n那么下一个问题来了：这份被反复复用的“中间结果”到底是什么？它为什么大到能吃掉半张显卡的显存？DeepSeek 又是怎么把它压缩到传统方案 10% 的？\n这就是下一篇要拆的术语：KV Cache。\n本文价格数据核对自 DeepSeek、Anthropic、OpenAI 官方定价页（2026 年 7 月 12 日）。**\n","permalink":"https://blog.onecai.site/2026/07/13/041-prompt-caching-billing/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文为「术语解构」系列。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一账单上差了-50-倍的两行数字\"\u003e一、账单上差了 50 倍的两行数字\u003c/h2\u003e\n\u003cp\u003e打开 DeepSeek 的官方定价页，V4-Flash 这个模型的输入价格写了两行：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e输入（缓存命中）：\u003cstrong\u003e0.02 元 / 百万 tokens\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e输入（缓存未命中）：\u003cstrong\u003e1 元 / 百万 tokens\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e同样是把 100 万个 token 喂给同一个模型，价格差了 \u003cstrong\u003e50 倍\u003c/strong\u003e。V4-Pro 更夸张：命中 0.025 元，未命中 3 元，差 \u003cstrong\u003e120 倍\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这不是 DeepSeek 独有的玩法。Anthropic 的 Claude，缓存读取按标准输入价的 \u003cstrong\u003e10%\u003c/strong\u003e 计费——Sonnet 4.6 的输入从 3 美元/百万降到 0.3 美元/百万。OpenAI 的 GPT-5.5，输入 5 美元/百万，缓存输入 0.5 美元/百万，同样是 \u003cstrong\u003e1/10\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e也就是说，2026 年主流大模型 API 的账单上，“你输入了多少 token”已经不是决定性变量了。\u003cstrong\u003e决定性变量是：这些 token 里，有多少是模型“见过”的。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这个“见过”的判定机制，就是今天要拆的术语——\u003cstrong\u003e前缀缓存（Prefix Caching）\u003c/strong\u003e，以及它背后的计费逻辑。\u003c/p\u003e\n\u003ch2 id=\"二模型凭什么给你打一折前缀缓存的极简原理\"\u003e二、模型凭什么给你打一折：前缀缓存的极简原理\u003c/h2\u003e\n\u003cp\u003e大模型处理你的提示词，不是“读一遍文字”这么轻松。每个 token 进来，模型都要为它计算一大堆注意力中间结果（专业名词叫 KV Cache，键值缓存），存在显存里，供后续生成使用。提示词越长，这一步烧的算力越多——这也是为什么长提示词的首字响应总是慢半拍。\u003c/p\u003e\n\u003cp\u003e前缀缓存的思路很直接：\u003cstrong\u003e如果这次请求的开头部分，和之前某次请求的开头一模一样，那这部分的中间结果就不用重算了，直接复用上次存下来的。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e打个比方。我整理邮票贴片时，前 30 页已经排定、贴好、写完说明的部分，不会因为要加第 31 页就全部拆掉重排——只有新的那一页需要动手。模型也一样：相同的前缀直接翻到“上次整理好的位置”，只算新增的后缀。\u003c/p\u003e","title":"同一份材料，为什么第二次交给AI只收1/10？缓存计费拆解"},{"content":"6月29日晚，一批使用DeepSeek API的开发者收到了一封调价邮件，DeepSeek开放平台首页也同步挂出了通知。\nDeepSeek V4正式版计划于7月中旬上线。伴随新模型而来的，还有一套新的峰谷定价机制：每天上午9点到12点、下午2点到6点，API调用价格是其他时段的两倍。\n有人说，AI也开始学电费分峰谷了；也有人认为，这就是换一种方式涨价。\n但把价格表真正摊开来看，这次变化不只是“贵了一倍”那么简单。它把AI推理服务一直藏在后台的一条负载曲线，直接印在了价目表上。\n一、先看价格：不是全天涨价，而是7个小时翻倍 DeepSeek API一天 24 小时的峰谷价格变化 按照DeepSeek公布的峰谷定价方案，高峰时段每天：\n9:00—12:00； 14:00—18:00。 一共7个小时，其他17个小时维持平时价格。\n这里顺带澄清一个流传较广的说法：有媒体解读称“周末不执行高峰价”。但从官方口径看，DeepSeek的调价邮件和开放平台通知，措辞都是“每日”；7月3日腾讯云上线DeepSeek-V4原厂直供模型、同步官网峰谷定价机制时，公告同样把高峰时段定义为“每日9:00至12:00和14:00至18:00（北京时间）”——两个官方渠道都没有出现周末豁免的表述。\n在DeepSeek计费页面给出进一步细则之前，把“周末照常执行高峰价”作为预算假设，是更稳妥的做法。具体价格如下：\n模型 计费项目 平时价格 高峰价格 V4 Pro 输入，缓存命中 0.025元/百万Token 0.05元/百万Token V4 Pro 输入，缓存未命中 3元/百万Token 6元/百万Token V4 Pro 输出 6元/百万Token 12元/百万Token V4 Flash 输入，缓存命中 0.02元/百万Token 0.04元/百万Token V4 Flash 输入，缓存未命中 1元/百万Token 2元/百万Token V4 Flash 输出 2元/百万Token 4元/百万Token DeepSeek给出的解释是，通过峰谷定价“更合理地配置资源、提升服务稳定性”。从价格表看，平时时段没有涨价，高峰时段整体翻倍。因此，它更接近一次“削峰填谷”，而不是全天统一提价。\n还有一个背景值得放在一起看。现在的平时价格，是今年4月底V4 Pro那轮永久降价之后的结果——降到了首发定价的四分之一。也就是说，即便高峰时段翻倍，价格也只回到了首发价的一半。这张表里，有三个数字值得停下来看看。\n第一，高峰只有7个小时 价格翻倍的时间，几乎覆盖了国内企业最主要的办公时段。\n上午开工后到午休前，下午上班到下班前，正是客服、办公软件、代码助手和企业工作流调用最密集的时候。\n所以，虽然它不是全天涨价，但对主要在工作时间调用API的国内企业来说，体感很可能接近涨价。\n第二，缓存命中和未命中的差距达到120倍 以V4 Pro高峰时段为例：\n缓存命中输入：0.05元/百万Token； 缓存未命中输入：6元/百万Token。 同样是100万Token输入，价格相差120倍。这比“高峰翻倍”更值得关注，它说明未来使用大模型，成本不只取决于用了多少Token，还取决于这些Token是不是每次都要重新计算。\n第三，Flash和Pro之间也有明显价差 V4 Pro平时的未缓存输入价格是每百万Token 3元，V4 Flash是1元；输出分别是6元和2元——同样相差3倍，这意味着，真正有效的省钱方法不只是凌晨跑任务，还包括：\n简单任务不要一上来就用最强模型。\n二、为什么AI也会有“高峰期”？ AI推理算力为什么会出现高峰和低谷 理解峰谷定价，最简单的方法是把GPU集群想成一张电网。\n电有一个明显特点：\n发出来以后，要立刻被使用。\n虽然现实中可以用电池和抽水蓄能等方式储存一部分电力，但大规模、低成本地把所有闲置电量长期存起来，仍然不容易。\nAI推理算力也有类似特点。凌晨2点，一张GPU卡空闲了一个小时，这段空闲时间不能装进仓库，等到第二天上午10点再拿出来使用，时间过去，算力也就过去了。\nToken同样不能提前生产。平台不能在凌晨先生成100亿个“通用Token”，上午有用户提问时再从仓库里发给他。因为每一次回答，都取决于当时的提示词、上下文、模型状态和用户问题。\nGPU集群一天24小时都在产生折旧、电力、制冷、网络和运维成本，但用户请求并不是平均分布的，它更像一条潮汐曲线：\n1 2 3 4 5 凌晨：GPU大量空闲 上午：请求快速涌入 午间：负载回落 下午：再次进入高峰 晚上：逐步下降 问题就出在这里。\n企业不能只按“一天平均有多少请求”准备算力，还要保证上午10点最拥挤的时候，服务不会排队、超时或者崩溃。\n为了应对每天那几个小时的峰值，平台必须准备更多GPU，但峰值过去以后，多出来的算力又可能闲置。这就是AI推理服务一个很现实的矛盾：\n按平均负载建集群，高峰扛不住；按峰值负载建集群，大部分时间又浪费。\n峰谷定价的作用，就是用价格把一部分不着急的任务从上午搬到晚上。\n从这个角度看，它不只是价格调整，而是一个负载调度工具。DeepSeek并没有隐藏这件事，它直接告诉开发者：工作时间调用，价格更高；能够错峰的任务，放到低谷时段，仍然按原价运行。\n换句话说：\n峰谷定价，就是把数据中心的负载曲线印在了价格表上。\n三、同一批任务，错开时间能省多少钱？ 只看“价格翻倍”还不够，我们来算三笔账。\n第一笔：每天处理1200万Token 假设一家公司每天使用V4 Pro处理：\n1000万Token输入，全部缓存未命中； 200万Token输出。 如果全部放在平时时段运行（不考虑缓存写入、工具调用等其他费用）：\n1 2 3 输入费用：10 × 3元 = 30元 输出费用：2 × 6元 = 12元 每天合计：42元 按30天计算：\n1 42 × 30 = 1260元 如果这些任务全部在高峰时段运行：\n1 2 3 输入费用：10 × 6元 = 60元 输出费用：2 × 12元 = 24元 每天合计：84元 一个月就是：\n1 84 × 30 = 2520元 两种运行时间，处理的是同一批数据，使用的是同一个模型，输出规模也一样。\n月账单相差：\n1 2520 - 1260 = 1260元 当然，很少有公司把所有调用都压在高峰。还有一种更接近现实的算法——假设调用量在24小时里均匀分布，其中7个小时按2倍计费：\n1 (17 + 7 × 2) ÷ 24 ≈ 1.29 也就是说，全天均匀调用的账单，大约上涨29%——月费用从1260元涨到约1630元。\n调用越集中在国内工作时间，涨幅就越接近100%。你的账单变化，取决于你的流量曲线有多像国内的上班时间。\n这个规模对大型企业不算高。\n但如果每天调用量不是1200万Token，而是1.2亿Token，全高峰运行的差额就会放大到每月12600元。\n如果是12亿Token，就是每月12.6万元。\n峰谷定价真正影响的，不是偶尔调用几次API的人，而是已经把模型铺进业务流程、每天自动运行大量任务的企业。\n第二笔：分析一篇3000字文章 再看一个个人用户更熟悉的任务。\n假设把一篇3000字文章发给V4 Pro，请它完成审核、总结和修改建议。\n为了便于计算，我们假设：\n输入约4000 Token； 输出约1500 Token； 输入没有命中缓存。 平时时段费用约为2.1分钱，计算如下：\n1 2 3 输入：4000 ÷ 1000000 × 3元 = 0.012元 输出：1500 ÷ 1000000 × 6元 = 0.009元 合计：0.021元 高峰时段费用约为4.2分钱，计算如下：\n1 2 3 输入：4000 ÷ 1000000 × 6元 = 0.024元 输出：1500 ÷ 1000000 × 12元 = 0.018元 合计：0.042元 确实翻倍了，但只多了2.1分钱。\n因此，对少量调用的个人开发者来说，这次调价的实际影响可能很有限。\n真正需要重新算账的是那些每天处理成千上万份文档、客服记录、代码和业务数据的系统。\n第三笔：批处理任务错峰运行 很多AI任务根本不要求实时完成，例如：\n每晚生成经营日报； 批量整理客户留言； 给历史文档打标签； 清洗数据库内容； 汇总一天的客服记录； 批量生成商品描述； 对代码仓库做离线检查。 这些任务上午9点完成，和凌晨3点完成，业务价值可能没有区别——把它们从高峰搬到低谷，调用成本直接减半。\n这不是模型能力下降，也不是压缩了输出，更没有换成质量更低的服务，仅仅只是调整了执行时间。\n类似思路并非DeepSeek独有。OpenAI的Batch API允许开发者把非实时任务放进最长24小时的异步队列，输入和输出费用相较同步API均可获得50%折扣。\n以上这些反映出一种越来越清晰的行业趋势：\n实时性本身也有价格。\n你要求模型立刻回答，就需要与其他用户争抢当下的GPU资源。如果你愿意等几个小时，平台就可以把任务安排到更空闲的时段，而任务以同样质量却以更低的价格完成了。\n四、DeepSeek为什么不直接扩容？ 看到这里，一个很自然的问题是：既然上午请求太多，为什么不多买一些GPU？\n答案是，扩容当然可以，但它可能是最贵的解决方案。\n假设一家平台平时只需要1000张卡，上午高峰需要2000张卡。\n为了保证高峰稳定，它需要再增加1000张卡。问题是，高峰每天只有7个小时，剩下17个小时，这批为峰值准备的算力可能无法被充分利用。\nGPU集群的成本却不会因为闲置自动消失：\n服务器仍然在折旧； 机房仍然需要供电和制冷； 网络、存储和运维仍然存在； 算力卡买回来以后，不会因为今天少用了几个小时就退款。 因此，单纯为峰值扩容，相当于为了每天7个小时的拥堵，承担全天候的基础设施成本。\n于是，峰谷定价提供了另一种解决办法——不一定马上增加全部硬件，而是先让一部分任务主动错峰。\n实时客服、在线编程、用户对话继续留在白天，日报、批处理、文档归档、离线分析搬到夜间。\n这样做的结果是：\n高峰请求下降； 低谷利用率提高； 服务稳定性改善； 同一批GPU可以处理更多总任务。 从平台角度看，这近似于一次“不买卡的扩容”。\n其实，这也不是DeepSeek第一次用价格调节负载。2025年初，它就在V3和R1上推出过错峰优惠：北京时间凌晨0:30到8:30，V3调用五折，R1低至2.5折。但单向的低谷打折，力度终究有限——白天该跑的任务还是在跑。\n这次把方向反过来，从“低谷奖励”改成“高峰加价”，才是一个真正有约束力的调度信号。\n当然，用户也有理由不满意。因为DeepSeek划定的高峰时段，恰好覆盖国内最主要的工作时间。对于必须实时响应的企业来说，根本没有错峰空间。\n客服不可能告诉客户说现在API太贵，请凌晨再来咨询，办公助手也不能要求所有员工晚上使用。\n所以，这套机制最终会把用户分成两类：一类是可以延迟的任务，用时间换价格；另一类是必须实时的业务，为确定性和响应速度支付溢价。\n这与云服务器中的按需实例、竞价实例，以及物流中的普通件、加急件，本质上是同一套逻辑。\n五、这次调价，普通聊天用户受影响吗？ 目前讨论的重点是DeepSeek API，而不是普通用户直接使用的网页端或App聊天服务。\n普通聊天用户通常不会看到：\n输入用了多少Token； 输出用了多少Token； 调用发生在峰时还是谷时； 单次请求实际花了几分钱。 真正受影响的是通过API付费的用户，例如：\n把DeepSeek接入自己软件的开发者； 使用模型处理内部文档的企业； 搭建AI客服、Agent和自动化工作流的团队； 批量调用模型生成内容的平台； 通过第三方工具间接使用API的人。 因此，这不是“上午问DeepSeek聊天要收费、凌晨免费”的变化。它讨论的是开发者调用模型接口时的成本，对于日常用量不大的用户可以关注，但不必因为“价格翻倍”四个字产生过度焦虑。\n六、开发者现在可以做什么？ 降低大模型 API 成本的三种方法 如果已经在工作流中使用DeepSeek API，有三件事值得马上检查。\n1. 把非实时任务搬到低谷 先把现有任务分成两类：必须实时和可以延迟。\n必须实时：\n在线客服； 实时搜索； 交互式编程； 用户正在等待的生成任务。 可以延迟：\n日报和周报； 批量文档处理； 数据清洗； 内容审核； 历史数据分类； 离线评测； 批量生成摘要。 第二类任务可以通过定时器、消息队列或任务调度系统，统一放到18点以后或上午9点以前执行。\n不改模型，不改提示词，只改运行时间，就能把费用降回平时水平。\n2. 提高缓存命中率 V4 Pro高峰时段，缓存命中输入是每百万Token是0.05元，未命中是6元，相差120倍。\n这意味着，缓存带来的影响远远大于峰谷差价。\n如果把企业工作流中经常反复出现的内容诸如系统提示词、产品手册、企业制度、固定工具定义、品牌写作规范、代码仓库公共上下文等这些内容每次都能稳定命中缓存，输入成本可能发生数量级变化。\n反过来，如果每次都调整顺序、在开头插入时间戳，或者不断改写固定提示词，就可能破坏缓存。\n关于缓存命中为什么能便宜这么多，下一篇单独拆解。\n3. 简单任务先用Flash 并不是所有任务都需要Pro级别的模型。\n例如：\n文本分类； 信息提取； 格式转换； 简单摘要； 关键词生成； 固定模板改写。 这类任务可以先在Flash上测试。只有复杂推理、长链条分析、困难代码和高质量内容生成，再交给Pro。平时时段，Flash的未缓存输入和输出价格都是Pro的三分之一。\n模型分级带来的节省，可能比错峰更大，成熟的AI工作流，不应该只配置一个模型。\n更合理的做法是：\n1 2 3 非实时任务 → 低谷运行 重复上下文 → 尽量命中缓存 简单任务 → Flash，复杂任务 → Pro 这三招组合起来，才是一套完整的成本控制方案。\n七、峰谷定价真正改变了什么？ 过去比较大模型价格，我们通常习惯看一张静态表格：\n每百万Token输入多少钱； 每百万Token输出多少钱； 哪家便宜，哪家贵。 DeepSeek这次峰谷定价提醒我们，今后的AI价格可能不会再是一个固定数字。\n同一个模型、同样数量的Token，因为以下条件不同，最终成本也可能不同：\n什么时间调用； 是否需要实时返回； 有没有命中缓存； 使用Flash还是Pro； 同步处理还是批量处理； 输入和输出各占多少； 能不能把任务排进低谷队列。 所以，未来企业比较大模型成本，不能只问：\n每百万Token多少钱？\n还要继续追问：\n是什么时间的价格？\n缓存命中还是未命中？\n实时队列还是批量队列？\n这项任务真的需要最强模型吗？\n价格表正在从一个简单数字，变成一套调度规则。这也是AI从聊天工具走进生产系统后，必然会出现的变化。个人偶尔问一个问题，多几分钱、少几分钱，几乎感受不到。\n但当API进入客服、办公、代码、营销和数据处理流程，每天自动调用几千万甚至几亿Token时，时间、缓存和模型分级都会变成必须认真管理的成本变量。\nDeepSeek峰谷定价，看起来只是上午9点以后贵了一倍。\n它真正透露的是：\nAI算力并不是取之不尽的自来水。什么时候使用、怎样排队、能否复用，都会被写进账单。\n下一篇继续算另一笔更夸张的账：\nV4 Pro高峰时段，缓存命中输入是0.05元，缓存未命中是6元。\n同样100万Token，价格为什么能相差120倍？\n我们来拆一拆，提示词缓存到底缓存了什么。\n","permalink":"https://blog.onecai.site/2026/07/12/040-deepseek-peak-off-peak-pricing/","summary":"\u003cp\u003e6月29日晚，一批使用DeepSeek API的开发者收到了一封调价邮件，DeepSeek开放平台首页也同步挂出了通知。\u003c/p\u003e\n\u003cp\u003eDeepSeek V4正式版计划于7月中旬上线。伴随新模型而来的，还有一套新的峰谷定价机制：每天上午9点到12点、下午2点到6点，API调用价格是其他时段的两倍。\u003c/p\u003e\n\u003cp\u003e有人说，AI也开始学电费分峰谷了；也有人认为，这就是换一种方式涨价。\u003c/p\u003e\n\u003cp\u003e但把价格表真正摊开来看，这次变化不只是“贵了一倍”那么简单。它把AI推理服务一直藏在后台的一条负载曲线，直接印在了价目表上。\u003c/p\u003e\n\u003ch2 id=\"一先看价格不是全天涨价而是7个小时翻倍\"\u003e一、先看价格：不是全天涨价，而是7个小时翻倍\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"deepseek-peak-off-peak-pricing-1.avif\"\n         alt=\"DeepSeek API一天 24 小时的峰谷价格变化\"/\u003e \u003cfigcaption\u003e\n            DeepSeek API一天 24 小时的峰谷价格变化\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e按照DeepSeek公布的峰谷定价方案，高峰时段每天：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e9:00—12:00；\u003c/li\u003e\n\u003cli\u003e14:00—18:00。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e一共7个小时，其他17个小时维持平时价格。\u003c/p\u003e\n\u003cp\u003e这里顺带澄清一个流传较广的说法：有媒体解读称“周末不执行高峰价”。但从官方口径看，DeepSeek的调价邮件和开放平台通知，措辞都是“每日”；7月3日腾讯云上线DeepSeek-V4原厂直供模型、同步官网峰谷定价机制时，公告同样把高峰时段定义为“每日9:00至12:00和14:00至18:00（北京时间）”——两个官方渠道都没有出现周末豁免的表述。\u003c/p\u003e\n\u003cp\u003e在DeepSeek计费页面给出进一步细则之前，把“周末照常执行高峰价”作为预算假设，是更稳妥的做法。具体价格如下：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e计费项目\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e平时价格\u003c/th\u003e\n          \u003cth style=\"text-align: right\"\u003e高峰价格\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Pro\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输入，缓存命中\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e0.025元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e0.05元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Pro\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输入，缓存未命中\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e3元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e6元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Pro\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输出\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e6元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e12元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Flash\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输入，缓存命中\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e0.02元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e0.04元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Flash\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输入，缓存未命中\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e1元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e2元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eV4 Flash\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e输出\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e2元/百万Token\u003c/td\u003e\n          \u003ctd style=\"text-align: right\"\u003e4元/百万Token\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eDeepSeek给出的解释是，通过峰谷定价“更合理地配置资源、提升服务稳定性”。从价格表看，平时时段没有涨价，高峰时段整体翻倍。因此，它更接近一次“削峰填谷”，而不是全天统一提价。\u003c/p\u003e\n\u003cp\u003e还有一个背景值得放在一起看。现在的平时价格，是今年4月底V4 Pro那轮永久降价之后的结果——降到了首发定价的四分之一。也就是说，即便高峰时段翻倍，价格也只回到了首发价的一半。这张表里，有三个数字值得停下来看看。\u003c/p\u003e\n\u003ch3 id=\"第一高峰只有7个小时\"\u003e第一，高峰只有7个小时\u003c/h3\u003e\n\u003cp\u003e价格翻倍的时间，几乎覆盖了国内企业最主要的办公时段。\u003c/p\u003e\n\u003cp\u003e上午开工后到午休前，下午上班到下班前，正是客服、办公软件、代码助手和企业工作流调用最密集的时候。\u003c/p\u003e\n\u003cp\u003e所以，虽然它不是全天涨价，但对主要在工作时间调用API的国内企业来说，体感很可能接近涨价。\u003c/p\u003e\n\u003ch3 id=\"第二缓存命中和未命中的差距达到120倍\"\u003e第二，缓存命中和未命中的差距达到120倍\u003c/h3\u003e\n\u003cp\u003e以V4 Pro高峰时段为例：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e缓存命中输入：0.05元/百万Token；\u003c/li\u003e\n\u003cli\u003e缓存未命中输入：6元/百万Token。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e同样是100万Token输入，价格相差120倍。这比“高峰翻倍”更值得关注，它说明未来使用大模型，成本不只取决于用了多少Token，还取决于这些Token是不是每次都要重新计算。\u003c/p\u003e\n\u003ch3 id=\"第三flash和pro之间也有明显价差\"\u003e第三，Flash和Pro之间也有明显价差\u003c/h3\u003e\n\u003cp\u003eV4 Pro平时的未缓存输入价格是每百万Token 3元，V4 Flash是1元；输出分别是6元和2元——同样相差3倍，这意味着，真正有效的省钱方法不只是凌晨跑任务，还包括：\u003c/p\u003e","title":"同一个问题，上午9点问比凌晨贵一倍：DeepSeek峰谷定价的算力账"},{"content":" 本文是「术语解构」系列之一。\nDeepSeek-R1 满血版有 6710 亿参数，而你在 LM Studio 里下载的 R1-Distill-Qwen-14B 只有 140 亿——体积差了大约 48 倍，但它确实“学到了”大模型的推理能力。\n这中间发生的事，就叫蒸馏（Distillation）。\n打开任何一个本地模型下载页，名字里带 “Distill” 的模型比比皆是。但“蒸馏”到底蒸的是什么？它和我们熟悉的量化（比如 IQ4_XS）有什么区别？为什么有人说蒸馏是“教学生”，有人说蒸馏是“抄作业”？\n这篇先把概念讲透，下篇上实测数据。\n一、为什么叫“蒸馏”：从一锅混合物里提取精华 AI蒸馏不是复制大模型，而是从大模型中提取知识精华 化学里的蒸馏，是把一锅混合液加热，让沸点低的成分先变成蒸汽，再冷凝收集——留下的是你想要的精华，扔掉的是杂质。\n2015 年 3 月，Geoffrey Hinton（就是后来拿了诺贝尔物理学奖的那位）和 Oriol Vinyals、Jeff Dean 发表了论文《Distilling the Knowledge in a Neural Network》，把这个词借到了神经网络领域：\n把一个大模型（老师）学到的“知识”，提取出来，灌进一个小模型（学生）的身体里。\n注意这个说法的微妙之处：提取的是“知识”，不是“参数”。学生模型的参数是从头训练的，只是训练的目标从“学习标准答案”变成了“模仿老师的判断”。\n这和量化有本质区别——量化是给同一个模型降精度，人还是那个人，只是“说话没那么精确了”；蒸馏是重新培养一个新人。这一点我们后面展开。\n二、暗知识：老师教的不是答案，是“感觉” 暗知识：老师教给学生的不只是答案，而是答案之间的相似性 这是整个蒸馏概念里最精彩的部分，也是 Hinton 那篇论文的核心洞察。\n假设我们训练一个识别图片的模型，给它看一张猫的照片。\n普通训练用的是硬标签（hard label）：\n正确答案：猫。就一个字，没了。 蒸馏训练用的是老师模型输出的软标签（soft label），也就是一整个概率分布：\n猫：90% 狗：8% 老虎：1.5% 汽车：0.0001% 看出区别了吗？“狗 8%，而汽车几乎是零”——这个差异本身就是知识。它告诉学生：猫和狗长得像，猫和汽车完全不像。这种类别之间的相似性结构，硬标签里根本不存在，只藏在老师的概率分布里。\nHinton 给这东西起了个很浪漫的名字：暗知识（dark knowledge）——像暗物质一样，平时看不见（推理时只取概率最高的那个答案），但它确实存在，而且信息量巨大。\n学生模型对着软标签学，相当于老师不仅告诉你答案是 A，还告诉你“B 有点像但差在哪、C 为什么完全不沾边”。一道题传递的信息量，是硬标签的很多倍——这就是为什么蒸馏出来的小模型，往往比同样大小、从零硬训的模型强。\n顺便解决一个老疑问：温度参数是从这来的 你在 API 调参时天天见的 temperature，最早的出处之一就是这篇蒸馏论文。\n老师模型的输出分布往往太“自信”——猫 99.9%，其他全是零点零几，软标签又快退化成硬标签了，暗知识都被压没了。Hinton 的办法是在计算概率时除以一个温度 T：T 调高，分布被“捂软”，狗和老虎的概率被抬起来，类别间的相似性信息重新显形。学生就对着这个“加温软化”过的分布学。\n蒸馏、软化、温度——你看，整套比喻是自洽的。\n三、模型瘦身三兄弟：量化、剪枝、蒸馏 量化、剪枝、蒸馏三种模型瘦身方式的区别 本地跑模型的朋友对“瘦身”都不陌生，但这三个词经常被混着用。放一张对比表：\n量化 Quantization 剪枝 Pruning 蒸馏 Distillation 干的事 降低每个参数的数字精度 砍掉不重要的参数/结构 重新训练一个小模型 参数数量 不变 变少 全新的、更少的 需要重新训练吗 基本不用 通常要微调恢复 必须，而且成本不低 一句话类比 同一个人，说话保留小数点后 1 位 同一个人，切掉冗余记忆 教出一个新学生 之前的例子 IQ4_XS、Q8_0 结构化剪枝模型 R1-Distill 全家桶 关键区别：量化和剪枝动的是“同一个模型”，蒸馏产出的是“另一个模型”。\n所以这两件事完全可以叠加——你本地跑的 R1-Distill-Qwen-14B 的 IQ4_XS 版本，就是“先蒸馏、再量化”的产物：先教出一个 14B 的学生，再把学生的说话精度压到 4-bit 左右。\n四、LLM 时代，“蒸馏”分裂成了两个词 到了大语言模型时代，“蒸馏”这个词的含义悄悄扩大了，很多科普文把两种东西混在一起讲，这里必须掰开：\n白盒蒸馏：拿得到老师的“内心活动” 如果老师模型的权重在你手里（比如你自己训的大模型，或开源模型），你就能拿到它对每个 token 的完整概率分布（logits），让学生逐 token 对齐这个分布。\n这是 Hinton 原教旨意义上的蒸馏：学的是软标签，吃的是暗知识。\n黑盒蒸馏：只拿得到老师“说出口的话” 如果老师是一个闭源 API（你只能看到它输出的文本，看不到概率分布），那你能做的是：用老师生成大量高质量的问答数据，拿这些文本去做监督微调（SFT）。\n严格说，这已经不是概率分布层面的蒸馏了，本质是“用合成数据训练”。但业界习惯上也管它叫蒸馏——学生学的是老师的“言传”，而不是“心法”。\n记住这个区分：白盒学分布，黑盒学文本。下篇要聊的那场著名争议（某闭源大厂指责某开源新贵“蒸馏”了自家模型），争的就是黑盒这一种。\n五、把 DeepSeek-R1-Distill-Qwen-14B 这个名字拆开 之前写过一篇本地模型命名规则，这里正好用蒸馏的知识把这个经典名字彻底拆解：\nDeepSeek-R1：老师是谁——6710 亿参数的推理模型 R1（MoE 架构，每次激活约 370 亿） Distill：用了什么方法——DeepSeek 用 R1 生成了约 80 万条推理数据，对小模型做训练。按上面的分类，这是偏黑盒式的数据蒸馏，只不过老师和学生都在自己手里 Qwen：学生的底座是谁——拿 Qwen2.5 系列做基座，而不是从零训练。官方还发了 Llama 底座的版本 14B：学生的体格——140 亿参数 所以这个名字翻译成人话就是：“R1 老师教出来的、Qwen2.5 底子的、14B 的学生”。官方一口气发了 1.5B、7B、8B、14B、32B、70B 六个尺寸，相当于同一个老师带了六个体格不同的学生。\n它推理时的思考方式像 R1（会输出长长的思维链），但说话的底子、知识面的边界，还是 Qwen 的——这就是为什么它既不完全像 R1，也不完全像原版 Qwen。像谁更多、差距多大，得靠实测说话。\n六、下篇预告：让学生和“没上过课的同龄人”同台考试 概念讲完了，下篇上数据。\n在本地设备上让 R1-Distill-Qwen-14B 和 原版 Qwen 14B 跑同一组题（复用之前 12 个模型读书笔记测试那套 prompt），看蒸馏到底带来了什么、丢掉了什么，顺便聊聊那场“蒸馏算学习还是算抄袭”的行业争议。\n你本地跑过哪个带 Distill 的模型？和同尺寸的原版比，你感觉差别在哪？\n","permalink":"https://blog.onecai.site/2026/07/11/039-what-is-ai-distillation/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e本文是「术语解构」系列之一。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eDeepSeek-R1 满血版有 6710 亿参数，而你在 LM Studio 里下载的 R1-Distill-Qwen-14B 只有 140 亿——\u003cstrong\u003e体积差了大约 48 倍，但它确实“学到了”大模型的推理能力\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这中间发生的事，就叫蒸馏（Distillation）。\u003c/p\u003e\n\u003cp\u003e打开任何一个本地模型下载页，名字里带 “Distill” 的模型比比皆是。但“蒸馏”到底蒸的是什么？它和我们熟悉的量化（比如 IQ4_XS）有什么区别？为什么有人说蒸馏是“教学生”，有人说蒸馏是“抄作业”？\u003c/p\u003e\n\u003cp\u003e这篇先把概念讲透，下篇上实测数据。\u003c/p\u003e\n\u003ch2 id=\"一为什么叫蒸馏从一锅混合物里提取精华\"\u003e一、为什么叫“蒸馏”：从一锅混合物里提取精华\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"what-is-ai-distillation-1.avif\"\n          alt=\"AI蒸馏不是复制大模型，而是从大模型中提取知识精华\"/\u003e \u003cfigcaption\u003e\n             AI蒸馏不是复制大模型，而是从大模型中提取知识精华\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e化学里的蒸馏，是把一锅混合液加热，让沸点低的成分先变成蒸汽，再冷凝收集——\u003cstrong\u003e留下的是你想要的精华，扔掉的是杂质\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e2015 年 3 月，Geoffrey Hinton（就是后来拿了诺贝尔物理学奖的那位）和 Oriol Vinyals、Jeff Dean 发表了论文《Distilling the Knowledge in a Neural Network》，把这个词借到了神经网络领域：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e把一个大模型（老师）学到的“知识”，提取出来，灌进一个小模型（学生）的身体里。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e注意这个说法的微妙之处：提取的是“知识”，不是“参数”。学生模型的参数是从头训练的，只是训练的目标从“学习标准答案”变成了“模仿老师的判断”。\u003c/p\u003e\n\u003cp\u003e这和量化有本质区别——量化是给同一个模型降精度，人还是那个人，只是“说话没那么精确了”；蒸馏是重新培养一个新人。这一点我们后面展开。\u003c/p\u003e\n\u003ch2 id=\"二暗知识老师教的不是答案是感觉\"\u003e二、暗知识：老师教的不是答案，是“感觉”\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"what-is-ai-distillation-2.avif\"\n          alt=\"暗知识：老师教给学生的不只是答案，而是答案之间的相似性\"/\u003e \u003cfigcaption\u003e\n             暗知识：老师教给学生的不只是答案，而是答案之间的相似性\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这是整个蒸馏概念里最精彩的部分，也是 Hinton 那篇论文的核心洞察。\u003c/p\u003e\n\u003cp\u003e假设我们训练一个识别图片的模型，给它看一张猫的照片。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e普通训练\u003c/strong\u003e用的是硬标签（hard label）：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e正确答案：猫。就一个字，没了。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e蒸馏训练\u003c/strong\u003e用的是老师模型输出的软标签（soft label），也就是一整个概率分布：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e猫：90%\u003c/li\u003e\n\u003cli\u003e狗：8%\u003c/li\u003e\n\u003cli\u003e老虎：1.5%\u003c/li\u003e\n\u003cli\u003e汽车：0.0001%\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e看出区别了吗？\u003cstrong\u003e“狗 8%，而汽车几乎是零”——这个差异本身就是知识\u003c/strong\u003e。它告诉学生：猫和狗长得像，猫和汽车完全不像。这种类别之间的相似性结构，硬标签里根本不存在，只藏在老师的概率分布里。\u003c/p\u003e\n\u003cp\u003eHinton 给这东西起了个很浪漫的名字：\u003cstrong\u003e暗知识（dark knowledge）\u003c/strong\u003e——像暗物质一样，平时看不见（推理时只取概率最高的那个答案），但它确实存在，而且信息量巨大。\u003c/p\u003e\n\u003cp\u003e学生模型对着软标签学，相当于老师不仅告诉你答案是 A，还告诉你“B 有点像但差在哪、C 为什么完全不沾边”。\u003cstrong\u003e一道题传递的信息量，是硬标签的很多倍\u003c/strong\u003e——这就是为什么蒸馏出来的小模型，往往比同样大小、从零硬训的模型强。\u003c/p\u003e\n\u003ch3 id=\"顺便解决一个老疑问温度参数是从这来的\"\u003e顺便解决一个老疑问：温度参数是从这来的\u003c/h3\u003e\n\u003cp\u003e你在 API 调参时天天见的 temperature，最早的出处之一就是这篇蒸馏论文。\u003c/p\u003e","title":"AI蒸馏是什么？不是复制大模型，而是让小模型学会做题方式"},{"content":" WorkBuddy 实战手册 · 第8篇\n有一种办公崩溃，很多人都遇到过：人已经离开公司，文件还在公司电脑里。更烦的是，别人不是明天要，也不是下周要，而是现在就要。\n上个月有天下班路上，我在地铁里收到同事消息：\n明天一早开会要用的方案，最终版是不是还在你电脑桌面上？能不能现在发我一下？\n如果是以前，我大概率只有两个选择：\n第一，掉头回公司。\n第二，找还在办公室的同事帮我开电脑、找文件、传文件。\n两个选择都不舒服。\n那天我试了第三种方式：打开微信里的 WorkBuddy 小程序，切到本机模式，让它在我办公室电脑上找到那份文件，再用绑定好的邮箱发给同事。\n几分钟后，同事回了两个字：\n收到。\n这件事给我的感觉很直接——WorkBuddy 不只是坐在电脑前用的 AI 助手，它还可以变成一个「手机遥控电脑」的工具。你人不在电脑前，但电脑上的文件、邮件、表格和任务，依然可以继续处理。\n这篇就讲一个很具体的场景：\n怎么用 WorkBuddy 微信小程序和 ClawBot，在手机上远程操控电脑，完成取文件、发邮件、处理本地资料这类办公任务。\n一、手机端有三种入口 入口 适合场景 我的建议 微信客服号 简单问答、轻量任务 能用，但能力比较基础 ClawBot 插件 微信聊天里快速发指令 适合语音和临时操作 微信小程序 查看任务、下载文件、切换模式 最推荐，体验最完整 在微信里搜索「腾讯 WorkBuddy」，进入小程序后，就可以看到任务入口、模式切换、结果展示和文件下载。\nClawBot 更像一个微信聊天里的快捷入口，小程序更像一个完整的手机工作台。\n临时一句话，用 ClawBot；\n要看结果、下载文件、确认任务进度，用小程序。\n两个配合起来，体验会顺很多。\n二、云端模式和本机模式不是一回事 WorkBuddy云端模式和本机模式的区别 WorkBuddy 手机端通常会涉及两类任务：\n云端模式：任务在云端跑。\n本机模式：任务在你的电脑上跑。\n这两个差别很大。\n1. 云端模式：电脑关着也能用 云端模式适合不依赖你电脑本地文件的任务。\n比如：\n写一篇文章大纲； 整理一段文案； 生成一个活动方案； 分析你手动上传的资料； 做一个通用选题规划。 这些任务不需要访问你电脑桌面，也不需要打开你本地硬盘，所以电脑关着也没关系。你可以在地铁、高铁、咖啡馆里直接用手机发指令。\n2. 本机模式：电脑必须开着 本机模式的重点是：\nWorkBuddy 可以远程操作你的电脑。\n它适合这些任务：\n找电脑桌面上的文件； 读取本地文件夹里的资料； 用本地文件生成汇总表； 把本地文件作为附件发邮件； 处理公司电脑上的文档、表格和图片。 但前提也很明确：\n你的电脑必须开机，WorkBuddy 电脑端必须处于可用状态。\n如果电脑盒盖休眠、关机、断网，本机模式就跑不起来。\n所以判断方式很简单：\n不碰本地文件，用云端模式。\n要动电脑里的文件，用本机模式。\n本机模式之前，先确认电脑没睡着。\n这一步搞清楚，后面会少踩很多坑。\n三、最实用的场景：手机远程发邮件 手机远程发邮件的四步流程 我认为目前最值得先跑通的场景，就是手机遥控电脑发邮件。\n因为它解决的是一个非常真实的问题：\n文件在电脑上，人不在电脑前，但邮件现在就要发。\n完整流程分四步。\n第一步：开通邮箱 SMTP 服务 要让 WorkBuddy 自动发邮件，先要给邮箱开通 SMTP。\n以 QQ 邮箱为例，大致流程是：\n登录 QQ 邮箱网页版； 进入设置； 找到账户相关选项； 开启 SMTP 服务； 按提示完成短信验证； 获取一串授权码。 这里最容易搞错的是授权码。授权码不是邮箱登录密码，它是邮箱单独生成的一串字符，专门给第三方工具使用。\n后面在 WorkBuddy 里绑定邮箱时，要填的是这串授权码，不是你的邮箱密码。\n第二步：在 WorkBuddy 电脑端绑定邮箱 打开 WorkBuddy 电脑端，直接输入：\n1 帮我绑定邮箱。 然后按提示填入：\n邮箱地址； SMTP 授权码； 发件人信息。 绑定完成后，先发一封测试邮件。测试成功，这一步就算完成。这件事只需要做一次，后面你在手机上发邮件时，就不用每次重新配置。\n第三步：在手机上发指令 邮箱绑定好之后，就可以在手机上远程发邮件了。\n比如你可以在 WorkBuddy 小程序里这样说：\n1 2 3 4 5 6 7 8 9 10 11 请用我的工作邮箱发一封邮件给 zhangsan@example.com。 主题：方案确认 正文： 方案已经更新到最终版，请查收附件。 附件： 请使用电脑桌面上名为「市场方案最终版」的文件。 发送前请先展示邮件草稿，包括收件人、主题、正文和附件名称，等我确认后再发送。 注意，我建议加上最后一句：\n发送前请先展示邮件草稿，等我确认后再发送。\n远程发邮件不是小事，尤其涉及客户、领导、合同、报价这些内容时，不要一上来就让它直接发送。\n先预览，再确认，稳很多。\n第四步：第一次使用后，去邮箱里检查一次 刚开始用的时候，建议你打开邮箱确认一下：\n收件人是否正确； 主题是否正确； 正文有没有错别字； 附件是不是你要的那一份； 邮件是否已经成功发出。 用过几次之后，你会慢慢知道它在哪些任务上可靠，哪些任务还需要你多看一眼。\n远程办公最重要的不是炫技，而是可控。\n四、第二个高频场景：手机远程取电脑文件 发邮件之外，更常见的场景是取文件。\n比如：\n方案在公司电脑桌面； 报价单在 D 盘项目文件夹； 客户资料在本地同步盘里； PPT 最终版在电脑下载目录； 发票扫描件在某个临时文件夹。 以前遇到这种情况，经常要麻烦同事。\n现在可以直接在手机上说：\n1 2 3 4 5 6 7 请在本机模式下，帮我查找 D 盘「工作资料」文件夹里名称包含「Q3季度报告」的文件。 找到后，请先列出匹配到的文件名、路径和修改时间。 不要删除、移动或重命名任何文件。 我确认后，再把对应文件发送到手机端供我下载。 这条指令里有两个细节很重要。\n第一，不要只说「帮我找那个报告」。\n你最好写清楚：盘符、文件夹、关键词、文件类型、时间范围。\n第二，先列结果，再下载。\n如果电脑里有多个相似文件，比如：\nQ3季度报告.docx Q3季度报告_修改版.docx Q3季度报告_最终版.pdf Q3季度报告_给领导版.pptx 让它先列出来，你确认后再下载，就不容易拿错。\n五、ClawBot 适合做什么？ 除了小程序，ClawBot 也是一个很方便的入口。\n它的优势不是功能更多，而是更顺手。\n因为它就在微信聊天里。\n走路、通勤、不方便打字时，你可以直接发语音：\n帮我找一下桌面上的市场方案最终版，先列出文件名，不要直接发送。\n这种短指令，用 ClawBot 很舒服。\n绑定方式也不复杂：\n打开 WorkBuddy 电脑端； 在左侧找到 Claw 相关入口； 进入「微信 ClawBot 集成」； 按提示生成二维码； 用微信扫码绑定。 绑定完成后，你就可以在微信里直接跟它对话。\n语音快操作，用 ClawBot。\n看任务进度、下载结果文件，用小程序。\n复杂任务，还是回到小程序或电脑端确认。\n不要把所有事情都塞给一个入口，哪个顺手用哪个。\n六、几个真实使用场景 远程办公不是一定要做多复杂的事，很多时候，它解决的是那些「卡一下就很烦」的小问题。\n场景一：通勤路上补发文件 你已经下班，在地铁上，同事临时要一份方案。你用手机连到本机模式，让 WorkBuddy 找到电脑桌面上的文件，生成邮件草稿，你确认后发送。不用掉头回公司，也不用麻烦别人开你的电脑。\n场景二：高铁上修改 PPT 出差路上发现 PPT 里有几页标题不统一。你可以让 WorkBuddy 打开本地文件，按规则统一标题格式，导出一个新版本。\n更稳的指令是：\n1 2 3 4 5 请基于原 PPT 生成一个修改版，不要覆盖原文件。 修改内容：统一所有页面标题格式，标题字号保持一致。 完成后请列出修改过的页码。 远程处理文件，一定要保留原始版本。\n场景三：周末在家临时做数据汇总 数据表在公司电脑里，同事临时要一个区域销售汇总。你可以让 WorkBuddy 读取本地 Excel，按区域汇总 Q3 销售额，生成一个新表格，再传回手机。\n这种任务要加约束：\n1 2 3 所有计算必须基于原始表格。 如果缺少字段，请直接说明，不要自行补数据。 处理完成后，输出一个新 Excel，不要修改原文件。 数据类任务尤其要小心。AI 可以帮你快，但不能替你对结果负责。\n场景四：临时整理一个选题大纲 如果任务不涉及本地文件，就不用本机模式。比如你在通勤路上突然想到一个选题，可以直接用云端模式：\n1 2 3 4 5 帮我整理一篇公众号文章大纲，主题是「手机操控电脑远程办公」。 读者是普通办公用户，不要写成技术教程。 结构要包括：痛点场景、工具入口、操作流程、适合场景、安全提醒和小结。 这种任务云端模式就够了，电脑开不开机都不影响。\n七、远程办公最容易踩的三个坑 手机远程办公的安全边界 跑通之后，你会发现它确实方便，但方便不等于随便用。\n1. 电脑休眠了，本机模式就没法用 本机模式依赖你的电脑在线。\n如果电脑关机、休眠、断网，手机端就无法远程操作本地文件。\n所以如果你确实需要下班后也能远程取文件，可以提前设置：\n电脑保持联网； WorkBuddy 电脑端保持运行； 系统不要过早自动休眠； 笔记本注意电量和电源连接。 Mac 和 Windows 都有电源管理设置，这个不复杂，但很容易忘。\n2. 指令太含糊，来回确认会浪费时间 远程办公最怕一句话：\n帮我把那个文件发给老王。\n这里面至少有三个不清楚：\n哪个文件？ 老王是谁？ 发到哪里？ 更好的写法是：\n1 2 3 4 5 6 7 请在电脑桌面查找文件名包含「市场方案最终版」的 Word 或 PDF 文件。 收件人：wang@example.com 主题：市场方案最终版 正文：王老师您好，方案最终版已放在附件中，请查收。 发送前请先展示草稿，等我确认后再发送。 把对象、文件、动作、边界说清楚，效率会高很多。\n3. 复杂任务不要一口气做完 如果任务包含多个动作，比如：\n找文件 → 修改内容 → 导出 PDF → 发给三个人 → 同步到文件夹\n不要一句话全塞进去，建议拆成四步：\n先找到文件； 再修改并输出新版本； 再生成邮件草稿； 最后确认发送。 远程操作时，分步确认比一次性自动执行更安全。尤其是涉及发邮件、改文件、移动文件、删除文件这些动作时，宁可慢半分钟，也不要省掉确认。\n八、哪些任务适合远程做？哪些不建议？ 我现在对这类工具的判断标准很简单：\n规则清楚、风险可控、结果可检查，适合远程交给 AI 做。\n责任重大、后果不可逆、需要强判断，不要全自动处理。\n适合远程处理的任务：\n找文件； 发送普通附件邮件； 生成文章大纲； 整理会议纪要； 汇总非敏感表格； 批量转换普通文件格式； 生成日报、周报初稿； 根据已有资料整理清单。 不建议完全自动处理的任务：\n合同关键条款修改； 财务最终对账； 客户敏感资料批量外发； 涉及价格、报价、付款的信息； 一次性删除、覆盖、移动大量文件； 需要法律、财务、人事责任判断的内容。 WorkBuddy 可以帮你把操作跑完，但决定能不能发、能不能改、能不能作为正式结论，还是要人来判断。这条边界不要丢。\n九、可以直接复制的远程办公 Prompt 下面给一版通用模板，以后手机远程操控电脑时，可以直接改里面的文件名、收件人和任务目标。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 请在本机模式下处理以下任务。 任务目标： 帮我查找电脑中的【文件名称或关键词】，并准备通过邮件发送给【收件人邮箱】。 查找范围： 优先查找【桌面 / D盘工作文件夹 / 指定文件夹路径】。 查找规则： 1. 文件名包含【关键词】； 2. 优先选择最近修改的版本； 3. 如果找到多个相似文件，请先列出文件名、路径、文件类型和修改时间； 4. 不要删除、移动、重命名或覆盖任何文件。 邮件要求： 1. 收件人：【邮箱地址】； 2. 主题：【邮件主题】； 3. 正文：【邮件正文】； 4. 附件：使用我确认后的文件。 执行边界： 1. 先展示找到的文件列表； 2. 等我确认附件后，再生成邮件草稿； 3. 发送前必须展示收件人、主题、正文和附件名称； 4. 等我明确确认后再发送。 这版 Prompt 的重点不是复杂，而是把四件事说清楚：\n找哪里。\n找什么。\n怎么发。\n哪一步必须确认。\n远程办公时，确认机制比自动化更重要。\n十、小结 用手机操控电脑，本质上不是为了显得高级，它解决的是一个很普通的问题：\n人不在电脑前，但事情不能等。\nWorkBuddy 微信小程序和 ClawBot 把这个流程变短了，以前你可能要回公司、找同事、开远程桌面、翻文件夹、传附件，现在可以变成：\n手机发指令 → 电脑执行 → 手机确认 → 结果返回。\n这就是它真正有价值的地方，但不要一开始就把重要任务全交出去。先从低风险任务开始：找文件、生成草稿、整理清单、发送普通附件。跑通几次之后，再逐步增加复杂度。\n远程办公最好的状态，不是 AI 替你做所有判断。而是它把那些必须坐在电脑前才能完成的操作，变成你在手机上也能推进的流程。\n你负责判断，它负责执行。\n手机不再只是看消息的工具，也可以变成一个真正能处理工作的入口。\n如果这篇文章对你有用，可以点个「在看」。\n你也可以在评论区说说：你最希望用手机远程处理电脑上的哪类任务？我后面可以挑几个典型场景继续实测。\n下载地址\n电脑端：https://www.codebuddy.cn/work/\n手机端：应用市场搜索「WorkBuddy」\n微信小程序：搜索「腾讯 WorkBuddy」\n","permalink":"https://blog.onecai.site/2026/07/10/038-workbuddy-mobile-remote-office/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy 实战手册 · 第8篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e有一种办公崩溃，很多人都遇到过：人已经离开公司，文件还在公司电脑里。更烦的是，别人不是明天要，也不是下周要，而是现在就要。\u003c/p\u003e\n\u003cp\u003e上个月有天下班路上，我在地铁里收到同事消息：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e明天一早开会要用的方案，最终版是不是还在你电脑桌面上？能不能现在发我一下？\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e如果是以前，我大概率只有两个选择：\u003c/p\u003e\n\u003cp\u003e第一，掉头回公司。\u003c/p\u003e\n\u003cp\u003e第二，找还在办公室的同事帮我开电脑、找文件、传文件。\u003c/p\u003e\n\u003cp\u003e两个选择都不舒服。\u003c/p\u003e\n\u003cp\u003e那天我试了第三种方式：打开微信里的 WorkBuddy 小程序，切到本机模式，让它在我办公室电脑上找到那份文件，再用绑定好的邮箱发给同事。\u003c/p\u003e\n\u003cp\u003e几分钟后，同事回了两个字：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e收到。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这件事给我的感觉很直接——WorkBuddy 不只是坐在电脑前用的 AI 助手，它还可以变成一个「手机遥控电脑」的工具。你人不在电脑前，但电脑上的文件、邮件、表格和任务，依然可以继续处理。\u003c/p\u003e\n\u003cp\u003e这篇就讲一个很具体的场景：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e怎么用 WorkBuddy 微信小程序和 ClawBot，在手机上远程操控电脑，完成取文件、发邮件、处理本地资料这类办公任务。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一手机端有三种入口\"\u003e一、手机端有三种入口\u003c/h2\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e入口\u003c/th\u003e\n          \u003cth\u003e适合场景\u003c/th\u003e\n          \u003cth\u003e我的建议\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e微信客服号\u003c/td\u003e\n          \u003ctd\u003e简单问答、轻量任务\u003c/td\u003e\n          \u003ctd\u003e能用，但能力比较基础\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eClawBot 插件\u003c/td\u003e\n          \u003ctd\u003e微信聊天里快速发指令\u003c/td\u003e\n          \u003ctd\u003e适合语音和临时操作\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e微信小程序\u003c/td\u003e\n          \u003ctd\u003e查看任务、下载文件、切换模式\u003c/td\u003e\n          \u003ctd\u003e最推荐，体验最完整\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e在微信里搜索「腾讯 WorkBuddy」，进入小程序后，就可以看到任务入口、模式切换、结果展示和文件下载。\u003c/p\u003e\n\u003cp\u003eClawBot 更像一个微信聊天里的快捷入口，小程序更像一个完整的手机工作台。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e临时一句话，用 ClawBot；\u003cbr\u003e\n要看结果、下载文件、确认任务进度，用小程序。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e两个配合起来，体验会顺很多。\u003c/p\u003e\n\u003ch2 id=\"二云端模式和本机模式不是一回事\"\u003e二、云端模式和本机模式不是一回事\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"workbuddy-mobile-remote-office-1.avif\"\n          alt=\"WorkBuddy云端模式和本机模式的区别\"/\u003e \u003cfigcaption\u003e\n             WorkBuddy云端模式和本机模式的区别\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eWorkBuddy 手机端通常会涉及两类任务：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e云端模式：任务在云端跑。\u003cbr\u003e\n本机模式：任务在你的电脑上跑。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这两个差别很大。\u003c/p\u003e\n\u003ch3 id=\"1-云端模式电脑关着也能用\"\u003e1. 云端模式：电脑关着也能用\u003c/h3\u003e\n\u003cp\u003e云端模式适合不依赖你电脑本地文件的任务。\u003c/p\u003e\n\u003cp\u003e比如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e写一篇文章大纲；\u003c/li\u003e\n\u003cli\u003e整理一段文案；\u003c/li\u003e\n\u003cli\u003e生成一个活动方案；\u003c/li\u003e\n\u003cli\u003e分析你手动上传的资料；\u003c/li\u003e\n\u003cli\u003e做一个通用选题规划。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这些任务不需要访问你电脑桌面，也不需要打开你本地硬盘，所以电脑关着也没关系。你可以在地铁、高铁、咖啡馆里直接用手机发指令。\u003c/p\u003e\n\u003ch3 id=\"2-本机模式电脑必须开着\"\u003e2. 本机模式：电脑必须开着\u003c/h3\u003e\n\u003cp\u003e本机模式的重点是：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWorkBuddy 可以远程操作你的电脑。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e它适合这些任务：\u003c/p\u003e","title":"手机也能操控电脑：WorkBuddy微信小程序+Claw远程办公实战"},{"content":" WorkBuddy 实战手册 · 第6篇\n一个文件夹里有 137 个文件。\nWord、PDF、TXT、图片、Excel 混在一起。\n文件名也很熟悉：\n会议纪要最终版 会议纪要最终版2 会议纪要最终版绝对不改了 会议纪要真最终版 需求听起来不复杂：\n把这些资料整理成一份 PDF 合集，按时间排序，统一格式，方便归档。\n但真正做起来，问题就来了。\n分类要逐个打开看；Word 要另存为 PDF；扫描件要识别；重复版本不能误删；最后还要按顺序合并。\n这类活有一个特点：不难，但非常消耗人。\n它不需要多少创造力，却要求你一直点开、判断、拖拽、另存为、合并，中间还不能走神。漏一个文件，后面可能就要重来。\n后来我用 WorkBuddy 跑了一遍。\n这篇就讲一个很具体的办公场景：怎么用 WorkBuddy 批量处理文件，把「整理、转换、合并」这条最无聊的流水线自动化。\n先说结论：\n文件处理不是最适合炫技的 AI 场景，但可能是最容易省时间的 AI 场景。\n前提是，指令要写清楚，边界要画明白。\n一、为什么批量文件处理特别适合交给 AI 文件整理这件事，本质上不是一个动作，而是一条流程。\n通常包括五步：\n扫描文件 判断内容 分类归档 格式转换 合并输出 每一步都很规则化，每一步又高度重复。\n这正好是 AI Agent 适合发挥的地方。\n整理 5 个文件，手动可能更快。\n整理 50 个文件，AI 开始省时间。\n整理 100 个以上文件，差距会非常明显。\n因为人最怕的不是「判断一次」，而是「重复判断一百次」。\nWorkBuddy 的价值也不只是「帮你改文件名」。更准确地说，它处理的是一个文件夹里的工作流：扫描、理解、分类、移动、转换、输出结果。\n这和在聊天框里上传一个文件让 AI 修改，不是同一件事。\n上传文件，是「你把东西递给它」。\n授权工作空间，是「你给它限定一个工作台，让它在这个范围内干活」。\n但也正因为它能动本地文件，所以第一条原则必须先讲清楚：\n授权范围一定要小。\n你要整理「项目资料」，就只授权「项目资料」这个文件夹。\n不要一上来授权整个桌面、整个文档目录，更不要把含有身份证、工资表、合同原件、客户资料的文件夹一起放进去。\nAI 文件处理的第一原则，不是快，而是可控。\n二、先建立体感：100 份文档到底麻烦在哪里 100份文档整理真正麻烦在哪里 很多人低估了批量文件处理的工作量，因为它看起来只是「整理一下」。\n但真正拆开看，里面至少有四笔账。\n第一笔：打开成本。\n100 个文件，如果每个文件只花 30 秒打开、判断、关闭，也要 50 分钟。实际办公里，一个文件往往不止 30 秒。\n第二笔：判断成本。\n文件名不可靠。\n「最终版」「终版」「确认版」「修改版」这些名字，很多时候不能说明内容。你必须打开文件，看标题、日期、正文、盖章页、表格内容，才能判断它应该放在哪里。\n第三笔：转换成本。\nWord 转 PDF、TXT 转 PDF、图片扫描件转 PDF，看似都是小动作，但一多就很烦。尤其是图片扫描件，还可能涉及 OCR 识别、页面方向、清晰度检查。\n第四笔：返工成本。\n最麻烦的不是慢，而是错。\n如果第 37 个文件漏了，第 62 个文件排错了，第 89 个文件被误判为重复，最后合并好的 PDF 就不可信。你还得倒回去查。\n所以这类任务真正消耗的不是鼠标点击，而是注意力。\n而注意力，才是最贵的办公资源。\n三、一个典型案例：发票自动整理 先看一个容易理解的场景：发票整理。\n团队出差回来，文件夹里堆了几百份发票 PDF，名字可能是「微信图片_20260701」「发票1」「扫描件03」。\n如果手动整理，你要逐个打开 PDF，看客户名称、开票日期、金额，再按规则重命名、归档、生成汇总表。\n这类任务非常适合交给 WorkBuddy。\n可以直接这样下指令：\n请帮我整理当前工作空间里的发票文件。\n读取每张发票中的客户名称、开票日期和总金额。\n按照「客户名称 + 开票日期 + 总金额」的格式重命名。\n按月份建立文件夹归档。\n整理完成后，生成一份发票汇总表。\n不要删除任何原始文件，不要覆盖原文件。\n这条指令背后，其实包含一串动作：\n扫描授权文件夹 打开发票文件 识别发票内容 提取客户、日期、金额 生成新文件名 建立分类文件夹 移动或复制文件 输出汇总表 重点不在于「改名」，而在于它能基于文件内容做判断，再执行整理动作。\n这就是 WorkBuddy 文件处理的核心价值：\n它不是处理一个文件，而是处理一组文件之间的关系。\n四、实战：从 137 个文件到一份归档 PDF 从137个文件到一份归档PDF的五步流程 下面用我这个「项目资料」文件夹举例。\n文件夹里有 137 个文件，混合了 Word、PDF、TXT、图片、Excel 五种格式。\n目标是：\n把项目资料整理成一份可归档的 PDF 合集，按类别和时间排序，保留原始文件，并生成目录清单。\n这件事不要一口气做完，建议分五步。\n第一步：先授权文件夹，不要直接下命令 第一次用 WorkBuddy 处理本地文件，最容易忽略的就是授权工作空间。\n如果你直接说：\n帮我整理项目资料文件夹。\n它很可能会提示找不到路径。\n原因很简单：没有授权，它看不到你电脑上的文件。\n正确做法是：在输入框左下角点击「选择工作空间」，只选中本次要处理的文件夹。\n比如你要整理「项目资料」，就只授权这个文件夹。\n不要授权它的上级目录，不要授权整个桌面，也不要授权整个「文档」目录。\n授权越精准，有三个好处：\n扫描范围更小 处理速度更快 安全边界更清楚 这一步看起来简单，但它决定了后面所有操作是否可控。\n第二步：先生成文件清单，别急着转换和合并 不要一上来就说：\n全部转 PDF，然后合并。\n这是最容易翻车的指令。\n因为你还不知道文件夹里到底有什么。\n里面可能有合同、会议纪要、草稿、图片素材、扫描件、Excel 表格，也可能有重复文件和无关文件。\n正确做法是先盘点。\n可以这样写：\n请先扫描当前工作空间文件夹，列出所有文件的名称、格式、大小、创建时间、修改时间和大致内容主题，生成一份文件清单表格。\n这一步只做扫描和清单生成，不要移动、删除、重命名、覆盖或转换任何文件。\n这条指令最关键的是最后一句：\n不要移动、删除、重命名、覆盖或转换任何文件。\n第一步的目标不是处理，而是摸清楚情况。\n拿到清单后，你至少要看三件事：\n文件数量对不对 文件类型是否完整 内容主题有没有明显误判 这一步就像搬家前先列物品清单。\n没有清单就开始搬，后面发现丢东西都不知道从哪里查。\n第三步：确认清单后，再分类和转换 清单确认无误后，再让 WorkBuddy 动文件。\n可以这样写：\n请根据刚才生成的文件清单，对当前工作空间内的文件进行整理。\n整理规则如下：\n按内容主题分为四类：会议纪要、合同文件、技术文档、其他资料。 Word、TXT、可识别的文档类图片，统一转换为 PDF。 图片文件如果是合同、通知、表格等文档扫描件，请先做 OCR 识别，再转为 PDF。 纯图片素材保持原格式，不要转换。 疑似重复文件不要删除，只移动到「疑似重复文件」子文件夹。 不要修改原始文件内容，不要覆盖原始文件。 所有整理结果输出到新建文件夹「整理结果」中。 整理完成后，在每个分类文件夹内生成一份文件目录清单。 所有变更完成后，请列出本次新建、移动、复制、转换的文件明细。 这条指令里有几个关键点。\n第一，分类标准要具体。\n不要只说「按类型分类」。\n要明确分成几类，每类叫什么，判断依据是什么。\n第二，格式转换要分情况。\n不是所有文件都应该转 PDF。\n合同扫描件、通知扫描件、纸质表格照片，可以 OCR 后转 PDF。\n但纯图片素材、封面图、截图素材，没有必要转 PDF。\n第三，重复文件不要直接删除。\n更稳妥的写法是「疑似重复文件」。\n因为 AI 可能把两个内容相近但版本不同的文件判断成重复。\n比如「合同初稿」和「合同修订版」，它们相似，但不一定重复。\n所以我建议默认规则是：\n疑似重复文件只移动，不删除。\n删除是不可逆操作。移动到子文件夹，后面还能人工复核。\n第四步：检查变更列表，不要只看结果文件 WorkBuddy 处理完后，不要急着打开最终 PDF。\n先看变更列表。\n变更列表告诉你三件事：\n新建了哪些文件夹 移动了哪些文件 转换了哪些格式 这一步不能跳过。\n我第一次跑的时候就偷懒了，只看了最后合并出来的 PDF，结果后来发现少了两份合同。回头查才知道，其中一份被判断成了疑似重复文件，另一份被分到了「其他资料」。\n从那以后，我给自己定了一条规则：\n文件处理任务，变更列表必须看一遍。\n检查时重点看四类问题：\n合同有没有被分错 会议纪要有没有按时间归类 Word 转 PDF 有没有失败 疑似重复文件有没有误判 如果发现问题，不需要全部重跑。\n可以直接补充指令：\n第 35 号文件分类错了，它应该归到「合同文件」类。请只调整这个文件，不要改动其他已整理文件。\n这种局部纠偏，比重新跑一遍更稳。\n第五步：确认无误后，再合并 PDF 分类和格式转换都确认没问题后，最后再合并。\n可以这样写：\n请将「整理结果」文件夹中的 PDF 文件合并为一份完整 PDF。\n合并规则如下：\n合同文件类：按合同签订日期排序。 会议纪要类：按会议日期排序。 技术文档类：按版本号或创建日期排序。 其他资料类：按文件名排序。 每一类之间插入分页。 每一类前增加目录页，目录页标注类别名称和包含文件列表。 输出文件命名为「项目资料归档合集_YYYYMMDD.pdf」。 合并完成后，请生成一份合并顺序清单。 这里最容易忽略的是排序规则。\n不同文件类型的排序逻辑不一样：\n合同按签订日期排 会议纪要按会议日期排 技术文档按版本号或创建日期排 其他资料按文件名排 如果你不指定，AI 可能统一按文件名排序。\n但「最终版2」「真最终版」「绝对不改版」这种命名，按文件名排序通常不可靠。\n合并后的 PDF 也要预览。\n重点看五件事：\n目录页有没有漏 分页是否正常 文件顺序是否合理 扫描件是否清晰 OCR 识别是否影响阅读 到这里，整个流程才算完成。\n五、WorkBuddy 不只是整理，还能按内容找文件 批量文件处理不只是整理、转换和合并。\n还有一个很实用的场景：本地文件搜索。\n比如你记得之前存过一张「机器人滑滑板」的图片，但忘了放在哪里。\n系统搜索通常只能按文件名找。\n如果文件名叫「IMG_2048」或者「封面备选3」，你基本搜不到。\nWorkBuddy 的优势在于，它可以结合文件名和内容描述一起查找。\n可以这样写：\n请在当前授权的工作空间中，帮我查找一张内容是「机器人滑滑板」的图片。\n文件名可能包含「机器人」，也可能不包含。\n请告诉我图片所在路径、文件名、尺寸和文件大小。\n只做查找，不要移动或修改文件。\n它通常会先按文件名匹配，再结合图片内容识别和描述匹配。\n这个能力适合找那些「我大概记得内容，但忘了文件名」的资料。\n比如：\n找某次活动合影 找一份内容关于预算的 PDF 找一个包含某个关键词的合同 找一张曾经用于封面的插图 找一个忘记命名规则的项目资料包 但还是同一句话：搜索前也要控制授权范围。\n你想找项目资料，就授权项目资料文件夹。\n不要为了图省事，把整个电脑都交出去。\n六、文件处理指令的三个核心要素 文件处理类指令和写作、调研类指令不一样。\n写文章，指令模糊一点，AI 还能补充发挥。\n做调研，方向偏一点，你可以中途纠偏。\n但文件处理，指令模糊可能直接导致文件被错误分类、错误转换，甚至误删。\n所以文件处理指令最核心的是三件事。\n1. 分类标准要写到 AI 不用猜 不要说：\n按类型分一下。\n要说：\n分为会议纪要、合同文件、技术文档、其他资料四类。\n会议纪要的判断标准是：内容包含会议时间、参会人员、议题、纪要事项。\n合同文件的判断标准是：内容包含甲方、乙方、合同金额、签订日期或盖章页。\n技术文档的判断标准是：内容包含系统说明、接口说明、部署步骤、版本记录或技术参数。\n标准越具体，判断越稳定。\n这不是啰嗦，而是在减少 AI 自行发挥的空间。\n2. 操作行为必须明确 每一个动作都要写清楚：\n是移动，还是复制 是转换格式，还是保持原格式 是重命名，还是保留原文件名 是删除，还是移入子文件夹 是覆盖原文件，还是生成新文件 是直接执行，还是先生成清单等待确认 文件处理里最怕一句话：\n你看着办。\nAI 不是你的老同事，不知道你过去的归档习惯。\n你不说清楚，它只能按默认逻辑处理。\n默认逻辑不一定错，但不一定符合你的需求。\n3. 安全边界必须提前写进去 建议每次文件处理指令里都加上这几句话：\n不要删除任何原始文件。\n不要覆盖原始文件。\n不要修改原始文件内容。\n所有整理结果请输出到新建文件夹。\n疑似重复文件只移动到「疑似重复文件」文件夹，不要删除。\n每一步完成后，请列出变更清单，等待我确认。\n这几句话看起来很保守，但很有必要。\n因为文件处理不是聊天，不是写错一句话可以删掉重来。\n它会真实影响你的本地文件。\n七、手动处理 vs WorkBuddy：差距在哪里 同一个任务：整理 137 个文件，分类、转格式、合并成一份 PDF。\n步骤 手动操作 WorkBuddy 梳理文件清单 逐个打开查看内容，约 2-3 小时 自动扫描识别，约 3-5 分钟 分类整理 手动建文件夹、移动文件，约 1-2 小时 按规则自动分类，约 2-5 分钟 格式转换 逐个另存为 PDF，约 2-3 小时 批量转换，约 3-8 分钟 去重检查 逐个对比内容，约 1 小时 自动识别疑似重复，人工复核 合并 PDF 用工具逐个添加合并，约 30 分钟 按规则自动合并，约 2-5 分钟 人工检查 分散在每个步骤中，容易漏 集中检查变更列表和最终预览，约 10-15 分钟 总计 约 7-10 小时 约 25-40 分钟 这个差距会随着文件数量增大而扩大。\n10 个文件，手动和 AI 差距不大。\n50 个文件，AI 开始明显省时间。\n100 个以上文件，AI 的价值就很明显。\n但不要误解。\nAI 不是让你完全不管。\n更合理的分工是：\nAI 负责重复执行，人负责规则制定和结果验收。\n这句话要记住。\nWorkBuddy 能帮你省掉大量机械动作，但不能替你承担最终责任。\n八、几个实战细节：让文件处理更稳 AI文件处理的安全边界 1. 先备份，再处理 如果文件很重要，先复制一份备份，再把备份文件夹授权给 WorkBuddy 处理。\n尤其是合同、发票、项目归档、客户资料这类文件，不要直接在唯一原件上跑自动化。\n最稳的做法是：\n原始文件夹不动，复制一份「项目资料_待整理」，让 AI 处理复制件。\n2. 先清单，后操作 不管多急，先让 AI 生成文件清单，你确认后再让它动文件。\n多花 3 分钟看清单，往往能避免后面 30 分钟返工。\n3. 分步操作，不要一把梭 如果文件数量超过 50 个，或者处理规则比较复杂，建议分步走：\n先扫描生成清单 再分类 再格式转换 再检查重复文件 最后合并输出 每一步确认一次。\n这样即使出错，也只影响当前步骤，不会整套流程重来。\n4. 善用变更列表 每次操作后，先看变更列表，再看最终产物。\n变更列表告诉你「它动了什么」。\n最终产物告诉你「结果长什么样」。\n两个一起看，才算完整验收。\n5. 敏感文件谨慎授权 涉及身份证号、银行卡号、工资表、合同扫描件、客户资料的文件，要特别谨慎。\n原则很简单：\n不是这次任务必须用到的文件，不要放进授权文件夹。\nAI 办公最重要的不是炫技，而是边界清楚。\n九、哪些场景适合用 WorkBuddy 处理文件 特别适合的场景有这些：\n项目归档：大量文档按主题分类、统一格式、合并成合集 下载文件夹清理：按类型和时间分类，把杂乱文件重新整理 发票批量整理：提取客户、日期、金额，按规则命名归档 会议纪要合并：多份纪要按时间顺序整理成完整记录 批量格式转换：几十个 Word、TXT、图片扫描件转成 PDF 本地文件搜索：根据内容描述找文件，而不是只靠文件名 活动资料整理：把照片、通知、名单、总结按活动归档 公众号素材管理：按选题、封面、正文配图、参考资料分类 但下面这些场景要谨慎：\n涉及大量敏感信息的文件 需要逐字精修的合同条款 需要法律、财务最终判断的文件 500 个以上超大量文件一次性处理 文件命名和内容都非常混乱、需要强人工判断的资料 我的判断标准是：\n规则明确的批量操作，适合交给 AI。\n责任重大的最终判断，必须由人复核。\n文件越多，规则越清晰，WorkBuddy 的优势越明显。\n文件越少，判断越复杂，手动处理可能更稳。\n十、可以直接复制的文件处理 Prompt 最后给一版可以直接复制的模板。\n你只需要把分类名称、排序规则和输出格式替换成自己的需求。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 请处理当前授权工作空间中的文件。 处理前请先完成以下步骤： 1. 扫描文件夹内所有文件。 2. 生成文件清单，包含文件名、格式、大小、创建时间、修改时间、大致内容主题。 3. 只生成清单，不要移动、删除、重命名、覆盖或转换任何文件。 我确认清单后，再按以下规则整理： 1. 按内容分为【会议纪要】【合同文件】【技术文档】【其他资料】四类。 2. 文档类文件转换为 PDF。 3. 图片如果是扫描件，请 OCR 后转为 PDF；如果是普通图片，请保持原格式。 4. 疑似重复文件只移动到【疑似重复文件】文件夹，不要删除。 5. 不要修改原始文件内容，不要覆盖原始文件。 6. 所有整理结果输出到新建文件夹【整理结果】中。 7. 整理完成后，请生成变更清单和文件目录清单。 8. 等我确认后，再执行 PDF 合并。 PDF 合并规则： 1. 合同文件类按签订日期排序。 2. 会议纪要类按会议日期排序。 3. 技术文档类按版本号或创建日期排序。 4. 其他资料类按文件名排序。 5. 每一类前增加目录页。 6. 每一类之间插入分页。 7. 输出文件命名为【项目资料归档合集_YYYYMMDD.pdf】。 8. 合并完成后，请生成合并顺序清单。 这版 Prompt 的重点不是复杂，而是把三件事说清楚：\n先看清楚，再动文件；\n能复制，不覆盖；\n能移动，不删除。\n小结 用 WorkBuddy 批量处理文件，完整流程可以概括为五步：\n授权文件夹 → 生成文件清单 → 分类和格式转换 → 检查变更 → 合并导出\n核心原则也很简单：\n先备份，后处理；\n先清单，后操作；\n先确认，后合并；\n能移动，不删除；\n能复制，不覆盖。\n文件处理这件事，最讽刺的地方在于：它不创造多少显性价值，但它会消耗大量时间。\n分类、转换、合并、命名，这些动作不会让你的报告更专业，也不会让你的方案更有说服力。\n它们只是必须跨过去的办公流程。\n把这道坎交给 AI，省下来的不只是一下午时间，还有一下午的注意力。\n不用对着 137 个文件一个个点鼠标，不用在第 89 个文件时走神漏掉一个，也不用在领导催的时候说「还在整理」。\n说到底，文件整理是一种「存在感消耗」：\n做完了没人夸你，做错了所有人找你。\n这种活，能交给机器，就不要自己硬扛。\n下一篇，我们换一个完全不同的场景，讲怎么用 WorkBuddy 零基础搭建个人网站，不写一行代码。\nWorkBuddy 实战手册 · 第7篇预告：\n《不写一行代码，用 WorkBuddy 零基础搭建个人网站》\n下载地址 电脑端：https://www.codebuddy.cn/work/\n手机端：应用市场搜索「WorkBuddy」\n微信小程序：搜索「腾讯WorkBuddy」\n","permalink":"https://blog.onecai.site/2026/07/09/037-workbuddy-batch-file-processing/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy 实战手册 · 第6篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e一个文件夹里有 \u003cstrong\u003e137 个文件\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003eWord、PDF、TXT、图片、Excel 混在一起。\u003c/p\u003e\n\u003cp\u003e文件名也很熟悉：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e会议纪要最终版\u003c/li\u003e\n\u003cli\u003e会议纪要最终版2\u003c/li\u003e\n\u003cli\u003e会议纪要最终版绝对不改了\u003c/li\u003e\n\u003cli\u003e会议纪要真最终版\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e需求听起来不复杂：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e把这些资料整理成一份 PDF 合集，按时间排序，统一格式，方便归档。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e但真正做起来，问题就来了。\u003c/p\u003e\n\u003cp\u003e分类要逐个打开看；Word 要另存为 PDF；扫描件要识别；重复版本不能误删；最后还要按顺序合并。\u003c/p\u003e\n\u003cp\u003e这类活有一个特点：\u003cstrong\u003e不难，但非常消耗人。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e它不需要多少创造力，却要求你一直点开、判断、拖拽、另存为、合并，中间还不能走神。漏一个文件，后面可能就要重来。\u003c/p\u003e\n\u003cp\u003e后来我用 WorkBuddy 跑了一遍。\u003c/p\u003e\n\u003cp\u003e这篇就讲一个很具体的办公场景：怎么用 WorkBuddy 批量处理文件，把「整理、转换、合并」这条最无聊的流水线自动化。\u003c/p\u003e\n\u003cp\u003e先说结论：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e文件处理不是最适合炫技的 AI 场景，但可能是最容易省时间的 AI 场景。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e前提是，指令要写清楚，边界要画明白。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一为什么批量文件处理特别适合交给-ai\"\u003e一、为什么批量文件处理特别适合交给 AI\u003c/h2\u003e\n\u003cp\u003e文件整理这件事，本质上不是一个动作，而是一条流程。\u003c/p\u003e\n\u003cp\u003e通常包括五步：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e扫描文件\u003c/li\u003e\n\u003cli\u003e判断内容\u003c/li\u003e\n\u003cli\u003e分类归档\u003c/li\u003e\n\u003cli\u003e格式转换\u003c/li\u003e\n\u003cli\u003e合并输出\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e每一步都很规则化，每一步又高度重复。\u003c/p\u003e\n\u003cp\u003e这正好是 AI Agent 适合发挥的地方。\u003c/p\u003e\n\u003cp\u003e整理 5 个文件，手动可能更快。\u003cbr\u003e\n整理 50 个文件，AI 开始省时间。\u003cbr\u003e\n整理 100 个以上文件，差距会非常明显。\u003c/p\u003e\n\u003cp\u003e因为人最怕的不是「判断一次」，而是「重复判断一百次」。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 的价值也不只是「帮你改文件名」。更准确地说，它处理的是一个文件夹里的工作流：扫描、理解、分类、移动、转换、输出结果。\u003c/p\u003e\n\u003cp\u003e这和在聊天框里上传一个文件让 AI 修改，不是同一件事。\u003c/p\u003e\n\u003cp\u003e上传文件，是「你把东西递给它」。\u003cbr\u003e\n授权工作空间，是「你给它限定一个工作台，让它在这个范围内干活」。\u003c/p\u003e\n\u003cp\u003e但也正因为它能动本地文件，所以第一条原则必须先讲清楚：\u003c/p\u003e","title":"用WorkBuddy批量处理100份文档：整理、合并、格式转换的自动化方案"},{"content":" 本文是「术语解构」系列之一。上一篇《Token 到底是什么》我们搞清楚了大模型的计量单位，这一篇来拆它最常被吹的参数：上下文窗口。\n厂商发布会说：支持 100 万 token 上下文。\n学术测试说：32K 的时候，12 个主流模型里有 11 个能力已经腰斩。\n窗口只用了 3%，模型就开始变笨——这中间发生了什么？\n这篇把近两年最关键的几组公开测试数据摆在一起，讲清楚标称窗口和有效窗口之间隔着什么。\n一、1M token 到底有多大 1M token 能装下很多，但不等于都能用好 先建立体感。按 Qwen 系列 tokenizer 处理中文的大致压缩率（1 个 token 约对应 1～1.5 个汉字）估算：1M token 大约能装下 100 万～150 万字中文。《三体》三部曲全文约 88 万字——也就是说，一整套《三体》塞进去，窗口还有富余。\n听起来很美好。但有三笔账，发布会不会告诉你。\n第一笔：输入和输出是不对称的。\n窗口 1M 指的是模型一次能“读”多少。它一次能“写”多少？主流模型的输出上限普遍只有 8K～65K token。你可以把三本书塞进去，但它没法给你写出一本书来。上下文窗口是个漏斗，进去的多，出来的少。\n第二笔：厂商用定价告诉你，长上下文有多贵。\n看两个 2026 年的真实定价规则：\nGemini 3 Pro：上下文超过 200K，按阶梯涨价 GPT-5.5：输入超过 272K token，价格直接翻倍 如果长上下文是白捡的能力，厂商为什么要在这个位置设收费闸门？因为注意力机制的计算成本随序列长度平方增长——窗口翻倍，注意力层的计算量大约翻四倍。这笔账最终会转嫁到你的账单上。\n第三笔：显存账。\n这个系列的老读者应该有条件反射了：任何“能力”最终都要落到显存上。一个 32B 模型，在 1M 上下文满载时，仅 KV Cache（模型推理时的“草稿纸”，后面会单独写一篇）就需要 64GB 以上显存（FP16）。什么概念？一台 24GB 的 MacBook Pro，连这张“草稿纸”的一半都装不下，模型本体还没算。这也是为什么你在本地部署时，把上下文长度往大了调，内存占用会肉眼可见地飙升。\n所以 1M 窗口的真实含义是：技术上能读这么多，但读得越多，越贵、越慢、越吃硬件。\n而且，还越笨。\n二、大海捞针：怎么测一个模型“读没读进去” “大海捞针”（Needle in a Haystack，NIAH）是测试长上下文最经典的方法，原理简单粗暴：\n找一大堆无关文本当“干草堆”（haystack） 在某个位置插入一句捏造的、无法靠常识推断的事实，这就是“针”（needle）——比如“某某咖啡馆的会员密码是 7382” 把整堆文本喂给模型，问它针的内容 改变两个变量反复测：干草堆的总长度、针埋的深度（开头 / 中间 / 结尾） 测试结果通常画成一张热力图：横轴是上下文长度，纵轴是针的深度，绿色代表捞到了，红色代表没捞到。如果模型真的“均匀地”利用了整个窗口，这张图应该通体全绿。\n实际情况是——几乎没有模型能做到全绿。而且红色出现的位置非常有规律：长度越长越红，中间深度比两头更红。\n三、公开数据：从“捞不到针”到“能力腰斩” 大海捞针测试：模型到底有没有读进去 把近两年几组关键测试按严重程度排一下。\n第一组：NoLiMa 基准——32K 就腰斩。\nNoLiMa 是一个刻意提高难度的长上下文测试：它的“针”和问题之间没有字面上的关键词重叠，模型不能靠词汇匹配作弊，必须真正理解语义。结果：在 32K token 长度下，12 个被测主流模型中有 11 个的表现跌到其短上下文性能的 50% 以下。\n注意这个数字的含义：32K 只是那些标称 1M 窗口的 3%。窗口还剩 97% 没用，能力已经腰斩。\n第二组：RULER 基准——标称值普遍虚。\nRULER 比经典捞针更全面，覆盖检索、聚合、追踪等多种任务。它给出的结论是：在声称支持 32K 以上上下文的模型中，只有一半能在该长度下维持令人满意的表现。\n标称窗口和有效窗口，是两个东西。这就像显示器标称 100% sRGB 和实测 100% sRGB 的区别——只不过大模型这边，虚标是行业默认操作。\n第三组：Chroma《Context Rot》报告——无一幸免。\n2025 年，向量数据库公司 Chroma 发布了目前最系统的一份研究，标题起得很形象：Context Rot，上下文腐烂。他们评测了 18 个主流模型——GPT-4.1、Claude 4、Gemini 2.5、Qwen3 全在列。结论只有一句话：没有一个模型能均匀地利用上下文，全部随输入变长而性能下降——连“原样复述一段文本”这种最简单的任务都会退化。\n更要命的是，这份报告测的还只是简单任务。报告原文的判断是：真实场景需要综合信息、多步推理，性能退化只会更严重。\n第四组：复杂任务上的极端案例——从 29% 到 3%。\n上面的判断有数据支撑：LongCodeBench 基准（真实代码任务）里，Claude 3.5 Sonnet 随上下文增长，性能从 29% 一路跌到 3%。不是打折，是归零。\n四组数据放在一起，规律很清楚：任务越接近真实使用（从捞针→语义理解→综合推理→写代码），长上下文的退化越狠。\n四、为什么越长越笨：三个机制 长上下文的U形注意力：开头和结尾清晰，中间容易丢失 现象摆完了，说原因。模型变笨不是玄学，主要是三个机制叠加。\n机制一：U 形注意力，中间是盲区。\n斯坦福 2023 年那篇著名的《Lost in the Middle》发现：同样的事实，放在输入的第 1 位，回答准确率约 75%；放到第 10 位（约 4000 token 的检索场景），掉到 55%。整体呈 U 形曲线——开头和结尾记得牢，中间位置的准确率能低 30% 以上。\n这和人看文档的习惯出奇地像：认真读开头，翻到结尾看结论，中间靠扫。区别是人知道自己扫过去了，模型不知道——它会基于没读进去的内容，自信地作答。\n机制二：计算量平方增长，注意力被稀释。\nTransformer 的自注意力机制里，每个 token 都要和其他所有 token 计算关联度。序列长度翻倍，这部分计算量翻四倍。当 100 万个 token 互相争夺注意力时，每个 token 分到的“关注度”被摊薄——你的那根针，只是百万分之一。\n机制三：干扰项越多，错得越自信。\nChroma 报告里最有实用价值的一个发现：当干草堆里存在和针语义相似但不相同的干扰内容时，性能退化明显加速；针和问题的语义相似度越低，长上下文下掉得越快。\n这直接解释了一个常见的真实翻车场景：你把 10 份格式相近的合同/日志/代码文件一起丢给模型，问其中一份的细节——满屏都是“长得像针的草”，这正是模型最容易出错、而且错得最自信的配置。它往往不会说“找不到”，而是从某个相似段落里一本正经地编一个答案给你。\n五、说句公道话：新模型的“捞针”已经不差了 为了不变成一边倒的批判，补充一组反方向的数据。\nLlama 4 Scout 标称 10M token 窗口（目前开源模型的天花板），在 8M token 以内能保持 95% 以上的检索准确率，到 10M 极限才降到 89%。单针检索这个动作本身，新一代模型确实练出来了——毕竟大海捞针测试已经公开了两年多，厂商完全可以针对性优化（这也是 NIAH 这个测试的局限：它只测“词汇级检索”这一个狭窄能力，模型可以应试）。\n所以更准确的说法是：\n捞一根针：新模型基本能做到，发布会演示的就是这个 在长上下文里做理解、综合、多步推理：所有模型都在退化，退化幅度远大于捞针测试显示的（回看第三节那个从 NoLiMa 到 LongCodeBench 的梯度） 这个差距，就是发布会数字和你实际使用体验之间的落差来源。\n六、实用结论：窗口是资格题，不是打分项 最后落到怎么用。三条建议：\n1. 把窗口当“资格题”看。 你的任务如果真需要一次塞进一整个代码仓库、一本书，那 1M 窗口是硬性门槛，不满足直接淘汰。但如果你的输入本来就几千 token，纠结谁家窗口更大毫无意义——该花力气的是喂进去的内容质量，不是窗口数字。\n2. 精心准备的短上下文，胜过偷懒的长上下文。 与其把 50 万 token 一股脑塞进去指望模型自己找重点，不如先筛选、先摘要，只喂相关的部分。省钱、省时间，而且——根据本文所有数据——更准。尤其注意第四节机制三：格式相近的多份材料混在一起，是最容易诱发自信幻觉的用法，能拆开问就拆开问。\n3. 重要信息放两头，别放中间。 如果必须用长上下文，把关键指令和关键材料放在输入的开头或结尾。U 形曲线是客观规律，顺着它用。\n一句话总结这篇：上下文窗口的标称值是“能装多少”，不是“能懂多少”。装得下和读得懂之间，隔着一条 U 形曲线。\n下一篇预告：这篇里 KV Cache 出场了一次，就吃掉了 64GB 显存。这张随上下文线性膨胀的“草稿纸”到底是什么？为什么它才是长上下文真正的硬件瓶颈？下期拆它。\n如果这篇的数据梳理对你有用：\n点个在看，让更多被“1M 窗口”广告词困惑的人看到 星标本号，「术语解构」系列每篇都用数据说话，不做通稿复读 你在实际使用中遇到过模型“读了后面忘了前面”的翻车现场吗？评论区聊聊，典型案例我会在下篇里分析 （本文为原创内容。文中数据来源：Chroma《Context Rot》技术报告、NoLiMa 与 RULER 长上下文基准、斯坦福《Lost in the Middle》论文、LongCodeBench 基准及各厂商官方定价页，均为公开可查资料。）\n","permalink":"https://blog.onecai.site/2026/07/08/036-context-window-1m-token/","summary":"\u003cblockquote\u003e\n\u003cp\u003e本文是「术语解构」系列之一。上一篇《Token 到底是什么》我们搞清楚了大模型的计量单位，这一篇来拆它最常被吹的参数：上下文窗口。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e厂商发布会说：支持 \u003cstrong\u003e100 万 token\u003c/strong\u003e 上下文。\u003c/p\u003e\n\u003cp\u003e学术测试说：\u003cstrong\u003e32K\u003c/strong\u003e 的时候，12 个主流模型里有 \u003cstrong\u003e11 个\u003c/strong\u003e能力已经腰斩。\u003c/p\u003e\n\u003cp\u003e窗口只用了 \u003cstrong\u003e3%\u003c/strong\u003e，模型就开始变笨——这中间发生了什么？\u003c/p\u003e\n\u003cp\u003e这篇把近两年最关键的几组公开测试数据摆在一起，讲清楚标称窗口和有效窗口之间隔着什么。\u003c/p\u003e\n\u003ch2 id=\"一1m-token-到底有多大\"\u003e一、1M token 到底有多大\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"context-window-1m-token-1.avif\"\n          alt=\"1M token 能装下很多，但不等于都能用好\"/\u003e \u003cfigcaption\u003e\n             1M token 能装下很多，但不等于都能用好\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e先建立体感\u003c/strong\u003e。按 Qwen 系列 tokenizer 处理中文的大致压缩率（1 个 token 约对应 1～1.5 个汉字）估算：\u003cstrong\u003e1M token 大约能装下 100 万～150 万字中文\u003c/strong\u003e。《三体》三部曲全文约 88 万字——也就是说，一整套《三体》塞进去，窗口还有富余。\u003c/p\u003e\n\u003cp\u003e听起来很美好。但有三笔账，发布会不会告诉你。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一笔：输入和输出是不对称的。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e窗口 1M 指的是模型一次能“读”多少。它一次能“写”多少？主流模型的输出上限普遍只有 \u003cstrong\u003e8K～65K token\u003c/strong\u003e。你可以把三本书塞进去，但它没法给你写出一本书来。上下文窗口是个漏斗，进去的多，出来的少。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二笔：厂商用定价告诉你，长上下文有多贵。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e看两个 2026 年的真实定价规则：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGemini 3 Pro：上下文超过 \u003cstrong\u003e200K\u003c/strong\u003e，按阶梯涨价\u003c/li\u003e\n\u003cli\u003eGPT-5.5：输入超过 \u003cstrong\u003e272K\u003c/strong\u003e token，价格直接\u003cstrong\u003e翻倍\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果长上下文是白捡的能力，厂商为什么要在这个位置设收费闸门？因为注意力机制的计算成本随序列长度\u003cstrong\u003e平方增长\u003c/strong\u003e——窗口翻倍，注意力层的计算量大约翻四倍。这笔账最终会转嫁到你的账单上。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三笔：显存账。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这个系列的老读者应该有条件反射了：任何“能力”最终都要落到显存上。一个 32B 模型，在 1M 上下文满载时，仅 KV Cache（模型推理时的“草稿纸”，后面会单独写一篇）就需要 \u003cstrong\u003e64GB 以上\u003c/strong\u003e显存（FP16）。什么概念？一台 24GB 的 MacBook Pro，\u003cstrong\u003e连这张“草稿纸”的一半都装不下，模型本体还没算\u003c/strong\u003e。这也是为什么你在本地部署时，把上下文长度往大了调，内存占用会肉眼可见地飙升。\u003c/p\u003e","title":"上下文窗口：标称1M的token，为什么32K就开始变笨"},{"content":" WorkBuddy实战手册 · 第5篇\n同一个任务：一份5000字的行业调研报告，6个维度，20多个关键数据点，每个数据都要标来源。\n手动做，10到15小时。交给 WorkBuddy，1到1.5小时。其中大部分时间，你只是在旁边看着，偶尔插一句嘴。\n写一篇行业分析报告要多久？简单的两三天，深的一两周。时间主要花在哪——写作只占20%，剩下80%全在找资料、交叉验证、整理来源。\n打开十几个浏览器标签页，这个网站抄一段那个网站抄一段，数据对不上还得找第三个源确认。最痛苦的是写到后面忘了某个数据从哪来的，翻半天历史记录，找不到只能删掉重查。\n这篇讲怎么用 WorkBuddy 做一份带信息来源的调研报告：从定选题到导出成品，全程在一个对话框里完成。第一次跑的时候我也踩了坑，下面一起讲。\n一、先说清楚：WorkBuddy做调研和“百度一下”差在哪 很多人觉得调研就是搜索，打开 WorkBuddy 直接说“帮我调研一下AI算力行业”。能跑，但出来的东西大概率是一篇正确的废话。\n简单搜索是“找一个答案”，深度调研是“拼出一个完整的认知”。前者搜一次就完，后者需要多轮搜索、交叉验证、甄别矛盾信息、结构化整合，完全是另一个量级的活。\nWorkBuddy 做调研，最打动我的是两点。\n一是真联网。不是拿训练数据糊弄你，是实打实去网上搜当前最新的信息。行业调研最怕过时数据——拿去年的数字写今年的报告，内行人一眼看穿。\n二是多轮搜。不是搜一次就完事，而是根据上一轮结果判断还缺什么，自动发起第二轮、第三轮搜索。你给它一个问题，它自己拆成若干子问题，逐个搜、逐个验，最后拼到一起。\n而且这个过程全程可见：每一轮搜了什么、找到了什么、下一步打算搜什么，都在对话区展示。不是黑箱，你随时可以插嘴“这个方向不用查了”或者“这块再深挖一下”，它听人话。\n二、实战：从一句话到一份带引用的调研报告 场景：写一份“2025年中国AI算力行业现状”的调研报告，给领导或客户看，要求有数据、有来源、有判断。\n第一步：Plan模式定框架，框架不确认不动手 别上来就说“帮我写一份AI算力行业调研报告”。我第一次就这么干，它直接开写，出来的东西结构散乱，该有的维度没有，不需要的塞了一堆。\n正确做法是先用 Plan 模式让它出框架：\n「我需要写一份关于2025年中国AI算力行业现状的调研报告。请先用Plan模式，帮我规划报告的框架，包括要覆盖的核心维度、每个维度需要搜索的关键问题、预期数据来源类型。框架发给我确认后再开始调研。」\nWorkBuddy 会先拆解报告应该覆盖的维度——市场规模、主要玩家、技术路线、政策环境、供需格局、价格趋势、未来展望——每个维度下列出要搜的具体问题。\n你检查框架，要加、要砍、要调优先级，直接说。框架阶段调整成本几乎为零，等报告写完再调结构等于重做。\n我有一次没确认框架就让它跑，搜了20分钟出来，发现缺了“价格趋势”这个维度——恰恰是领导最关心的，补搜又花了不少时间。后来学乖了。\n第二步：切Craft模式，逐维度搜索 框架确认后，切到 Craft 模式：\n「框架确认。请按以下顺序进行调研，每个维度搜索完成后先汇总该维度的发现和来源，再进入下一个维度。所有关键数据必须标注来源（网站名称+链接+检索日期）。」\n这条指令有三个关键点。\n逐维度搜，不要一把梭。每个维度搜完给你看结果，确认信息够了再进下一个。你能控制节奏，发现某个维度不足时及时补搜。\n来源标注必须写进指令。不写的话，WorkBuddy 可能只给数据不给来源。明确要求“网站名称+链接+检索日期”三要素，报告里每个数据都能追溯。你想想，一份数据查不到来源的调研报告，跟编的有什么区别？\n要阶段性汇总。这比一口气搜完所有维度再给你一个长报告好得多，因为你能在过程中纠偏。\n第三步：盯着它搜，跑偏随时插嘴 WorkBuddy 搜索时，对话区会实时展示它搜了哪些关键词、打开了哪些网页、提取了什么信息。发现方向不对，随时说：\n「政策环境这块搜得太浅了，目前只有国家级政策，请补充地方政策，特别是北京、上海、深圳的算力补贴政策。」\n它会基于你的反馈调整搜索策略，不会从头开始，而是在已有结果上补充——多轮对话的好处就在这，它记得之前搜了什么、还缺什么。\n我有一次看它搜“主要玩家”，只搜了阿里、腾讯、华为这些互联网大厂，漏了浪潮、曙光这类专业算力服务商。我插了一句“补充专业算力服务商的信息”，它立刻发起新一轮搜索补上了。我要是不管，报告里就缺一大块。\n第四步：数据打架时，让它标矛盾，别替你选 不同来源的数据对不上，是调研里最头疼的事之一。比如AI算力市场规模，有的报告说1500亿，有的说2000亿，差距不小。手动调研时你得自己判断哪个更靠谱，费时费力。\nWorkBuddy 碰到这种情况会主动标注：\n「关于2025年中国AI算力市场规模，不同来源数据存在差异。来源A（某某研究院）数据为1500亿元，来源B（某某咨询机构）数据为2000亿元。差异可能源于统计口径不同：来源A仅统计智能算力，来源B包含通用算力和智能算力。」\n它不帮你随便挑一个数字，而是告诉你矛盾在哪、差异原因可能是什么，判断权留给你。后续指令里你可以告诉它用哪个口径，或者两个都保留并说明差异。\n数据矛盾时，AI 负责标注，人负责判断 第五步：一条指令，输出带引用的完整报告 所有维度搜完后，让它整合：\n「所有维度调研已完成。请将以上所有发现整合为一份完整的调研报告，要求：\n报告结构按确认的框架组织，包含摘要、各维度分析、结论与展望 所有关键数据在正文中用括号标注来源编号，报告末尾附完整来源列表 每个维度末尾加一段“分析师判断”，基于数据给出趋势判断 总字数控制在5000字左右 保存为Word格式」 这条指令决定成品质量，四个点都不能省。\n来源标注方式要明确。“正文用编号、末尾附完整列表”，报告既好看又可追溯；不指定，来源散落正文，读起来乱。\n“分析师判断”让报告从资料堆砌升级为有观点的分析。光有数据没有判断的叫资料汇编，不叫调研报告。\n字数必须说。不说的话，它可能给你3000字，也可能给你10000字。\n输出格式要明确。Word 方便后续编辑，也可以要 Markdown 或 PDF，看你的需求。\nWorkBuddy深度调研的五步流程 三、调研指令和写作指令，核心区别就一条 写文章，表达是核心，信息是素材；做调研，信息是核心，表达只是容器。搞反了，写得再漂亮也是空的。所以调研指令抓三件事就够了：\n来源可溯。没有来源的数据，等于没有数据。这条不写进指令，AI 可能把训练数据里的旧信息当事实写进去，你根本分不清哪些是搜来的、哪些是编的。\n矛盾显性。数据矛盾是常态不是异常，让 AI 主动标注矛盾并分析原因，比让它替你选一个数字更有价值。\n分步执行。一把梭的后果是：等它全搜完给你一个长报告，你才发现某个关键维度信息不足，又得从头补搜。\n四、算一笔账：手动调研 vs WorkBuddy调研 同一个任务：5000字AI算力行业调研报告，6个维度，每个维度3-5个关键数据点。\n步骤 手动调研 WorkBuddy调研 定框架 查同类报告、列大纲，1-2小时 Plan模式自动拆解，5分钟 搜资料 逐维度搜索、记录信息，4-6小时 自动多轮搜索，30-40分钟 交叉验证 找第三个源确认矛盾数据，1-2小时 自动标注矛盾及原因，含在搜索中 整理来源 整理链接、编号、对应正文，1-1.5小时 搜索时自动记录 写报告 整合信息、组织结构、撰写，3-4小时 自动结构化输出，5-10分钟 人工校验 — 抽查数据和来源，20-30分钟 总计 约10-15小时 约1-1.5小时 手动调研和AI辅助调研的效率差异 时间差8-10倍。省掉的主要是信息收集和整理：搜索、筛选、记录来源、组织结构——这些不需要创造力，需要的只是耐心和时间。\n工具帮你把信息拼到一起，判断还是你来做。你的时间应该花在“这份报告要回答什么问题、数据背后的趋势是什么、对业务有什么启示”上。\n五、六个实战细节，报告质量再上一档 Plan模式先行。调研不规划框架等于蒙眼跑步，跑得越快偏得越远。Plan 出框架、确认后切 Craft 执行，顺序不能反。\n用“变更”标签查“裸数据”。报告生成后，在结果区的“变更”标签里通读全文，重点查有没有没标来源的数字。说真的，我第一次没仔细检查，报告里混了两个裸数据，被领导问“这个数据哪来的”，当场答不上来。多花5分钟检查来源，能避免这种尴尬。\n产物传到知识库。结果区预览时点分享图标，可以上传到 IMA 知识库或腾讯文档。调研报告是长期参考资料，下次写相关主题，直接让 WorkBuddy 读知识库里的旧报告做参考。\n上传已有资料交叉印证。手头有行业报告 PDF 或内部数据，直接拖进输入框，让它把联网搜索的结果和你的资料互相验证，比单一来源的调研全面得多。\n大主题拆开搜。“全球AI行业全景”这种主题别一次全搜，拆成几个子主题分多次任务，最后合并。一次性搜太大的主题，AI 的搜索深度不够，每个维度都浅尝辄止。\n指定信息时效。指令里加一句“优先采用2025年以来的数据和信息”，能过滤掉大量过时内容。行业变化快的领域，去年的数据今年可能已经不成立了。\n六、哪些调研适合交给AI，哪些不行 适合的：行业现状调研，多维度信息汇总，多轮搜索优势最明显；竞品分析，产品信息、定价、口碑能系统化覆盖；技术趋势调研，联网能力保证时效；市场进入分析，政策、规模、竞争格局快速拼出全景。\n要谨慎的：涉及机密的内部调研，敏感信息不要发给 AI 搜索；需要一手访谈的调研，AI 只能搜公开信息，替代不了真实采访；财务尽调这类对准确性要求极高的活，AI 搜集的数据只能当线索，必须人工核实原始来源。\n判断标准一句话：AI 做信息收集和结构化整理，人做判断和决策。\n小结 用 WorkBuddy 做深度调研，完整流程五步：\nPlan模式定框架 → Craft模式逐维度搜索 → 过程中插嘴纠偏 → 交叉验证矛盾数据 → 结构化输出带引用报告\n核心原则三条：框架不确认不动手，每个数据可追溯，每个维度确认后再继续。\n信息收集是体力活，判断才是脑力活。把体力活交给AI，脑子留给真正重要的事。\n做调研这件事，说到底是一个人用有限的时间去拼一个无限的世界。以前你一个人拼，能拼到的角落有限；现在 AI 帮你拼，你只需要做一件事——判断哪些碎片是真的、哪些该留下。\n你最近有没有一份一直拖着没动手的调研？评论区说说主题，后面的实战案例从里面挑。觉得有用，顺手点个“在看”，让更多被资料搜集拖垮的人看到这篇。\n下一篇换个场景，讲怎么用 WorkBuddy 批量处理100份文档，把文件整理这件纯体力活彻底自动化。\nWorkBuddy 实战手册 · 第6篇预告：《批量文件处理，100份文档整理合并格式转换的自动化方案》\n下载地址：\n电脑端 https://www.codebuddy.cn/work/\n手机端 应用市场搜「WorkBuddy」\n微信小程序 搜「腾讯WorkBuddy」\n","permalink":"https://blog.onecai.site/2026/07/07/035-workbuddy-deep-research-cited-report/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy实战手册 · 第5篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e同一个任务：一份5000字的行业调研报告，6个维度，20多个关键数据点，每个数据都要标来源。\u003c/p\u003e\n\u003cp\u003e手动做，10到15小时。交给 WorkBuddy，1到1.5小时。\u003cstrong\u003e其中大部分时间，你只是在旁边看着，偶尔插一句嘴。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e写一篇行业分析报告要多久？简单的两三天，深的一两周。时间主要花在哪——写作只占20%，剩下80%全在找资料、交叉验证、整理来源。\u003c/p\u003e\n\u003cp\u003e打开十几个浏览器标签页，这个网站抄一段那个网站抄一段，数据对不上还得找第三个源确认。最痛苦的是写到后面忘了某个数据从哪来的，翻半天历史记录，找不到只能删掉重查。\u003c/p\u003e\n\u003cp\u003e这篇讲怎么用 WorkBuddy 做一份带信息来源的调研报告：从定选题到导出成品，全程在一个对话框里完成。第一次跑的时候我也踩了坑，下面一起讲。\u003c/p\u003e\n\u003ch2 id=\"一先说清楚workbuddy做调研和百度一下差在哪\"\u003e一、先说清楚：WorkBuddy做调研和“百度一下”差在哪\u003c/h2\u003e\n\u003cp\u003e很多人觉得调研就是搜索，打开 WorkBuddy 直接说“帮我调研一下AI算力行业”。能跑，但出来的东西大概率是一篇正确的废话。\u003c/p\u003e\n\u003cp\u003e简单搜索是“找一个答案”，深度调研是“拼出一个完整的认知”。前者搜一次就完，后者需要多轮搜索、交叉验证、甄别矛盾信息、结构化整合，完全是另一个量级的活。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 做调研，最打动我的是两点。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一是真联网\u003c/strong\u003e。不是拿训练数据糊弄你，是实打实去网上搜当前最新的信息。行业调研最怕过时数据——拿去年的数字写今年的报告，内行人一眼看穿。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e二是多轮搜\u003c/strong\u003e。不是搜一次就完事，而是根据上一轮结果判断还缺什么，自动发起第二轮、第三轮搜索。你给它一个问题，它自己拆成若干子问题，逐个搜、逐个验，最后拼到一起。\u003c/p\u003e\n\u003cp\u003e而且这个过程全程可见：每一轮搜了什么、找到了什么、下一步打算搜什么，都在对话区展示。不是黑箱，你随时可以插嘴“这个方向不用查了”或者“这块再深挖一下”，它听人话。\u003c/p\u003e\n\u003ch2 id=\"二实战从一句话到一份带引用的调研报告\"\u003e二、实战：从一句话到一份带引用的调研报告\u003c/h2\u003e\n\u003cp\u003e场景：写一份“2025年中国AI算力行业现状”的调研报告，给领导或客户看，要求有数据、有来源、有判断。\u003c/p\u003e\n\u003ch3 id=\"第一步plan模式定框架框架不确认不动手\"\u003e第一步：Plan模式定框架，框架不确认不动手\u003c/h3\u003e\n\u003cp\u003e别上来就说“帮我写一份AI算力行业调研报告”。我第一次就这么干，它直接开写，出来的东西结构散乱，该有的维度没有，不需要的塞了一堆。\u003c/p\u003e\n\u003cp\u003e正确做法是先用 Plan 模式让它出框架：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e「我需要写一份关于2025年中国AI算力行业现状的调研报告。请先用Plan模式，帮我规划报告的框架，包括要覆盖的核心维度、每个维度需要搜索的关键问题、预期数据来源类型。框架发给我确认后再开始调研。」\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eWorkBuddy 会先拆解报告应该覆盖的维度——市场规模、主要玩家、技术路线、政策环境、供需格局、价格趋势、未来展望——每个维度下列出要搜的具体问题。\u003c/p\u003e\n\u003cp\u003e你检查框架，要加、要砍、要调优先级，直接说。\u003cstrong\u003e框架阶段调整成本几乎为零，等报告写完再调结构等于重做。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我有一次没确认框架就让它跑，搜了20分钟出来，发现缺了“价格趋势”这个维度——恰恰是领导最关心的，补搜又花了不少时间。后来学乖了。\u003c/p\u003e\n\u003ch3 id=\"第二步切craft模式逐维度搜索\"\u003e第二步：切Craft模式，逐维度搜索\u003c/h3\u003e\n\u003cp\u003e框架确认后，切到 Craft 模式：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e「框架确认。请按以下顺序进行调研，每个维度搜索完成后先汇总该维度的发现和来源，再进入下一个维度。所有关键数据必须标注来源（网站名称+链接+检索日期）。」\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这条指令有三个关键点。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e逐维度搜，不要一把梭\u003c/strong\u003e。每个维度搜完给你看结果，确认信息够了再进下一个。你能控制节奏，发现某个维度不足时及时补搜。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e来源标注必须写进指令\u003c/strong\u003e。不写的话，WorkBuddy 可能只给数据不给来源。明确要求“网站名称+链接+检索日期”三要素，报告里每个数据都能追溯。你想想，一份数据查不到来源的调研报告，跟编的有什么区别？\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e要阶段性汇总\u003c/strong\u003e。这比一口气搜完所有维度再给你一个长报告好得多，因为你能在过程中纠偏。\u003c/p\u003e\n\u003ch3 id=\"第三步盯着它搜跑偏随时插嘴\"\u003e第三步：盯着它搜，跑偏随时插嘴\u003c/h3\u003e\n\u003cp\u003eWorkBuddy 搜索时，对话区会实时展示它搜了哪些关键词、打开了哪些网页、提取了什么信息。发现方向不对，随时说：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e「政策环境这块搜得太浅了，目前只有国家级政策，请补充地方政策，特别是北京、上海、深圳的算力补贴政策。」\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e它会基于你的反馈调整搜索策略，不会从头开始，而是在已有结果上补充——多轮对话的好处就在这，它记得之前搜了什么、还缺什么。\u003c/p\u003e\n\u003cp\u003e我有一次看它搜“主要玩家”，只搜了阿里、腾讯、华为这些互联网大厂，漏了浪潮、曙光这类专业算力服务商。我插了一句“补充专业算力服务商的信息”，它立刻发起新一轮搜索补上了。我要是不管，报告里就缺一大块。\u003c/p\u003e\n\u003ch3 id=\"第四步数据打架时让它标矛盾别替你选\"\u003e第四步：数据打架时，让它标矛盾，别替你选\u003c/h3\u003e\n\u003cp\u003e不同来源的数据对不上，是调研里最头疼的事之一。比如AI算力市场规模，有的报告说1500亿，有的说2000亿，差距不小。手动调研时你得自己判断哪个更靠谱，费时费力。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 碰到这种情况会主动标注：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e「关于2025年中国AI算力市场规模，不同来源数据存在差异。来源A（某某研究院）数据为1500亿元，来源B（某某咨询机构）数据为2000亿元。差异可能源于统计口径不同：来源A仅统计智能算力，来源B包含通用算力和智能算力。」\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e它不帮你随便挑一个数字，而是告诉你矛盾在哪、差异原因可能是什么，判断权留给你\u003c/strong\u003e。后续指令里你可以告诉它用哪个口径，或者两个都保留并说明差异。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"workbuddy-deep-research-cited-report-02.avif\"\n          alt=\"数据矛盾时，AI 负责标注，人负责判断\"/\u003e \u003cfigcaption\u003e\n             数据矛盾时，AI 负责标注，人负责判断\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch3 id=\"第五步一条指令输出带引用的完整报告\"\u003e第五步：一条指令，输出带引用的完整报告\u003c/h3\u003e\n\u003cp\u003e所有维度搜完后，让它整合：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e「所有维度调研已完成。请将以上所有发现整合为一份完整的调研报告，要求：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e报告结构按确认的框架组织，包含摘要、各维度分析、结论与展望\u003c/li\u003e\n\u003cli\u003e所有关键数据在正文中用括号标注来源编号，报告末尾附完整来源列表\u003c/li\u003e\n\u003cli\u003e每个维度末尾加一段“分析师判断”，基于数据给出趋势判断\u003c/li\u003e\n\u003cli\u003e总字数控制在5000字左右\u003c/li\u003e\n\u003cli\u003e保存为Word格式」\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这条指令决定成品质量，四个点都不能省。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e来源标注方式要明确。\u003c/strong\u003e“正文用编号、末尾附完整列表”，报告既好看又可追溯；不指定，来源散落正文，读起来乱。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e“分析师判断”让报告从资料堆砌升级为有观点的分析\u003c/strong\u003e。光有数据没有判断的叫资料汇编，不叫调研报告。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字数必须说\u003c/strong\u003e。不说的话，它可能给你3000字，也可能给你10000字。\u003c/p\u003e","title":"腾讯WorkBuddy深度调研实测：10小时的行业报告1.5小时交付，每个数据带来源"},{"content":" WorkBuddy 实战手册 · 第3篇\n同一个任务：清洗一份500行的销售数据，分类汇总，出3张图表，整理成Word报告。\n手动做，实测85到155分钟。交给 WorkBuddy，算上人工确认的时间，10分钟以内。全程不写一个公式，不建一张透视表。\nExcel 是职场里最矛盾的工具：人人都打开过，真正能熟练处理数据的人不多。VLOOKUP、透视表、条件格式——名字都听过，真用的时候还得一边查教程一边试错。而数据分析最耗时间的，往往不是“分析”本身，是分析之前那堆体力活：日期格式不统一、产品名称多了空格、数字和文字混在一列、空值不知道怎么处理。\n这篇讲怎么把这些体力活整个交出去，同时守住几条不能交出去的底线。\n一、为什么是 WorkBuddy 而不是继续死磕 Excel Excel手动操作与 AI 执行助理的差异 你想知道的其实很简单：哪个产品卖得最好？哪个区域销售额最高？本月有没有异常？这些需求本身不复杂，但在 Excel 里要经过很多步：清洗、筛选、建透视表、插图表、调格式、复制到 Word。\nWorkBuddy 的优势不是“替代 Excel”，而是把这些重复操作变成自然语言任务。你只需要把文件拖进去，说清楚三件事：按什么维度分析、算哪些指标、输出什么格式。 剩下的读取、清洗、统计、出图、成文，交给它执行。\nExcel 是工具箱，WorkBuddy 是一个能听懂任务的执行助理。\n二、实战：一份销售数据的完整分析流程 假设你手头有一份月度销售数据 Excel，包含日期、产品名称、区域、销售额、销量等字段，500行左右。目标：清洗数据，找出表现最好的产品和区域，出图，整理成 Word 报告。五步走完。\n第一步：先让它看懂数据，别急着分析 打开 WorkBuddy，选 Craft 模式，把 Excel 拖进对话区。不要一上来就说“帮我分析一下”——太泛，AI 只能给你空泛总结。第一条指令这样写：\n先读取这份Excel，做一份数据概况说明：1）多少行、多少列；2）每列字段名称和数据类型；3）哪些列存在空值、重复值或格式异常。暂时不要修改原始数据，只检查，只说明。\n它会返回一份“数据体检报告”。这一步非常关键：后续所有分析都建立在字段识别和数据质量之上，第一步看错了字段，后面的结论跟着全错。\n第二步：清洗数据——先诊断，再动手 AI做数据清洗必须先诊断，再确认处理 真实的 Excel 几乎没有干净的：日期一列三种写法、“产品A”和“产品 A”被当成两个产品、销售额里混着“未统计”、空值散落各处。\n第二条指令，注意这里的关键约束：\n帮我清洗这份数据：1）日期统一为 YYYY-MM-DD；2）去除产品名称和区域名称中的多余空格；3）检查销售额、销量字段里的非数字内容，列出异常值；4）对空值先不要直接替换，告诉我空值分布，并给出建议处理方式；5）完成后输出一份清洗记录，说明每一步处理了多少条数据。\n为什么空值不能一句话让它全填0？因为不同字段的空值含义不一样：销售额为空可能是没统计，销量为空可能是漏填，区域为空是数据不完整。直接替换成0，均值和客单价会被拉低，数据含义也变了。\n先让 AI 列出问题，你来决定怎么处理。 确认之后再追加一条：\n确认：销售额和销量的空值按0处理；区域为空的记录标记为“未知区域”；生成清洗后的Excel，保留清洗记录。\n清洗后的改动可以在结果区的“变更”标签里逐条核对，效果类似 Word 的修订模式——每处修改的前后对比都看得到。财务、合同这类不允许出错的数据，这个功能尤其重要。\n第三步：分类统计，算出核心指标 基于清洗后的数据做分类统计：1）按产品类别汇总销售额和销量；2）按区域汇总销售额和销量；3）列出销售额Top5和最低5个产品；4）如果表中存在上月或同期数据，计算环比或同比；如果没有，明确说明“原表缺少对比周期数据，无法计算增长率”，不要编造；5）结果用表格呈现。\n这在 Excel 里要建透视表，在这里一句话。它会返回类似这样的结构化表格（示例）：\n产品类别 销售额（万元） 销量 环比增长 电子产品 156.3 1,240 +12.5% 家居用品 89.7 2,100 -3.2% 服装 67.4 890 +8.7% 表格后面通常跟一段判断：“电子产品环比增长12.5%，是增长最快的品类；家居用品下滑3.2%，建议关注原因。”这段判断基于前面算出的数据，有数据，有结论，不是空话。\n注意指令里那个约束：表里有什么，就分析什么；表里没有的，不许编。 没有同期数据不能算同比，没有成本字段不能算利润率，没有客户数不能算客单价。数据分析最怕的不是结论慢，而是结论看起来很完整，数据基础根本不存在。\n第四步：生成图表 从分类统计到可视化图表 给领导看，图表比表格有冲击力。三类图各有分工：柱状图看对比，折线图看趋势，饼图看占比。\n根据上面的分析结果生成3张图表：1）柱状图——各产品类别销售额对比；2）柱状图——各区域销售额对比；3）折线图——按日期的销售额趋势。每张图要有标题、坐标轴名称和单位，附不超过50字的说明，导出为PNG。如果日期字段不适合做趋势分析，改为生成产品类别占比图，并说明原因。\n最后那句防御性约束很有用——它能避免 AI 为了完成任务硬生成一张不合适的图。图不是越多越好，普通汇报3张够了。不确定用什么图，直接问它“这份数据适合什么图表”，它按数据特征给建议，拍板的是你。\n第五步：整理成 Word 报告 真正能交付的不是几张散图，是一份结构清楚的文档：\n把以上分析结果整理成Word报告，结构：一、数据概况（来源、字段、数据量、清洗情况）；二、核心指标汇总（表格）；三、产品分析；四、区域分析；五、趋势或结构分析（插入图表并解释）；六、结论与建议（3条基于数据的业务建议）。要求：语气正式，结论必须来自前面的数据，不要写空泛口号，输出Word文件。\n到这一步，你得到的不是“AI 回答”，而是一个可以直接修改、转发、汇报的文件。这是完整闭环：上传 → 检查 → 清洗 → 统计 → 出图 → 成报告。\n三、数据类指令最容易踩的三个坑 用 AI 做数据分析，最大的风险不是它不会做，而是你没把规则说清楚。\n坑1：只说“帮我分析一下”。 产出多半是“整体表现良好”“部分区域有增长空间”这种正确的废话。改成：“按产品类别和区域两个维度，分别汇总销售额、销量和占比，列出Top5与Bottom5。”\n坑2：没说明空值怎么处理。 空值、异常值、重复值是最容易影响结论的地方。每次都加一句：“遇到空值、异常值和重复值，先列出问题和建议处理方式，不要直接删除或替换。”把风险前置。\n坑3：让 AI 算原表里不存在的指标。 表里只有销售额和销量，你让它算利润率，它可能真给你“算”一个出来。必须加约束：“如果原始数据不支持某项指标计算，明确说明原因，不要编造。”这句话建议每次处理表格都带上。\n四、账算一下：手动做 vs WorkBuddy 做 同一个任务，500行销售数据，检查+清洗+汇总+3张图+报告：\n步骤 手动做 WorkBuddy 做 数据检查 逐列查看，容易漏，10-15分钟 一句话，1分钟 数据清洗 筛选、替换、统一格式，30-60分钟 诊断+确认两句话，2-3分钟 分类统计 建透视表、写公式，20-30分钟 一句话，1分钟 生成图表 插图、调格式、导出，15-20分钟 一句话，1-2分钟 整理报告 复制粘贴、排版，20-30分钟 一句话，1-2分钟 总计 95-155分钟 6-9分钟（含确认约10分钟） 时间差在10倍以上。但注意省掉的是什么——不是判断时间，是操作时间。真正的分工是：\n人负责提出问题、判断结论、承担责任；AI 负责读取数据、执行计算、整理格式。\nAI 可以帮你更快跑完流程，但不能替你对结论负责。\n五、什么场景适合，什么场景必须谨慎 AI数据分析的效率边界与安全边界 适合的四类：日常运营数据汇总（周报月报，结构不变只换数据）、临时分析（领导下班前要结论，没必要搭模板）、数据清洗（格式混乱的重复劳动）、快速可视化（出图做汇报和配图）。\n必须谨慎的：财务对账、工资核算、报销审核这类金额精确性任务（AI 算完必须人工复核）；合同、审计、合规类需要留痕追溯的任务（没有专业 BI 那种完整审计日志）；几万行以上的大数据量（变慢、可能截断）；以及最重要的——涉及客户隐私、身份证号、手机号、银行卡号的数据，上传前必须先脱敏。删掉姓名、电话、证件号、合同号这些敏感字段，再交给 AI。\n效率可以外包给 AI，数据安全不能。\n六、可以直接复制的提示词模板 不想每次重新组织语言，直接复制这段：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 请你作为数据分析助理，先读取我上传的Excel文件，不要急着下结论。 1. 数据概况 - 说明表格行数、列数，列出字段名称和类型； - 检查空值、重复值、异常格式和明显不合理的数据。 2. 数据清洗 - 先列出清洗建议，不要直接删除或替换； - 日期统一为 YYYY-MM-DD，去除文本字段多余空格； - 检查数值字段中的非数字内容； - 清洗后输出处理记录，说明每步影响了多少条数据。 3. 分类统计 - 按我指定的维度汇总核心指标，输出Top5和Bottom5； - 如果原始数据不支持某项指标计算，明确说明原因，不要编造。 4. 可视化 - 根据数据特点推荐合适图表； - 图表必须有标题、坐标轴名称、单位和简短说明； - 不要生成与数据结构不匹配的图表。 5. 报告输出 - 将概况、清洗记录、核心表格、图表和结论整理成Word报告； - 结论必须来自前面的数据，不写空泛口号； - 最后给出3条可执行建议。 这个模板的重点不是长，是把边界说清楚：先检查再清洗，能算就算、不能算就说明，先出表再出图最后成文档。\n小结 WorkBuddy 数据分析完整流程：\n上传表格 → 检查数据 → 清洗数据 → 分类统计 → 生成图表 → 整理报告\n它把公式、透视表、图表排版这些门槛往后挪，让你把注意力放回问题本身：这份数据到底说明了什么？下一步该怎么做？\n如果这篇替你省掉了下一个“调格式的下午”，点个“在看”，让还在手动清数据的人也看到。想第一时间收到第4篇，星标本号——不星标，推送大概率沉底。\n你在 Excel 里最头疼的体力活是什么？评论区说说，典型的我拿真实数据实测一遍，写进后面的篇目。\nWorkBuddy 实战手册 · 第4篇预告：《30分钟出一份PPT：从需求到演示文稿全流程拆解》\n下载地址：\n电脑端：https://www.codebuddy.cn/work/\n手机端：应用市场搜“WorkBuddy”\n微信小程序：搜“腾讯WorkBuddy”\n","permalink":"https://blog.onecai.site/2026/07/06/034-workbuddy-data-analysis/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy 实战手册 · 第3篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cp\u003e同一个任务：清洗一份500行的销售数据，分类汇总，出3张图表，整理成Word报告。\u003c/p\u003e\n\u003cp\u003e手动做，实测85到155分钟。交给 WorkBuddy，算上人工确认的时间，10分钟以内。\u003cstrong\u003e全程不写一个公式，不建一张透视表。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eExcel 是职场里最矛盾的工具：人人都打开过，真正能熟练处理数据的人不多。VLOOKUP、透视表、条件格式——名字都听过，真用的时候还得一边查教程一边试错。而数据分析最耗时间的，往往不是“分析”本身，是分析之前那堆体力活：日期格式不统一、产品名称多了空格、数字和文字混在一列、空值不知道怎么处理。\u003c/p\u003e\n\u003cp\u003e这篇讲怎么把这些体力活整个交出去，同时守住几条不能交出去的底线。\u003c/p\u003e\n\u003ch2 id=\"一为什么是-workbuddy-而不是继续死磕-excel\"\u003e一、为什么是 WorkBuddy 而不是继续死磕 Excel\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"workbuddy-data-analysis-1.avif\"\n          alt=\"Excel手动操作与 AI 执行助理的差异\"/\u003e \u003cfigcaption\u003e\n             Excel手动操作与 AI 执行助理的差异\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e你想知道的其实很简单：哪个产品卖得最好？哪个区域销售额最高？本月有没有异常？这些需求本身不复杂，但在 Excel 里要经过很多步：清洗、筛选、建透视表、插图表、调格式、复制到 Word。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 的优势不是“替代 Excel”，而是把这些重复操作变成自然语言任务。你只需要把文件拖进去，说清楚三件事：\u003cstrong\u003e按什么维度分析、算哪些指标、输出什么格式。\u003c/strong\u003e 剩下的读取、清洗、统计、出图、成文，交给它执行。\u003c/p\u003e\n\u003cp\u003eExcel 是工具箱，WorkBuddy 是一个能听懂任务的执行助理。\u003c/p\u003e\n\u003ch2 id=\"二实战一份销售数据的完整分析流程\"\u003e二、实战：一份销售数据的完整分析流程\u003c/h2\u003e\n\u003cp\u003e假设你手头有一份月度销售数据 Excel，包含日期、产品名称、区域、销售额、销量等字段，500行左右。目标：清洗数据，找出表现最好的产品和区域，出图，整理成 Word 报告。五步走完。\u003c/p\u003e\n\u003ch3 id=\"第一步先让它看懂数据别急着分析\"\u003e第一步：先让它看懂数据，别急着分析\u003c/h3\u003e\n\u003cp\u003e打开 WorkBuddy，选 Craft 模式，把 Excel 拖进对话区。不要一上来就说“帮我分析一下”——太泛，AI 只能给你空泛总结。第一条指令这样写：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e先读取这份Excel，做一份数据概况说明：1）多少行、多少列；2）每列字段名称和数据类型；3）哪些列存在空值、重复值或格式异常。暂时不要修改原始数据，只检查，只说明。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e它会返回一份“数据体检报告”。这一步非常关键：后续所有分析都建立在字段识别和数据质量之上，第一步看错了字段，后面的结论跟着全错。\u003c/p\u003e\n\u003ch3 id=\"第二步清洗数据先诊断再动手\"\u003e第二步：清洗数据——先诊断，再动手\u003c/h3\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"workbuddy-data-analysis-2.avif\"\n          alt=\"AI做数据清洗必须先诊断，再确认处理\"/\u003e \u003cfigcaption\u003e\n             AI做数据清洗必须先诊断，再确认处理\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e真实的 Excel 几乎没有干净的：日期一列三种写法、“产品A”和“产品 A”被当成两个产品、销售额里混着“未统计”、空值散落各处。\u003c/p\u003e\n\u003cp\u003e第二条指令，注意这里的关键约束：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e帮我清洗这份数据：1）日期统一为 YYYY-MM-DD；2）去除产品名称和区域名称中的多余空格；3）检查销售额、销量字段里的非数字内容，列出异常值；4）\u003cstrong\u003e对空值先不要直接替换，告诉我空值分布，并给出建议处理方式\u003c/strong\u003e；5）完成后输出一份清洗记录，说明每一步处理了多少条数据。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e为什么空值不能一句话让它全填0？因为不同字段的空值含义不一样：销售额为空可能是没统计，销量为空可能是漏填，区域为空是数据不完整。直接替换成0，均值和客单价会被拉低，数据含义也变了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e先让 AI 列出问题，你来决定怎么处理。\u003c/strong\u003e 确认之后再追加一条：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e确认：销售额和销量的空值按0处理；区域为空的记录标记为“未知区域”；生成清洗后的Excel，保留清洗记录。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e清洗后的改动可以在结果区的“变更”标签里逐条核对，效果类似 Word 的修订模式——每处修改的前后对比都看得到。财务、合同这类不允许出错的数据，这个功能尤其重要。\u003c/p\u003e\n\u003ch3 id=\"第三步分类统计算出核心指标\"\u003e第三步：分类统计，算出核心指标\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e基于清洗后的数据做分类统计：1）按产品类别汇总销售额和销量；2）按区域汇总销售额和销量；3）列出销售额Top5和最低5个产品；4）如果表中存在上月或同期数据，计算环比或同比；\u003cstrong\u003e如果没有，明确说明“原表缺少对比周期数据，无法计算增长率”，不要编造\u003c/strong\u003e；5）结果用表格呈现。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这在 Excel 里要建透视表，在这里一句话。它会返回类似这样的结构化表格（示例）：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e产品类别\u003c/th\u003e\n          \u003cth\u003e销售额（万元）\u003c/th\u003e\n          \u003cth\u003e销量\u003c/th\u003e\n          \u003cth\u003e环比增长\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e电子产品\u003c/td\u003e\n          \u003ctd\u003e156.3\u003c/td\u003e\n          \u003ctd\u003e1,240\u003c/td\u003e\n          \u003ctd\u003e+12.5%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e家居用品\u003c/td\u003e\n          \u003ctd\u003e89.7\u003c/td\u003e\n          \u003ctd\u003e2,100\u003c/td\u003e\n          \u003ctd\u003e-3.2%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e服装\u003c/td\u003e\n          \u003ctd\u003e67.4\u003c/td\u003e\n          \u003ctd\u003e890\u003c/td\u003e\n          \u003ctd\u003e+8.7%\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e表格后面通常跟一段判断：“电子产品环比增长12.5%，是增长最快的品类；家居用品下滑3.2%，建议关注原因。”这段判断基于前面算出的数据，有数据，有结论，不是空话。\u003c/p\u003e","title":"腾讯WorkBuddy数据分析实测：500行脏数据到成品报告，零公式零透视表"},{"content":" WorkBuddy 实战手册 · 第2篇\n上一篇里，我提到一个心法：把你脑子里那套隐性标准，翻译成显性约束。\n“帮我写个报告”——隐性标准是“我想要一份看起来靠谱的、领导能看的报告”，但 AI 读不懂“靠谱”和“能看”。它只认你写出来的东西：格式、语气、篇幅、结构、约束。说白了，一条好指令要回答四个问题：做什么、基于什么做、交付什么、不能怎么做。\n这篇就把那个心法落地。20个指令模板，覆盖最常见的办公场景，每个都能直接复制到 WorkBuddy 的输入框里用。用完之后你会理解一个规律：好指令不是写得多，而是写得准。\n写在前面的 AI 工具多到挑不过来，但有一个问题很少有人提：怎么才能让 AI 替你干活，而不是替自己发挥？\n答案很简单——你得把它当“自己人”。把你的素材、数据、文档喂给它，它才能用你的东西干你的活。否则它就只能凭自己的理解去猜，猜出来的东西看着像，但不是你的。\nWorkBuddy 解决这个问题的方式很直接：连接器。\n在对话框里，通过连接器打通你的工作生态——腾讯文档、钉钉、腾讯会议、IMA 知识库（这个后面会专门讲）、QQ 邮箱、飞书、企业微信、Notion、GitHub……你的素材在哪里，它就连接哪里。甚至可以自定义连接器，对接你自己的系统。\n连接好了之后，AI 读的是你的数据，用的是你的素材，产出的结果自然也是你的——不再是一份“看起来还行但和我没关系”的通用内容，而是一份带着你的真实信息、你的业务语境的成品。\n把数据喂进去，AI 才能真正替你干活。这步不做，后面的所有技巧都白搭。\n一、指令公式：四要素拆解 好指令的四要素：目标、输入、输出格式、约束 先记住一个公式，后面所有模板都踩着它走：\n目标 + 输入 + 输出格式 + 约束\n要素 含义 示例 目标 你要它做什么 写一份周报 输入 它基于什么材料来做 上传的项目进展文档 输出格式 你想要什么格式的结果 Word / Excel / PPT 约束 风格、篇幅、语气、限制 语气正式，不超过1500字，不要编造数据 四要素不全，产出必打折。少了“输出格式”，它可能只给你一段纯文字，而不是你想要的 Word 或 Excel 文件。少了“执行约束”，语气、篇幅、结构就会变成 AI 自己猜。\n下面的20个模板，每一个都踩准了这四个要素。你可以直接用，也可以根据自己的实际情况替换其中的关键词。\n二、文档写作类（模板1-5） 1. 项目周报 1 根据我上传的本周工作记录，帮我写一份项目周报，包含三个部分：本周工作总结（列出3项已完成的关键任务及成果）、下周工作计划（列出2项重点工作及预期目标）、需要协调的事项（1项，附建议解决方案）。语气正式，适合发给领导看，突出结果和进展，不要写成流水账，Word格式输出。 产出：一份结构完整的 Word 周报，三个板块都有标题和内容。\n提示：如果不上传工作记录，AI 只能给你一个空框架，具体任务和成果全靠你自己往里填。上传一份哪怕很粗糙的工作流水（备忘录、待办清单截图都行），产出直接从“模板”变“成品”。\n2. 会议纪要 1 根据上传的会议录音转写文本，帮我整理一份会议纪要。格式要求：会议主题、参会人员、时间地点、讨论要点（不超过5条，每条附结论）、待跟进事项（列出负责人和截止日期）、未决问题（会上没有形成结论的事项单独列出）。只基于转写文本整理，不要自行补充事实；参会人、时间、地点等信息原文里没有的，标注\u0026#34;原文未提及\u0026#34;。语气客观正式，Word格式输出。 使用方式：先把录音转写文本（或会议笔记）拖到输入框上传，再发指令。WorkBuddy 会读取文件内容作为素材。\n要点：会议纪要最怕两件事——AI 编造参会人和结论、把闲聊也写进去。“只基于转写文本”“没有就标注原文未提及”这两条约束，就是专门堵这两个坑的。“未决问题”单独列出也很实用：会上吵了半天没结论的事，往往才是下次会议的重点。\n3. 通知邮件 1 帮我写一封部门内部通知邮件，主题是\u0026#34;7月15日团队建设活动报名\u0026#34;。内容包含：活动时间地点、活动内容简介、报名截止日期、报名方式。语气亲切但不失正式，篇幅控制在200字以内，直接输出邮件正文。我没提供的具体信息（时间、地点、报名方式等）用【待补充】标注，不要自行编造。 注意：最后那句“用【待补充】标注”很关键——不加的话，AI 会随手编一个时间地点出来，看着完整，实际全是假的。当然，如果你有具体的活动安排文档，上传后基于真实信息来写，连【待补充】都省了。\n4. 工作汇报（长版） 1 根据我上传的季度数据和项目材料，帮我写一份Q2季度工作汇报，结构按四个板块组织：一、季度目标回顾及达成率；二、重点项目进展与成果（3个项目）；三、遇到的问题与应对措施；四、Q3工作计划与资源需求。语气正式、数据导向，所有数据一律以上传材料为准，材料里没有的数据标注【待补充】，不要虚构。Word格式输出，总篇幅3000字左右。 要点：这条指令的关键约束是“数据以上传材料为准、缺的标注【待补充】、不要虚构”。汇报类文档最怕的不是 AI 写得不好，而是它一本正经地编数字——“达成率92%”看起来很专业，但那个92%可能是它现场编的。加了这条约束，缺什么数据一目了然，你补上就行。\n5. 文档润色 1 帮我润色这份文档，要求：修正语法错误和错别字、统一术语表述、删除重复段落、让行文更紧凑流畅但不改变原意。保持原有语气，不添加新内容。如果发现事实、数据或逻辑上的疑点，不要直接改，单独列一份\u0026#34;需要人工确认的问题\u0026#34;清单。修改后的版本用Word格式输出。 使用方式：上传原始文档后发指令。这条指令的核心约束是“不改变原意、不添加新内容”——防止 AI 帮你“越改越多”。“疑点单独列出”是个加分项：润色的职责是改文字，事实对不对应该由你来判断，AI 替你“顺手改了”反而危险。\n三、数据分析类（模板6-9） 从 Excel 数据到分析报告和图表 6. Excel 数据分析 1 分析这份Excel销售数据，帮我做以下处理：1）按产品类别汇总销售额和销量；2）计算每个类别的增长率（数据里有去年同期就算同比，只有连续月份就算环比，数据不支持的直接说明缺少什么字段，不要估算）；3）找出销售额Top5的产品；4）生成一份包含数据表格和结论的Word分析报告。结论部分要给出\u0026#34;哪些品类增长最快、哪些下滑最明显\u0026#34;的判断，所有结论必须对应原始数据。 使用方式：上传 Excel 文件后发指令。WorkBuddy 会读取数据、自动清洗、计算指标、生成报告。\n要点：括号里那句“数据不支持的直接说明，不要估算”很重要。比如你的表里只有今年的数据，“同比增长率”根本算不出来——不加这条约束，AI 可能会硬凑一个数出来。\n7. 数据可视化图表 1 根据这份Excel数据，帮我生成3张图表：1）柱状图——各区域销售额对比；2）折线图——月度销售趋势；3）饼图——产品类别占比。图表中的标题、图例、坐标轴文字全部用中文，并标注数据单位。如果原始数据不支持某张图，说明原因并建议替代方案，不要硬画。每张图表附简要说明（不超过50字），所有图表导出为PNG图片。 要点：明确了要哪种图表、每个图表展示什么数据。模糊指令“帮我做几张图”往往产出错位——你想要饼图它给你柱状图，你想要区域对比它给你时间趋势。“不支持就说明、不要硬画”是另一层保险：数据里没有月份字段，它照样能给你“画”出一条趋势线来，那种图比没有图更误导人。\n8. 报表自动生成 1 根据这份月度运营数据Excel，帮我生成一份标准运营月报，包含：核心指标汇总表（DAU、MAU、留存率、ARPU）、环比变化分析、异常指标预警（标注环比波动超过10%的指标）、下月建议。所有指标必须来自原始表格，缺少的指标列入\u0026#34;数据缺口\u0026#34;说明，不要编造。输出为Excel文件：指标汇总和环比数据放在\u0026#34;数据\u0026#34;工作表，异常预警和分析建议放在\u0026#34;分析\u0026#34;工作表。 特色：这条指令指定了“环比波动超过10%”这个量化阈值——AI 会按这个标准自动标注异常，而不是泛泛地说“某些指标有变化”。输出格式也拆到了工作表级别：数据归数据、分析归分析，不会出现大段文字挤在单元格里的尴尬排版。\n9. 多表合并与对比 1 我上传了3份不同月份的销售数据Excel，帮我：1）先检查各文件的字段是否一致，不一致的话列出差异和你的合并方案，等我确认后再执行；2）合并成一张总表，新增\u0026#34;月份\u0026#34;列标注每行数据的来源月份；3）计算每个月的核心指标（总销售额、订单数、客单价）；4）做环比对比分析。输出两个文件：合并后的Excel总表 + Word分析报告，报告结论部分指出增长趋势和下滑风险。 使用方式：依次上传3份Excel，或者一起拖进去，然后发指令。\n要点：多表合并最容易翻车的地方是字段不一致——这个月的表叫“销售额”，上个月的叫“成交金额”，直接合并数据就串了。“先检查字段、确认后执行”这一步就是防这个的。另外明确说了要“两个文件”，总表和报告都会交付，不会只给你一份报告完事。\n四、PPT 与演示类（模板10-11） 10. 汇报 PPT 1 帮我做一份10页的项目汇报PPT，主题是\u0026#34;新产品上线复盘\u0026#34;。结构：第1页封面标题、第2页项目概述、第3-5页三项核心成果（每页一个成果，附数据）、第6-7页遇到的问题和解决方案、第8页下一步计划、第9页总结、第10页致谢。每页只放3-5个要点，不要大段文字；上传材料里没有的数据用【需补充数据】标注，不要编造。风格简洁商务，色调偏蓝，PPT格式输出。 要点：给了明确的页数和每页内容安排。“10页”这个约束防止 AI 做出20页的PPT——信息密度太低，领导看不下去。“每页3-5个要点”防的是另一个经典错误：把 Word 段落原样搬进幻灯片，做出来的不是 PPT，是文档截图。\n11. 方案 PPT 1 根据上传的方案文档，帮我做成一份8页的PPT。每页只表达一个核心观点，内容从文档中提炼，保持原文核心观点，但文字要精简为PPT风格（短句、要点式、少长段落）。封面用方案标题，最后一页放行动建议。风格专业简洁，PPT格式输出。 使用方式：先上传方案文档，再发指令。这条的核心约束是“每页一个观点 + PPT风格”——文档转 PPT 的本质不是换格式，是重组表达。\n五、文件处理类（模板12-14） AI调研与内容创作：事实、来源、判断分开写 12. 文件分类整理 1 帮我整理这个文件夹里的文件：【替换成你的文件夹路径，比如 D:\\工作文件 或 ~/Desktop/待整理】。按类型分类：文档类（Word/PDF/TXT）放入\u0026#34;文档\u0026#34;子文件夹，表格类（Excel/CSV）放入\u0026#34;数据\u0026#34;子文件夹，图片类（JPG/PNG）放入\u0026#34;图片\u0026#34;子文件夹，演示类（PPT）放入\u0026#34;演示\u0026#34;子文件夹，其他类型放入\u0026#34;其他\u0026#34;子文件夹。子文件夹不存在就先创建。操作前先列出分类计划和将要移动的文件清单，等我确认后再执行；只移动，不删除任何文件。 要点：三个关键点。一是给出明确的文件夹路径——“桌面”在不同电脑上位置不同，写清路径 AI 才能准确定位。二是“先列计划、确认后执行”——相当于在 Plan 模式下先审阅再动手，防止误归类。三是“只移动，不删除”——文件操作必须保守，这条底线约束什么时候都不多余。对分类方案满意后，在对话里回复“确认执行”就行。\n13. 批量格式转换 1 把我上传的这5份Word文档全部转换成PDF格式，文件名保持不变只改后缀。转换完成后把5份PDF一起输出给我，并列出每个文件的转换状态；如果有转换失败的文件，说明失败原因。 使用方式：一次性拖入5份 Word 文件，发指令。这个模板适合任何批量转换场景——PDF转Word、图片转指定格式，只需要替换文件类型关键词。注意：上传的文件是在 WorkBuddy 的工作环境里处理的，所以指令要写“输出给我”，而不是“保存在原目录”——原目录在你电脑上，它够不着。“逐个报告状态”这条也别省：批量任务偶尔会有个别文件失败（加密文档、格式损坏），不报状态你根本不知道少了一份。\n14. 文件内容提取 1 从这份PDF合同中提取关键信息，整理成一份结构化表格，包含：合同编号、签约方名称、签约日期、合同金额、有效期、付款方式、关键条款摘要（不超过5条）。只提取合同原文中明确出现的信息，原文没有的字段填\u0026#34;未提及\u0026#34;；只做信息整理，不做法律判断。表格用Excel格式输出。 使用方式：上传 PDF 后发指令。这条指令的核心价值是把非结构化的合同文本变成结构化的表格——一眼看清所有关键条款，不用从头翻到尾。“只提取、不判断”这条约束在合同场景里尤其重要：你要的是台账，不是 AI 的“法律意见”，条款有没有风险应该交给专业的人看。\n六、调研与研究类（模板15-17） 15. 行业快速调研 1 帮我调研2026年上半年中国AI算力行业的最新动态，重点关注：1）主要厂商的产品发布和定价变化；2）市场规模和增速数据；3）政策动向。输出一份调研摘要，不超过2000字，每个观点附信息来源，并区分\u0026#34;已确认事实\u0026#34;和\u0026#34;趋势判断\u0026#34;，没有来源的数据不要用。Word格式输出。 要点：这条指令用了 WorkBuddy 的联网搜索能力。“附信息来源”让产出可追溯——你能知道哪个数据来自哪篇文章，方便二次核实。“区分事实和判断”是更进一步的要求：调研摘要里最危险的内容，就是把某个分析师的预测当成既定事实写出来。\n16. 竞品对比分析 1 帮我做一份竞品对比分析，对比对象是【产品A】、【产品B】和【产品C】（替换成实际产品名；如果竞品背景信息比较多，也可以整理成文档上传）。对比维度：核心功能、定价模式、目标用户、市场口碑、差异化优势。涉及价格、版本、功能的信息要标注来源和时间，不确定的标注\u0026#34;需进一步核实\u0026#34;。输出格式：对比表格（Excel）+ 分析结论（Word，指出各自优劣，给出推荐选择并写清推荐的前提条件）。 使用方式：直接在指令里写明产品名称，WorkBuddy 会联网搜索补充信息，再整合对比。如果你手上有内部整理的竞品资料，上传后对比会更精准。\n要点：“价格标注时间”和“推荐写清前提”是两个容易忽略的细节。产品定价随时在变，一份没有时间戳的对比表过两个月就是误导；而“推荐B产品”和“预算有限、团队小于10人的情况下推荐B产品”，是两种完全不同的结论质量。\n17. 深度研究报告 1 对\u0026#34;大模型推理成本优化\u0026#34;这个主题做一份深度研究报告，要求：1）定义问题背景和核心概念；2）梳理当前主流的3-5种优化方案及其原理；3）对比各方案的效果数据和适用场景；4）给出趋势判断和行动建议。报告要数据支撑、逻辑严密、附来源引用，专业术语第一次出现时给出解释。先输出报告大纲，等我确认后再写全文。Word格式输出，3000字左右。 要点：这是最复杂的一类指令——多步骤、有深度要求、有结构要求。“先出大纲、确认后写全文”这一步值回票价：3000字的报告方向跑偏了，返工成本很高；大纲阶段纠偏，只需要改几行字。配合 Plan 模式使用效果更好。这类任务耗时较长（通常3-5分钟），但产出质量远高于简单搜索。\n七、写作与内容类（模板18-20） 18. 公众号文章 1 帮我写一篇微信公众号文章，主题是\u0026#34;XXX\u0026#34;，要求：先给出3个备选标题；正文挑3-5个和目标读者最相关的要点，每个要点配具体案例或数据，参考刘润公众号的写作风格（短段落、小标题分层、数据支撑观点）；不要用\u0026#34;彻底改变\u0026#34;\u0026#34;颠覆行业\u0026#34;这类空话。总篇幅3000字左右，写完发布到我的公众号草稿箱。 要点：这条指令把上一篇的核心实战经验浓缩进去了——目标、约束（3-5个要点）、风格（参考刘润）、动作（发布到草稿箱）。“3个备选标题”是新增的实用项：公众号打开率一半靠标题，多要几个备选比自己憋强。“写完发布到草稿箱”是 WorkBuddy 独有的能力，普通 AI 写完只给你一段文字，这里交付的是一个已经躺在公众号后台的成品——注意是草稿箱不是直接群发，所以这个动作是安全的，最终发不发还是你说了算。\n19. 产品文案 1 为一款XXX产品写一组营销文案。产品信息：目标用户是XXX，核心功能是XXX，主要优势是XXX。输出包含：1）一句话定位语（不超过20字）；2）50字产品简介；3）3条核心卖点（每条不超过20字）；4）1条100字的使用场景描述。语气有感染力但不夸张，不用\u0026#34;行业领先\u0026#34;\u0026#34;颠覆式创新\u0026#34;这类空泛表述，卖点写具体收益（比如省多少时间、降低什么门槛）。 要点：两处升级。一是指令开头补了一段产品信息——不给这些，AI 只能对着产品名瞎猜卖点；二是“卖点写具体收益”这条约束，让文案从“喊口号”变成“说清楚价值”。字数约束依然是灵魂：定位语、简介、卖点各多少字全部量化，防止 AI 写出一篇500字的“简介”来。\n20. 知识科普 1 帮我写一篇面向普通读者的科普文章，主题是\u0026#34;XXX\u0026#34;，要求：用类比和日常场景来解释核心概念，避免专业术语堆砌，必须用术语时第一次出现要解释；关键数据要联网核实并标注来源；结构按\u0026#34;是什么→为什么重要→怎么理解→一个实际例子\u0026#34;展开，总篇幅1500字左右，Word格式输出。 要点：“避免专业术语堆砌”“用类比和日常场景”——这两条约束让 AI 写出每个人能看懂的内容，而不是一篇只有同行才看得懂的论文。“联网核实并标注来源”则是给数据上保险：科普文里一个错误数字被读者揪出来，比整篇写得平庸伤害大得多。\n八、通用技巧：让指令更好用的四个调整 模板是起点。实际用的时候，你大概率要根据具体情况调整。四个最有效的调整方向：\n1. 加上传文件。 模板里很多指令可以纯文字驱动，但加上一份真实素材，产出质量直接跳一个档次。“帮我写周报”生成模板，“根据这份文档帮我写周报”生成成品——区别就在有没有输入。\n2. 加语气约束。 “语气正式”“语气亲切”“语气客观”“有感染力但不夸张”——一条语气约束，能让同一段内容读起来完全不同。不加这条，AI 默认写什么都像教科书。\n3. 加量化约束。 “不超过5条”“每条不超过20字”“环比波动超过10%”“3000字左右”——量化约束是让 AI 产出可控的核心手段。没有量化，它大概率给你“很多条”“很长”“很全面”，但这通常不是你要的。\n4. 加安全约束。 凡是涉及事实、数据的任务（汇报、分析、调研、合同提取），统一加这句：\n1 原始材料中没有出现的数据、事实和结论不要编造；缺少信息的地方用【待补充】或【需人工确认】标注。 凡是涉及文件操作的任务（整理、移动、转换、改名），统一加这句：\n1 操作前先列出处理计划和将要操作的文件清单，等我确认后再执行；不要删除或覆盖任何文件。 这两句话可以无脑加。前一句防 AI 编数据，后一句防误操作——都是那种“平时感觉不到、出事就是大事”的保险。\n九、一个反面教材 模糊指令和精准指令的产出差异 对比一下这两条指令的产出差异：\n模糊版：“帮我分析一下这份销售数据。”\n这条指令的问题是：没说分析什么指标、没说要不要图表、没说输出什么格式、没说结论要回答什么问题、没说缺数据时怎么办。AI 只能全靠猜，大概率给你一段泛泛的文字描述。\n精准版：“分析这份Excel销售数据，按产品类别汇总销售额和销量，计算环比增长率，找出销售额Top5的产品，生成一份Word分析报告，结论给出增长和下滑判断，缺少的数据不要编造。”\n精准版产出一份结构化的 Word 报告，有汇总表、有排名、有结论，缺数据的地方明确标出来。\n差距不是 AI 的能力不够，是你没告诉它你要什么。\n小结 20个模板，按场景分五类：\n类别 模板编号 覆盖场景 文档写作 1-5 周报、会议纪要、邮件、汇报、润色 数据分析 6-9 Excel分析、可视化图表、报表、多表合并 PPT与演示 10-11 汇报PPT、方案PPT 文件处理 12-14 分类整理、格式转换、内容提取 调研研究 15-17 行业调研、竞品分析、深度报告 写作内容 18-20 公众号文章、产品文案、知识科普 实际使用的顺序建议是：先找到和你任务最接近的模板 → 替换主题、文件和输出格式 → 根据任务风险加上“不要编造”“确认后执行” → 复杂任务先让它出大纲或计划，确认方向后再生成最终文件。\n每个模板踩准了四要素公式（目标+输入+输出格式+约束），可以直接复制使用。用到熟练之后，你会发现自己写指令的速度越来越快——因为公式已经内化了，你只需要填内容。\n下一篇，我们进入第一个专业场景：数据分析零门槛——用WorkBuddy 读表格、清洗数据、出可视化图表，全程不用写一个公式。\nWorkBuddy 实战手册 · 第3篇预告：《数据分析零门槛：用 WorkBuddy 读表格、清洗数据、出图表》\n电脑端下载地址：https://www.codebuddy.cn/work/\n手机端：应用市场搜“WorkBuddy”\n微信小程序：搜“腾讯WorkBuddy”\n","permalink":"https://blog.onecai.site/2026/07/05/033-workbuddy-01-02/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy 实战手册 · 第2篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e上一篇里，我提到一个心法：\u003cstrong\u003e把你脑子里那套隐性标准，翻译成显性约束。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e“帮我写个报告”——隐性标准是“我想要一份看起来靠谱的、领导能看的报告”，但 AI 读不懂“靠谱”和“能看”。它只认你写出来的东西：格式、语气、篇幅、结构、约束。说白了，一条好指令要回答四个问题：\u003cstrong\u003e做什么、基于什么做、交付什么、不能怎么做。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这篇就把那个心法落地。20个指令模板，覆盖最常见的办公场景，每个都能直接复制到 WorkBuddy 的输入框里用。用完之后你会理解一个规律：\u003cstrong\u003e好指令不是写得多，而是写得准。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"写在前面的\"\u003e写在前面的\u003c/h2\u003e\n\u003cp\u003eAI 工具多到挑不过来，但有一个问题很少有人提：怎么才能让 AI 替你干活，而不是替自己发挥？\u003c/p\u003e\n\u003cp\u003e答案很简单——你得把它当“自己人”。把你的素材、数据、文档喂给它，它才能用你的东西干你的活。否则它就只能凭自己的理解去猜，猜出来的东西看着像，但不是你的。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 解决这个问题的方式很直接：\u003cstrong\u003e连接器。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在对话框里，通过连接器打通你的工作生态——腾讯文档、钉钉、腾讯会议、IMA 知识库（这个后面会专门讲）、QQ 邮箱、飞书、企业微信、Notion、GitHub……你的素材在哪里，它就连接哪里。甚至可以自定义连接器，对接你自己的系统。\u003c/p\u003e\n\u003cp\u003e连接好了之后，AI 读的是你的数据，用的是你的素材，产出的结果自然也是你的——不再是一份“看起来还行但和我没关系”的通用内容，而是一份带着你的真实信息、你的业务语境的成品。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e把数据喂进去，AI 才能真正替你干活。这步不做，后面的所有技巧都白搭。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"一指令公式四要素拆解\"\u003e一、指令公式：四要素拆解\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"workbuddy-prompts-1.avif\"\n          alt=\"好指令的四要素：目标、输入、输出格式、约束\"/\u003e \u003cfigcaption\u003e\n             好指令的四要素：目标、输入、输出格式、约束\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e先记住一个公式，后面所有模板都踩着它走：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e目标 + 输入 + 输出格式 + 约束\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e要素\u003c/th\u003e\n          \u003cth\u003e含义\u003c/th\u003e\n          \u003cth\u003e示例\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e目标\u003c/td\u003e\n          \u003ctd\u003e你要它做什么\u003c/td\u003e\n          \u003ctd\u003e写一份周报\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e输入\u003c/td\u003e\n          \u003ctd\u003e它基于什么材料来做\u003c/td\u003e\n          \u003ctd\u003e上传的项目进展文档\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e输出格式\u003c/td\u003e\n          \u003ctd\u003e你想要什么格式的结果\u003c/td\u003e\n          \u003ctd\u003eWord / Excel / PPT\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e约束\u003c/td\u003e\n          \u003ctd\u003e风格、篇幅、语气、限制\u003c/td\u003e\n          \u003ctd\u003e语气正式，不超过1500字，不要编造数据\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e四要素不全，产出必打折。少了“输出格式”，它可能只给你一段纯文字，而不是你想要的 Word 或 Excel 文件。少了“执行约束”，语气、篇幅、结构就会变成 AI 自己猜。\u003c/p\u003e\n\u003cp\u003e下面的20个模板，每一个都踩准了这四个要素。你可以直接用，也可以根据自己的实际情况替换其中的关键词。\u003c/p\u003e\n\u003ch2 id=\"二文档写作类模板1-5\"\u003e二、文档写作类（模板1-5）\u003c/h2\u003e\n\u003ch3 id=\"1-项目周报\"\u003e1. 项目周报\u003c/h3\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e根据我上传的本周工作记录，帮我写一份项目周报，包含三个部分：本周工作总结（列出3项已完成的关键任务及成果）、下周工作计划（列出2项重点工作及预期目标）、需要协调的事项（1项，附建议解决方案）。语气正式，适合发给领导看，突出结果和进展，不要写成流水账，Word格式输出。\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e\u003cstrong\u003e产出\u003c/strong\u003e：一份结构完整的 Word 周报，三个板块都有标题和内容。\u003c/p\u003e","title":"Prompt实战手册：20个可以直接复制的WorkBuddy指令模板"},{"content":" WorkBuddy 实战手册 · 第1篇\n我见过太多人下载了 WorkBuddy，打开，盯着空白界面看了 30 秒，关掉。\n这不怪你。大部分 AI 工具的问题不在功能，而在入口：你知道它能干活，但不知道第一步该干什么。\n这篇就是那个入口。从下载安装到让它交出第一份 Word 周报，实测 10 分钟。跟着做就行。\n一、下载安装：电脑端认准官网 WorkBuddy 从下载安装到第一次可用的 5 步流程 WorkBuddy 有电脑端和手机端。电脑端是完整功能的载体——文件操作、多任务并行、代码开发这些核心能力全在桌面版。手机端定位是移动指挥所，不依赖电脑也能派任务（后面会专门讲）。\n电脑端：必须去官网下载。\nhttps://www.codebuddy.cn/work/\n页面会自动识别你的操作系统，提供 Windows 和 macOS 两个版本。下载后双击安装包，一路下一步。系统要求不高：Windows 10 及以上，macOS 12 及以上，建议 8GB 内存，安装包约 500MB。\n为什么强调官网？因为桌面端涉及本地文件读写权限，非官方渠道的安装包有安全风险。codebuddy.cn/work 是唯一可信的下载入口。\n手机端：应用市场搜“WorkBuddy”。\nApp Store 或各大安卓应用商店直接搜。微信里还有小程序“腾讯WorkBuddy”，不装 App 也能用——云端模式不依赖电脑，本机模式远程连接桌面端。\n二、登录与授权：两分钟搞定 AI工具只读取被授权的文件夹 打开后第一步是登录。支持微信扫码和手机号两种方式，建议用微信——后续联动腾讯文档、小程序更方便。\n登录后，系统会提示你授权文件夹。很多人在这一步犹豫：让 AI 读我的文件，安全吗？\n两句话说清：WorkBuddy 只能读取你明确授权的文件夹，不会碰任何未授权的内容。 只授权你实际需要它处理的目录——桌面和文档文件夹就够了。不需要全盘授权，也不建议全盘授权。\n授权完成，进入主界面。\n三、界面认识：三个区域，各管各的事 WorkBuddy 的界面只有三个区域：\n区域 位置 干什么 左侧栏 左边 任务列表和历史记录，底部是头像和设置入口 对话区 中间 输入需求、和 AI 对话、上传文件 结果区 右边 查看生成的文件、代码、预览 第一次打开，对话区是空的。别慌，这就是你接下来要填的地方。\n对话区上方有三个场景标签：日常办公、代码开发、设计创意。点进去是一堆常用任务模板——写周报、做 PPT、数据分析、网站开发。不知道怎么下指令的时候，先抄模板，再按自己的需求改，很快就有感觉。\n四、选择模式：三种权限，按需切换 Ask、Plan、Craft 三种 AI 执行模式的区别 输入框下方有三个模式按钮：Ask（问一问）、Craft（做一做）、Plan（想一想）。这决定了 WorkBuddy 的执行权限：\n模式 权限 适合场景 一句话理解 Ask 只读，不碰文件 查资料、问问题 当顾问用 Plan 只读，先出方案 复杂任务、需要审阅改动范围 先看方案再拍板 Craft 读写，直接执行 文档生成、数据处理、文件整理 直接干活 新手建议：简单问答选 Ask（最省积分），让它做事选 Craft（权限全开，效率最高），大量文件操作或结果不确定时选 Plan（先审再执行，避免误操作）。\n第一次用 Craft 时会弹一个权限说明，点确认就行。这不是“警告”，是“告知”——告诉你它这回会读写文件了，心里有数就好。\n五、第一个任务：写一份周报 一句话需求如何变成一份 Word 周报 界面看完，别急着研究功能，先动手跑一个任务。\n在输入框里打这一句：\n“帮我写一份部门周报模板，包含本周工作总结、下周工作计划、需要协调事项三个部分，用 Word 格式输出。”\n回车。\n你会看到 WorkBuddy 先“思考”几秒——它不是拿到指令就动笔，而是先拆解：理解需求 → 确定结构 → 生成内容 → 输出文件。整个规划过程在对话区实时显示。\n大概十几秒后，右侧结果区出现一个 .docx 文件。点开直接预览：三个板块的标题、正文框架、占位内容都已填好。下载到本地，替换占位内容就能用。\n这就是一个完整的任务闭环：一句话 → 思考 → 执行 → 交付文件。\n没有复杂操作，没有手动调格式。你只负责说需求，它负责交结果。\n六、进阶一步：让它读你的真实数据 模板只是起步。WorkBuddy 的真正价值在于它能操作你的本地文件——读取授权文件夹里的真实数据，基于这些数据生成内容。\n试一下：把一份本周的项目进展文档（Word 或 TXT）拖进输入框，然后说：\n“根据这份文档，帮我写一份正式的周报，总结本周进展，列出下周计划，格式和语气适合发给领导看，Word 格式输出。”\n它会先读取文档、提取关键信息，再按你的格式和语气要求组织成周报。不再是模板，而是基于真实数据的成品。\n这个能力是 WorkBuddy 和普通 AI 聊天工具的分水岭：后者只能凭空写，前者能从你的真实素材中提炼。\n上传方式：直接拖拽，或点附件按钮。支持 Word、Excel、PDF、图片、代码文件等常见格式。\n七、三个让后续更顺的细节 模型切换。 左下角头像 → 设置里可以换模型：写中文文档、整理纪要用混元；数据分析、生成 PPT 用 MiniMax（响应快）；技术分析和深度推理用 DeepSeek（逻辑严密）。不切也行，系统会自动匹配，但主动选往往产出更精准。\n任务可以继续，不用重开。 生成周报后想改某部分，直接在同一个对话里说“把\u0026rsquo;需要协调事项\u0026rsquo;扩展一下，加上截止日期”，它会基于当前上下文继续改，不会从头来。\n历史任务在左侧栏。 所有任务按文件夹分组存着，想找之前生成的报告，左侧栏搜索就行，不用翻本地文件夹。生成文件后结果区还有“产物 / 全部文件 / 变更 / 预览”四个标签，简单任务看“产物”就够。\n八、新手最容易踩的三个坑 指令太模糊。 “帮我写个报告”和“帮我写一份项目进展周报，包含本周三个里程碑的完成状态、下周两项重点工作、需要领导协调的一个问题，语气正式”——后者产出质量远高于前者。给 AI 下指令的核心心法就一条： 把你脑子里那套隐性标准，翻译成显性约束。\n全盘授权文件夹。 没必要，也不安全。只授权实际需要处理的目录。\nCraft 模式直接动重要文件。 要改重要合同或不可替换的原始数据？先备份，或者用 Plan 模式先看方案再执行。\n小结 从下载到跑通第一个任务，完整路径五步：\n官网下载安装 → 2. 微信扫码登录 → 3. 授权桌面/文档文件夹 → 4. 选 Craft 模式 → 5. 说一句“帮我写周报” 10分钟，够了。\n下一篇，我会给出 20 个可以直接复制的 WorkBuddy 指令模板——覆盖周报、邮件、数据分析、PPT、文件整理五大办公场景，即抄即用。\n如果这篇帮你省了摸索的时间，点个“在看”，让更多刚下载就关掉的人看到这个入口。想第一时间收到第2篇，星标本号——不星标，推送大概率会沉底。\n你在 WorkBuddy 里跑的第一个任务是什么？评论区聊聊，我挑几个典型场景写进下一篇。\nWorkBuddy 实战手册 · 第2篇预告：《Prompt 实战手册：20个可以直接复制的指令模板》\n电脑端下载地址：https://www.codebuddy.cn/work/\n手机端：应用市场搜“WorkBuddy”\n微信小程序：搜“腾讯WorkBuddy”\n","permalink":"https://blog.onecai.site/2026/07/04/032-workbuddy-01-01/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eWorkBuddy 实战手册 · 第1篇\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e我见过太多人下载了 WorkBuddy，打开，盯着空白界面看了 30 秒，关掉。\u003c/p\u003e\n\u003cp\u003e这不怪你。大部分 AI 工具的问题不在功能，而在入口：你知道它能干活，但不知道第一步该干什么。\u003c/p\u003e\n\u003cp\u003e这篇就是那个入口。从下载安装到让它交出第一份 Word 周报，实测 10 分钟。跟着做就行。\u003c/p\u003e\n\u003ch2 id=\"一下载安装电脑端认准官网\"\u003e一、下载安装：电脑端认准官网\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"WorkBuddy-01-1.avif\"\n          alt=\"WorkBuddy 从下载安装到第一次可用的 5 步流程\"/\u003e \u003cfigcaption\u003e\n             WorkBuddy 从下载安装到第一次可用的 5 步流程\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003eWorkBuddy 有电脑端和手机端。电脑端是完整功能的载体——文件操作、多任务并行、代码开发这些核心能力全在桌面版。手机端定位是移动指挥所，不依赖电脑也能派任务（后面会专门讲）。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e电脑端：必须去官网下载。\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://www.codebuddy.cn/work/\"\u003ehttps://www.codebuddy.cn/work/\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e页面会自动识别你的操作系统，提供 Windows 和 macOS 两个版本。下载后双击安装包，一路下一步。系统要求不高：Windows 10 及以上，macOS 12 及以上，建议 8GB 内存，安装包约 500MB。\u003c/p\u003e\n\u003cp\u003e为什么强调官网？因为桌面端涉及本地文件读写权限，非官方渠道的安装包有安全风险。\u003ccode\u003ecodebuddy.cn/work\u003c/code\u003e 是唯一可信的下载入口。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e手机端：应用市场搜“WorkBuddy”。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eApp Store 或各大安卓应用商店直接搜。微信里还有小程序“腾讯WorkBuddy”，不装 App 也能用——云端模式不依赖电脑，本机模式远程连接桌面端。\u003c/p\u003e\n\u003ch2 id=\"二登录与授权两分钟搞定\"\u003e二、登录与授权：两分钟搞定\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"WorkBuddy-01-2.avif\"\n          alt=\"AI工具只读取被授权的文件夹\"/\u003e \u003cfigcaption\u003e\n             AI工具只读取被授权的文件夹\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e打开后第一步是登录。支持微信扫码和手机号两种方式，建议用微信——后续联动腾讯文档、小程序更方便。\u003c/p\u003e\n\u003cp\u003e登录后，系统会提示你授权文件夹。很多人在这一步犹豫：让 AI 读我的文件，安全吗？\u003c/p\u003e\n\u003cp\u003e两句话说清：\u003cstrong\u003eWorkBuddy 只能读取你明确授权的文件夹，不会碰任何未授权的内容。\u003c/strong\u003e 只授权你实际需要它处理的目录——桌面和文档文件夹就够了。不需要全盘授权，也不建议全盘授权。\u003c/p\u003e\n\u003cp\u003e授权完成，进入主界面。\u003c/p\u003e\n\u003ch2 id=\"三界面认识三个区域各管各的事\"\u003e三、界面认识：三个区域，各管各的事\u003c/h2\u003e\n\u003cp\u003eWorkBuddy 的界面只有三个区域：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e区域\u003c/th\u003e\n          \u003cth\u003e位置\u003c/th\u003e\n          \u003cth\u003e干什么\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e左侧栏\u003c/td\u003e\n          \u003ctd\u003e左边\u003c/td\u003e\n          \u003ctd\u003e任务列表和历史记录，底部是头像和设置入口\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e对话区\u003c/td\u003e\n          \u003ctd\u003e中间\u003c/td\u003e\n          \u003ctd\u003e输入需求、和 AI 对话、上传文件\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e结果区\u003c/td\u003e\n          \u003ctd\u003e右边\u003c/td\u003e\n          \u003ctd\u003e查看生成的文件、代码、预览\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e第一次打开，对话区是空的。别慌，这就是你接下来要填的地方。\u003c/p\u003e","title":"腾讯WorkBuddy上手实测：从下载到交出第一份周报，10分钟"},{"content":"前几天我试了一下 WorkBuddy，原本的想法很简单：看看它能不能替我写一篇公众号文章。\n试完之后，结论先放这儿：能写，但如果只把它当“写稿工具”，挺浪费的。\n真正让我觉得有用的，不是它替我写了几段正文，而是它把公众号写作前后那一串琐碎流程接了过去：查资料、搭结构、出初稿、写封面提示词、排版、存草稿。\n这篇文章就讲清楚三件事：它到底能干到哪一步，它的短板在哪，以及我以后会怎么用它。\n一、一个人做公众号，最累的不是写，是写之前 一个人做公众号，被一堆准备工作包围 一篇文章从想法到发布，中间有一长串不起眼的小动作：选题要想，资料要查，数据要核，结构要搭，正文要写，封面要配，后台要排版，最后还要预览手机效果。每一步单独看都不复杂，但全部压在一个人身上，就很容易拖延。\n我以前写一篇工具类文章，流程基本固定：想到题目，打开浏览器查资料。查完之后资料是散的——官网页面、新闻稿、价格表、别人写过的介绍，还有一些不确定是否准确的二手信息。要把这些重新整理成自己的结构，判断哪些能用、哪些要删、哪些需要再核实，然后才轮到真正写正文。\n写完也没完。还要想标题、配封面、调小标题、把文章贴进公众号后台一段一段检查格式。有时候文章明明写完了，就因为不想处理封面和排版，在草稿里一放好几天。\n公众号写作最消耗人的，从来不是“写几段文字”，而是从一个想法到一篇可发布文章之间那条长流程。\n特别是写 AI 工具、模型、算力、价格对比这类文章，前面的核对更烦。读者关心的是具体信息：价格多少，功能开没开放，国内能不能用，适合谁。只要有一个关键参数写错，整篇文章的可信度就塌了。\n这也是我这次想试 WorkBuddy 的原因。我不指望它一次生成一篇完美文章，我想看的是：这条流程，它能帮我往前推多远。\n二、它不是聊天工具，是能跑流程的桌面助理 WorkBuddy 和普通 AI 聊天工具不太一样。\n普通 AI 工具是“你问我答”：让它写一段话，它给你一段话；让它列大纲，它列大纲。有用，但后面的动作还得你自己做——开网页、查资料、整理文件、贴到后台、排版、存草稿。\nWorkBuddy 更像一个桌面助理。它的特点不是单次回答多漂亮，而是能把任务拆开，然后一步一步执行。 它能打开浏览器查资料，能读你指定的本地文件，还能把整理结果放进文档里。\n对公众号写作来说，这比“写一段更好看的文字”实用得多，因为公众号不是单点任务，是一串任务。哪怕它生成的第一版不完美，只要能把空白页变成一个有结构、有素材、有配图思路的草稿，对个人创作者来说就已经省了不少时间。\n先把丑话说在前面：它不是那种“输入一句话，直接给你一篇可以群发的文章”的工具。至少以我这次的体验看，还不能这么用。它适合干前期和中间环节的活，最后那一遍判断和修改，还是得自己个来。\n三、实测：让它写一篇“AI 工具速递” 这次我选的测试任务，是一篇“AI 新工具速递”类公众号文章。\nWorkBuddy 把公众号写作流程往前推进 这类文章看着不复杂，写起来挺麻烦。它不是纯观点文，不能只写“这个工具很强”“哪个很适合创作者”，你得知道每个工具最近更新了什么、发布时间、功能限制、价格变化、适合开发者还是内容创作者。\n所以我给 WorkBuddy 的指令不是一句“帮我写一篇 AI 工具文章”，而是说得很具体：\n帮我写一篇 7 月 AI 新工具速递类公众号文章，挑 5 款和开发者、内容创作者相关的新品。每个工具都要写清楚发布时间、主要功能、价格或使用限制、适合人群，再加上我的判断。写完后生成封面图提示词，并整理成适合微信公众号排版的格式。\n后面我又补了一句：\n保存到公众号草稿箱，不要发布。\n这句话很关键。AI 可以帮你写、帮你排版、帮你存草稿，但发布按钮最好还是自己点。 文章一旦发出去，标题有没有夸张、数据有没有错、图片有没有版权问题，最后都算在作者头上。AI 可以替你干活，不能替你承担发布责任。\nWorkBuddy 接到任务后，没有直接开写，而是先把任务拆开：先查资料，再把不同工具的信息整理出来，然后才生成文章结构。这比直接让聊天工具硬写一篇要稳，因为它至少先做了资料准备。\n当然，资料准备不等于完全准确。价格、发布时间、功能开放范围这些细节，还是要自己再核一遍。\n四、最省时间的三件事：资料、大纲、配图提示词 这次试下来，我觉得它最有用的地方有三个，都不在正文。\n第一，资料整理。\n工具类文章最怕信息散：功能说明在官网，价格在另一个页面，更新记录在博客或公告里，别人的介绍又夹着不少二手理解。手动整理的结果往往是浏览器标签页越开越多，写文章的精力先被消耗光了。\nWorkBuddy 可以把这些信息按固定结构先整理出来：这个工具是什么、更新了什么、适合谁、限制在哪。整理出来的内容不一定能直接进文章，但至少让素材从“散乱网页”变成了“可处理材料”。\n第二，搭大纲。\n写文章经常在结构上花时间：先讲什么后讲什么，哪些放前面吸引读者，哪些放后面做判断。它给的第一版大纲不一定符合个人的表达习惯，但有了框架再删改，比从空白文档开始轻松太多。\n第三，配图提示词。\n写 AI、算力、本地模型这类文章，经常需要横版封面和正文插图。图不能太花，不能像广告，不能出现真实品牌 Logo。WorkBuddy 能根据文章内容生成图片提示词，比如：2.35:1 横版、极简写实科技风、不要人物、不要真实商标、右下角加 by OneCai。提示词一旦标准化，整个账号的配图风格就稳了。\n至于正文写作，反而是我最不看重的部分。它能写，但第一版通常要大改——完全采用 AI 初稿的工具文，很容易太完整、太平滑、太像产品介绍。读者看一会儿就能感觉出来：这篇只是把公开资料重新整理了一遍。\n五、它的硬伤：初稿太“正确”，像总结不像经历 WorkBuddy 生成的初稿有一个典型问题：写得很稳、很完整，但太正确了。\n所谓太正确，就是每一段都像经过总结，每一节都很工整，每个观点后面都想升华一下。读起来没大错，但少了人写文章时的自然感。\n人写文章会有具体感受：这一步为什么烦，哪个环节让我意外，哪句话我不放心，哪个功能看着有用但还要再观察。这些东西不宏大，但它们让文章像一个真实的人写的。\nAI 初稿缺的就是这个。它很擅长写：\n这说明 AI 正在改变内容生产方式。\n但它不会自然地写：\n我原本只是想让它列个大纲，结果它把封面提示词也一起整理出来了，这一步比我预期中省事。\n前者像总结，后者像经历。读者要看的是后者。\n所以用 WorkBuddy 写公众号，一定要把初稿当“材料”，不能当“终稿”。它负责把内容摊开，作者负责把不像自己的地方删掉，把真实体验补进去，把说太满的判断压回去。\n特别是那些看起来漂亮但没有支撑的句子，直接删。比如“这不是一次普通的工具升级，而是生产力方式的重构”——前面没有足够事实撑着，这种话就是空的。公众号文章不怕朴素，怕的是空泛。\n六、如果长期用，我会这样拆任务 以后继续用 WorkBuddy，我不会一上来就让它写整篇文章，而是拆成五步：\n第一步，整理选题。 围绕我想写的方向（AI 工具、模型价格、本地部署、智能体工作流）先列 10 个选题，每个说清楚：适合谁看、为什么值得写、需要查哪些资料。先判断哪个题有价值，再进入具体写作。\n第二步，做资料表。 写 token 价格对比，就让它整理各平台的输入输出价格、上下文长度、免费额度；写本地模型，就整理模型大小、显存需求、推理速度。资料先变成表格，文章才好写。\n第三步，生成初稿。 这一步要明确告诉它：不要写成产品宣传稿，不要过度拔高，不要每节都总结。即便如此初稿也必须改，但至少材料排好了，结构搭出来了。\n第四步，生成封面和插图提示词。 封面负责让读者点进来，插图负责解释概念。统一的提示词规范能让整个账号的图看起来是一套的，而不是每篇换一种风格。\n第五步，排版和存草稿。 段落空行、小标题、重点加粗、插图位置、保存草稿——这些本来就是重复劳动，交给它先处理一遍，我再检查，比全手动省事得多。\n七、结论：它是助理，不是作者 AI适合做助理，人仍然是作者 试完这一轮，我对 WorkBuddy 的定位很明确了：\n它适合做公众号助理，不适合做公众号作者。\n助理的意思是，它能处理执行性工作：查资料、整理素材、搭大纲、出初稿、写配图提示词、排版、存草稿。它让你更快从“有一个想法”走到“有一篇可以改的草稿”。\n但作者该做的事，它替不了：这个题值不值得写，文章站在什么角度，哪些信息必须核实，哪些判断不能说太满，哪些地方要加自己的经验。\n尤其是个人公众号，最重要的不是把信息写全，而是让读者知道：这是你怎么看的。 读者关注一个账号，不只是为了看资料，是为了看这个作者怎么筛选、怎么判断、怎么表达。\n所以我现在对它的期待反而更现实了：不需要它写出完美文章，只要它把资料查好、结构搭好、封面提示词写好、草稿放进后台，我就已经省下了大量精力。\n最后那一遍，还是要自己来。标题要不要改，观点要不要收，哪些句子太像 AI，哪里要补自己的经历——这些都不能省。\nAI 工具的价值不是让你不用写文章，而是让你少被杂活拖住。 把脏活、累活、重复活交出去，你才有时间回答真正重要的三个问题：\n这个题值不值得写。\n这个判断站不站得住。\n这篇文章有没有自己的味道。\n这三个问题想不清楚，再强的 AI 也只是帮你更快写出一篇普通文章。\n你现在写东西的时候，会把哪一步交给 AI？是查资料、写初稿，还是排版？欢迎留言聊聊你的分工方式。\n","permalink":"https://blog.onecai.site/2026/07/03/031-workbuddy-wechat-article/","summary":"\u003cp\u003e前几天我试了一下 WorkBuddy，原本的想法很简单：看看它能不能替我写一篇公众号文章。\u003c/p\u003e\n\u003cp\u003e试完之后，结论先放这儿：\u003cstrong\u003e能写，但如果只把它当“写稿工具”，挺浪费的。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e真正让我觉得有用的，不是它替我写了几段正文，而是它把公众号写作前后那一串琐碎流程接了过去：查资料、搭结构、出初稿、写封面提示词、排版、存草稿。\u003c/p\u003e\n\u003cp\u003e这篇文章就讲清楚三件事：它到底能干到哪一步，它的短板在哪，以及我以后会怎么用它。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一一个人做公众号最累的不是写是写之前\"\u003e一、一个人做公众号，最累的不是写，是写之前\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"WorkBuddy-1.avif\"\n         alt=\"一个人做公众号，被一堆准备工作包围\"/\u003e \u003cfigcaption\u003e\n            一个人做公众号，被一堆准备工作包围\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e一篇文章从想法到发布，中间有一长串不起眼的小动作：选题要想，资料要查，数据要核，结构要搭，正文要写，封面要配，后台要排版，最后还要预览手机效果。每一步单独看都不复杂，但全部压在一个人身上，就很容易拖延。\u003c/p\u003e\n\u003cp\u003e我以前写一篇工具类文章，流程基本固定：想到题目，打开浏览器查资料。查完之后资料是散的——官网页面、新闻稿、价格表、别人写过的介绍，还有一些不确定是否准确的二手信息。要把这些重新整理成自己的结构，判断哪些能用、哪些要删、哪些需要再核实，然后才轮到真正写正文。\u003c/p\u003e\n\u003cp\u003e写完也没完。还要想标题、配封面、调小标题、把文章贴进公众号后台一段一段检查格式。有时候文章明明写完了，就因为不想处理封面和排版，在草稿里一放好几天。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e公众号写作最消耗人的，从来不是“写几段文字”，而是从一个想法到一篇可发布文章之间那条长流程。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e特别是写 AI 工具、模型、算力、价格对比这类文章，前面的核对更烦。读者关心的是具体信息：价格多少，功能开没开放，国内能不能用，适合谁。只要有一个关键参数写错，整篇文章的可信度就塌了。\u003c/p\u003e\n\u003cp\u003e这也是我这次想试 WorkBuddy 的原因。我不指望它一次生成一篇完美文章，我想看的是：这条流程，它能帮我往前推多远。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"二它不是聊天工具是能跑流程的桌面助理\"\u003e二、它不是聊天工具，是能跑流程的桌面助理\u003c/h2\u003e\n\u003cp\u003eWorkBuddy 和普通 AI 聊天工具不太一样。\u003c/p\u003e\n\u003cp\u003e普通 AI 工具是“你问我答”：让它写一段话，它给你一段话；让它列大纲，它列大纲。有用，但后面的动作还得你自己做——开网页、查资料、整理文件、贴到后台、排版、存草稿。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 更像一个桌面助理。\u003cstrong\u003e它的特点不是单次回答多漂亮，而是能把任务拆开，然后一步一步执行。\u003c/strong\u003e 它能打开浏览器查资料，能读你指定的本地文件，还能把整理结果放进文档里。\u003c/p\u003e\n\u003cp\u003e对公众号写作来说，这比“写一段更好看的文字”实用得多，因为公众号不是单点任务，是一串任务。哪怕它生成的第一版不完美，只要能把空白页变成一个有结构、有素材、有配图思路的草稿，对个人创作者来说就已经省了不少时间。\u003c/p\u003e\n\u003cp\u003e先把丑话说在前面：它不是那种“输入一句话，直接给你一篇可以群发的文章”的工具。至少以我这次的体验看，还不能这么用。它适合干前期和中间环节的活，最后那一遍判断和修改，还是得自己个来。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"三实测让它写一篇ai-工具速递\"\u003e三、实测：让它写一篇“AI 工具速递”\u003c/h2\u003e\n\u003cp\u003e这次我选的测试任务，是一篇“AI 新工具速递”类公众号文章。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"WorkBuddy-2.avif\"\n         alt=\"WorkBuddy 把公众号写作流程往前推进\"/\u003e \u003cfigcaption\u003e\n            WorkBuddy 把公众号写作流程往前推进\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e这类文章看着不复杂，写起来挺麻烦。它不是纯观点文，不能只写“这个工具很强”“哪个很适合创作者”，你得知道每个工具最近更新了什么、发布时间、功能限制、价格变化、适合开发者还是内容创作者。\u003c/p\u003e\n\u003cp\u003e所以我给 WorkBuddy 的指令不是一句“帮我写一篇 AI 工具文章”，而是说得很具体：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e帮我写一篇 7 月 AI 新工具速递类公众号文章，挑 5 款和开发者、内容创作者相关的新品。每个工具都要写清楚发布时间、主要功能、价格或使用限制、适合人群，再加上我的判断。写完后生成封面图提示词，并整理成适合微信公众号排版的格式。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e后面我又补了一句：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e保存到公众号草稿箱，不要发布。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这句话很关键。\u003cstrong\u003eAI 可以帮你写、帮你排版、帮你存草稿，但发布按钮最好还是自己点。\u003c/strong\u003e 文章一旦发出去，标题有没有夸张、数据有没有错、图片有没有版权问题，最后都算在作者头上。AI 可以替你干活，不能替你承担发布责任。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 接到任务后，没有直接开写，而是先把任务拆开：先查资料，再把不同工具的信息整理出来，然后才生成文章结构。这比直接让聊天工具硬写一篇要稳，因为它至少先做了资料准备。\u003c/p\u003e\n\u003cp\u003e当然，资料准备不等于完全准确。价格、发布时间、功能开放范围这些细节，还是要自己再核一遍。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"四最省时间的三件事资料大纲配图提示词\"\u003e四、最省时间的三件事：资料、大纲、配图提示词\u003c/h2\u003e\n\u003cp\u003e这次试下来，我觉得它最有用的地方有三个，都不在正文。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一，资料整理。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e工具类文章最怕信息散：功能说明在官网，价格在另一个页面，更新记录在博客或公告里，别人的介绍又夹着不少二手理解。手动整理的结果往往是浏览器标签页越开越多，写文章的精力先被消耗光了。\u003c/p\u003e\n\u003cp\u003eWorkBuddy 可以把这些信息按固定结构先整理出来：这个工具是什么、更新了什么、适合谁、限制在哪。整理出来的内容不一定能直接进文章，但至少让素材从“散乱网页”变成了“可处理材料”。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二，搭大纲。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e写文章经常在结构上花时间：先讲什么后讲什么，哪些放前面吸引读者，哪些放后面做判断。它给的第一版大纲不一定符合个人的表达习惯，但有了框架再删改，比从空白文档开始轻松太多。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三，配图提示词。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e写 AI、算力、本地模型这类文章，经常需要横版封面和正文插图。图不能太花，不能像广告，不能出现真实品牌 Logo。WorkBuddy 能根据文章内容生成图片提示词，比如：2.35:1 横版、极简写实科技风、不要人物、不要真实商标、右下角加 by OneCai。\u003cstrong\u003e提示词一旦标准化，整个账号的配图风格就稳了。\u003c/strong\u003e\u003c/p\u003e","title":"我试了下WorkBuddy：替我写文章不行，替我干杂活是真行"},{"content":" 术语解构系列·超分比\n文中价格与产品信息查证时间：2026年7月3日。云厂商产品线与活动价变动频繁，请以官网当日信息为准。\n同样是“2核2G”，凭什么差几倍？ 打开云厂商的售卖页，你会看到一个奇怪的现象：同样标着“2核2G”的云主机，阿里云经济型e实例曾长期卖99元一年（新老同享、续费不涨价的官方活动价），而同配置的企业级独享实例，一年要贵出好几倍。\n配置表上找不到区别，底层CPU甚至可能是同一颗，差别藏在一个产品页上永远不会明说的数字里——超分比。\n今天这篇讲清楚四件事：超分比是什么，它怎么把“账面算力”和“有效算力”变成两回事，怎么验证你自己的云主机被超分了多少，以及为什么这套玩了二十年的商业魔法，到了GPU时代突然失灵了。\n一、超分比：云厂商的印钞旋钮 CPU超分比如何把物理算力变成更多账面vCPU 超分比（overcommitratio）=卖出去的vCPU总数÷物理机的逻辑核总数。\n拿一台具体的机器算账。一台双路AMDEPYC9654的服务器：\n物理核：96×2=192核 开超线程后：384个逻辑核 成本：EPYC9654发布时官方定价11,805美元/颗（约8.4万元），两颗芯片按官方标价就是17万元。不过Genoa如今已是两代前的平台，渠道价早已跳水——2026年7月查询，京东上双路9654的整机（基础配置塔式，192核384线程）券后约5.3万元。云厂商用的是ODM定制机型加大批量采购，再配上虚拟化所需的TB级内存，单台成本大致在10万元这个量级（估算） 如果按1：1售卖，这台机器最多卖384个vCPU。\n如果按1：4超分，同一台机器可以卖出1536个vCPU——售卖容量直接翻四倍，硬件成本一分没多花。\n这就是99元云主机能存在的全部原因。它不是硬件更差，而是这个旋钮被拧得更大。\n一个容易踩的细节：1:1也不是你想的1:1 注意分母是超线程后的逻辑核，不是物理核。厂商说“独享不超分”，通常指的是1vCPU独占1个超线程。而同一个物理核的两个超线程共享执行单元，单线程极限性能大约只有独占整个物理核的60%~70%。\n也就是说，“标称核数”和“实际算力”之间，从CPU时代起就隔着两层折扣：先打超线程的折，再打超分的折。\n有意思的是，这层折扣如今也开始被当成卖点消除：阿里云2026年最新一代企业级实例（如搭载AMDTurin的g9a）在官方文档里明确写着“采用物理核设计，计算性能稳定”——1vCPU=1物理核，连超线程的折扣都不打了。确定性本身，正在成为溢价商品。\n二、为什么敢超卖？——因为你根本用不满 超分的底气来自一个统计事实：绝大多数虚机的CPU利用率长期在5%~20%之间。\nWeb服务在等请求，数据库在等磁盘IO，开发机在等程序员敲键盘。宿主机的调度器（KVM场景下就是Linux的CFS）把每个vCPU当作一个普通线程做时间片轮转——只要不是所有租户同时要CPU，谁也感觉不到谁。\n这叫统计复用。打个比方：一家餐厅只有100个座位，却卖出了300张预约券。只要客人分散到店，一切正常，翻台率还高得漂亮；可一旦300人同时进门，座位立刻不够，排队就开始了。\n整个云计算的低价入门产品线，都建立在“客人不会同时进门”这个赌注上。\n各家云厂商把这个赌注做成了显式的产品分层（以下产品线信息查证于2026年7月3日各厂商官网文档）：\n层级 典型产品 机制 独享/企业级 阿里云企业级实例（g/c/r系列）、腾讯云CVM标准型（S9/SA9等）、AWSM/C/R系列 1vCPU绑定1超线程，性能稳定，有性能SLA；阿里云最新g9a更进一步采用物理核设计 共享型 阿里云共享型实例、经济型e实例 官方文档原话大意：vCPU被随机分配到任意空闲超线程上，不同实例会争抢物理CPU，高负载时性能波动——有可用性SLA，但无性能SLA 突发性能型 AWSt系列、阿里云t系列、腾讯云蜂驰型BF1 CPU积分/基准算力机制：基线可能只有单核算力的10%~40%，平时攒积分，突发时消耗，耗尽被压回基线 阿里云是把机制写得最坦白的一家——共享型文档里“争抢”“无性能SLA”这些词都是白纸黑字。腾讯云则没有公开叫“共享型”的在售CVM产品线，它把这个价位段交给了两个产品：轻量应用服务器（Lighthouse，不承诺具体CPU型号、随机分配、按套餐+流量包售卖）和蜂驰型BF1（把“基准算力/最高算力”直接写进规格）。包装不同，拧的是同一个旋钮。\n突发性能实例是其中最诚实的形态：它把超分风险直接产品化了——规则全部写在明面上，基线多少、积分怎么攒怎么花，童叟无欺。\n三、账面算力≠有效算力 账面算力不等于有效算力 有了超分比这个概念，就可以把平时被混着说的“算力”拆成三层：\n物理算力：硬件真实具备的计算能力——多少颗CPU、多少核心、什么主频、什么架构。这是分母，是不会说谎的那一层。\n账面算力：虚拟化之后对外分配出去的vCPU总量。因为有超分，账面算力可以远大于物理算力——100核的物理机，账面上可以“变出”400核。\n有效算力：业务高峰期，你仍然能稳定拿到的那部分。这才是你真正买到手的东西。\n超分比决定的，正是从账面到有效之间的兑现率。\n回到前面的例子：同样一台“8核”云主机，底层超分2：1的平台上，这8个vCPU大概率随叫随到；底层超分8：1的平台上，你买到的其实不是8核算力，而是共享池里的8个排队入口——低峰期看不出区别，高峰期开始抽号。\n云主机卖的是规格，你需要的是可兑现的算力。这句话记住，后面讲到GPU和智算中心时还会用到。\n四、动手环节：看看你的云主机被超分了多少 先说一个很多人遇到过的困惑：“我这台机器CPU才用了40%，为什么业务还是慢？”\n原因往往不在虚机内部，而在虚机外部——你的vCPU已经就绪、想跑，但宿主机没把物理CPU分给你。这段等待，从虚机内部的CPU使用率上是看不到的。\nLinux里专门有个指标记录它。在你的云主机上跑：\n1 vmstat110 看最后一列st（stealtime）——“被偷走的时间”：\nst长期为0：基本是独享，或者邻居们都很安静 st经常出现5%~10%甚至更高：宿主机上有“吵闹邻居”在和你抢核 如果你用的是VMware私有云，宿主机侧对应的指标叫CPUReadyTime，含义相同：vCPU就绪了，在等物理核翻牌。\n两个旁证：一是用sysbench在深夜和工作日下午各跑一次分，波动明显就说明高峰期有争抢；二是别只看规格压测，跑一段真实业务——接口QPS、数据库查询耗时、一次完整编译的时间——不同时段各来一遍，兑现率高不高，数字不会撒谎。\n99元的云主机，你应该要知道自己买的是什么。\n五、如果你自己管资源池 超分比不只是买云主机时的避坑知识。如果你在管私有云、IDC资源池，它是一道经营平衡题：超分太低，服务器利用率上不去，成本浪费；超分太高，账面漂亮，高峰期体验崩盘。\n行业里的常见做法是分池设置，不同业务给不同的旋钮位置：\n资源池类型 常见超分比 逻辑 核心生产池（数据库、交易、计费） 1：1~2：1 稳定优先，要的是有效算力 普通生产池（Web、中间件、办公系统） 2：1~4：1 利用率和性能的平衡点 测试开发池 4：1~8：1 容忍波动，换利用率 桌面云/教学环境 6：1~12：1 看并发峰值定，人不会同时敲键盘 AI推理/高性能计算 1：1或不超分 持续满载，没有空闲可赌 这张表的最后一行，正好引出下半篇的主角。\n六、到了GPU时代，魔法失灵了 现在把镜头切到算力这边。\n你有没有想过一个问题：CPU可以拆成vCPU论“个”卖，为什么H100从来都是整卡、整台（8卡）、甚至整个集群起租？为什么没有“0.25张H100”这种商品？——因为超分成立的三个前提，在GPU训练场景下全部崩塌：\n前提一：利用率有波谷→崩塌。训练任务的GPU利用率长期压在90%以上，一跑就是几天几周。统计复用赌的是“客人不会同时进门”，而训练负载是一个客人进门就把整个餐厅包了，而且不走。没有波谷，就没有可以复用的空闲时间片。\n前提二：争抢的后果可以优雅降级→崩塌。CPU争抢的后果是排队变慢，可以忍。而GPU的硬约束是显存：一张H100就80GBHBM，模型和激活值放不下就是直接OOM崩掉，没有“慢一点”这个选项。显存没法像CPU时间片那样切了轮着用。\n前提三：资源是独立的→崩塌。训练是8卡通过NVLink组成一个整体，再通过RDMA网络和其他节点做All-Reduce。任何一张卡被别的租户干扰，整个集群的同步都要等它——这就是为什么训练集群不仅不能超分，连网络都要做成1：1无收敛。\n所以GPU训练算力的商品形态退回了“整租”：按卡·小时计价，本质上和租一台挖掘机没有区别。算力在训练场景下，是不可超分的商品——账面即有效，兑现率必须是100%，做不到就是训练事故。\nCPU超分、GPU训练、GPU推理三种算力负载的差异 七、但推理，让超分借尸还魂了 故事到这里还没完。训练不能超分，推理可以。\n推理负载和Web服务很像：有波峰波谷（白天问答多、深夜没人用），单次请求占用时间短，对延迟的容忍度也分三六九等。统计复用的前提又回来了——客人重新变成了散客。\n于是GPU侧长出了一整套“切分与超分”的工具：\nMIG（Multi-InstanceGPU）：A100/H100可以在硬件层切成最多7个实例，每份显存和算力物理隔离——这是“诚实的切分”，相当于1：1，只是粒度变小了 Time-slicing/MPS：多个推理任务分时共享同一张卡——这就是真“超分”，和CPU的时间片轮转一个思路，代价同样是延迟抖动 ServerlessGPU：按请求计费，底层就是极高超分比的GPU池子，厂商赌的还是那句话——大家不会同时来 你会发现历史在押韵：推理算力的售卖，正在重演CPU云主机走过的路——先整卡卖，再切分卖，最后超分卖，价格一路下探，兑现率一路让渡。\n八、回到那个“P”字 上一篇我们拆过智算中心的“1P算力”是怎么算出来的。现在可以把两个概念接上了。\n智算中心报的P数，是物理算力乘出来的账面数字——所有卡、满血跑、理论峰值。而你实际租到手的有效算力，要连乘三层折扣：\n有效算力≈标称P数×你分到的份额×MFU\n所以下次谈算力租赁，除了问单价，还要问清楚三件事：\n独占还是切分？是整卡/整机独占，还是MIG切分，还是time-slicing共享？——这决定“你分到的份额” 网络什么规格？是无收敛RDMA，还是普通以太网凑数？——训练场景这条直接决定MFU 有没有性能SLA？记住阿里云共享型文档里那句坦白话——“有可用性SLA，无性能SLA”。算力租赁同样要问：承诺的是“开着机”，还是“跑得快”？ 问完这三个问题，报价单上的账面数字，才开始向有效算力靠拢。\n写在最后 超分比这个概念，本质是成本和性能确定性之间的定价旋钮，它衡量的是账面算力到有效算力的兑现率：\nCPU时代，旋钮拧的是时间片，赌的是“你用不满” GPU训练时代，负载焊死在90%+，旋钮拧不动了，算力退回整租 GPU推理时代，波峰波谷回来了，旋钮又开始转——MIG、time-slicing、serverless，历史重新押韵 真正有价值的算力，要满足三个词：可持续、可调度、可兑现。\n过去我们看云服务器，习惯问“几核几G”；以后看任何算力——云主机也好，智算中心也好——都值得多问一句：\n这些核，到了高峰期还能不能真正跑起来？\n本文属于「术语解构」系列。上一篇：《1P算力到底是多少》。文中价格与产品信息查证于2026年7月3日。\n","permalink":"https://blog.onecai.site/2026/07/02/030-cpu-overcommit-ratio-vs-gpu/","summary":"\u003cblockquote\u003e\n\u003cp\u003e术语解构系列·\u003cstrong\u003e超分比\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e文中价格与产品信息查证时间：2026年7月3日。云厂商产品线与活动价变动频繁，请以官网当日信息为准。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"同样是2核2g凭什么差几倍\"\u003e同样是“2核2G”，凭什么差几倍？\u003c/h2\u003e\n\u003cp\u003e打开云厂商的售卖页，你会看到一个奇怪的现象：同样标着“2核2G”的云主机，阿里云经济型e实例曾长期卖99元一年（新老同享、续费不涨价的官方活动价），而同配置的企业级独享实例，一年要贵出好几倍。\u003c/p\u003e\n\u003cp\u003e配置表上找不到区别，底层CPU甚至可能是同一颗，差别藏在一个产品页上永远不会明说的数字里——\u003cstrong\u003e超分比\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e今天这篇讲清楚四件事：超分比是什么，它怎么把“账面算力”和“有效算力”变成两回事，怎么验证你自己的云主机被超分了多少，以及为什么这套玩了二十年的商业魔法，到了GPU时代突然失灵了。\u003c/p\u003e\n\u003ch2 id=\"一超分比云厂商的印钞旋钮\"\u003e一、超分比：云厂商的印钞旋钮\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"overcommit-1.avif\"\n         alt=\"CPU超分比如何把物理算力变成更多账面vCPU\"/\u003e \u003cfigcaption\u003e\n            CPU超分比如何把物理算力变成更多账面vCPU\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e超分比（overcommitratio）=\u003cstrong\u003e卖出去的vCPU总数÷物理机的逻辑核总数\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e拿一台具体的机器算账。一台双路AMDEPYC9654的服务器：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e物理核：96×2=192核\u003c/li\u003e\n\u003cli\u003e开超线程后：\u003cstrong\u003e384个逻辑核\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e成本：EPYC9654发布时官方定价11,805美元/颗（约8.4万元），两颗芯片按官方标价就是17万元。不过Genoa如今已是两代前的平台，渠道价早已跳水——2026年7月查询，京东上双路9654的整机（基础配置塔式，192核384线程）券后约5.3万元。云厂商用的是ODM定制机型加大批量采购，再配上虚拟化所需的TB级内存，单台成本大致在10万元这个量级（估算）\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果按1：1售卖，这台机器最多卖384个vCPU。\u003c/p\u003e\n\u003cp\u003e如果按\u003cstrong\u003e1：4超分\u003c/strong\u003e，同一台机器可以卖出\u003cstrong\u003e1536个vCPU\u003c/strong\u003e——售卖容量直接翻四倍，硬件成本一分没多花。\u003c/p\u003e\n\u003cp\u003e这就是99元云主机能存在的全部原因。它不是硬件更差，而是这个旋钮被拧得更大。\u003c/p\u003e\n\u003ch3 id=\"一个容易踩的细节11也不是你想的11\"\u003e一个容易踩的细节：1:1也不是你想的1:1\u003c/h3\u003e\n\u003cp\u003e注意分母是\u003cstrong\u003e超线程后的逻辑核\u003c/strong\u003e，不是物理核。厂商说“独享不超分”，通常指的是1vCPU独占1个超线程。而同一个物理核的两个超线程共享执行单元，单线程极限性能大约只有独占整个物理核的60%~70%。\u003c/p\u003e\n\u003cp\u003e也就是说，“\u003cstrong\u003e标称核数\u003c/strong\u003e”和“\u003cstrong\u003e实际算力\u003c/strong\u003e”之间，从CPU时代起就隔着两层折扣：先打超线程的折，再打超分的折。\u003c/p\u003e\n\u003cp\u003e有意思的是，这层折扣如今也开始被当成卖点消除：阿里云2026年最新一代企业级实例（如搭载AMDTurin的g9a）在官方文档里明确写着“采用物理核设计，计算性能稳定”——1vCPU=1物理核，连超线程的折扣都不打了。确定性本身，正在成为溢价商品。\u003c/p\u003e\n\u003ch2 id=\"二为什么敢超卖因为你根本用不满\"\u003e二、为什么敢超卖？——因为你根本用不满\u003c/h2\u003e\n\u003cp\u003e超分的底气来自一个统计事实：\u003cstrong\u003e绝大多数虚机的CPU利用率长期在5%~20%之间\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003eWeb服务在等请求，数据库在等磁盘IO，开发机在等程序员敲键盘。宿主机的调度器（KVM场景下就是Linux的CFS）把每个vCPU当作一个普通线程做时间片轮转——只要不是所有租户同时要CPU，谁也感觉不到谁。\u003c/p\u003e\n\u003cp\u003e这叫\u003cstrong\u003e统计复用\u003c/strong\u003e。打个比方：\u003cu\u003e一家餐厅只有100个座位，却卖出了300张预约券。只要客人分散到店，一切正常，翻台率还高得漂亮；可一旦300人同时进门，座位立刻不够，排队就开始了。\u003c/u\u003e\u003c/p\u003e\n\u003cp\u003e整个云计算的低价入门产品线，都建立在“客人不会同时进门”这个赌注上。\u003c/p\u003e\n\u003cp\u003e各家云厂商把这个赌注做成了显式的产品分层（以下产品线信息查证于2026年7月3日各厂商官网文档）：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e层级\u003c/th\u003e\n          \u003cth\u003e典型产品\u003c/th\u003e\n          \u003cth\u003e机制\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e独享/企业级\u003c/td\u003e\n          \u003ctd\u003e阿里云企业级实例（g/c/r系列）、腾讯云CVM标准型（S9/SA9等）、AWSM/C/R系列\u003c/td\u003e\n          \u003ctd\u003e1vCPU绑定1超线程，性能稳定，有性能SLA；阿里云最新g9a更进一步采用物理核设计\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e共享型\u003c/td\u003e\n          \u003ctd\u003e阿里云共享型实例、经济型e实例\u003c/td\u003e\n          \u003ctd\u003e官方文档原话大意：vCPU被随机分配到任意空闲超线程上，不同实例会争抢物理CPU，高负载时性能波动——\u003cstrong\u003e有可用性SLA，但无性能SLA\u003c/strong\u003e\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e突发性能型\u003c/td\u003e\n          \u003ctd\u003eAWSt系列、阿里云t系列、腾讯云蜂驰型BF1\u003c/td\u003e\n          \u003ctd\u003eCPU积分/基准算力机制：基线可能只有单核算力的10%~40%，平时攒积分，突发时消耗，耗尽被压回基线\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e阿里云是把机制写得最坦白的一家——共享型文档里“争抢”“无性能SLA”这些词都是白纸黑字。腾讯云则没有公开叫“共享型”的在售CVM产品线，它把这个价位段交给了两个产品：轻量应用服务器（Lighthouse，不承诺具体CPU型号、随机分配、按套餐+流量包售卖）和蜂驰型BF1（把“基准算力/最高算力”直接写进规格）。\u003cstrong\u003e包装不同，拧的是同一个旋钮。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e突发性能实例是其中最诚实的形态：它把超分风险直接产品化了——规则全部写在明面上，基线多少、积分怎么攒怎么花，童叟无欺。\u003c/p\u003e\n\u003ch2 id=\"三账面算力有效算力\"\u003e三、账面算力≠有效算力\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"overcommit-2.avif\"\n         alt=\"账面算力不等于有效算力\"/\u003e \u003cfigcaption\u003e\n            账面算力不等于有效算力\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e有了超分比这个概念，就可以把平时被混着说的“算力”拆成三层：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e物理算力\u003c/strong\u003e：硬件真实具备的计算能力——多少颗CPU、多少核心、什么主频、什么架构。这是分母，是不会说谎的那一层。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e账面算力\u003c/strong\u003e：虚拟化之后对外分配出去的vCPU总量。因为有超分，账面算力可以远大于物理算力——100核的物理机，账面上可以“变出”400核。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e有效算力\u003c/strong\u003e：业务高峰期，你仍然能稳定拿到的那部分。这才是你真正买到手的东西。\u003c/p\u003e\n\u003cp\u003e超分比决定的，正是从账面到有效之间的\u003cstrong\u003e兑现率\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e回到前面的例子：同样一台“8核”云主机，底层超分2：1的平台上，这8个vCPU大概率随叫随到；底层超分8：1的平台上，你买到的其实不是8核算力，而是\u003cstrong\u003e共享池里的8个排队入口\u003c/strong\u003e——低峰期看不出区别，高峰期开始抽号。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e云主机卖的是规格，你需要的是可兑现的算力\u003c/strong\u003e。这句话记住，后面讲到GPU和智算中心时还会用到。\u003c/p\u003e\n\u003ch2 id=\"四动手环节看看你的云主机被超分了多少\"\u003e四、动手环节：看看你的云主机被超分了多少\u003c/h2\u003e\n\u003cp\u003e先说一个很多人遇到过的困惑：“我这台机器CPU才用了40%，为什么业务还是慢？”\u003c/p\u003e\n\u003cp\u003e原因往往不在虚机内部，而在虚机\u003cstrong\u003e外部\u003c/strong\u003e——你的vCPU已经就绪、想跑，但宿主机没把物理CPU分给你。这段等待，从虚机内部的CPU使用率上是看不到的。\u003c/p\u003e\n\u003cp\u003eLinux里专门有个指标记录它。在你的云主机上跑：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003evmstat110\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e看最后一列\u003cstrong\u003est（stealtime）\u003c/strong\u003e——“被偷走的时间”：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003est长期为0：基本是独享，或者邻居们都很安静\u003c/li\u003e\n\u003cli\u003est经常出现5%~10%甚至更高：宿主机上有“吵闹邻居”在和你抢核\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果你用的是VMware私有云，宿主机侧对应的指标叫\u003cstrong\u003eCPUReadyTime\u003c/strong\u003e，含义相同：\u003cstrong\u003evCPU就绪了，在等物理核翻牌\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e两个旁证：一是用sysbench在深夜和工作日下午各跑一次分，波动明显就说明高峰期有争抢；二是别只看规格压测，跑一段真实业务——接口QPS、数据库查询耗时、一次完整编译的时间——不同时段各来一遍，兑现率高不高，数字不会撒谎。\u003c/p\u003e\n\u003cp\u003e99元的云主机，你应该要知道自己买的是什么。\u003c/p\u003e\n\u003ch2 id=\"五如果你自己管资源池\"\u003e五、如果你自己管资源池\u003c/h2\u003e\n\u003cp\u003e超分比不只是买云主机时的避坑知识。如果你在管私有云、IDC资源池，它是一道经营平衡题：超分太低，服务器利用率上不去，成本浪费；超分太高，账面漂亮，高峰期体验崩盘。\u003c/p\u003e\n\u003cp\u003e行业里的常见做法是\u003cstrong\u003e分池设置\u003c/strong\u003e，不同业务给不同的旋钮位置：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e资源池类型\u003c/th\u003e\n          \u003cth\u003e常见超分比\u003c/th\u003e\n          \u003cth\u003e逻辑\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e核心生产池（数据库、交易、计费）\u003c/td\u003e\n          \u003ctd\u003e1：1~2：1\u003c/td\u003e\n          \u003ctd\u003e稳定优先，要的是有效算力\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e普通生产池（Web、中间件、办公系统）\u003c/td\u003e\n          \u003ctd\u003e2：1~4：1\u003c/td\u003e\n          \u003ctd\u003e利用率和性能的平衡点\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e测试开发池\u003c/td\u003e\n          \u003ctd\u003e4：1~8：1\u003c/td\u003e\n          \u003ctd\u003e容忍波动，换利用率\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e桌面云/教学环境\u003c/td\u003e\n          \u003ctd\u003e6：1~12：1\u003c/td\u003e\n          \u003ctd\u003e看并发峰值定，人不会同时敲键盘\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eAI推理/高性能计算\u003c/td\u003e\n          \u003ctd\u003e1：1或不超分\u003c/td\u003e\n          \u003ctd\u003e持续满载，没有空闲可赌\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这张表的最后一行，正好引出下半篇的主角。\u003c/p\u003e","title":"为什么CPU能一卖四,GPU却只能整卡出租?"},{"content":" 价格数据核对时间：2026年7月初。文中人民币按7.2汇率粗算，具体以官方文档为准。\n最近看各家大模型API的token价格，会有一个很明显的感觉：\n有的平台很贵，贵到像“高级顾问”；\n有的平台很便宜，便宜到可以当“日常水电”。\n到底差多少？同样生成一百万个token（大约50万汉字）：\n用DeepSeek V4 Flash，输出费用0.28美元，约合2块人民币； 用GPT-5.4 Pro，输出费用180美元，约合1300块人民币。 640倍的价差。 不是打折与原价的区别，是自行车和特斯拉的区别。\n更关键的问题是：日常做公众号、写文章、整理资料、做自动化，到底该用贵模型，还是便宜模型？\n我的判断很明确：\n贵模型不是智商税，但不能滥用；便宜模型不是低端货，而是AI普及的真正基础设施。\n这篇把账算清楚。\n一、先看价格全景：四个梯队 以下均为官方API标准价（非batch、非缓存），单位是美元/百万tokens，格式为“输入/输出”。\n旗舰档：买的是天花板\n模型 输入/输出 折合人民币（输出） GPT-5.5 $5 / $30 ≈¥216/百万 Claude Opus 4.8 $5 / $25 ≈¥180/百万 GPT-5.4 Pro $30 / $180 ≈¥1296/百万 主力档：生产环境的默认选择\n模型 输入/输出 备注 Claude Sonnet 5 $2 / $10（首发价） 6月30日刚发布，8月31日后恢复$3/$15，标配1M上下文 GPT-5.4 $2.5 / $15 OpenAI当前主力 Gemini 3.1 Pro $2 / $12 2M上下文，超20万token的请求涨到$4/$18 性价比档：国产模型的主场\n模型 输入/输出 备注 GLM-5.2 $1.4 / $4.4 智谱6月刚调的价 MiniMax M3 $0.6 / $2.4 SWE-bench 80.5%，80分以上最便宜 DeepSeek R1 $0.55 / $2.19 推理成本约为o3的1/27 底价档：跑量专用\n模型 输入/输出 备注 DeepSeek V4 Flash $0.14 / $0.28 全场最低 Gemini 3.1 Flash-Lite $0.10 / $0.40 闭源里最便宜之一 大模型 API 价格的四个梯队 看到这些表格，模型选择就不该问“哪个最强”，而要问：这个任务值不值得用最贵的模型？\n二、贵的三个理由 贵在“上限”：最后8个百分点是断层，不是斜坡 一个很有意思的数据：在SWE-bench Verified（用真实GitHub issue测代码能力的基准）上，有5个模型挤在80.2%~80.6%之间——只差0.4个百分点——但价格横跨5倍。而GPT-5.5和Opus 4.8在88%以上。\n普通问答、简单改写、摘要提取，你感觉不到这8个点的差别。但任务一复杂，差距就出来了：\n读完多份文档，找出里面的矛盾； 分析一段复杂代码，给出可运行的修改方案； 连续调用工具，完成一套自动化流程； 在长上下文里保持前后逻辑一致； 在模糊问题里判断你的真正意图。 这些任务不是“会说话”就行。贵模型不是每个token都神奇，而是在复杂任务里失败率更低。\n算一笔账：一个多文件重构任务，旗舰模型一次通过，便宜模型平均重试2.5次外加你半小时人工review。token差价几毛钱，你半小时值多少钱？\n所以正确的度量单位是**“每完成任务的成本”，而不是“每token的成本”**。\n贵在“稳定性”：token成本只是总成本的一部分 个人用户看到模型写错一句话，手动改一下就行。但对严肃工作流来说，输出不稳定就是真金白银的成本。\n便宜的API还有个隐藏条款：不保证你要用的时候它在。DeepSeek的价格一直很诱人，但公开API的速率限制和可用性波动是老问题。如果你的流水线每天早上7点必须出结果（比如盘前分析），“最便宜”和“最可用”往往不是同一家。宕机时的最便宜，等于无穷贵。\n企业买贵模型，买的还包括并发保障、工具调用可靠性、版本管理、日志审计、数据合规、技术支持。真正贵的从来不是token，是系统出错、流程中断和数据泄露。\n贵在“生态”：单点不贵，整套系统贵 三大平台各有一套完整生态：OpenAI的工具链最系统化（文件、函数调用、图像、语音、Agent工作流都单独成体系）；Claude强在长文、代码和Agent场景，新发的Sonnet 5主打的就是agentic能力，且1M上下文不加价——整个代码库塞进上下文不用额外掏钱；Gemini靠Google生态和2M超长上下文，适合搜索、文档理解的组合场景。\n如果你只让它写一段公众号开头，确实浪费。但接入知识库、读文件、调工具、跑流程时，这套系统的价值就出来了。\n三、便宜的三个杠杆 反过来，便宜模型的价值也不在“省几块钱”，而在于它解锁的三种打法。\n杠杆一：让AI从“偶尔请专家”变成“每天用工具” 贵模型适合关键节点，便宜模型适合全流程铺开。以公众号运营为例，批量找选题、批量生成标题、批量写摘要、批量提取关键词、批量生成小红书版本、批量整理参考资料——这些任务不需要最强模型，DeepSeek、通义千问、豆包、Gemini Flash-Lite就足够。\n这才是生产力变化的关键：不是AI更聪明了，是AI便宜到可以嵌进每一个环节了。\n杠杆二：允许你反复试错 用贵模型时会下意识减少尝试次数，因为每次长输出都在花钱。但内容创作恰恰需要反复试错——标题从来不是一次生成就能用的。\n更合理的流程是：\n便宜模型生成20个标题； 便宜模型筛掉平庸的； 便宜模型按你的风格重写； 中档模型优化结构； 贵模型做最终质检。 便宜模型让你敢试、敢改、敢批量生成；贵模型负责最后判断和拔高。 AI创作不是单次命中，而是流程设计。\n杠杆三：分级路由——省钱效果最猛的架构 大部分产品的请求分布是金字塔形：约70%是简单请求（分类、提取、格式转换），20%中等，只有10%真正需要旗舰级智力。\n1 2 3 4 用户请求 → 复杂度分类器 ├─ 简单（70%）→ Flash/Nano级 $0.1~0.4/M ├─ 中等（20%）→ Mini/Haiku级 $0.4~4/M └─ 复杂（10%）→ 旗舰 $3~30/M 有个公开案例：月请求量100万的服务，全量用旗舰月成本约$10,500；改成分级路由后降到$1,500——降幅86%，质量几乎无损，因为难题依然由旗舰处理。\n分类器可以很土：按请求长度、有没有代码、关键词先分一轮，不确定的丢给一个Nano级模型判断，分类成本相对节省可以忽略。\n**简单请求走便宜模型，复杂请求走旗舰模型** 附赠两个官方折扣，不用白不用 Batch五折：OpenAI的Batch API和Anthropic的Message Batches对异步任务直接打5折。条件只有一个：接受24小时内返回。定时任务、批量生成、离线分析不用batch，等于主动多付一倍钱。 缓存一折：提示词缓存命中折扣已扩大到90%以上，Anthropic的缓存读取只按输入价的10%计费。系统提示词长、每次变化小的agent工作流（比如每次都带5000 token指令+20个工具定义），缓存后这部分几乎白嫖。 四、但便宜模型也有代价 便宜模型最大的问题是复杂任务上限。常见表现：\n长文容易写散，结构容易重复； 代码修改容易顾此失彼； 多轮对话中容易遗忘前文； 工具调用格式不够稳定； 容易给出“看起来合理但其实不准”的答案。 所以便宜模型适合做“量”的工作，不适合做“最终判断”。让它写公众号初稿没问题，让它独立完成一篇严肃行业分析，最好不要完全信任。\n一句话原则：便宜模型负责铺材料，贵模型负责做判断。\n五、一个专坑新手的计费陷阱：隐藏的思考token 推理模型（o系列、R1、开启thinking的模型）在给你答案之前会先“想”，这些思考token你看不见，但按输出价全额计费。\n一次调用可能烧掉5万个思考token，最后只吐一段话。标价看着便宜，实际成本可能是标价的3~10倍。\n两条对策：\n永远设置max_output_tokens上限； 先用非推理模型跑你的任务——很多任务根本不需要思考过程，效果一样，价格差几倍。 **看不见的思考 token 也在计费** 六、普通创作者的分工方案 如果你做公众号、博客、小红书，建议这样配：\n选题、标题、摘要、关键词 → 便宜模型。 这是高频试错任务，你要的是“多给几个方向”，不是一次给终极答案。DeepSeek Flash、Qwen Flash、豆包、Gemini Flash-Lite都行。\n文章初稿 → 中档模型。 Qwen Plus、Kimi、Sonnet、Gemini Flash/Pro。中文内容生产上国产模型性价比很高。\n长文档阅读 → 长上下文模型。 Kimi、Gemini Pro、Sonnet。但注意：上下文不是越长越好，越长越贵，模型也容易在中间信息里迷路。更好的方式是先切分、分段总结、最后统一归纳。\n最终润色和判断 → 贵模型。 查逻辑漏洞、判断观点是否站得住、改掉机械味、检查事实风险。这一步调用不多，但最关键。\n贵模型应该用在最后20%，而不是从头到尾。\n七、本地部署什么时候比API划算 以一台Mac Studio M4 Max 64GB做本地推理服务器，跑Qwen3.6-27B做日常内容生成。\n粗算电费账：推理时整机功耗按150W算，27B模型出token约25~30 tok/s，生成一百万token大约10小时，耗电约1.5度，电费不到1块钱。同样一百万token走Sonnet标准价输出要一百块出头。\n但除了直接成本，本地方案的真实成本还有：\n硬件折旧：机器两万多，按三年折旧每天摊约20块。只有当每天推理量真能替代20块以上的API开销，硬件才回本； 质量上限：27B量化模型大致对标便宜档API，替代不了旗舰； 你的时间：搭环境、调参、维护都是成本。 实际配置以三层混合为最佳：跑量任务走本地（边际成本≈0），常规生产走国产便宜档API，只有错误代价高的关键决策走旗舰。\n（对本地部署感兴趣的，可以翻我之前那篇12个本地模型横评。）\n**本地跑量，API 处理关键任务** 八、结论：别迷信贵，也别迷信便宜 贵模型强在复杂任务的确定性、稳定性、生态和最终判断力；便宜模型让AI可以高频用、批量用、自动化用，让个人和小团队把AI变成日常生产工具。\n所以别问“哪个模型最好”，要问“这个任务该用哪个档位”。个人建议是：\n80%的日常任务，用便宜模型完成；\n15%的复杂任务，用中档模型处理；\n5%的关键判断，用最贵模型收尾。\n一句话总结：贵模型买的是“错误代价高的那10%任务的确定性”，便宜模型赚的是“其余90%流量的规模经济”。\n贵模型决定上限，便宜模型决定普及。而真正会用AI的人，懂得把这两种价值组合起来。\n最后说一句 本文涉及到价格表的保质期大概一个季度。Sonnet 5的首发价8月31日就到期；OpenAI已放风夏季新旗舰会重置价格档；DeepSeek下一代也会重新锚定低价区。过去一年全行业价格降了约80%，这个趋势还没停。\n我会在价格发生大变动时更新这个系列。关注我，下次调价第一时间看到新账本。\n","permalink":"https://blog.onecai.site/2026/07/01/029-token-price-comparison/","summary":"\u003cblockquote\u003e\n\u003cp\u003e价格数据核对时间：2026年7月初。文中人民币按7.2汇率粗算，具体以官方文档为准。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e最近看各家大模型API的token价格，会有一个很明显的感觉：\u003c/p\u003e\n\u003cp\u003e有的平台很贵，贵到像“高级顾问”；\u003c/p\u003e\n\u003cp\u003e有的平台很便宜，便宜到可以当“日常水电”。\u003c/p\u003e\n\u003cp\u003e到底差多少？同样生成一百万个token（大约50万汉字）：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e用DeepSeek V4 Flash，输出费用\u003cstrong\u003e0.28美元\u003c/strong\u003e，约合2块人民币；\u003c/li\u003e\n\u003cli\u003e用GPT-5.4 Pro，输出费用\u003cstrong\u003e180美元\u003c/strong\u003e，约合1300块人民币。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e640倍的价差。\u003c/strong\u003e 不是打折与原价的区别，是自行车和特斯拉的区别。\u003c/p\u003e\n\u003cp\u003e更关键的问题是：日常做公众号、写文章、整理资料、做自动化，到底该用贵模型，还是便宜模型？\u003c/p\u003e\n\u003cp\u003e我的判断很明确：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e贵模型不是智商税，但不能滥用；便宜模型不是低端货，而是AI普及的真正基础设施。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这篇把账算清楚。\u003c/p\u003e\n\u003ch2 id=\"一先看价格全景四个梯队\"\u003e一、先看价格全景：四个梯队\u003c/h2\u003e\n\u003cp\u003e以下均为官方API标准价（非batch、非缓存），单位是美元/百万tokens，格式为“输入/输出”。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e旗舰档：买的是天花板\u003c/strong\u003e\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e输入/输出\u003c/th\u003e\n          \u003cth\u003e折合人民币（输出）\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGPT-5.5\u003c/td\u003e\n          \u003ctd\u003e$5 / $30\u003c/td\u003e\n          \u003ctd\u003e≈¥216/百万\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eClaude Opus 4.8\u003c/td\u003e\n          \u003ctd\u003e$5 / $25\u003c/td\u003e\n          \u003ctd\u003e≈¥180/百万\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGPT-5.4 Pro\u003c/td\u003e\n          \u003ctd\u003e$30 / $180\u003c/td\u003e\n          \u003ctd\u003e≈¥1296/百万\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cstrong\u003e主力档：生产环境的默认选择\u003c/strong\u003e\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e输入/输出\u003c/th\u003e\n          \u003cth\u003e备注\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eClaude Sonnet 5\u003c/td\u003e\n          \u003ctd\u003e$2 / $10（首发价）\u003c/td\u003e\n          \u003ctd\u003e6月30日刚发布，8月31日后恢复$3/$15，标配1M上下文\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGPT-5.4\u003c/td\u003e\n          \u003ctd\u003e$2.5 / $15\u003c/td\u003e\n          \u003ctd\u003eOpenAI当前主力\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGemini 3.1 Pro\u003c/td\u003e\n          \u003ctd\u003e$2 / $12\u003c/td\u003e\n          \u003ctd\u003e2M上下文，超20万token的请求涨到$4/$18\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cstrong\u003e性价比档：国产模型的主场\u003c/strong\u003e\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e输入/输出\u003c/th\u003e\n          \u003cth\u003e备注\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eGLM-5.2\u003c/td\u003e\n          \u003ctd\u003e$1.4 / $4.4\u003c/td\u003e\n          \u003ctd\u003e智谱6月刚调的价\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eMiniMax M3\u003c/td\u003e\n          \u003ctd\u003e$0.6 / $2.4\u003c/td\u003e\n          \u003ctd\u003eSWE-bench 80.5%，80分以上最便宜\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDeepSeek R1\u003c/td\u003e\n          \u003ctd\u003e$0.55 / $2.19\u003c/td\u003e\n          \u003ctd\u003e推理成本约为o3的1/27\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cstrong\u003e底价档：跑量专用\u003c/strong\u003e\u003c/p\u003e","title":"用AI工具，为什么有人花2块，有人花1300块？"},{"content":" 6月底到7月初这两周，模型厂商和工具厂商都在密集出货。这一期挑了5款和开发者、内容创作者关系最大的新品，全部给出具体价格和参数，方便你直接判断值不值得上手。\n一、Claude Sonnet 5：Anthropic 中端主力换代 发布时间：2026年6月30日\nAnthropic 把 Sonnet 这条“性价比主力线”推到了 5 代。官方定位是“迄今最具 Agent 能力的 Sonnet”，重点强化了编码、工具调用、推理和知识工作，性能宣称接近自家旗舰 Opus 4.8，但价格低得多。\n关键数字：\n首发优惠 API 定价：输入 $2 / 百万 token，输出 $10 / 百万 token，优惠期截至 2026年8月31日 优惠期结束后恢复 Sonnet 标准价：输入 $3 / 输出 $15 已成为 Free 和 Pro 套餐的默认模型，API 模型串 claude-sonnet-5 一个重要脚注：Sonnet 5 换用了新 tokenizer，同样文本会产生约 1.0–1.35 倍的 token 量。官方说法是首发优惠价的设计目标就是让迁移期成本大致持平 怎么看：Sonnet 一直是“日常干活模型”的甜点位。如果你在用 Claude Code 或自己的 Agent 管线，这个价位接近 Opus 级能力，值得在8月31日优惠结束前把评测跑完，确认是否切换默认模型。但注意上面那条 tokenizer 脚注——“输入 $2”不等于账单直接降三分之一，同样的文档会被切出更多 token，实际成本要拿自己的真实负载跑过才知道。这也是官方给优惠窗口的原因：让你在涨回 $3/$15 之前测清楚。\n二、Cursor iOS App：AI 编码 Agent 装进手机 AI 编码 Agent 异步化：人在手机上派活，Agent 在云端或电脑上执行 状态：公测（Public Beta），所有付费订阅用户可用\nCursor 推出了原生 iOS 应用，核心不是“在手机上写代码”，而是在手机上指挥云端/本地的编码 Agent：\n在云端启动 AI 编码 Agent（跑在带完整开发环境的隔离虚拟机里），或通过 Remote Control 远程操控本机正在跑的 Agent（需设置保持电脑唤醒） 语音输入 + 斜杠命令，可选任意前沿模型 锁屏 Live Activities 实时显示任务进度，Agent 完成、需要输入或待 review 时推送通知 直接在手机上查看 Agent 产出的 demo、截图和日志，review diff、合并 PR 支持本地与云端任务互相交接：本地计划可以甩给云端 Agent 继续跑 支持 iPhone 和 iPad，要求 iOS 26.0+ 限时优惠：通过移动端运行 Composer 2.5 享 75% 折扣，截至 2026年7月5日（写稿时基本已到期，后续留意是否延长）。\n怎么看：这是“Agent 异步化”趋势的标志性产品——任务在云端跑，人只负责派活和验收。通勤路上让 Agent 修一个 bug、到工位直接合 PR，这个工作流对独立开发者非常实用。缺点是公测阶段仅限付费用户。\n三、Gemini Spark 登陆 macOS：桌面自动化 Agent 桌面自动化 Agent：在用户授权的文件夹里完成本地任务 状态：macOS 公测，仅限美国区 Google AI Ultra 订阅用户\nGoogle 把桌面任务自动化 Agent Gemini Spark 带到了 Mac 上：\n本地任务自动化：把下载文件夹里的 PDF 按规则归档、从本地发票文件直接生成预算表格；用户在侧边栏显式授权文件夹，可随时撤销 新增应用集成：Google Tasks 和 Keep 已接入；Canva、Dropbox、Instacart、OpenTable、Zillow Rentals 先在 web 和移动端于一周内陆续上线，macOS 端要再等数周 自定义 MCP 支持正在推送 从手机远程发起 Mac 上的多步任务是官方预告的后续更新，当前版本还没有 硬件门槛：macOS 15 + Apple Silicon 怎么看：亮点是 MCP 那条——自定义 MCP 支持意味着它不再是封闭的 Google 全家桶玩具，理论上可以接自己的工具链。但门槛不低：AI Ultra 订阅 $100/月，且 Beta 仅限美国、18岁以上用户。国内用户短期用不上，但值得关注这个产品形态：操作系统级 Agent + 文件夹级授权 + MCP 开放生态，这是 Claude Cowork、Gemini Spark 都在押注的方向。另外提醒一句：这类 Agent 拿到的是你本地文件的读写权限，文件会经 Google 云端处理，授权前想清楚给哪个文件夹。\n四、Nano Banana 2 Lite + Gemini Omni Flash：生成媒体的价格屠夫 生成媒体进入低价素材时代：图像按张计价，视频按秒计价 Google 同期发布了两款生成媒体模型，主打一个字：便宜。\nNano Banana 2 Lite（图像生成，正式版 GA）：\n$0.034 / 张（1K分辨率）—— 注意是每张，不是每千张；API 定价页标准价 $0.0336/张，批量价 $0.0168/张 文生图延迟约 4 秒 模型 ID：gemini-3.1-flash-lite-image，官方推荐作为初代 Nano Banana 的替代 已陆续接入 Search AI Mode、Gemini App、NotebookLM、Google Photos 和 Google Ads Gemini Omni Flash（视频生成 + 对话式编辑，公开预览）：\n$0.10 / 秒输出，与 Veo 3.1 Fast 同价 支持用自然语言对话式编辑视频 当前限制：单次生成最长 10 秒，暂不支持音频参考输入 两者均已上线 Google AI Studio 和 Gemini API，所有输出带 SynthID 隐形水印。\n怎么看：官方主推的玩法是两个模型串联——Lite 4秒出图、Omni Flash 把图动画化，一条“图 + 10秒视频”的素材成本约 $1.03。图像单价 3 美分/张、千张约 $34，对批量配图来说依然便宜，但别被“$0.034 / 1K image”的官方话术误导——那个 1K 指分辨率不是张数，我核对 API 定价页时差点踩坑。视频 $0.10/秒把短视频素材生成拉进了个人可承受区间，但 10 秒上限意味着目前只适合做片段素材。\n五、Claude Apps Gateway：企业级 Claude Code 网关 Anthropic 发布了 Claude Apps Gateway，把 Claude Code 接入 Amazon Bedrock 和 Google Cloud 的企业网关：\n以单个无状态容器形式跑在自己的基础设施上（Linux 部署，PostgreSQL 做后端） 企业 SSO 登录（对接 OIDC 身份源）、集中策略管控、基于角色的权限管理 按用户的成本归因，支持按日/周/月设支出上限，粒度到组织、组或个人 除非显式配置 Claude API 作为上游，网关不向 Anthropic 发送推理流量和用量数据 网关协议已公开，第三方可以做兼容实现 怎么看：这款主要面向团队和企业，一人公司用不上完整功能，但它释放了一个信号：AI 编码工具正在从“个人订阅”走向“企业基础设施”，成本归因、权限管控这些运维属性开始产品化。做 AI 基础设施内容的朋友可以关注这条线——这是“Agent 进入生产环境”之后必然出现的配套设施层。\n彩蛋：一枚会打字的戒指 WisprFlow 技术加持的听写戒指也开启了预售：不用出声说话即可转写文字，降噪麦克风 + 触觉反馈触控板支持手指手势导航和纠错，续航 16 小时，预售价 $289，预计 2026 年圣诞前后发货。语音交互硬件化的又一次尝试，能不能活下来另说，形态本身挺有意思。\n本月小结 三条主线值得记住：\nAgent 异步化：Cursor iOS 和 Gemini Spark 都在做同一件事——人负责派活，Agent 在云端/桌面自主执行。 生成媒体进入“按张计价”时代：图像 3 美分/张、视频 $0.10/秒，图生视频串联工作流一条素材约 $1，个人创作者完全可承受，但还没到“免费随便挥霍”的程度。 中端模型价格战：Sonnet 5 以 $2/$10 的首发价对标旗舰性能，8月底前是最佳测试窗口——记得把新 tokenizer 的 token 膨胀算进成本模型。 信息来源：Anthropic 官方博客与 Claude Platform 定价页（2026-06-30）、Cursor 官方博客（cursor.com/blog/ios-mobile-app）、Google 官方博客（blog.google 与 Google Cloud Blog）。以上价格和参数均已于 2026年7月3日 逐条核对官方页面。\n","permalink":"https://blog.onecai.site/2026/06/30/028-ai-in-july/","summary":"\u003cblockquote\u003e\n\u003cp\u003e6月底到7月初这两周，模型厂商和工具厂商都在密集出货。这一期挑了5款和开发者、内容创作者关系最大的新品，全部给出具体价格和参数，方便你直接判断值不值得上手。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"一claude-sonnet-5anthropic-中端主力换代\"\u003e一、Claude Sonnet 5：Anthropic 中端主力换代\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e发布时间\u003c/strong\u003e：2026年6月30日\u003c/p\u003e\n\u003cp\u003eAnthropic 把 Sonnet 这条“性价比主力线”推到了 5 代。官方定位是“迄今最具 Agent 能力的 Sonnet”，重点强化了编码、工具调用、推理和知识工作，性能宣称接近自家旗舰 Opus 4.8，但价格低得多。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e关键数字\u003c/strong\u003e：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e首发优惠 API 定价：输入 $2 / 百万 token，输出 $10 / 百万 token，优惠期截至 2026年8月31日\u003c/li\u003e\n\u003cli\u003e优惠期结束后恢复 Sonnet 标准价：输入 $3 / 输出 $15\u003c/li\u003e\n\u003cli\u003e已成为 Free 和 Pro 套餐的默认模型，API 模型串 \u003ccode\u003eclaude-sonnet-5\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e一个重要脚注：Sonnet 5 换用了新 tokenizer，同样文本会产生约 1.0–1.35 倍的 token 量。官方说法是首发优惠价的设计目标就是让迁移期成本大致持平\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e怎么看\u003c/strong\u003e：Sonnet 一直是“日常干活模型”的甜点位。如果你在用 Claude Code 或自己的 Agent 管线，这个价位接近 Opus 级能力，值得在8月31日优惠结束前把评测跑完，确认是否切换默认模型。但注意上面那条 tokenizer 脚注——“输入 $2”不等于账单直接降三分之一，同样的文档会被切出更多 token，实际成本要拿自己的真实负载跑过才知道。这也是官方给优惠窗口的原因：让你在涨回 $3/$15 之前测清楚。\u003c/p\u003e\n\u003ch2 id=\"二cursor-ios-appai-编码-agent-装进手机\"\u003e二、Cursor iOS App：AI 编码 Agent 装进手机\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"ai7-1.avif\"\n          alt=\"AI 编码 Agent 异步化：人在手机上派活，Agent 在云端或电脑上执行\"/\u003e \u003cfigcaption\u003e\n             AI 编码 Agent 异步化：人在手机上派活，Agent 在云端或电脑上执行\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e状态\u003c/strong\u003e：公测（Public Beta），所有付费订阅用户可用\u003c/p\u003e","title":"7月AI新工具速递：本月值得关注的5款新品"},{"content":"很多人第一次接触大模型时，都会被两个词绕住：训练，推理。\n这两个词听起来都很“AI”，但它们不是一回事。\n一句话讲清楚：\n训练，是让模型学会能力。\n推理，是让模型使用能力。\n再说得直白一点：训练是造模型，推理是用模型。\n你平时用ChatGPT、DeepSeek、Kimi、豆包，或者在本地用LMStudio、Ollama、MLX跑模型，绝大多数时候做的都是推理——不是训练。\n这个区别很重要。\n因为它解释了一个普通用户经常遇到的问题：为什么我的电脑能跑一个32B大模型，却很难训练一个7B小模型？\n答案就在“训练”和“推理”的资源差距里。\n一、推理：模型已经学会了，现在拿来用 先说推理。\n推理就是模型已经训练好了，你给它一个问题，它根据已有参数生成答案。\n比如你问：\n推理和训练有什么区别？\n模型不会因为回答了这个问题，就真的重新学习一遍。它只是根据已经训练好的参数、当前输入和上下文，计算出最可能的回答。\n这个过程里，模型参数基本不变。\n它像一本已经印好的书。你可以翻，可以查，可以用里面的内容，但你翻了一页，并不会改写这本书的正文。\n所以推理的核心是：不改变模型参数，只使用模型参数。\n你让模型写文章、总结PDF、分析代码、生成标题、做错题讲解，本质上都是推理。本地大模型里的“运行模型”，通常也是推理。\n训练是学习能力，推理是使用能力 二、训练：模型还不会，需要反复纠错 训练就不一样了。\n训练不是让模型回答一个问题，而是让模型通过大量数据不断改变自己。\n它的基本过程可以简单理解为四步：\n第一步，模型先预测。\n第二步，把预测结果和标准答案对比。\n第三步，计算它错在哪里。\n第四步，根据错误调整内部参数。\n然后换下一批数据，继续重复。\n模型看过海量文本、代码、数学题、图片、问答数据之后，才逐渐形成语言规律、知识结构、表达方式和推理能力。\n所以训练的本质是：通过大量样本和反复纠错，修改模型参数。\n如果把模型比作学生：\n训练像上课和刷题。上课时，学生做题、改错、复盘，能力会发生变化。\n推理像考试现场答题。考试时，学生只是调用已经学过的知识，现场作答。\n这就是训练和推理的根本区别。\n三、技术上的关键差别：有没有反向传播 从技术上说，训练和推理最大的区别是：\n推理只做前向计算。 前向计算，就是模型根据输入算出输出。\n训练既做前向计算，也做反向传播。 反向传播，就是模型根据错误结果，反过来计算每个参数应该怎么调整。\n推理时，模型只负责“算答案”。\n训练时，模型不仅要“算答案”，还要“算自己错在哪”，再修改参数。\n所以训练天然比推理重得多。\n这就像：\n推理是做一道题。\n训练是做题、对答案、分析错因、修改学习方法。\n一个只是使用能力，一个是在改造能力。\n四、为什么训练比推理吃资源？ 训练和推理的资源差距，最直观体现在显存和内存上。\n以一个7B模型为例。\n7B，就是大约70亿个参数。\n如果用FP16精度推理，每个参数大约2字节，那么模型权重大约是：\n70亿×2字节≈14GB\n如果做Q4量化，每个参数大约0.5字节，那么模型权重大约是：\n70亿×0.5字节≈3.5GB到4GB\n所以很多普通电脑、MacBook、Macmini，可以跑7B量化模型。\n但训练完全不同。\n训练时，系统不只要保存模型权重，还要保存：\n梯度； 优化器状态； 中间计算结果； 激活值； 训练数据batch。 也就是说，训练不是只把模型“装进去”就行，还要为修改参数准备一整套额外空间。\n同一个7B模型，推理可能几GB到十几GB就能跑起来；训练时，单是参数相关状态就可能需要上百GB，再加上中间结果，需求会继续增加。\n所以你会看到一个现象：\n普通电脑可以推理一个不小的模型，却很难训练一个比它更小的模型。\n原因不是模型名字大小的问题，而是任务性质不同。\n推理是读参数。\n训练是改参数。\n改参数需要保存更多东西。\n推理只读参数，训练要改参数 五、为什么训练需要GPU集群，而推理可以本地跑？ 训练大模型通常需要很多张GPU。\n不是因为一张卡完全不能算，而是因为模型太大、数据太多、训练时间太长。\n训练过程中，多个GPU要不断同步参数和梯度，这就需要高速互联，比如NVLink、InfiniBand，以及复杂的分布式训练系统。\n所以训练不是“多买几张显卡”这么简单。它是一个系统工程。\n而推理的门槛低得多。\n尤其是单人本地推理，通常只关心三件事：\n模型能不能装下。 数据读取够不够快。 token生成速度能不能接受。 这也是为什么本地大模型选设备时，不能只看算力。\n很多时候，真正先卡住我们的不是算力，而是：内存容量、显存容量、内存带宽、KVCache。\n所以本地大模型选设备，可以按这个顺序看：容量第一，带宽第二，算力第三。\n先看模型能不能装下。\n再看数据搬得快不快。\n最后才看计算速度够不够。\n这也是本地推理和大规模训练最现实的区别。\n容量第一，带宽第二，算力第三 六、微调算训练吗？ 可以肯定的是，微调也算训练——只要更新了模型参数，就属于训练。\n微调不是从零训练一个模型，而是在已有模型基础上，用特定数据继续训练一小段。\n常见的微调方式包括：\n类型 是否属于训练 说明 预训练 是 从海量数据中训练基础模型 SFT 是 用问答数据教模型更像助手 LoRA 是 只训练少量附加参数 DPO/RLHF 是 让模型更符合人类偏好 普通聊天 否 只是推理 RAG知识库 通常否 检索资料后再回答 这里最容易混淆的是LoRA和RAG。LoRA虽然轻量，但它仍然在更新参数，所以属于训练。RAG通常不是训练。\n七、知识库不是训练 很多人会说：\n我把资料放进知识库，是不是就训练了一个自己的模型？\n通常不是。\n知识库问答一般属于RAG，也就是“检索增强生成”。\n知识库的流程是：\n先把资料切片、向量化，放进知识库，你提问时，系统先去知识库里查相关资料。然后把查到的内容塞进上下文。最后让模型结合这些资料回答。这个过程中，模型参数没有改变。资料并没有真正“长进模型脑子里”。它只是回答前临时翻了一下资料。\n所以可以这样理解：\nRAG像开卷考试。\n微调像专项补课。\n预训练像从小学读到大学。\n三者不能混为一谈。\n八、为什么有些AI看起来越用越懂我？ 有人可能会问：\n可是有些AI产品确实越用越懂我，这是不是训练了？\n不一定。\n这里通常有几种情况。\n第一，是上下文还在。同一个对话里，模型能看到前面的聊天记录，所以显得记住了你。\n第二，是产品有记忆功能。系统把你的偏好、身份、写作风格保存下来，下次聊天时再提供给模型。\n第三，是接入了知识库。模型回答前先查你的资料。\n第四，才是真正微调。用数据继续训练模型，更新参数。\n所以“越用越懂我”不一定等于训练。\n很多时候，只是系统给模型提供了更多关于你的上下文。\n九、我们真正应该关心什么？ 对大多数人来说，不必一上来就想着训练模型。\n训练是模型公司的底层工程。推理才是普通人每天真正接触的AI使用现场。\n我们真正应该关心的是三件事：\n第一，选对模型。 不同模型擅长的事情不同。有的适合写作，有的适合代码，有的适合长文总结，有的适合复杂推理。\n第二，用好上下文。 模型回答不好，很多时候不是模型不行，而是你给的信息不够清楚。目标、背景、限制条件、输出格式、参考资料，都会影响推理质量。\n第三，搭好工作流。 本地模型、云端API、知识库、Obsidian、Markdown、快捷指令、自动化脚本，这些组合起来，才是真正有价值的AI使用系统。\n模型只是发动机。\n真正决定效率的，是你怎么把它接进自己的工作流。\n十、最后总结 训练和推理，是理解大模型必须先分清楚的一组概念。\n训练，是制造模型能力。\n推理，是使用模型能力。\n你下载一个模型，本地运行它，是推理。 你上传一份PDF，让模型总结，是推理。 你建一个知识库，让模型查资料回答，通常还是推理。 你用一批数据去更新模型参数，才进入训练范畴。\n所以以后再看到训练成本、推理成本、推理加速、本地推理、LoRA微调、RAG知识库这些词，就能更准确地理解它们背后的含义。\n一句话收尾：\n训练解决的是：模型怎么变聪明。\n推理解决的是：模型怎么帮你干活。\n我们使用AI，重点不是重新造一个大脑，而是学会调用这个大脑。\n","permalink":"https://blog.onecai.site/2026/06/29/027-training-vs-inference/","summary":"\u003cp\u003e很多人第一次接触大模型时，都会被两个词绕住：\u003cstrong\u003e训练\u003c/strong\u003e，\u003cstrong\u003e推理\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这两个词听起来都很“AI”，但它们不是一回事。\u003c/p\u003e\n\u003cp\u003e一句话讲清楚：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e训练，是让模型学会能力。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e推理，是让模型使用能力。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e再说得直白一点：\u003cstrong\u003e训练是造模型，推理是用模型。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你平时用ChatGPT、DeepSeek、Kimi、豆包，或者在本地用LMStudio、Ollama、MLX跑模型，绝大多数时候做的都是推理——\u003cstrong\u003e不是训练\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这个区别很重要。\u003c/p\u003e\n\u003cp\u003e因为它解释了一个普通用户经常遇到的问题：\u003cstrong\u003e为什么我的电脑能跑一个32B大模型，却很难训练一个7B小模型？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e答案就在“训练”和“推理”的资源差距里。\u003c/p\u003e\n\u003ch2 id=\"一推理模型已经学会了现在拿来用\"\u003e一、推理：模型已经学会了，现在拿来用\u003c/h2\u003e\n\u003cp\u003e先说推理。\u003c/p\u003e\n\u003cp\u003e推理就是模型已经训练好了，你给它一个问题，它根据已有参数生成答案。\u003c/p\u003e\n\u003cp\u003e比如你问：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e推理和训练有什么区别？\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e模型不会因为回答了这个问题，就真的重新学习一遍。它只是根据已经训练好的参数、当前输入和上下文，计算出最可能的回答。\u003c/p\u003e\n\u003cp\u003e这个过程里，模型参数基本不变。\u003c/p\u003e\n\u003cp\u003e它像一本已经印好的书。你可以翻，可以查，可以用里面的内容，但你翻了一页，并不会改写这本书的正文。\u003c/p\u003e\n\u003cp\u003e所以推理的核心是：\u003cstrong\u003e不改变模型参数，只使用模型参数。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你让模型写文章、总结PDF、分析代码、生成标题、做错题讲解，本质上都是推理。本地大模型里的“运行模型”，通常也是推理。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"training-1.avif\"\n          alt=\"训练是学习能力，推理是使用能力\"/\u003e \u003cfigcaption\u003e\n             训练是学习能力，推理是使用能力\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"二训练模型还不会需要反复纠错\"\u003e二、训练：模型还不会，需要反复纠错\u003c/h2\u003e\n\u003cp\u003e训练就不一样了。\u003c/p\u003e\n\u003cp\u003e训练不是让模型回答一个问题，而是让模型通过大量数据不断改变自己。\u003c/p\u003e\n\u003cp\u003e它的基本过程可以简单理解为四步：\u003c/p\u003e\n\u003cp\u003e第一步，模型先预测。\u003c/p\u003e\n\u003cp\u003e第二步，把预测结果和标准答案对比。\u003c/p\u003e\n\u003cp\u003e第三步，计算它错在哪里。\u003c/p\u003e\n\u003cp\u003e第四步，根据错误调整内部参数。\u003c/p\u003e\n\u003cp\u003e然后换下一批数据，继续重复。\u003c/p\u003e\n\u003cp\u003e模型看过海量文本、代码、数学题、图片、问答数据之后，才逐渐形成语言规律、知识结构、表达方式和推理能力。\u003c/p\u003e\n\u003cp\u003e所以训练的本质是：\u003cstrong\u003e通过大量样本和反复纠错，修改模型参数。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e如果把模型比作学生：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e训练像上课和刷题\u003c/strong\u003e。上课时，学生做题、改错、复盘，能力会发生变化。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e推理像考试现场答题\u003c/strong\u003e。考试时，学生只是调用已经学过的知识，现场作答。\u003c/p\u003e\n\u003cp\u003e这就是训练和推理的根本区别。\u003c/p\u003e\n\u003ch2 id=\"三技术上的关键差别有没有反向传播\"\u003e三、技术上的关键差别：有没有反向传播\u003c/h2\u003e\n\u003cp\u003e从技术上说，训练和推理最大的区别是：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e推理只做前向计算。\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e前向计算，就是模型根据输入算出输出。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e训练既做前向计算，也做反向传播。\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e反向传播，就是模型根据错误结果，反过来计算每个参数应该怎么调整。\u003c/p\u003e\n\u003cp\u003e推理时，模型只负责“算答案”。\u003c/p\u003e\n\u003cp\u003e训练时，模型不仅要“算答案”，还要“算自己错在哪”，再修改参数。\u003c/p\u003e\n\u003cp\u003e所以\u003cstrong\u003e训练天然比推理重得多\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这就像：\u003c/p\u003e\n\u003cp\u003e推理是做一道题。\u003c/p\u003e\n\u003cp\u003e训练是做题、对答案、分析错因、修改学习方法。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e一个只是使用能力，一个是在改造能力。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"四为什么训练比推理吃资源\"\u003e四、为什么训练比推理吃资源？\u003c/h2\u003e\n\u003cp\u003e训练和推理的资源差距，最直观体现在显存和内存上。\u003c/p\u003e\n\u003cp\u003e以一个7B模型为例。\u003c/p\u003e\n\u003cp\u003e7B，就是大约70亿个参数。\u003c/p\u003e\n\u003cp\u003e如果用FP16精度推理，每个参数大约2字节，那么模型权重大约是：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e70亿×2字节≈14GB\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e如果做Q4量化，每个参数大约0.5字节，那么模型权重大约是：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e70亿×0.5字节≈3.5GB到4GB\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e所以很多普通电脑、MacBook、Macmini，可以跑7B量化模型。\u003c/p\u003e\n\u003cp\u003e但训练完全不同。\u003c/p\u003e\n\u003cp\u003e训练时，系统不只要保存模型权重，还要保存：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e梯度；\u003c/li\u003e\n\u003cli\u003e优化器状态；\u003c/li\u003e\n\u003cli\u003e中间计算结果；\u003c/li\u003e\n\u003cli\u003e激活值；\u003c/li\u003e\n\u003cli\u003e训练数据batch。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e也就是说，训练不是只把模型“装进去”就行，还要为修改参数准备一整套额外空间。\u003c/p\u003e\n\u003cp\u003e同一个7B模型，推理可能几GB到十几GB就能跑起来；训练时，单是参数相关状态就可能需要上百GB，再加上中间结果，需求会继续增加。\u003c/p\u003e\n\u003cp\u003e所以你会看到一个现象：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e普通电脑可以推理一个不小的模型，却很难训练一个比它更小的模型。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e原因不是模型名字大小的问题，而是任务性质不同。\u003c/p\u003e","title":"训练和推理，到底差在哪？为什么你能跑大模型，却训练不了小模型"},{"content":"我们一开始买 AI 设备，第一眼看的是算力，会想需要多少 TFLOPS？多少 TOPS？GPU 核心多不多？NPU 强不强？\n但真正用来跑本地大模型时，你很快会发现：算力不是唯一答案，甚至很多时候不是第一答案。\n有的机器纸面算力很高，但模型装不进去。 有的机器勉强能装进去，但生成速度很慢。 有的机器看起来参数一般，实际跑 7B、14B 模型却很舒服。 还有的设备明明没有独立显卡，却能跑一些消费级显卡装不下的大模型。 问题就出在三个经常被混在一起的词上：显存、内存、算力。\n显存和内存，听起来就差一个字。算力又经常被厂商放在宣传页最显眼的位置。于是很多人买设备时容易陷入一个误区：\n只看谁算力大，忽略模型到底装不装得下，也忽略数据搬运跟不跟得上。\n这篇文章用一个后厨的比喻，把这三个概念一次讲清楚。看完你就会明白：\nAI 设备不是单纯看谁算力大，而是看容量、带宽、算力是否匹配。\n一、显存和内存：同一种东西，两种性格 先说一个容易被忽略的事实：显存和内存，物理上是同一类东西——都是 DRAM 存储芯片，都是用来临时存放数据的。\n但它们服务的对象不同。\n内存 RAM，主要服务 CPU。\n电脑系统、浏览器、微信、Word、Python、数据库、剪辑软件、开发工具，大部分普通程序运行时都要占用内存。\nCPU 的工作特点是：任务杂、跳跃性强、经常处理零散请求。一会儿处理键盘输入， 一会儿调度网络请求， 一会儿打开一个网页， 一会儿计算一个 Excel 表格。\n所以内存更看重的是：响应快、延迟低、系统调度灵活。\n你可以把内存理解为：\nCPU 面前的一张大办公桌。\n办公桌越大，能同时摊开的文件越多。内存越大，电脑就越能多任务，打开大量网页、软件、工程文件时也更不容易卡。\n显存 VRAM，主要服务 GPU。\nGPU 的工作方式和 CPU 不一样。CPU 更像少数几个能力全面的员工，什么活都能处理，但同时处理的数量有限。GPU 更像一整排流水线工人，每个人做的事情相对单一，但可以同时处理海量重复计算。\n比如：\n同时处理几百万个像素； 同时渲染大量纹理； 同时计算神经网络里一大批矩阵乘法； 同时处理模型权重和中间张量。 GPU 干活时，需要一次搬运很大的数据量。所以显存更看重的是：高带宽、大吞吐、离 GPU 足够近。\n你可以把显存理解为：\nGPU 旁边的高速专用工作台。\n工作台越大，模型、贴图、视频帧、中间计算结果就越能直接放在 GPU 身边。工作台的数据通道越宽，GPU 就越不容易“等数据”。\n所以显存和内存的区别，不只是名字不同，而是设计取向不同。\n显存和内存的区别 对比项 内存 RAM 显存 VRAM 主要服务对象 CPU GPU 典型用途 系统、软件、多任务 图形、视频、AI 推理、AI 训练 核心取向 低延迟、灵活调度 高带宽、大吞吐 物理位置 主板内存或统一封装内存 显卡上的专用高速内存 不够时的表现 系统卡顿、频繁换页 模型装不下、任务报错、速度骤降 一句话：\n内存决定电脑整体能不能顺畅运行；显存决定 GPU 任务能不能装下并高效运行。\n二、把电脑想象成一个后厨 为了更容易理解，可以把一台跑 AI 的机器想象成一个后厨。\n这个后厨里有几样关键东西。\n算力，是厨师的手速。\n厨师切菜快不快、翻锅快不快、同时能处理多少锅菜，对应的就是芯片的计算能力。放到硬件参数里，就是 FLOPS、TFLOPS、TOPS 这些指标。\n显存，是灶台旁边的备菜台。\n厨师真正下锅时，最需要的是伸手就能拿到食材。模型权重、中间计算结果、KV Cache、图像数据，都要尽量摆在这个备菜台上。\n备菜台有两个重要指标：\n面积：对应显存容量； 传菜速度：对应显存带宽。 显存容量不够，食材摆不下。\n显存带宽不够，食材送不上来。\n内存，是后厨里的仓库。\n上一节说内存是 CPU 的办公桌，那是 CPU 的视角。换到 GPU 的视角，内存就成了仓库：东西放得下，但不在灶台边上。\n仓库空间可以很大，但它离灶台更远。食材放在仓库里不是不能用，而是拿取成本更高。如果 GPU 每做一步都要从内存里搬数据，速度就会明显下降。\n硬盘，是城外冷库。\n硬盘容量更大，但速度更慢。它适合长期存储文件、模型、数据集，不适合作为 GPU 实时计算的工作区。\n用后厨比喻 AI 硬件 这个比喻可以解释很多现象。\n为什么显存不够，模型可能直接跑不了？ 因为模型权重、KV Cache 和运行开销没有足够空间摆上备菜台。\n为什么“显存不够，用内存凑”会很慢？ 因为厨师每做一步都要去仓库搬食材，中间通道再宽，也比不上灶台旁边直接拿。\n为什么顶级 AI GPU 要堆 HBM？ 因为大模型不是只需要厨师手快，还需要食材源源不断送到手边。HBM 的价值就在于提供极高的显存带宽。\n三、三个参数，三种角色 理解了后厨，就可以把显存、内存、算力的关系压缩成一句话：\n容量决定能不能跑，带宽决定日常快不快，算力决定长输入和高并发顶不顶得住。\n这句话比“显卡越强越好”更接近真实情况。\n1. 容量是门槛：装不下，一切免谈 跑本地大模型，第一件事不是看算力，而是看模型能不能装进去。\n模型运行时主要占用几类空间：\n模型权重； KV Cache； 上下文缓存； 推理框架开销； 系统和其他程序占用。 很多人只看模型文件大小，以为 20GB 的模型放进 24GB 显存就一定没问题。实际并不是这样。\n因为模型运行时还会额外占用空间。尤其是上下文长度越长，KV Cache 占用越大。你把上下文从 4K 拉到 32K，不只是“多放了一些文字”，而是模型需要保存更多中间状态。\n所以经常会出现这种情况：\n模型能加载，但一拉长上下文就爆显存。\n这也是为什么本地大模型选型时，显存或统一内存容量是第一道门槛。\n7B、8B 模型相对容易跑。\n14B 模型开始明显吃资源。\n32B 模型对显存和内存就有更高要求。\n70B 模型即使量化，也不是普通消费级设备可以轻松处理的。\n容量不够时，算力再强也没意义。\n这就像厨师再厉害，备菜台摆不下食材，也没法开工。\n2. 带宽决定日常速度：大模型推理经常是“搬运密集型” 很多人以为大模型生成慢，是因为“算不过来”。这只说对了一半。\n对大模型推理来说，尤其是日常聊天、写作、问答这种逐字生成场景，瓶颈经常不是纯计算，而是数据搬运。\n大模型生成回答，大致分两个阶段：\nPrefill：读入你的问题和上下文； Decode：一个 token 一个 token 地生成回答。 大模型推理的两个阶段 在 Decode 阶段，模型每生成一个 token，都要访问大量模型权重。对稠密模型来说，绝大部分权重都要参与计算。这时 GPU 很多时候不是“不会算”，而是“等数据送过来”。\n所以显存带宽非常重要。\n你可以粗略理解为：\n每秒生成 token 的速度，很大程度上取决于模型每一步要搬多少数据，以及显存带宽能多快把数据送到 GPU。\n这也是为什么一些纸面算力很高的设备，跑大模型未必特别快。因为算力高只是说明厨师手速快，但如果传菜通道太窄，厨师也会等米下锅。\nMoE 模型在这里有一个优势。\nMoE 模型总参数量可能很大，但每生成一个 token 时，只激活其中一部分专家。换句话说，它的总菜谱很厚，但每道菜真正用到的食材没有那么多。\n所以在带宽受限的设备上，MoE 模型有时会比同等总参数量的稠密模型更友好。\n3. 算力决定上限：长 prompt 和高并发时才轮到它主场 那算力到底重要不重要？——当然重要。\n只是它重要的场景，不完全等同于很多人想象中的“生成每个字都只看算力”。\n在大模型推理里，算力最明显发挥作用的阶段，是 Prefill。\n也就是模型读入你的问题、长文档、代码仓库、PDF 内容的阶段。\n如果你只是问一句：\n帮我写一段朋友圈文案。\n这时输入很短，Prefill 压力不大。\n但如果你扔进去的是：\n一篇 2 万字文章； 一份几十页 PDF； 一个长代码文件； 一大段会议纪要； 多轮复杂上下文； 这时候模型要先“读题”。输入 token 越多，Prefill 阶段越重。算力弱的机器，就会出现明显的首字延迟。\n也就是：\n回答一旦开始生成，速度还可以；\n但第一个字出来之前，要等很久。\n这就是算力在长上下文场景里的作用。\n所以更准确的说法是：\n显存 / 内存容量：决定模型能不能装下； 显存 / 内存带宽：决定日常生成快不快； 算力：决定长输入处理、高并发、复杂计算场景顶不顶得住。 四、Mac 的统一内存：把仓库和备菜台部分打通了 在Mac中会出现这样的情况：\nMac 没有独立显存，为什么还能跑本地大模型？\n这是因为 Apple Silicon 使用的是统一内存架构。\n传统 PC 里，CPU 用系统内存，GPU 用独立显存。两边是分开的。数据经常需要在内存和显存之间复制。\nApple Silicon 的思路不一样。CPU、GPU、NPU 共享同一块统一内存池。你可以把它理解为：\n后厨仓库和备菜台之间的隔墙被打掉了，变成了一个更大的共享工作区。\n这带来了一个非常现实的好处：容量更灵活。\n传统消费级独立显卡，显存容量通常是 8GB、12GB、16GB、24GB。再往上就进入专业卡、数据中心卡或者多卡方案。\n而 Mac 可以提供 32GB、64GB、96GB、128GB 甚至更高规格的统一内存。对于本地大模型来说，这意味着一些消费级显卡装不下的量化模型，Mac 反而有机会装进去。\n这里特别需要关注的是：\nMac 的统一内存不等于 NVIDIA 显卡的独立显存。\n统一内存确实能被 GPU 分配使用，但系统、应用、推理框架、缓存都会占用一部分空间，不是标称 64GB 就能完整拿来当 64GB 显存。\n同时，统一内存的带宽也要具体看芯片型号。它通常明显强于普通 DDR 内存，但和高端 NVIDIA GPU 的 GDDR6X、HBM 相比，仍然有差距。\n所以 Mac 跑本地大模型的特点可以这样理解：\n维度 Mac 统一内存的表现 容量 优势明显，适合装较大的量化模型 带宽 比普通内存强，但不等同于高端 HBM 算力 日常推理够用，但和高端 NVIDIA GPU 有差距 生态 MLX 体验越来越好，但 CUDA 生态仍然更强 适合场景 本地写作、总结、轻量代码、个人知识库 不适合场景 大规模训练、高并发服务、极限推理性能 Mac 的优势是“能装得下”和“日常够用”，不是在所有 AI 场景下都比独立显卡更快。\n如果你主要是个人使用，跑 7B、14B、部分 32B 量化模型，Mac 的统一内存很有价值。\n但如果你要训练模型、做高并发推理、追求极限 token 速度，NVIDIA 大显存显卡仍然是主流方案。\n五、买 AI 设备，先看这三个问题 看懂显存、内存和算力之后，买设备时就不要只盯着“多少 TFLOPS”了。\n更实用的判断顺序是三个问题。\n第一：模型装不装得下？ 这是容量问题。\n跑本地大模型时，先看显存或统一内存够不够。模型权重、KV Cache、上下文长度、运行框架都会占空间。\n容量不够，结果通常有几种：\n模型无法加载； 一拉长上下文就报错； 只能换更低量化版本； 只能把部分计算放到 CPU； 速度慢到不想用。 所以买设备时，第一步不是问“这台机器算力多强”，而是问：\n我要跑的模型，它装得下吗？\n大致可以这样判断：\n需求 更应该关注什么 跑 7B / 8B 模型 16GB 内存或 8GB 显存起步 跑 14B 模型 24GB 内存或 12GB+ 显存更稳 跑 32B 模型 32GB 以上统一内存，或 24GB 显存更合适 跑 70B 量化模型 64GB+ 统一内存、多卡或专业大显存方案更现实 训练模型 优先大显存 NVIDIA GPU 这不是绝对标准，因为不同模型结构、量化格式、上下文长度都会影响占用。但作为普通用户的第一轮判断，已经够用。\n第二：数据搬得快不快？ 这是带宽问题。\n模型装得下，只说明你过了第一关。接下来要看它跑起来快不快。\n大模型生成文字时，经常需要反复读取大量权重和中间数据。显存带宽越高，数据越能及时送到 GPU，生成速度通常越稳。\n所以你会看到：\n同样是 24GB 显存，不同显卡速度差距明显； 同样能跑 32B 模型，有的机器流畅，有的机器拖沓； 同样参数规模，MoE 模型在某些设备上体验更好。 原因之一就是带宽不同。\n如果你主要做本地聊天、写作、改稿、总结、问答，带宽对体验的影响非常直接。\n这时不要只看“模型能不能加载”，还要看：\n它每秒能生成多少 token？\n长对话会不会越来越慢？\n上下文拉长后还能不能保持可用速度？\n第三：长输入处理得快不快？ 这是算力问题。\n算力最容易体现在几个场景：\n读取长文档； 分析代码仓库； 总结几十页 PDF； 多用户并发推理； 大 batch 推理； 模型训练或微调。 如果你经常让模型处理长资料，就不能只看显存容量。因为模型读入大量上下文时，Prefill 阶段会明显吃算力。\n这时候算力弱的机器会出现一种典型体验：\n模型不是不能回答，而是第一个字出来之前等得很久。\n所以，我们可以记住这个顺序：\n先看容量，决定能不能跑；\n再看带宽，决定日常快不快；\n最后看算力，决定长输入和高并发顶不顶得住。\n这个顺序比单纯看宣传页上的算力数字更可靠。\n六、不同使用场景，该优先看什么？ 把上面的逻辑落到实际选择，可以整理成一张表。\n使用场景 第一优先级 第二优先级 容易被什么误导 普通办公 内存容量 SSD 速度 迷信独显 AI 绘图 显存容量 GPU 算力 只看核心数 本地大模型 7B / 8B 内存 / 显存容量 推理框架优化 以为所有设备都一样快 本地大模型 14B 显存 / 统一内存 带宽 只看模型文件大小 本地大模型 32B+ 容量 带宽 低估 KV Cache 占用 长文档总结 算力 + 带宽 上下文容量 只看模型参数量 模型训练 / 微调 显存容量 CUDA / Tensor Core 生态 用消费级设备硬扛 多用户部署 显存容量 + 算力 带宽和并发优化 只看单用户速度 如果你只是个人使用，本地跑模型写文章、做总结、改代码、做轻量知识库，核心不是追求最强算力，而是让容量、带宽和模型规模匹配。\n如果你的目标是稳定生产力，优先级应该是：\n先确定你常用多大模型； 再确定上下文长度需求； 再看设备能不能完整承载； 最后再比较生成速度和首字延迟。 这比直接问“买哪台最强”更有效。\n七、三者关系 概念 后厨角色 关键指标 决定什么 内存 RAM 仓库 / 大办公桌 容量、延迟、带宽 系统流畅度、多任务能力、部分模型承载能力 显存 VRAM 灶台旁边的备菜台 容量、带宽 GPU 任务能不能装下、生成速度快不快 算力 FLOPS / TOPS 厨师手速 FP16、BF16、INT8、INT4 等计算能力 长输入处理、高并发、训练和复杂计算能力 带宽 传菜速度 GB/s、TB/s 数据能不能及时喂给计算单元 硬盘 SSD 冷库 容量、读写速度 长期存储模型和文件，不适合实时计算 下次再看到一张设备参数表，上面写着：\nXX GB 显存； XX GB 内存； XX TB/s 带宽； XX TFLOPS 算力； 可以先在心里问三个问题：\n第一：容量够不够？\n不够，模型装不下，后面都不用看。\n第二：带宽大不大？\n它很大程度上决定日常生成体验。\n第三：算力强不强？\n它决定长文档、复杂输入、高并发和训练任务能不能顶住。\n所以，显存、内存、算力不是谁替代谁的关系，而是分工不同。\n显存 / 内存决定你能不能把模型摆上桌；\n带宽决定数据能不能及时送到手边；\n算力决定厨师真正开工后能做到多快。\n买 AI 设备，最怕只看一个数字。 真正应该看的，是这三件事是否匹配。\n本文是「术语解构」系列的一篇。这个系列的目标是：把 AI 基础设施领域的黑话，一个一个翻译成人话。\n","permalink":"https://blog.onecai.site/2026/06/28/026-vram-ram-compute-ai/","summary":"\u003cp\u003e我们一开始买 AI 设备，第一眼看的是算力，会想需要\u003cstrong\u003e多少 TFLOPS？多少 TOPS？GPU 核心多不多？NPU 强不强？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e但真正用来跑本地大模型时，你很快会发现：\u003cstrong\u003e算力不是唯一答案，甚至很多时候不是第一答案。\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e有的机器纸面算力很高，但模型装不进去。\u003c/li\u003e\n\u003cli\u003e有的机器勉强能装进去，但生成速度很慢。\u003c/li\u003e\n\u003cli\u003e有的机器看起来参数一般，实际跑 7B、14B 模型却很舒服。\u003c/li\u003e\n\u003cli\u003e还有的设备明明没有独立显卡，却能跑一些消费级显卡装不下的大模型。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e问题就出在三个经常被混在一起的词上：\u003cstrong\u003e显存、内存、算力。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e显存和内存，听起来就差一个字。算力又经常被厂商放在宣传页最显眼的位置。于是很多人买设备时容易陷入一个误区：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e只看谁算力大，忽略模型到底装不装得下，也忽略数据搬运跟不跟得上。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这篇文章用一个后厨的比喻，把这三个概念一次讲清楚。看完你就会明白：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAI 设备不是单纯看谁算力大，而是看容量、带宽、算力是否匹配。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"一显存和内存同一种东西两种性格\"\u003e一、显存和内存：同一种东西，两种性格\u003c/h2\u003e\n\u003cp\u003e先说一个容易被忽略的事实：\u003cstrong\u003e显存和内存，物理上是同一类东西——都是 DRAM 存储芯片，都是用来临时存放数据的。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e但它们服务的对象不同。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e内存 RAM，主要服务 CPU。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e电脑系统、浏览器、微信、Word、Python、数据库、剪辑软件、开发工具，大部分普通程序运行时都要占用内存。\u003c/p\u003e\n\u003cp\u003eCPU 的工作特点是：任务杂、跳跃性强、经常处理零散请求。一会儿处理键盘输入，  一会儿调度网络请求，  一会儿打开一个网页，  一会儿计算一个 Excel 表格。\u003c/p\u003e\n\u003cp\u003e所以内存更看重的是：\u003cstrong\u003e响应快、延迟低、系统调度灵活。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你可以把内存理解为：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eCPU 面前的一张大办公桌。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e办公桌越大，能同时摊开的文件越多。内存越大，电脑就越能多任务，打开大量网页、软件、工程文件时也更不容易卡。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003e显存 VRAM，主要服务 GPU。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eGPU 的工作方式和 CPU 不一样。CPU 更像少数几个能力全面的员工，什么活都能处理，但同时处理的数量有限。GPU 更像一整排流水线工人，每个人做的事情相对单一，但可以同时处理海量重复计算。\u003c/p\u003e\n\u003cp\u003e比如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e同时处理几百万个像素；\u003c/li\u003e\n\u003cli\u003e同时渲染大量纹理；\u003c/li\u003e\n\u003cli\u003e同时计算神经网络里一大批矩阵乘法；\u003c/li\u003e\n\u003cli\u003e同时处理模型权重和中间张量。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGPU 干活时，需要一次搬运很大的数据量。所以显存更看重的是：\u003cstrong\u003e高带宽、大吞吐、离 GPU 足够近。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你可以把显存理解为：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eGPU 旁边的高速专用工作台。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e工作台越大，模型、贴图、视频帧、中间计算结果就越能直接放在 GPU 身边。工作台的数据通道越宽，GPU 就越不容易“等数据”。\u003c/p\u003e\n\u003cp\u003e所以显存和内存的区别，不只是名字不同，而是设计取向不同。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"vram-1.avif\"\n          alt=\"显存和内存的区别\"/\u003e \u003cfigcaption\u003e\n             显存和内存的区别\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e对比项\u003c/th\u003e\n          \u003cth\u003e内存 RAM\u003c/th\u003e\n          \u003cth\u003e显存 VRAM\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e主要服务对象\u003c/td\u003e\n          \u003ctd\u003eCPU\u003c/td\u003e\n          \u003ctd\u003eGPU\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e典型用途\u003c/td\u003e\n          \u003ctd\u003e系统、软件、多任务\u003c/td\u003e\n          \u003ctd\u003e图形、视频、AI 推理、AI 训练\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e核心取向\u003c/td\u003e\n          \u003ctd\u003e低延迟、灵活调度\u003c/td\u003e\n          \u003ctd\u003e高带宽、大吞吐\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e物理位置\u003c/td\u003e\n          \u003ctd\u003e主板内存或统一封装内存\u003c/td\u003e\n          \u003ctd\u003e显卡上的专用高速内存\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e不够时的表现\u003c/td\u003e\n          \u003ctd\u003e系统卡顿、频繁换页\u003c/td\u003e\n          \u003ctd\u003e模型装不下、任务报错、速度骤降\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e一句话：\u003c/p\u003e","title":"显存、内存、算力，到底谁决定你的 AI 跑得快？"},{"content":"很多人第一次听到token，是在用AI的时候。\n比如你让AI总结一份很长的PDF，它可能提示“内容太长”。你让AI写一篇长文章，它有时候写到后面会忘记前面说过什么。你看一些AI工具的收费说明，又会发现它不是按“字数”收费，而是按token收费。\ntoken到底是什么？\n它是一个字吗？是一个词吗？还是一段话？\n简单说，token可以理解成AI处理文字时使用的“基本颗粒”。\nAI不是像人一样按一篇文章、一页纸、一个段落来理解文本，而是先把文字切成一个个token，再进行读取、理解和生成。\n所以，token不是一个离我们现实生活很远的技术词，它会直接影响AI能读多长的内容、写多快、花多少钱，以及本地模型要占多少内存。\n一、什么是token token 影响 AI 的速度、成本、上下文和内存 第一：token不是固定等于一个字。\n在中文里，一个token可能接近一个字，也可能是一段词的一部分。在英文里，一个token可能是一个单词，也可能只是单词的一部分。\n举个例子，“今天天气不错”这句话，模型不一定是按“今天／天气／不错”这样符合我们语感的方式切分，它可能切成“今天”“天气”“不错”，也可能切成更细碎的片段，具体取决于模型用的分词方式。\n同样，英文单词“tokenization”也常常会被切成“token”+“ization”两个片段，而不是当成一个完整单词处理。所以不能简单理解成：\n1个token=1个字。\n这个理解不准确。\n第二：token是AI处理文本时的基本计量单位。\n人看到的是一句话、一段话、一篇文章。\n但AI看到的不是完整文章，而是一串被切分过的token，它先把文字拆开，再进行计算。\n第三：输入和输出都会消耗token。\n你发给AI的提示词、资料、PDF内容、历史对话，都是输入token，而对于AI，是以输出token的方式回应你的要求。\n很多人只看AI最后写了多少字，却忽略了前面塞进去的资料、提示词和对话历史，这也都在占“token”。\n第四：token越多，AI处理压力越大。\ntoken越多，模型要读的信息越多，信息越多，就会影响速度、成本、上下文长度、内存占用。token不是一个纯技术词，而是理解AI使用成本和体验的入口。\n二、token和字数是什么关系？ 很多人最容易误解的地方，就是把token直接等同于字数，这不准确，因为不同语言、不同内容、不同符号，被切分成token的方式不一样。可以简单看这个表：\n内容类型 我们看到的单位 AI处理时的单位 中文文章 字、句子、段落 token 英文文章 单词、句子 token 代码 变量、符号、缩进 token 表格 行、列、字段 token PDF内容 页数、段落 token 对话记录 一轮一轮聊天 token 我们不需要精确记住每句话会被切成多少token，只要记住一个大方向：文字越多，结构越复杂，token通常就越多。 如果想有个粗略的量感，可以记一个大致的经验范围：中文大概1～2个字对应1个token，英文大概3～4个字母对应1个token，不需要精确，只是一个方便估算的尺子。\n比如：\n一段普通聊天，token很少。 一篇3000字公众号文章，token明显增加。 一份几十页PDF，再加上你让AI总结、改写、提炼标题，token就会继续增加。 如果你还让AI保留前面的所有对话，再继续修改，历史对话也会继续占token。\n所以AI处理内容时，真正看的不是你主观感觉“这也没多少字”，而是模型内部实际要处理多少token。\n三、为什么AI不按字数算，而按token算？ 这个问题很重要，因为在我们的习惯里，文章是按字数算的，比如公众号文章3000字、作文800字、报告5000字，而AI模型真正处理的，是token序列。\n你可以理解成：\n字数是给人看的单位，token是给模型算的单位。\n为什么不能直接按字数算？原因可能是以下三个方面：\n1. 不同语言的切分方式不同 中文、英文、数字、标点、代码，被拆分的方式都不一样。\n比如英文里，一个常见单词可能是一个token，也可能被拆成多个token。\n代码里，一个函数名、一个括号、一个缩进，也可能都会影响token数量。\n中文也不是永远一个字一个token。所以，用“字数”作为统一标准并不准确。\n2. AI真正处理的是token序列 模型不是直接读一篇完整文章。\n它先把文字转换成token，再把token转换成模型可以计算的表示，然后模型根据前面的token，预测后面最可能出现的token。这就是大语言模型生成文字的基本过程。\n所以从模型角度看，它不是在写“字”，而是在一个token一个token地生成内容。\n3. token更适合衡量成本 AI服务为什么按token计费？\n因为token更接近模型真实的计算量，输入token越多，模型要读的内容越多；输出token越多，模型要生成的内容越多。这两部分都会消耗计算资源。\n所以，按token计费，虽然一开始看起来不直观，但它比按“字数”“篇数”“页数”更接近AI的实际工作方式。\n四、token对使用AI的我们有什么影响？ token不是一个只属于程序员的概念。\n我们在使用AI时，很多体验问题都和token有关：\n你遇到的问题 背后的token原因 AI提示内容太长 输入token超过上下文限制 长文总结容易漏内容 token太多，模型注意力被拉长 AI写长文变慢 输出token越多，生成时间越长 API调用变贵 输入和输出token都会计费 聊久了AI忘记前文 对话历史token太多，旧内容被截断或弱化 本地模型占内存变高 长上下文会带来额外内存压力 同一个问题换种问法成本不同 提示词长度不同，token消耗不同 举个简单例子：\n你让AI写一句标题，消耗的token很少。 你让AI写一篇完整文章，消耗的token会明显增加。 你先丢给AI一万字资料，再让它总结、提炼、改写、生成标题、写朋友圈文案，消耗的token就不只是最后那篇文章，而是整个过程。 这也是为什么很多AI工具会限制单次输入长度、文件大小、对话轮数、上下文长度、输出长度——表面上看，是工具不给你用，本质上看，是token有上限，计算资源也有成本。这也是为什么一直以来免费的豆包也推出了付费版，现在的免费版豆包也会提示“今日额度已用完”。\n这里有一个容易被忽略的点：AI消耗的不是最后那篇文章的字数，而是整个对话过程中输入和输出的token。\n比如你最后只得到一篇3000字文章，但在生成这篇文章之前，你可能给了它：\n一段选题说明 一份参考资料 一套写作要求 一份标题规则 几轮修改意见 一些历史对话背景 这些都会进入token消耗。\n所以，当你发现AI写文章越来越慢、回答越来越短、或者开始忘记前面的要求时，不一定是模型突然变差了，也可能是上下文里的token太多了。\n五、token和“上下文长度”是什么关系？ 现在很多模型介绍里都会写 8K 上下文、32K 上下文、128K 上下文、1M 上下文，这里的K，通常就是指token数量级。\n看到长上下文，我们一般会直接理解成——这个模型能读更多内容，所以一定更好，这个判断只对了一半。\n长上下文确实有用，它能让模型一次读更多资料，保留更长对话，处理更复杂的任务，但长上下文也不是免费的。上下文越长，模型需要同时处理的信息越多，速度、成本和内存压力都会上升。\n尤其在本地模型里，这一点更明显。你在云端用AI，成本主要体现在服务费用和响应速度上；你在Mac或本地电脑上跑模型，成本就会直接体现在内存、显存和运行速度上。\n这也是为什么同一个模型，在 8K 上下文下可以跑得比较舒服，开到 32K 以后就可能明显变慢，甚至爆内存。\n所以，我们理解上下文长度，不要只看“越长越好”，更准确的理解是：\n上下文长度决定AI这次最多能同时记住多少token，但记得越多，处理压力也越大。\n六、token和本地模型有什么关系？ 本地模型为什么会被上下文拖慢 如果你只用云端AI工具、不打算在本地跑模型，可以直接跳到“七、怎么用好token这个概念”。\n如果你只是用云端AI，token主要影响费用、速度和上下文，但如果你开始在Mac上跑本地模型，token就会和内存直接挂钩。\n很多人在选本地模型时，只看参数量，比如7B、14B、32B、70B，参数量当然重要，但它不是唯一因素。\n本地模型能不能跑得舒服，还要看上下文长度、量化方式、KV Cache、内存带宽等因素。可以简单理解成下面这个表：\n概念 普通理解 模型参数量 这颗“大脑”本身有多大 量化等级 这颗“大脑”被压缩到什么程度 上下文长度 这次最多要同时记住多少token KV Cache 为了记住上下文临时占用的工作空间 内存/显存 模型运行时可用的工作台 为什么同一个本地模型，有时候能跑，有时候卡？\n一个重要原因就是上下文设置不同。如果你仅仅向AI问一句话，模型压力不大。但是你让它读一篇长文、保持几十轮对话、再写一篇完整分析，token数增加，KV Cache压力也会上来。这时候，内存占用就可能明显增加。\n所以本地模型不是只看“我能不能加载这个模型”，更重要的是：在你真实使用场景下，它能不能稳定处理足够多的token。\n这也是为什么 24GB 内存的 Mac 跑本地模型时，不能只看模型参数量，还要看上下文开多大、量化格式怎么选、任务到底有多长。\n七、怎么用好token这个概念？ 我们怎么用好 token 理解token，不是为了每天去计算token数，更需要的是用它改善AI使用方式。从实用性上来说：\n1. 提示词不要无意义堆长 很多人写提示词，喜欢把所有背景一次性塞进去，但提示词绝不是越长越好。如果背景很长，却和任务没关系，只会增加token，增加模型负担。\n在使用AI过程中更好的方式是：先说任务目标，再补充必要背景。\n比如不要一上来就粘贴几千字资料，可以先告诉AI：\n我接下来会给你一篇文章，请先只提炼结构，不要改写。\n这样任务更清楚，也更省token。\n2. 长文资料要分段处理 如果你要让AI总结一份很长的资料，不建议一次性全部丢进去，更稳的方式是：\n第一步，分段总结。 第二步，合并要点。 第三步，再让AI形成完整文章。 这样比一次性让AI读完所有内容再输出，通常更稳定。\n3. 多轮对话后要做阶段性摘要 如果一个对话聊了很久，历史内容会不断占用token，有时候你觉得AI开始“走偏”了。这时候可以主动让AI做一次阶段性摘要。\n比如：\n请把目前已经确定的要求整理成一份简短项目说明，后续回答只按这份说明执行。\n这样可以减少历史对话负担，也能降低AI忘记重点的概率。\n4. 本地模型不要盲目开超长上下文 很多本地模型工具里可以设置上下文长度，看到 32K、64K，不要本能地拉满。如果你只是日常问答、写短文、改标题，8K 或 16K 可能就够用；如果你要处理长文、PDF、代码项目，再考虑更长上下文。\n上下文开得越长，不代表效果一定越好，更可能的是它也会带来速度和内存压力。\n5. 用API时要同时看输入和输出 如果你用API做自动化，比如总结文章、生成日报、批量写文案，就不能只看输出。\n输入的资料越长，成本也会上升，尤其是批量任务，token消耗会被放大。一篇文章多消耗一点看不出来，一百篇、一千篇之后，成本差异就明显了，token消耗量很快就会告急。\n八、token不是越少越好，也不是越多越好 token不是越少越好——如果你给AI的背景太少，它可能理解不清任务，输出就会空泛。\ntoken也不是越多越好——如果你把大量无关信息都塞进去，模型反而更容易抓不住重点，速度也会变慢，成本也会上升。token越多，只利好算力提供商。\n更好的状态是：给AI足够完成任务的信息，但不要给它一堆无关负担。\n这和人沟通其实很像。你请别人帮你写一篇文章，不能只说“帮我写一篇”，那信息太少；但你也没必要把所有聊天记录、所有参考链接、所有想法碎片都丢过去，那信息太乱。\n最好的方式是：目标清楚，背景适量，要求明确，分步骤推进。\n这就是我们日常使用token概念最实际的意义。\n九、最后总结 token不是一个必须背定义的技术词：AI不是按字、按页、按篇处理内容，而是按token这种“文字颗粒”处理内容。\n它影响AI能读多长、写多快、花多少钱，也影响本地模型占多少内存。\n理解token，不是为了变成工程师，而是为了更清楚地使用AI。\n当你知道AI是按token工作之后，会发现AI嫌内容太长、长文总结容易漏、API按token收费、本地模型开长上下文更吃内存、同一个模型有时快有时慢——这些看似不同的问题，背后都指向同一个原理：AI处理的从来不是“字”，而是token。\n","permalink":"https://blog.onecai.site/2026/06/27/025-whatisthetoken/","summary":"\u003cp\u003e很多人第一次听到token，是在用AI的时候。\u003c/p\u003e\n\u003cp\u003e比如你让AI总结一份很长的PDF，它可能提示“内容太长”。你让AI写一篇长文章，它有时候写到后面会忘记前面说过什么。你看一些AI工具的收费说明，又会发现它不是按“字数”收费，而是按token收费。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003etoken到底是什么？\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e它是一个字吗？是一个词吗？还是一段话？\u003c/p\u003e\n\u003cp\u003e简单说，token可以理解成AI处理文字时使用的“基本颗粒”。\u003c/p\u003e\n\u003cp\u003eAI不是像人一样按一篇文章、一页纸、一个段落来理解文本，而是先把文字切成一个个token，再进行读取、理解和生成。\u003c/p\u003e\n\u003cp\u003e所以，token不是一个离我们现实生活很远的技术词，它会直接影响AI能读多长的内容、写多快、花多少钱，以及本地模型要占多少内存。\u003c/p\u003e\n\u003ch2 id=\"一什么是token\"\u003e一、什么是token\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"token-1.avif\"\n          alt=\" token 影响 AI 的速度、成本、上下文和内存\"/\u003e \u003cfigcaption\u003e\n              token 影响 AI 的速度、成本、上下文和内存\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cstrong\u003e第一：token不是固定等于一个字。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在中文里，一个token可能接近一个字，也可能是一段词的一部分。在英文里，一个token可能是一个单词，也可能只是单词的一部分。\u003c/p\u003e\n\u003cp\u003e举个例子，“今天天气不错”这句话，模型不一定是按“今天／天气／不错”这样符合我们语感的方式切分，它可能切成“今天”“天气”“不错”，也可能切成更细碎的片段，具体取决于模型用的分词方式。\u003c/p\u003e\n\u003cp\u003e同样，英文单词“tokenization”也常常会被切成“token”+“ization”两个片段，而不是当成一个完整单词处理。所以不能简单理解成：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e1个token=1个字。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这个理解不准确。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二：token是AI处理文本时的基本计量单位。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e人看到的是一句话、一段话、一篇文章。\u003c/p\u003e\n\u003cp\u003e但AI看到的不是完整文章，而是一串被切分过的token，它先把文字拆开，再进行计算。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三：输入和输出都会消耗token。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你发给AI的提示词、资料、PDF内容、历史对话，都是输入token，而对于AI，是以输出token的方式回应你的要求。\u003c/p\u003e\n\u003cp\u003e很多人只看AI最后写了多少字，却忽略了前面塞进去的资料、提示词和对话历史，这也都在占“token”。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第四：token越多，AI处理压力越大。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003etoken越多，模型要读的信息越多，信息越多，就会影响\u003cstrong\u003e速度、成本、上下文长度、内存占用\u003c/strong\u003e。token不是一个纯技术词，而是理解AI使用成本和体验的入口。\u003c/p\u003e\n\u003ch2 id=\"二token和字数是什么关系\"\u003e二、token和字数是什么关系？\u003c/h2\u003e\n\u003cp\u003e很多人最容易误解的地方，就是把token直接等同于字数，这不准确，因为不同语言、不同内容、不同符号，被切分成token的方式不一样。可以简单看这个表：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e内容类型\u003c/th\u003e\n          \u003cth\u003e我们看到的单位\u003c/th\u003e\n          \u003cth\u003eAI处理时的单位\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e中文文章\u003c/td\u003e\n          \u003ctd\u003e字、句子、段落\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e英文文章\u003c/td\u003e\n          \u003ctd\u003e单词、句子\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e代码\u003c/td\u003e\n          \u003ctd\u003e变量、符号、缩进\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e表格\u003c/td\u003e\n          \u003ctd\u003e行、列、字段\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003ePDF内容\u003c/td\u003e\n          \u003ctd\u003e页数、段落\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e对话记录\u003c/td\u003e\n          \u003ctd\u003e一轮一轮聊天\u003c/td\u003e\n          \u003ctd\u003etoken\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e我们不需要精确记住每句话会被切成多少token，只要记住一个大方向：\u003cstrong\u003e文字越多，结构越复杂，token通常就越多。\u003c/strong\u003e 如果想有个粗略的量感，可以记一个大致的经验范围：中文大概1～2个字对应1个token，英文大概3～4个字母对应1个token，不需要精确，只是一个方便估算的尺子。\u003c/p\u003e\n\u003cp\u003e比如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e一段普通聊天，token很少。\u003c/li\u003e\n\u003cli\u003e一篇3000字公众号文章，token明显增加。\u003c/li\u003e\n\u003cli\u003e一份几十页PDF，再加上你让AI总结、改写、提炼标题，token就会继续增加。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003e如果你还让AI保留前面的所有对话，再继续修改，\u003cstrong\u003e历史对话也会继续占token\u003c/strong\u003e。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e所以AI处理内容时，真正看的不是你主观感觉“这也没多少字”，而是模型内部实际要处理多少token。\u003c/p\u003e\n\u003ch2 id=\"三为什么ai不按字数算而按token算\"\u003e三、为什么AI不按字数算，而按token算？\u003c/h2\u003e\n\u003cp\u003e这个问题很重要，因为在我们的习惯里，文章是按字数算的，比如公众号文章3000字、作文800字、报告5000字，而AI模型真正处理的，是token序列。\u003c/p\u003e\n\u003cp\u003e你可以理解成：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e字数是给人看的单位，token是给模型算的单位。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e为什么不能直接按字数算？原因可能是以下三个方面：\u003c/p\u003e\n\u003ch3 id=\"1-不同语言的切分方式不同\"\u003e1. 不同语言的切分方式不同\u003c/h3\u003e\n\u003cp\u003e中文、英文、数字、标点、代码，被拆分的方式都不一样。\u003c/p\u003e\n\u003cp\u003e比如英文里，一个常见单词可能是一个token，也可能被拆成多个token。\u003c/p\u003e","title":"token是什么？为什么AI不是按字数算账"},{"content":" 存储通胀：AI 数据中心把硬件账单递给普通消费者 AI 时代第一张递到普通人手里的硬件账单——「又强又便宜」的二十年，结束了\n6 月 25 日晚，苹果官网突然下线维护。几个小时后回来，价格表全变了：Mac、iPad 全线涨价，最高一台涨 3500 块，只有 iPhone、Apple Watch、AirPods 没动。\n社交平台上一片“苹果终于露出獠牙”的骂声。但如果你只看到这一层，就把这件事看小了。\n过去一年我们聊 AI，眼睛都盯着模型：谁更聪明、谁上下文更长、谁的智能体更像人。而你为 AI 付的钱，你以为是会员费、API、token——其实它正在悄悄变成另一个数字：你电脑价签上多出来的那几千块。\n苹果不是想多赚。它已经把成本“内部消化”了大半年，扛到 6 月才不得不把账单甩给消费者。而这张账单真正的开账人，在一千公里外的 AI 数据中心。\n下面把这条链一节一节拆开。\n一、账单：苹果到底涨了多少 苹果硬件价格集体上涨 先把数字砸出来，这是最直观的部分。中国区官网这一轮共 13 款产品调价，平均涨幅约 21%：\n产品 起售价变化（元） 涨幅 Mac Studio 16499 → 19999 +3500 MacBook Pro 13499 → 15999 +2500 iPad Pro 8999 → 10799 +1800 MacBook Air 8499 → 9999 +1500 iPad Air 4799 → 5999 +1200 MacBook Neo 4599 → 5499 +900 iPad（基础款） 2999 → 3799 +800 HomePod mini、Mac mini、iPad A16 这几款涨幅甚至超过 25%。Mac Studio 顶配叠加定制选项，部分机型总价涨幅超过 5000 元。\n消息一出，苹果美股盘中一度跌超 5%，一夜市值蒸发约 1.8 万亿人民币。\n注意一个细节：iPhone、Apple Watch、AirPods 一分没涨。 记住这个反常，第四节回收。\n二、钱到底去哪了 苹果这次没绕弯子，声明里把原因写得明明白白——内存和存储芯片成本持续飙升。原话大意是：AI 数据中心迅猛扩张导致存储需求激增，零部件涨价的幅度和速度，他们“前所未见”。\n翻译成硬数字：\nDDR5 内存：每 GB 采购价从 2025 年初的约 3 美元，涨到 2026 年 6 月的约 8 美元，涨幅超 160%； NAND 闪存：部分大容量型号涨幅超 200%。 谁在这场涨价里赚翻了？看美光就够了。苹果宣布涨价的前一天，美光交出季度财报，毛利率直接突破 80%。更关键的是管理层的口风——三个月前他们还说存储紧张“持续到今年年底”，这次直接改口“持续到 2027 年以后”。\n一句话：存储的定价权，已经被 HBM 和 AI 服务器抽走了。 你买 Mac 多掏的那几千块，本质上是在和黄仁勋的客户们抢同一批内存颗粒，而你抢不过。\n三、被打断的二十年 要明白这事有多反常，得回头看过去二十年我们默认的一个常识：\n今年买的电脑比三年前快，今年买的手机比三年前强；同样的钱，能买到更大内存、更大硬盘、更好屏幕——很多时候性能涨了，价格还没怎么动。\n这不是厂商良心，是摩尔定律的红利：晶体管越做越小，单位成本往下走，性能往上走，电子产品一代一代既变强又变便宜。久了，所有人都把它当成天经地义：电子产品就该越来越强，还越来越便宜。\nAI 把这条默认规则掐断了。\nAI 对算力的需求不是线性涨，是指数涨；而它最饿的恰恰是内存和存储。以前你电脑的内存伺候的是系统、浏览器、剪辑、游戏；现在 AI 数据中心也在疯抢同一批颗粒，而且出价比你高得多。于是出现一个很别扭的局面：不是你突然更需要内存，而是 OpenAI、字节、Google 的数据中心更需要——它们一抬手，整条供应链的价格中枢就被顶上去了。\n苹果这次涨价，本质上就是这条二十年红利曲线，第一次明确地向下拐头。\n四、不止苹果：整个消费电子都在挨刀 如果你以为这是苹果一家的事，那低估了这轮通胀的规模。\nAI 数据中心推高 DRAM、NAND、HBM 存储芯片价格 PC 阵营早就动手了。联想、惠普、华硕四月份就涨过一轮终端价。后续硬盘、CPU、GPU、电路板全在涨，经销商的说法是“几乎一天一个价”——隔壁联想有的型号直接涨了 6000 元。横向一比，Mac 涨这点居然“还算良心”。\n那为什么 iPhone 这次能独善其身？这是库克的算盘，不是苹果的良心：\niPhone 贡献了苹果一半以上营收，涨价对终端销量的杀伤太大； 距离 9 月新品发布和库克退休只剩两个月，这节骨眼上不宜节外生枝； 所以苹果选了“先拿 Mac/iPad 探路，再让 iPhone 跟进”的老套路。 但分析师已经把话挑明了：存储在手机物料成本里的占比，正从常规的 15% 飙到 30% 以上。Counterpoint 估算，单台 iPhone 成本要增加约 200 美元。9 月的 iPhone 18 涨价，基本是板上钉钉——区别只在涨多少。（摩根大通乐观一点，预判 iPhone 18 可能只涨约 50 美元，靠折叠屏新品类去消化大头成本。）\n对普通人来说，结论很直接：“等等党”这次大败退。越等越贵，已经成了未来两年的换机基本面。\n五、另起炉灶：华为韬定律，赌的是同一个拐点的另一面 讲到这里，很多人会想起 5 月 25 日华为发的“韬（τ）定律”，然后顺手得出一个结论：华为有救场的办法。\n从暴力堆料到时间优化：华为韬定律的另一条路 先泼盆冷水：这个挂法是错的。 而把它讲对，恰恰是这篇文章和别人不一样的地方。\n第一层，先把芯片分清楚。 这轮涨价涨的是存储芯片（DRAM、NAND、HBM）；而韬定律谈的主要是逻辑芯片的演进路线。这是两类不同的物理产品。所以请记住：韬定律不会让你下个月的内存条便宜一分钱。 谁要是拿韬定律来解释苹果涨价，基本是没读懂。\n那它到底在解什么？打个比方就清楚了。\n过去半导体提性能，靠的是**“拓宽马路”：制程往前推、晶体管做得更小、同样的面积里塞进更多“车”（晶体管）——这就是几何缩微**。但马路宽到一定程度就拓不动了：光刻机太贵、良率太难、缩无可缩。韬定律提的**“时间缩微”，是换个思路——别死磕拓马路了，转去优化红绿灯、重排路网、做智能调度，让车少等、少绕、走得更快。τ 就是电路里的时间常数**，τ 越小，电路切换越快。\n第二层，往深一层问：内存为什么会涨上天？ 答案藏在 AI 算力的底层逻辑里。今天喂大模型的方式，本质是暴力堆料——模型越大，就堆越多的 HBM、越宽的带宽、越多的内存颗粒。算力的瓶颈早就不是“晶体管够不够密”，而是“数据能不能足够快地搬进搬出”，也就是业内说的“内存墙”（memory wall）。\n这本质上是一个时间问题（延迟、带宽），却被整个行业用数量的办法去硬解：不够快？那就买更多。于是需求爆炸 → 价格飙升 → 你的 Mac 贵了 3500。你掏的这笔钱，是为“用数量硬解时间”这套打法买单。\n第三层，这才轮到韬定律登场。 韬定律的野心，是把“时间”本身作为整个计算栈的统一优化目标——它明确覆盖了从单个晶体管到数据中心工作负载、跨越 12 个数量级的范围，被称为“自登纳德缩放定律以来首个全栈统一优化原理”。\n关键在它的系统级方案：内存语义统一总线架构、近封装 Hi-ONE 光学 I/O、edge-to-surface 3D 折叠技术。这几样东西打的，恰恰就是“内存墙”那个数据搬运瓶颈——也就是前面交通类比里的“让车走得更快”：缩短路径、降低时延，在有限功耗下榨出更多有效算力，而不是靠无脑堆内存。 华为给出的验证数字是：移动 SoC 上逻辑折叠让晶体管密度阶跃提升 55%、能效提升 41%；AI 系统侧，预计到 2035 年实现超 100 倍的硬件集成度增长。\n第四层，对照就清晰了：\n苹果涨价，是“几何缩微 + 暴力堆料”这条老路撞墙后，递到消费者手上的账单； 韬定律，是赌这条老路已经走到头，换“时间维度”重新开一条赛道。 一个在为旧路线买单，一个在赌如何下次不收到这张账单。它俩不是因果关系，而是同一个产业拐点的两面。这，才是把华为和苹果放在一篇文章里的正确理由。\n第五层，最后必须留一句清醒话（也是对读者负责）。韬定律目前仍处在行业探索初期，业内人士直言它尚未形成通用的衡量指标，需要全行业一起迭代。所谓“2031 年对标 1.4nm”“2035 年 100 倍集成度”，都是目标和赌注，不是已交付的产品。换句话说：在 2026—2027 这个内存最贵的窗口里，韬定律救不了你的钱包。它赌的是几年后的事。\n所以这场存储通胀的本质，可以浓缩成一句：AI 算力正在用“数量”硬解“时间”问题；而韬定律赌的是反过来——用“时间”，解掉行业对“数量”的饥渴。谁对，2031 年见。\n六、给你一个能带走的判断 抛开宏大叙事，落到换机这件具体的事上：\n刚需：别等，趁电商还有低价尾货赶紧下手。涨价次日，多个平台的 Mac、iPad 低内存版本就已经售罄； 非刚需：把换机周期从 3 年拉到 4—5 年。厂商正在主动“砍低端、向高端集中”，用结构换毛利，低配性价比机型只会越来越少； 别赌价格回落：美光自己说了，供应紧张至少撑到 2027 年以后。 还有一层，跑本地大模型的人尤其要算这笔账。 内存和显存就是本地 AI 的入场券：以前 16GB 凑合，现在跑模型 32GB 起步，等端侧 AI 真正普及，64GB、128GB 会变成刚需——而这些大内存高配版，恰恰是这轮涨得最狠的。换句话说，存储通胀正在悄悄抬高“本地 AI 自由”的门槛：普通人只能跑小模型，舍得砸钱的才玩得起大模型。想上车的，机器要趁早。\n过去二十年，消费电子的成本锚是“处理器 + 屏幕”；从今年起，换成了“存储”。而存储的定价权，握在一千公里外的 AI 数据中心手里。\n苹果选择把账单递给你，华为选择换一条路——一个在为旧红利的终结买单，一个在赌新红利还能被造出来。谁对，2031 见。\n而对今天的你，结论很朴素：“硬件越来越强、还越来越便宜”的好日子，先告一段落了。\n","permalink":"https://blog.onecai.site/2026/06/26/024-apple-price-hike-huawei-tau-law-ai-hardware/","summary":"\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"tau-cover.avif\"\n          alt=\" 存储通胀：AI 数据中心把硬件账单递给普通消费者\"/\u003e \u003cfigcaption\u003e\n              存储通胀：AI 数据中心把硬件账单递给普通消费者\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eAI 时代第一张递到普通人手里的硬件账单——「又强又便宜」的二十年，结束了\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cp\u003e6 月 25 日晚，苹果官网突然下线维护。几个小时后回来，价格表全变了：Mac、iPad 全线涨价，最高一台涨 3500 块，只有 iPhone、Apple Watch、AirPods 没动。\u003c/p\u003e\n\u003cp\u003e社交平台上一片“苹果终于露出獠牙”的骂声。但如果你只看到这一层，就把这件事看小了。\u003c/p\u003e\n\u003cp\u003e过去一年我们聊 AI，眼睛都盯着模型：谁更聪明、谁上下文更长、谁的智能体更像人。而你为 AI 付的钱，你以为是会员费、API、token——\u003cstrong\u003e其实它正在悄悄变成另一个数字：你电脑价签上多出来的那几千块。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e苹果不是想多赚。它已经把成本“内部消化”了大半年，扛到 6 月才不得不把账单甩给消费者。而这张账单真正的开账人，在一千公里外的 AI 数据中心。\u003c/p\u003e\n\u003cp\u003e下面把这条链一节一节拆开。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一账单苹果到底涨了多少\"\u003e一、账单：苹果到底涨了多少\u003c/h2\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"tau-1.avif\"\n          alt=\" 苹果硬件价格集体上涨\"/\u003e \u003cfigcaption\u003e\n              苹果硬件价格集体上涨\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e先把数字砸出来，这是最直观的部分。中国区官网这一轮共 13 款产品调价，平均涨幅约 21%：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e产品\u003c/th\u003e\n          \u003cth\u003e起售价变化（元）\u003c/th\u003e\n          \u003cth\u003e涨幅\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eMac Studio\u003c/td\u003e\n          \u003ctd\u003e16499 → 19999\u003c/td\u003e\n          \u003ctd\u003e+3500\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eMacBook Pro\u003c/td\u003e\n          \u003ctd\u003e13499 → 15999\u003c/td\u003e\n          \u003ctd\u003e+2500\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eiPad Pro\u003c/td\u003e\n          \u003ctd\u003e8999 → 10799\u003c/td\u003e\n          \u003ctd\u003e+1800\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eMacBook Air\u003c/td\u003e\n          \u003ctd\u003e8499 → 9999\u003c/td\u003e\n          \u003ctd\u003e+1500\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eiPad Air\u003c/td\u003e\n          \u003ctd\u003e4799 → 5999\u003c/td\u003e\n          \u003ctd\u003e+1200\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eMacBook Neo\u003c/td\u003e\n          \u003ctd\u003e4599 → 5499\u003c/td\u003e\n          \u003ctd\u003e+900\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eiPad（基础款）\u003c/td\u003e\n          \u003ctd\u003e2999 → 3799\u003c/td\u003e\n          \u003ctd\u003e+800\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eHomePod mini、Mac mini、iPad A16 这几款涨幅甚至超过 25%。Mac Studio 顶配叠加定制选项，部分机型总价涨幅超过 5000 元。\u003c/p\u003e","title":"存储通胀:苹果涨21%、美光毛利80%、华为另起炉灶"},{"content":"这两天看到 DeepSeek 又冒出来一个新词：DSpark。\n第一眼看上去，很容易以为它又发布了一个新模型。毕竟现在大模型圈子里，只要名字后面多几个字母，大家就会本能地想：是不是能力又上去了？是不是推理更强了？是不是又要重新排榜了？\n但 DSpark 这事，最好不要这么理解，它不是一个新大脑，它更像是 DeepSeek 给模型换了一种更快的说话方式。\n简单说，DSpark 解决的不是“DeepSeek 会不会回答”，而是“DeepSeek 能不能更快把答案吐出来”。\n这两个问题不一样：一个是能力问题，一个是效率问题。\n大模型为什么总是一点点往外蹦字？ 我们平时用大模型，最直观的感觉就是：它不是一下子把整篇回答发给你，而是一行一行慢慢出来。\n有时候看着还挺像一个人在打字。\n但这不是界面故意做出来的打字机效果，而是大模型本来就这么工作。\n大模型生成内容，不是先在脑子里写好一整篇文章，然后复制粘贴出来。它更像是在不断猜下一个字、下一个词、下一个 token。\n前面说了什么，决定后面最可能说什么。\n大模型如何一个 token 一个 token 生成文本⁠ 所以它的工作方式大概是：先预测下一个 token，再根据这个 token，预测再下一个 token，再继续往后预测。\n一路这么走下去，最后才变成我们看到的一段回答。\n这里的 token 不需要理解得太复杂。可以粗略当成 AI 处理文字的基本颗粒。中文里可能接近一个字，也可能是一个词的一部分；英文里可能是一个单词，也可能是单词的一部分。\n关键不在 token 的精确定义，而在它的生成方式：\n大模型原来基本是一个颗粒一个颗粒往外吐。\n这就像一个人说话，每说一个字都要停下来想一下。 能说，但慢。\nDSpark 在中间加了一个“小助手” DSpark 的思路，可以用一个很土但很容易懂的比喻来讲。\n原来的大模型，像一个很谨慎的老师。\n每写一个字，都要自己想、自己判断、自己落笔。\nDSpark 相当于给这个老师配了一个学生。\n学生写草稿，老师快速批改⁠ 学生先写一小段草稿，老师再快速批改：\n这几个字对，保留。 这个词不对，改掉。 后面这一小段可以直接用。 这里猜错了，退回来重新写。 如果学生猜得准，老师就省事了。\n老师不用从空白纸开始一个字一个字写，而是可以在草稿上快速确认。\n这就是所谓的“推测解码”。\n听起来挺技术，其实就是四个字：\n先猜，再验。\n小模型或者草稿模块先把后面可能出现的 token 猜出来，主模型再来验证。猜对了，就一口气通过；猜错了，再回头修正。\n所以 DSpark 不是让小模型代替大模型，也不是降低标准凑速度。\n它更像是让大模型少做重复劳动。\n它不是让 DeepSeek 更聪明 这个地方最容易误解。\nDSpark 出来以后，很多人会问：那 DeepSeek 是不是更强了？\n我的理解是：不能这么说。\n如果你说的“更强”，是指数学题准确率更高、代码能力更好、复杂推理更稳、幻觉更少，那 DSpark 本身不负责这个。\n它不是换模型，不是重新训练出一个更聪明的大脑。\n它改变的是模型生成答案时的流程。\n就像一辆车，发动机没换，但是换了一套更顺的变速箱。车不一定马力更大，但开起来更顺，提速更快，油耗可能也更低。\nDSpark 对 DeepSeek 的意义，大概就是这个。\n它不直接提高模型能力上限，但会提高模型交付答案的效率。\n这在大模型真正被大量人使用的时候，其实很关键。\n早期大家看大模型，主要看榜单、参数、上下文、推理能力。 但真正用起来以后，普通用户最在意的往往不是这些词。\n而是：\n它快不快？ 会不会卡？ 高峰期能不能打开？ 写长文会不会写一半停住？ API 调用会不会慢得影响业务？ 价格能不能继续压下来？\n这些问题背后，都是推理效率问题。\nDSpark 正好打在这一层。\n对普通用户来说，最明显就是更快 对于普通用户来说，DSpark 这个名字其实没必要记得多清楚。\n你最终能感觉到的，大概就是一句话：\nDeepSeek 回答更快了。\n尤其是长回答。\nDSpark 对用户体验的影响⁠⁠ 如果只是问一句“今天星期几”，本来就没几个字，快不快差别不大。\n但如果你让它写一篇公众号文章、整理一份报告、总结一本书、生成一段代码、做一次长材料分析，那差别就会更明显。\n因为这些任务不是难在第一句话，而是难在后面要持续输出很多内容。\n以前它可能是一点点往外挤。 现在如果 DSpark 起作用，就会更像顺着往外流。\n不是说内容一定更好，而是等待时间更短，输出过程更顺。\n按 DeepSeek 公布的数据，同吞吐量条件下，单用户文本生成速度提升了 60% 到 85%。这不是实验室跑出来的理论值，这是线上真实流量实测出来的结果。已全量部署在 DeepSeek-V4 线上服务，即你现在用 DeepSeek 聊天，背后跑的可能就是 DSpark。\n这对用户体验很重要。\n很多时候，一个 AI 工具从“能用”到“好用”，差的不是某个特别玄乎的能力，而是这些很朴素的体验：\n别让我等太久。 别写到一半卡住。 别高峰期一问就转圈。 别让我感觉它明明会答，但就是憋不出来。\n对 DeepSeek 来说，更大的意义是成本 从 DeepSeek 自己的角度看，DSpark 的意义可能比普通用户感受到的更大。\n因为大模型服务不是单机软件。\n它背后是服务器，是 GPU，是并发，是成本。\n同样一批 GPU，如果每个回答都能更快生成完，就意味着这批 GPU 可以服务更多用户。\n同样一个用户请求，如果生成阶段耗时更短，就意味着系统周转更快。\n这件事最后会影响什么？\n影响稳定性。 影响 API 成本。 影响高峰期体验。 也影响 DeepSeek 后面能不能继续把价格打下来。 大模型价格战，本质上不是谁愿意便宜，而是谁真的有能力便宜。\n如果单位 token 的推理成本降不下来，价格低只是烧钱。 如果推理效率真的提升了，低价才有可能变成长期策略。\n所以 DSpark 这类东西，看起来只是一个技术优化，但它背后其实是商业竞争力。\n而且一个好消息是，DeepSeek 这次把整套方案都开源了——训练代码库 DeepSpec 已上线 GitHub，意味着其他开发者也能在自己的大模型上用上这套推测解码方法。不止 DeepSeek 能快，整个行业都有可能受益。\nAPI 用户会更敏感 如果只是普通聊天，用户可能只是觉得“快了一点”。\n但如果你是 API 用户，或者用 DeepSeek 做自己的工具，这类优化就更值得关注。\n比如你做一个知识库问答系统。 每个用户问一次，模型要读资料、组织答案、生成长文本。\n如果每次都慢，整个产品就会显得笨。\n再比如你做智能体应用。 智能体不是只回答一句话，它要规划、调用工具、读取结果、继续判断、再执行下一步。\n每一步都要等模型生成。\n底层生成速度快一点，整个智能体的体验就会顺很多。\n所以 DSpark 对普通用户是“更快”，对开发者是“更稳、更能扛、更有成本空间”。\n这不是一个小差别。\n这类技术说明大模型竞争进入了下一层 我觉得 DSpark 值得关注，不是因为它名字新，而是因为它说明大模型竞争已经不只是在模型本身了。\n以前大家主要看：\n参数有多大。 榜单分数有多高。 上下文有多长。 推理能力有多强。 这些当然重要。\n但现在另一个问题越来越重要：\n同样强的模型，谁能跑得更便宜？ 同样的服务器，谁能服务更多人？ 同样的价格，谁能给出更快的体验？ 这背后拼的就不是单纯的模型训练，而是完整的推理系统。\n包括推理框架、缓存管理、并发调度、量化、推测解码、服务器利用率。\nDSpark 就是这个系统里的一个零件。\n但这个零件不小。\n因为用户最终不关心你背后用了多少技术，用户只关心：\n我问了以后，它是不是很快给我一个能用的答案。\n最后怎么理解 DSpark？ 如果把 DSpark 用一句话讲清楚，我会这么说：\nDeepSeek 原来是一个字一个字往外说，DSpark 就像给它配了一个提前打草稿的小助手。小助手先猜后面要说什么，大模型再检查。猜对了就一口气说出来，猜错了再改。所以它不是让 DeepSeek 更聪明，而是让 DeepSeek 更快把答案说出来。\n再短一点：\nDSpark 不是换大脑，是换说话方式。\n它对普通用户的意义也很直接：\n长回答更快。\n输出更顺。\n高峰期可能更稳。\nAPI 成本更有下降空间。\n但模型能力本身不会因为它直接提高，大模型发展到现在，不能只看“会不会回答”，还要看“能不能快速、稳定、便宜地回答”。DSpark 讲的就是后面这件事。\n参考资料 DeepSeek-V4-Pro-DSpark 模型页：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark DeepSpec 开源仓库：https://github.com/deepseek-ai/DeepSpec NVIDIA 对推测解码的解释：https://developer.nvidia.com/blog/an-introduction-to-speculative-decoding-for-reducing-latency-in-ai-inference/ ","permalink":"https://blog.onecai.site/2026/06/25/023-deepseek-dspark/","summary":"\u003cp\u003e这两天看到 DeepSeek 又冒出来一个新词：DSpark。\u003c/p\u003e\n\u003cp\u003e第一眼看上去，很容易以为它又发布了一个新模型。毕竟现在大模型圈子里，只要名字后面多几个字母，大家就会本能地想：是不是能力又上去了？是不是推理更强了？是不是又要重新排榜了？\u003c/p\u003e\n\u003cp\u003e但 DSpark 这事，最好不要这么理解，它不是一个新大脑，它更像是 DeepSeek 给模型换了一种更快的说话方式。\u003c/p\u003e\n\u003cp\u003e简单说，DSpark 解决的不是“DeepSeek 会不会回答”，而是“DeepSeek 能不能更快把答案吐出来”。\u003c/p\u003e\n\u003cp\u003e这两个问题不一样：一个是能力问题，一个是效率问题。\u003c/p\u003e\n\u003ch2 id=\"大模型为什么总是一点点往外蹦字\"\u003e大模型为什么总是一点点往外蹦字？\u003c/h2\u003e\n\u003cp\u003e我们平时用大模型，最直观的感觉就是：它不是一下子把整篇回答发给你，而是一行一行慢慢出来。\u003c/p\u003e\n\u003cp\u003e有时候看着还挺像一个人在打字。\u003c/p\u003e\n\u003cp\u003e但这不是界面故意做出来的打字机效果，而是大模型本来就这么工作。\u003c/p\u003e\n\u003cp\u003e大模型生成内容，不是先在脑子里写好一整篇文章，然后复制粘贴出来。它更像是在不断猜下一个字、下一个词、下一个 token。\u003c/p\u003e\n\u003cp\u003e前面说了什么，决定后面最可能说什么。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"dspark-1.avif\"\n          alt=\" 大模型如何一个 token 一个 token 生成文本⁠\"/\u003e \u003cfigcaption\u003e\n              大模型如何一个 token 一个 token 生成文本⁠\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e所以它的工作方式大概是：先预测下一个 token，再根据这个 token，预测再下一个 token，再继续往后预测。\u003c/p\u003e\n\u003cp\u003e一路这么走下去，最后才变成我们看到的一段回答。\u003c/p\u003e\n\u003cp\u003e这里的 token 不需要理解得太复杂。可以粗略当成 AI 处理文字的基本颗粒。中文里可能接近一个字，也可能是一个词的一部分；英文里可能是一个单词，也可能是单词的一部分。\u003c/p\u003e\n\u003cp\u003e关键不在 token 的精确定义，而在它的生成方式：\u003c/p\u003e\n\u003cp\u003e大模型原来基本是一个颗粒一个颗粒往外吐。\u003c/p\u003e\n\u003cp\u003e这就像一个人说话，每说一个字都要停下来想一下。\n能说，但慢。\u003c/p\u003e\n\u003ch2 id=\"dspark-在中间加了一个小助手\"\u003eDSpark 在中间加了一个“小助手”\u003c/h2\u003e\n\u003cp\u003eDSpark 的思路，可以用一个很土但很容易懂的比喻来讲。\u003c/p\u003e\n\u003cp\u003e原来的大模型，像一个很谨慎的老师。\u003c/p\u003e\n\u003cp\u003e每写一个字，都要自己想、自己判断、自己落笔。\u003c/p\u003e\n\u003cp\u003eDSpark 相当于给这个老师配了一个学生。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"dspark-2.avif\"\n          alt=\"学生写草稿，老师快速批改⁠\"/\u003e \u003cfigcaption\u003e\n             学生写草稿，老师快速批改⁠\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e学生先写一小段草稿，老师再快速批改：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e这几个字对，保留。\u003c/li\u003e\n\u003cli\u003e这个词不对，改掉。\u003c/li\u003e\n\u003cli\u003e后面这一小段可以直接用。\u003c/li\u003e\n\u003cli\u003e这里猜错了，退回来重新写。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果学生猜得准，老师就省事了。\u003c/p\u003e\n\u003cp\u003e老师不用从空白纸开始一个字一个字写，而是可以在草稿上快速确认。\u003c/p\u003e\n\u003cp\u003e这就是所谓的“推测解码”。\u003c/p\u003e\n\u003cp\u003e听起来挺技术，其实就是四个字：\u003c/p\u003e\n\u003cp\u003e先猜，再验。\u003c/p\u003e\n\u003cp\u003e小模型或者草稿模块先把后面可能出现的 token 猜出来，主模型再来验证。猜对了，就一口气通过；猜错了，再回头修正。\u003c/p\u003e\n\u003cp\u003e所以 DSpark 不是让小模型代替大模型，也不是降低标准凑速度。\u003c/p\u003e","title":"DeepSeek新出的DSpark，不是让模型更聪明，而是让它说话更快"},{"content":" 12个本地模型，同一份提示词，谁能扛住24GB的内存墙？ 一句话背景：用一份「七板块结构化读书笔记」的硬 prompt，喂同一本书（Dan Koe《目的与利润 / Purpose \u0026amp; Profit》中英对照 PDF，正文约 3.1 万 token），把手头 12 个本地模型挨个拷打一遍。MLX（Metal GPU 推理）和 LM Studio 标准两条路线都上。结论先放这儿：在本地跑大模型，量化等级和那道 ~20GB 的内存墙，比「参数量」和「架构」更能决定你最终能用上谁。\n这不是一次只看输出是否流畅的测试。我还把模型给出的“原文锚点”逐条回到原书核对，看它到底是在引用、转述，还是编造。\n测试任务很简单，严格按七个板块输出：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 你是一位专业的非虚构书籍编辑和读书笔记作者。下面会给你一本书的完整内容（或节选）。请严格依据原文进行总结，完成结构化输出。 【硬性要求】 1. 只能依据所给文本。不得编造原文没有的观点、数据、人名、案例、术语。若某一项在文本中找不到依据，明确写\u0026#34;原文未提及\u0026#34;，不要猜测、不要用常识补全。 2. 严格按下面的板块标题和顺序输出，不增删板块，不写开场白或结束语。 3. 简练优先，遵守每个板块的字数/条数限制。冗长堆砌、空话套话视为低质量。 4. 全程使用简体中文。 【输出结构】 一、一句话总结（≤40字） 用一句话概括全书最核心的主张（不是主题词，是主张）。 二、核心论点（3–5条，每条≤2句） 提炼作者真正想论证的观点，而非泛泛的话题。 三、章节脉络（逐章，每章1–2句） 按原文章节顺序，逐章概括：这一章讲了什么、与全书主线的关系。 四、关键概念 / 方法论（3–6个） 列出书中提出的核心概念、框架或可操作方法，每个用一句话解释。作者自创的术语保留其原始表述。 五、原文锚点（2–4处） 精确转述能支撑上述论点的原文要点，并注明大致出处（第几章）。此板块用于核对是否忠于原文。 六、给读者的可执行建议（3–5条） 基于全书，提炼读完后能立刻行动的具体建议。 七、本次总结的盲区（≤3条） 诚实指出：受文本长度或上下文限制，哪些内容你可能没有充分覆盖或根本没读到。 【全书内容】上传的PDF就是全文内容。 一、谁活下来了：运行结果总览 12 个模型里，6 个连门都没进（加载即失败），6 个跑出了结果——其中 5 个老实按格式来，1 个（qwen3-32b-mlx）跑是跑了，但完全没理会格式要求。\n同一本书，同一份提示词 模型 运行方式 结果 gemma-4-12b-it-mlx MLX ✅ 成功 gemma-4-26b-a4b-it-qat LM Studio（量化） ✅ 成功 qwen3-14b-dwq-053125-mlx MLX ✅ 成功（输出中暴露 \u0026lt;think\u0026gt; 标签） qwen3-14b-dwq-053125 LM Studio ✅ 成功 qwen3.6-35b-a3b LM Studio（MoE） ✅ 成功 qwen3-32b-mlx MLX ⚠️ 跑通但格式失控 deepseek-r1-distill-qwen-32b-mlx MLX ❌ 上下文超限（31439 \u0026gt; 16384）+ OOM deepseek-r1-distill-qwen-32b LM Studio ❌ 系统内存不足（需 ~21.85 GB） gemma-4-26b-a4b-mlx MLX ❌ GPU 内存不足（Metal OOM） qwen3.6-27b-mlx MLX ❌ GPU 内存不足（Metal OOM） qwen3.6-27b LM Studio ❌ 系统内存不足（需 ~22.54 GB） qwen3.6-35b-a3b-mlx MLX ❌ GPU 内存不足（Metal OOM） 口径说明：6 个跑出结果，但 qwen3-32b-mlx 没遵守格式，所以真正「合格交付」的只有 5 个，合格率 5/12 ≈ 42%。如果只看“能不能跑出内容”，通过率是 6/12；如果按“跑通且按要求交付”计算，合格率只有 5/12。\n二、6 个模型为什么没跑起来：三道墙 失败不是玄学，全是物理墙，归成三类。\n不是参数量，是统一内存的上限 1. GPU 显存墙（Metal OOM）—— 3 个 gemma-4-26b-a4b-mlx、qwen3.6-27b-mlx、qwen3.6-35b-a3b-mlx 清一色报：\n1 2 [METAL] Command buffer execution failed: Insufficient Memory (kIOGPUCommandBufferCallbackErrorOutOfMemory) 这三个里既有 dense（qwen3.6-27b-mlx）也有 MoE（gemma-4-26b-a4b-mlx、qwen3.6-35b-a3b-mlx）。这里要破一个常见误解：MoE 省的是算力，不是显存——它的全部专家权重仍要按总参数量整个加载进内存，撑不撑得住和 dense 一样看总参数。在常见本地推理场景里，MoE 省的是每次推理激活的专家数量，也就是计算量；但模型权重通常仍要整体加载进内存。所以对 24GB 统一内存的 Mac 来说，MoE 不等于“显存占用按激活参数算”。在本轮测试的这台 24GB Mac 上，26B 及以上的 MLX 模型基本都顶穿了统一内存上限。，至少在本轮这套 MLX 运行方式下，它没有像 LM Studio 那样提前给出“内存不足，拒绝加载”的保护提示；一旦 Metal 内存不够，体感上就是直接OOM。\n2. 系统内存墙（RAM 不足）—— 2 个 deepseek-r1-distill-qwen-32b：需 ~21.85 GB qwen3.6-27b：需 ~22.54 GB 两个都超出系统可用量。这里有个细节值得记一笔：LM Studio 是「拒绝加载」，不是「崩溃」。它的保护机制提前拦下，避免把整机拖死冻住。比 MLX 那种「先跑后崩」体感安全得多。\n3. 上下文窗口墙 —— 1 个 deepseek-r1-distill-qwen-32b-mlx 报：\n1 sequence length for this model (31439 \u0026gt; 16384) 整本书 3.1 万 token，直接超出它 16K 的上下文窗口一倍。其余模型没踩这个坑，说明它们窗口更大、或对长文处理更宽容。\n小结：当前这台机器的实际天花板大约卡在 20GB 出头——凡是要 22GB+ RAM 的一律启动失败，26B+ 的 MLX 模型一律 Metal OOM。这就是所谓「内存墙」，也是本地大模型选型里第一个、也是最硬的约束。\n三、跑通的模型，谁更听话：Prompt 遵从性 能跑 ≠ 听话。把 5 个合格 + 1 个失控放在一起看格式：\n模型 七板块齐全 字数限制 无开场白/结语 纯简体中文 gemma-4-12b-it-mlx ✓ ✓（37 字，按汉字计在限内） ✓ ✓ gemma-4-26b-a4b-it-qat ✓ ✓ ✓ ✓ qwen3-14b-dwq-053125-mlx ✓（含 \u0026lt;think\u0026gt; 块） ✓ ✓ ✓ qwen3-14b-dwq-053125 ✓ ✓ ✓ ✓ qwen3.6-35b-a3b ✓ 一句话超限（41 字） ✓ ✓ qwen3-32b-mlx ✗ 严重违规 — 自创段落结构 ✓ qwen3-32b-mlx 是本次最大翻车现场：完全无视七板块，自创了「主要论点 / 关键概念 / 重要案例 / 实践路径」四段结构，硬生生缺了一句话总结、原文锚点、可执行建议、盲区四块。更关键的是，看它暴露出来的 \u0026lt;think\u0026gt; 推理链——模型从一开始就在按自己的框架想（“需要涵盖主要论点、关键概念、重要案例……不超过 600 字”），推理不但没纠偏，反而把错误方向固化了。\n这里得出第一个反直觉的结论：参数量不等于指令遵从性。32B 的 qwen3-32b-mlx 格式最差，14B 的两个 qwen3 反而最规整。至少在这次任务里，小模型在 instruction-following 上反而更可靠。这件事在本地部署场景里非常实用。\n四、逐板块拆解：质量到底差在哪 格式合格之后，才进入真正的内容比拼。挑三个最能见功力的板块说。\n① 一句话总结（≤40 字）—— 最考验提炼能力 模型 输出 点评 gemma-4-12b-it-mlx 通过建立“创业精神”与“创造者”思维，将解决问题的能力转化为个人价值与社会贡献的路径。 是「路径描述」不是「主张」，略泛（37 字，字数其实达标） gemma-4-26b-a4b-it-qat 通过解决自身及他人的问题并创造价值，实现从生存到使命的进化与自我货币化。 准确，含核心论点 qwen3-14b-dwq-053125-mlx 创业精神与自我实现是超越生存与金钱的核心路径。 太模糊，更像主题词 qwen3-14b-dwq-053125 将使命与收益结合，是实现个人价值的核心路径。 简洁，抓到核心 qwen3.6-35b-a3b 摒弃被动就业心态，以创业者视角主动解决自身问题并通过写作分享方案，实现目的与利润的统一。 最具体、最有力，但 41 字、超 40 字限 有意思的是：唯一栽在字数上的，反而是质量最高的 35b-a3b（41 字，超 1 字）——信息量足但收不住。最小的 gemma-12b 其实卡在限内（37 字），14b 标准版则拿捏得最稳，可以当「最小正确答案」参考。\n② 原文锚点 —— 忠实度的试金石 这一板块要求精确转述原文要点并注明章节，是核对模型「是否在编」的关键。回原书逐句核对后，差距相当明显：\nqwen3.6-35b-a3b 最佳，也是唯一干净通过的：四处锚点全是逐字精确引用，回原文一字不差（如「问题即是道路」「真正的能动性只有在你将所有问题都归咎于自身时才能培养出来」），章节也标得上。这是它拿下总分第一的硬底气。 gemma-4-26b-a4b-it-qat 次之，但栽了一处：把原文形容**「信息**」的那句「思维操作系统的密码」安到了**「写作**」头上——原文是「信息是你思维操作系统的密码」，张冠李戴。 qwen3-14b 两版：都有「把转述加上引号当原文」的毛病。标准版更甚，编了一句原文压根没有的「写作是唯一能跨越时间、空间与技术限制的元技能」——看着像引用，其实是脑补。 qwen3-32b-mlx：该板块直接缺失。 一句话：能不能逐字回引原文，是把「真读进去了」和「凭印象复述」区分开的分水岭。 这一关，只有 35b-a3b 走得干净。\n③ 关键概念独特性 —— 谁读得更深 模型 抓到的特色概念 是否忠于原文 gemma-4-26b-a4b-it-qat 「精神熵增」（技能与挑战不匹配导致的无聊/焦虑） ✓ 书中确有 qwen3.6-35b-a3b 「价值创造五问框架」（帮谁 / 解决什么 / 想去哪 / 何时见效 / 为何关心） ✓ 对应原书价值创造章的 5 个问题 qwen3-14b 两版 「自然的指南针」 ✓ 书中确有 gemma-4-12b-it-mlx 「目的论」 解释偏哲学，与全书实操导向略有偏差 「精神熵增」和「价值创造五问」都是书里真实存在的硬概念——能把它们单独拎出来，说明模型不只是在复述，而是真读进去了。这是 35b-a3b 和 26b-qat 拉开身位的地方。\n五、\u0026lt;think\u0026gt; 泄漏：推理模型的一把双刃剑 本次有 MLX 版思维链模型把 \u0026lt;think\u0026gt; 推理过程暴露在了最终输出里（qwen3-14b-dwq-053125-mlx、qwen3-32b-mlx），这是 MLX 运行时对思维链模型的适配问题，会污染交付质量，调用层得做过滤、或换适配版本。\nthink泄漏是推理模型的一把双刃剑 但更值得玩味的是同样是推理链，结果天差地别：\nqwen3-14b-dwq-053125-mlx：推理链帮模型理清了结构，最终格式完全正确，是所有成功模型里「自我核查格式」最明确的一个——推理是助力； qwen3-32b-mlx：推理链从第一句就跑偏，并把错误框架越想越实——推理是反噬。 所以「会思考」不是质量保证。推理链的价值，完全取决于它的方向对不对。\n六、综合排名 排名 模型 理由 🥇 1 qwen3.6-35b-a3b 最详细、原文引用最精确（唯一逐字回引原文）、章节概括最丰富，结构完整；唯一瑕疵是一句话超 1 字 🥈 2 gemma-4-26b-a4b-it-qat 格式严格合规、一句话精准、字数达标，独家抓到「精神熵增」；理解较深，仅锚点有一处张冠李戴 🥉 3 qwen3-14b-dwq-053125 简洁流畅、格式零瑕疵、无废话，「最小正确输出」标杆 4 qwen3-14b-dwq-053125-mlx 内容与标准版相近，带推理链，推理质量不错、有格式自检 5 gemma-4-12b-it-mlx 格式正确、内容完整、字数达标，但一句话偏「路径描述」而非「主张」、个别概念（目的论）偏哲学化 末 qwen3-32b-mlx 格式完全不符，参数最大却质量最差，本次最大负面案例 七、结论与选型建议 把两轮观察压缩成几条能直接用的硬结论：\n内存墙是第一约束，也是最硬的约束。 当前机器实际天花板 ~20GB 出头：22GB+ RAM 一律启动失败，26B+ dense 的 MLX 模型一律 Metal OOM。选型先算内存，再谈质量。\n别误读 MoE：它省算力，不省显存。 本次 qwen3.6-35b-a3b 能跑、qwen3.6-27b dense 反而 OOM，看着像「MoE 更省内存」，其实是两者量化等级不同造成的假象——那个 27b 用的是偏重的量化（需 ~22.54 GB），而跑通的 35b-a3b 用的是更轻的量化。同精度下，35B 的全部专家权重都要加载，占用按总参数 35B 算，比 27B dense 更高，不是更低。MoE 真正的红利在推理速度和算力，不在内存。\n参数量 ≠ 听话程度。 32B 格式最烂，14B 格式最稳。要稳定的指令遵从，别只盯参数表。\nMLX vs LM Studio，要的不只是速度。 MLX 对 26B+ 模型无法稳定运行，而 LM Studio 有内存保护（拒绝加载而非崩溃），更安全；MLX 版思维链模型还会漏 \u0026lt;think\u0026gt;，需额外过滤。\n「会思考」不保证质量。 推理链能助力格式自检，也能固化错误方向，全看方向对不对。\n实用选型（务必分清「质量最高」和「这台机器跑得动」是两件事）：\n本轮测出的质量榜首是 qwen3.6-35b-a3b，但它能不能落地完全取决于量化：在 24GB 这台机器上，常用量化版本会 OOM；要它跑起来，要么换更大内存（如计划中的 M4 Max 64GB），要么压到 IQ3 一档（约 13–14 GB，质量优势会被吃掉一部分）。「质量第一」≠「你现在用得上」。 这台机器今天就稳的选择：qwen3-14b-dwq-053125（标准版）——实测可跑、质量也已在本轮验证，格式零瑕疵、内容扎实，是最稳的日常档。 想要更大体量又跑得动：Qwen3.6-27B 用 IQ4_XS（约 14–15 GB）在 24GB 机器上可稳定运行（本机已验证）；不过它的总结质量本轮没测到（测试里那个 27B 用的是更重的量化、直接 OOM 了），建议拿 IQ4_XS 单独跑一遍这套 prompt 再定。 想用 MLX 提速：避开 26B+（不论 dense 还是 MoE），并在调用层处理好 \u0026lt;think\u0026gt; 泄漏。 如果只让我在这台 24GB Mac 上保留一个日常读书笔记模型，我会先选 qwen3-14b-dwq-053125 标准版。理由很简单：它不是本轮质量上限最高的模型，但它跑得动、格式稳、废话少、结果可控。对日常读书笔记来说，“稳定交付”比“理论上更聪明”更重要。\n本文为同一 prompt、同一本书（《目的与利润》）在本地多模型上的实测对比，硬件与软件版本会影响结果，仅供选型参考。\n","permalink":"https://blog.onecai.site/2026/06/24/022-12modelscompare/","summary":"\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"local_llm_benchmark_cover_235.avif\"\n          alt=\"12个本地模型，同一份提示词，谁能扛住24GB的内存墙？\"/\u003e \u003cfigcaption\u003e\n             12个本地模型，同一份提示词，谁能扛住24GB的内存墙？\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e一句话背景：用一份「七板块结构化读书笔记」的硬 prompt，喂同一本书（\u003ca href=\"https://blog.onecai.site/2026/06/16/009-dankoebookpurposeprofit/\"\u003eDan Koe《目的与利润 / Purpose \u0026amp; Profit》\u003c/a\u003e中英对照 PDF，正文约 3.1 万 token），把手头 12 个本地模型挨个拷打一遍。MLX（Metal GPU 推理）和 LM Studio 标准两条路线都上。结论先放这儿：\u003cstrong\u003e在本地跑大模型，量化等级和那道 ~20GB 的内存墙，比「参数量」和「架构」更能决定你最终能用上谁。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这不是一次只看输出是否流畅的测试。我还把模型给出的“原文锚点”逐条回到原书核对，看它到底是在引用、转述，还是编造。\u003c/p\u003e\n\u003cp\u003e测试任务很简单，严格按七个板块输出：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 2\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 3\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 4\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 5\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 6\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 7\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 8\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 9\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e10\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e11\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e12\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e13\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e14\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e15\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e16\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e17\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e18\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e19\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e20\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e21\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e22\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e23\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e24\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e25\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e26\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e27\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e28\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e29\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e30\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e31\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e32\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e你是一位专业的非虚构书籍编辑和读书笔记作者。下面会给你一本书的完整内容（或节选）。请严格依据原文进行总结，完成结构化输出。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e【硬性要求】\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e1. 只能依据所给文本。不得编造原文没有的观点、数据、人名、案例、术语。若某一项在文本中找不到依据，明确写\u0026#34;原文未提及\u0026#34;，不要猜测、不要用常识补全。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e2. 严格按下面的板块标题和顺序输出，不增删板块，不写开场白或结束语。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e3. 简练优先，遵守每个板块的字数/条数限制。冗长堆砌、空话套话视为低质量。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e4. 全程使用简体中文。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e【输出结构】\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e一、一句话总结（≤40字）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e用一句话概括全书最核心的主张（不是主题词，是主张）。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e二、核心论点（3–5条，每条≤2句）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e提炼作者真正想论证的观点，而非泛泛的话题。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e三、章节脉络（逐章，每章1–2句）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e按原文章节顺序，逐章概括：这一章讲了什么、与全书主线的关系。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e四、关键概念 / 方法论（3–6个）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e列出书中提出的核心概念、框架或可操作方法，每个用一句话解释。作者自创的术语保留其原始表述。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e五、原文锚点（2–4处）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e精确转述能支撑上述论点的原文要点，并注明大致出处（第几章）。此板块用于核对是否忠于原文。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e六、给读者的可执行建议（3–5条）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e基于全书，提炼读完后能立刻行动的具体建议。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e七、本次总结的盲区（≤3条）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e诚实指出：受文本长度或上下文限制，哪些内容你可能没有充分覆盖或根本没读到。\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e【全书内容】上传的PDF就是全文内容。\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003chr\u003e\n\u003ch2 id=\"一谁活下来了运行结果总览\"\u003e一、谁活下来了：运行结果总览\u003c/h2\u003e\n\u003cp\u003e12 个模型里，\u003cstrong\u003e6 个连门都没进\u003c/strong\u003e（加载即失败），\u003cstrong\u003e6 个跑出了结果\u003c/strong\u003e——其中 5 个老实按格式来，1 个（qwen3-32b-mlx）跑是跑了，但完全没理会格式要求。\u003c/p\u003e","title":"12个本地模型，同一份提示词，谁能扛住24GB的内存墙？"},{"content":"在众多模型中找适合自己的模型时，会看到类似Qwen3-32B 和 Qwen3-30B-A3B名字很相似的模型名称，一个带“A”，一个不带。参数量看着差不多，到底差在哪？\n这两个字母背后，藏着本地部署里最重要的一条分界线。搞懂它，你才知道自己那台机器该喂什么、该买什么。这篇就把它从头讲透，最后落到一个很实际的问题上：不同的一人公司，到底该怎么选本地模型。\n一、一句话区别：处理一个字时，到底激活了多少参数 先建立一个直觉。你可以把一个大模型想象成一家公司，公司里有一大群员工——每个员工就是一个「参数」（实际上是几十亿、上千亿个数字）——这个比喻不严谨，但足够帮我们理解后面的选择逻辑。\n所谓「32B 模型」，B 是 billion（十亿），就是这家公司有 320 亿名员工。\n模型「思考」的过程，是把你输入的文字拆成一个个小单位（叫 token，大致是「字」或「词的一部分」），然后让员工对每个 token 算一轮，吐出下一个字。\n稀疏和稠密的区别，不看公司一共多少人，只看处理一个字时，实际有多少人在干活。\n稠密（dense）：每来一个字，全部员工都上工。激活参数 = 总参数。 稀疏（MoE，混合专家）：每来一个字，只叫醒一小撮人，其余继续睡觉。激活参数 ≪ 总参数。 学名叫「激活稀疏性」或「条件计算」。一句话：总参数决定它知道多少，激活参数决定它每个字算得多快、多贵。\n二、稠密：全来一个字，全公司加班 传统模型是稠密的。规矩很简单粗暴：每处理一个 token，320 亿员工一个不落，全部上工。\n好处是简单、稳定、质量扎实；坏处是贵。员工越多，处理每个字越慢、越耗电、越吃内存。你想让它更聪明（加更多员工），处理每个字的成本就线性地往上涨，逃不掉。\n三、稀疏 MoE：路由器翻牌子，只叫醒几个专家 后来人们想了个偷懒的办法，这就是 MoE。\n它把公司里干重活的那个部门（技术上叫 FFN 层）拆成了一群专家，比如 64 个、128 个，各有所长。然后在专家前面安排了一个前台调度员，叫「路由器」（router）。\n每来一个 token，路由器先瞄一眼：「这个字大概讲代码，叫醒 2 号和 47 号就够了。」于是只有被点名的那几个专家干活，其余几十个继续睡觉，完全不参与这个字的计算。下一个字来了，路由器可能又翻别的牌子。\n这个「每次只激活一小撮」的特性，就是「稀疏」这个名字的来历。\n稠密与 MoE 两种前向传播对比 上图左边是稠密——每来一个 token，全部参数（亮的）都参与；右边是 MoE——路由器翻牌子，只有 2 个专家被叫醒，其余 4 个灰着不计算。颜色就是全部信息量：亮 = 真的在算，灰 = 睡觉不耗算力。\n四、怎么一眼认出来？看名字里那个大写 A 这是最实用的技巧。模型名字里的「A」就是 Activated（激活）：\nQwen3-32B：没有 A，稠密，320 亿员工全部上工。 Qwen3-30B-A3B：有 A，MoE，总共 300 亿，但每个字只激活 30 亿（A3B）。 Qwen3-235B-A22B：总 2350 亿，每个字只动用 220 亿。 在 Qwen 这类命名里，A 基本可以理解为 Activated，也就是每 token 激活参数量。看到 30B-A3B、235B-A22B，大概率就是 MoE。没有 A 的 Qwen3-32B，则是 dense。命名规则直接把答案写在脸上了。\n五、内存、速度、质量：MoE 把这三件事拆开了 对抠 Apple Silicon 内存的人来说，MoE 真正的价值是把「要多少内存」和「跑多快」解耦了。记住三条经验法则：\n基础内存占用主要看总参数，长上下文还要额外看 KV Cache。MoE 的专家虽然不是每次都激活，但权重通常仍要放在内存里；如果你把上下文从 8K 拉到 64K、128K，KV Cache 又会吃掉一大块内存。 速度 / 算力消耗 ≈ 激活参数。 M 系芯片推理几乎永远被内存带宽卡死，而 MoE 每个字只需读取被激活那部分权重，等于「大总参数换知识广度，小激活参数换速度」。 质量不能简单按“激活参数”线性估算。30B-A3B 通常会明显强于普通 3B dense，但它不等于“免费获得 30B dense 的全部能力”。MoE 的优势更像是：用较低的单 token 计算量，换取接近大模型的知识覆盖和任务泛化，但具体质量还要看训练、数据、量化和运行时。 所以一句话总结 MoE 的卖点：用大模型的脑子，跑出小模型的速度，代价是吃大模型的内存。\n反过来，如果内存极度紧张，稠密模型「每一份内存换来的智力」反而更划算——它把全部预算压在一条路上，没把参数摊薄到一群专家身上。\n六、回到正题：一人公司该怎么选 知道了区别，怎么落地？对一人公司来说，选模型最大的误区是问「哪个最强」。你没有 IT 团队，硬件是自己的钱，时间是最稀缺的资源——真正该问的是：「我这台机器到底在替我干哪种活？」\n这个问题几乎直接决定你走 dense 还是 MoE。核心就一条线：\n机器主要「陪你一个人深度用」（写作、对话、改代码、分析），评判标准是单次质量和延迟 → 内存有限时，dense 更划算。 机器主要「在后台跑量 / 服务多人」（批量、24h Agent、并发），评判标准是总吞吐和每 token 成本 → MoE 更划算。 本地模型选择决策树 场景 更适合 原因 一个人写作、问答、改稿 dense 优先 单次质量稳定，少折腾 低延迟聊天、轻量工具调用 MoE 可选 激活参数小，速度好 长文档 RAG 看上下文和 KV Cache 不只是模型大小问题 24h 自动化、批量任务 MoE 优先 吞吐、电费、速度更划算 隐私合规、本地固定流程 稳定 dense 优先 可复现、少意外 局域网多人共用 MoE + 批处理运行时 并发时更有优势 七、五种不同用途，对号入座 下面不是排行榜，只是按用途举几个代表性方向。模型生态变化太快，具体版本以模型卡为准。\n① 自媒体、作者、翻译。 活是长文起草、洗稿、翻译、摘要，不需要工具调用，能容忍延迟，命门是中文质量。走 dense 优先质量。24GB 内存适合 14B 级 dense（Q5/Q6）当主力；要更快就上 Qwen3.6-35B-A3B——这个 MoE 只激活 3B，跑得快还能留出上下文，如果追求速度和可用质量的平衡，可以关注 Qwen3.6-35B-A3B 这类 35B 总参、约 3B 激活的 MoE；它更像是“轻量跑得动的大模型”，而不是纯质量优先的 dense 替代品。英文、推理、结构化输出场景，也可以关注 Gemma 4 系列；但中文写作主力，我还是会优先看Qwen。\n②独立开发者。 拆两种活：行内补全看 FIM 优化模型，比如 Codestral 系、Qwen Coder 系这类专门做过代码补全/代码指令微调的模型；Qwen3-Coder-30B-A3B 这类 MoE 编码模型，在特定 agent 框架和评测设置下已经能跑出不错的 SWE-bench Verified 成绩；但这个数字强依赖工具链、turn 数、执行环境，不能简单理解成“本地一跑就有云端编码 Agent 的水平”。诚实提醒：复杂重构、长链 Agent 这类重活，本地仍追不上云端——顶级开源 agentic 编码（GLM-5.2、Kimi K2.6、DeepSeek V4）基本是服务器级。本地的甜区是：补全、隐私敏感代码、离线、省 API 钱的高频小任务。\n③ 做分析 / 研究 / 咨询。 活是长文档摘要、问答、检索，命门是长上下文 + RAG，而不是模型本身多聪明。真正的超长上下文（1M token）几乎得靠 DeepSeek V4 这一级，本地塞不下，更适合「本地嵌入 + 脱敏后云端推理」的混合方案。关键认知：一套靠谱的 RAG 管线（嵌入 + 检索 + 生成）比单模型的参数量重要得多。\n④ 跑自动化 / Agent （24h 后台、批量、信号系统）。 活是无人值守、高频、批量、工具调用要稳，单次质量可以不顶尖，但量大、要便宜、要快。这是 MoE 的绝对主场。 激活参数小让每 token 又快又省电，适合放在常开的便宜机器（Mac Mini）上。可选 Gemma 4 26B-A4B（消费级硬件约 85 t/s）、Nemotron Cascade 2（30B 总参 / 3.5B 激活）、或 Qwen 30B-A3B。跑量场景里吞吐和电费完胜单次质量。\n⑤ 客户数据、法律、医疗、财务。 选本地的理由本身就是「数据不出机器」，质量第二位。这种反而要克制：在内存允许范围内挑一个最稳、可复现的 dense，别为了炫技硬塞一个勉强能跑的大 MoE。稳定性 \u0026gt; 峰值性能。\n还有一种特殊情况：当机器从「陪你一个」变成「同时服务 3–5 人」（比如做局域网推理服务器），评判标准从单流延迟切换成总吞吐和并发。如果是 NVIDIA GPU 服务器，可以优先考虑 MoE + vLLM 这类支持批处理的运行时；如果是 Mac 本地，现实一点的选择还是 LM Studio、Ollama、llama.cpp 或 MLX 系工具链。\n八、两个 2026 年的硬件现实 第一，推理速度很大程度看内存带宽，不只看芯片代数。例如 M4 Pro 的内存带宽是 273GB/s，而高配 M3 Max 可到 400GB/s。跑本地大模型时，老一代高带宽 Max 芯片，未必比新一代 Pro 芯片慢。买机器别只看 M3、M4、M5 这个代数，也要看 Max / Pro、内存容量和带宽。\n第二，别把购买决策全部押在下一代。如果你半年内就要稳定跑本地模型，与其等传闻中的 M5 Studio，不如看现在能买到的 M4 Max / M3 Ultra。内存和存储价格已经明显受 AI 需求影响，后面未必更便宜。我的判断是：刚需可以买，非刚需再等。\n结尾： 我现在选本地模型，已经不太问“哪个模型最强”了。\n这个问题太容易把人带偏。真正该问的是：这台机器到底是陪我一个人慢慢干活，还是替我在后台跑量？\n如果是前者，dense 往往更稳，内存花得更实在。\n如果是后者，MoE 的价值才真正出来：它不一定每次回答都最强，但它便宜、快、吞吐好，适合长期跑。\n先想清楚工作方式，再选模型架构，最后才看具体型号。顺序反了，就很容易买一台看起来很强、实际用起来别扭的机器。\n本文涉及的模型版本、硬件信息为 2026 年年中数据，本地模型生态变化极快，落地前请以官方模型卡和最新发布为准。\n","permalink":"https://blog.onecai.site/2026/06/22/020-dense-moe/","summary":"\u003cp\u003e在众多模型中找适合自己的模型时，会看到类似\u003ccode\u003eQwen3-32B\u003c/code\u003e 和 \u003ccode\u003eQwen3-30B-A3B\u003c/code\u003e名字很相似的模型名称，一个带“A”，一个不带。参数量看着差不多，到底差在哪？\u003c/p\u003e\n\u003cp\u003e这两个字母背后，藏着本地部署里最重要的一条分界线。搞懂它，你才知道自己那台机器该喂什么、该买什么。这篇就把它从头讲透，最后落到一个很实际的问题上：\u003cstrong\u003e不同的一人公司，到底该怎么选本地模型。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"一一句话区别处理一个字时到底激活了多少参数\"\u003e一、一句话区别：处理一个字时，到底激活了多少参数\u003c/h2\u003e\n\u003cp\u003e先建立一个直觉。你可以把一个大模型想象成一家公司，公司里有一大群员工——每个员工就是一个「参数」（实际上是几十亿、上千亿个数字）——这个比喻不严谨，但足够帮我们理解后面的选择逻辑。\u003c/p\u003e\n\u003cp\u003e所谓「32B 模型」，B 是 billion（十亿），就是这家公司有 320 亿名员工。\u003c/p\u003e\n\u003cp\u003e模型「思考」的过程，是把你输入的文字拆成一个个小单位（叫 token，大致是「字」或「词的一部分」），然后让员工对每个 token 算一轮，吐出下一个字。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e稀疏和稠密的区别，不看公司一共多少人，只看处理一个字时，实际有多少人在干活。\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e稠密（dense）\u003c/strong\u003e：每来一个字，全部员工都上工。激活参数 = 总参数。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e稀疏（MoE，混合专家）\u003c/strong\u003e：每来一个字，只叫醒一小撮人，其余继续睡觉。激活参数 ≪ 总参数。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e学名叫「激活稀疏性」或「条件计算」。一句话：\u003cstrong\u003e总参数决定它知道多少，激活参数决定它每个字算得多快、多贵。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"二稠密全来一个字全公司加班\"\u003e二、稠密：全来一个字，全公司加班\u003c/h2\u003e\n\u003cp\u003e传统模型是稠密的。规矩很简单粗暴：每处理一个 token，320 亿员工一个不落，全部上工。\u003c/p\u003e\n\u003cp\u003e好处是简单、稳定、质量扎实；坏处是贵。员工越多，处理每个字越慢、越耗电、越吃内存。你想让它更聪明（加更多员工），处理每个字的成本就线性地往上涨，逃不掉。\u003c/p\u003e\n\u003ch2 id=\"三稀疏-moe路由器翻牌子只叫醒几个专家\"\u003e三、稀疏 MoE：路由器翻牌子，只叫醒几个专家\u003c/h2\u003e\n\u003cp\u003e后来人们想了个偷懒的办法，这就是 MoE。\u003c/p\u003e\n\u003cp\u003e它把公司里干重活的那个部门（技术上叫 FFN 层）拆成了\u003cstrong\u003e一群专家\u003c/strong\u003e，比如 64 个、128 个，各有所长。然后在专家前面安排了一个\u003cstrong\u003e前台调度员，叫「路由器」（router）\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e每来一个 token，路由器先瞄一眼：「这个字大概讲代码，叫醒 2 号和 47 号就够了。」于是\u003cstrong\u003e只有被点名的那几个专家干活，其余几十个继续睡觉\u003c/strong\u003e，完全不参与这个字的计算。下一个字来了，路由器可能又翻别的牌子。\u003c/p\u003e\n\u003cp\u003e这个「每次只激活一小撮」的特性，就是「稀疏」这个名字的来历。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"dense_vs_moe_forward_pass.avif\"\n          alt=\"稠密与 MoE 两种前向传播对比\"/\u003e \u003cfigcaption\u003e\n             稠密与 MoE 两种前向传播对比\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e\u003cem\u003e上图左边是稠密——每来一个 token，全部参数（亮的）都参与；右边是 MoE——路由器翻牌子，只有 2 个专家被叫醒，其余 4 个灰着不计算。颜色就是全部信息量：亮 = 真的在算，灰 = 睡觉不耗算力。\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"四怎么一眼认出来看名字里那个大写-a\"\u003e四、怎么一眼认出来？看名字里那个大写 A\u003c/h2\u003e\n\u003cp\u003e这是最实用的技巧。模型名字里的「A」就是 Activated（激活）：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eQwen3-32B\u003c/code\u003e：没有 A，\u003cstrong\u003e稠密\u003c/strong\u003e，320 亿员工全部上工。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eQwen3-30B-A3B\u003c/code\u003e：有 A，\u003cstrong\u003eMoE\u003c/strong\u003e，总共 300 亿，但每个字只激活 30 亿（A3B）。\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eQwen3-235B-A22B\u003c/code\u003e：总 2350 亿，每个字只动用 220 亿。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e在 Qwen 这类命名里，A 基本可以理解为 Activated，也就是每 token 激活参数量。看到 30B-A3B、235B-A22B，大概率就是 MoE。没有 A 的 Qwen3-32B，则是 dense。命名规则直接把答案写在脸上了。\u003c/p\u003e","title":"本地模型别只看总参数：稠密和稀疏差别很大"},{"content":"这是下篇，来看看内存占用速查表、质量优先的选型心法，以及把 Qwen3-32B 跑通的全流程实操。\n上篇我们把名字和原理讲透了——模型名怎么拆、量化是什么、为什么 Mac 适合跑大模型。这篇直接上硬货，回答三个最实际的问题：能跑多大、该选哪个、怎么跑通。\n下面所有结论，我都以一台 MacBook Pro M4 Pro、24GB 统一内存、273GB/s 带宽为例。你可以按自己机器的内存和带宽对号入座。\n一、你这台 Mac 到底能跑多大？ 先解决一个默认的坑 macOS 默认只允许大约 16GB 内存分给 GPU（Metal），哪怕你有 24GB。所以很多人第一反应“我 24GB 怎么连个 27B 都加载失败”，原因就在这。\n解决办法是手动抬高上限（具体命令放在第三部分实操里）。抬高之后，在“机器专用、关掉浏览器和其他重应用”的状态下，真正能用于“权重 + KV cache + 运行时开销”的预算大约 20~21GB。\n24GB 统一内存并不是全部都能给模型用 内存占用速查表 公式还是上篇那个：权重 ≈ 参数量 × bpw ÷ 8。下表是各规模、各量化档位下，仅权重的占用（GB）。KV cache 和运行时开销要另外再加约 1.5~3GB（取决于上下文长度）。\n规模 IQ4_XS Q4_K_M Q5_K_M Q6_K Q8_0 9B 4.8 🟢 5.5 🟢 6.4 🟢 7.4 🟢 9.6 🟢 14B 7.5 🟢 8.5 🟢 10.0 🟢 11.6 🟡 14.9 🟡 27B 14.5 🟡 16.4 🟡 19.2 🔴 22.3 🔴 28.7 🔴 32B 17.2 🟡 19.4 🔴 22.8 🔴 26.4 🔴 34.0 🔴 35B 18.8 🔴 21.2 🔴 24.9 🔴 28.9 🔴 37.2 🔴 40B 21.5 🔴 24.2 🔴 28.5 🔴 33.0 🔴 42.5 🔴 🟢 舒适（含长上下文也够）　🟡 临界（需抬内存上限、机器专用、上下文别拉满）　🔴 不现实\nMLX 版同档位比 GGUF 略省 5~10%，且 Apple Silicon 上带宽利用更好，这台机器优先选 MLX。\n三句话结论 9B~14B 才是 24GB 的真正舒适区，还能留出 6~8GB 给 KV cache 跑长上下文。 27B / 32B 只在 4bit 一档勉强能跑，属于“机器专用”状态，上下文一长就容易爆。 35B / 40B 在 24GB 上基本没戏——光权重就吃满，留不下 KV 和系统。它们是留给更大内存机型（比如 64GB 的 Mac Studio）的。 二、以输出质量为优先，到底该选哪个？ 假设你和我一样，主要做文本总结、prompt 处理这类任务，又希望输出质量尽量高、机器可以专用。该怎么选？\n与其直接甩答案，我更想给你四条可复用的心法——换个任务、换台机器也照样用得上。\n心法一：参数量 \u0026gt; 量化精度 上篇那条地基结论，这里直接落地：别把小模型拉到 Q8，要在内存装得下的前提下塞进尽可能大的 dense 模型，量化停在 4bit。\n一个 32B 的 4bit，质量明显高于一个 14B 的 Q8——尽管后者文件可能还更大。\n心法二：质量优先，选 dense，别选 MoE 上篇讲过 MoE（如 30B-A3B）的特点：内存吃得多、但速度快、单 token 质量天花板偏低。\n所以——追求速度选 MoE，追求质量选 dense（密集）模型。 你既然不在乎速度、只要质量，就该选真正的 32B dense，而不是 30B-A3B 这种。\n心法三：任务决定选型 不是模型越大越好，而是任务决定选型 这点最容易被忽略。不同任务的瓶颈不一样：\n总结 / prompt 处理：瓶颈是“指令遵循能力 + 能吃下多长的上下文”，不是推理深度。所以“14B 高量化 + 留足 KV cache”常常比“27B 低量化挤爆内存”更实用。也因此，这类任务不需要 Thinking 推理模型——那一大段思维链只会拖慢、啰嗦。 复杂推理 / 数学 / 代码：才真正吃参数量和推理能力，值得上更大的模型或 Thinking 版。 先想清楚你要干什么，再去挑模型。\n心法四：KV cache 设 Q8，等于白嫖内存 这是个几乎无损的省内存技巧。在 LM Studio 里把 KV cache 量化设成 Q8，KV 占用直接砍半。省出来的内存，你可以拿去升一档权重量化，或者把上下文拉得更长。质量优先场景，强烈建议开。\n落到具体答案 如果你就是要一个“24GB MacBook、质量优先做总结”的明确答案：\n质量上限：Qwen3-32B 的 IQ4_XS / MLX 4bit，搭配 Q8 KV cache。这是这台机器能压榨出的质量天花板。 更稳的次选：Gemma 3 27B（Q4_K_M） 或 Qwen3-27B 档。27B 比 32B 留更多余量，长文档时不容易爆。 追求舒适与速度：Qwen3-14B（MLX 6bit / GGUF Q5_K_M）。这是性价比和稳妥度最高的总结主力，留得出 8GB 给上下文。 我的建议：把 32B-4bit 和 27B 都下下来，拿同一段你常用的文本做对照，看哪个的中文输出更对胃口——大体上 Qwen3 偏精准凝练，Gemma 偏流畅自然。\n三、实战：把 Qwen3-32B 在 24GB 的 MacBook 上跑通 理论说完，来真的。以质量上限 Qwen3-32B 为例，走一遍完整流程。\n第一步：抬高 GPU 内存上限 终端执行（这一步重启后会失效）：\n1 sudo sysctl iogpu.wired_limit_mb=21504 # 放开到 21GB，留约 3GB 给系统 验证：\n1 2 sysctl iogpu.wired_limit_mb # 输出 iogpu.wired_limit_mb: 21504 就对了 想让它开机自动生效，建一个系统级 LaunchDaemon：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 sudo tee /Library/LaunchDaemons/com.local.gpulimit.plist \u0026gt; /dev/null \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; \u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Label\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.local.gpulimit\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProgramArguments\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;string\u0026gt;/usr/sbin/sysctl\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;iogpu.wired_limit_mb=21504\u0026lt;/string\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;key\u0026gt;RunAtLoad\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/plist\u0026gt; EOF sudo launchctl load /Library/LaunchDaemons/com.local.gpulimit.plist 第二步：下载——23 个结果里怎么挑？ 这是最容易翻车的一步。在 LM Studio 里搜 Qwen3-32B，往往蹦出来一长串同名结果。挑选记住两条：\n✅ 认准这些 publisher： lmstudio-community、mlx-community、模型官方（如 Qwen 本家）。优先选下载量大的——经过最多人验证，出问题概率最低。\n❌ 避开这些：\n看到这个词 为什么避开 VL / Vision 多模态版，你只做文本，白占体积还可能稀释文本能力 Thinking / Reasoning 推理模型，会先吐一大段思维链，总结任务用不上、还拖慢 abliterated / uncensored 去掉安全护栏的社区改版，日常用不需要 个人小号 publisher + 下载量个位数 来源不明、未经验证，跳过 补充：偶尔会看到 -DWQ 后缀，那是一种更新的量化方法，同 4bit 下质量通常更好一点点。属于进阶可选项，新手先不折腾，认准前面说的稳妥版本即可。\n下载时认准体积大概 17~18GB（4bit 的 32B 正常就这么大）。\n第三步：加载参数怎么设 下完别用默认设置直接加载，点开参数面板调这几项：\nContext Length（上下文长度）：32B 在 21GB 预算下是临界状态，别拉满。先设 8192，跑通了再视情况往上试 16384。总结单篇长文通常 8K~16K 够用。 GPU Offload / GPU Layers：拉到最大（全部层都上 GPU）。统一内存架构下没必要留层在 CPU。 KV Cache Quantization：设成 Q8——就是心法四说的省内存关键。GGUF 版找 K Cache / V Cache 量化选项，两个都设 Q8_0。 Flash Attention：GGUF 版若有这个开关，打开（开了 KV 量化更稳更省）。 第四步：验证没爆内存 加载并开始对话后，另开终端看：\n1 sudo memory_pressure # 看内存压力，别进 critical 或者直接看活动监视器的「已用内存」和「交换（swap）」。\n最关键的一条判断：有没有用到 swap。 一旦开始大量 swap，速度会断崖式下跌。没 swap、内存压力正常，就是稳的。\n排错速查表 现象 原因 处理 加载失败 / 报内存不足 预算不够 确认第一步生效；Context 降到 4096 再试 加载成功但巨慢、风扇狂转 用上 swap 了 降 Context、确认 KV 设了 Q8、关掉其他 App MLX 版找不到 KV 量化选项 版本 / 引擎限制 改用 GGUF IQ4_XS + K/V Cache Q8_0 输出质量没预期好 采样参数 Temperature 调到 0.3~0.6，总结任务低温更稳 选型决策速查 根据任务选择合适的本地模型 最后用一张表收口，下次选模型直接照着走：\n你要做什么 选多大 量化 格式 总结 / prompt（质量优先、机器专用） 32B dense 4bit / IQ4_XS + Q8 KV MLX 优先 总结 / prompt（求稳、留余量） 27B dense Q4_K_M MLX / GGUF 日常通用、要长上下文或并发 9B~14B Q5_K_M / 6bit MLX 优先 复杂推理 / 数学 / 代码 尽可能大 4bit 可选 Thinking 版 写在最后 两篇下来，从看懂一个模型名，到能亲手把 32B 跑通，应该就通了。\n如果只让我留一句心法，是这句：\n本地大模型选型，不是挑最强的，是挑你这台机器装得下、又最适合你任务的那一个。\n24GB 的 MacBook，质量天花板就停在 32B-4bit 这里。真要更高精度的 32B Q8、或者 35B/40B，那是更大内存机型该干的活——比如一台 64GB 的 Mac Studio 当作家里的 LAN 推理服务器。这个话题，留到以后再聊。\n本文是「本地大模型选型」系列下篇。上篇讲了命名规则、量化原理和 Mac 的架构优势，没看的可以翻回去补。觉得有用，欢迎转发收藏。\n","permalink":"https://blog.onecai.site/2026/06/21/019-choosemodel2/","summary":"\u003cp\u003e这是下篇，来看看内存占用速查表、质量优先的选型心法，以及把 Qwen3-32B 跑通的全流程实操。\u003c/p\u003e\n\u003cp\u003e上篇我们把名字和原理讲透了——模型名怎么拆、量化是什么、为什么 Mac 适合跑大模型。这篇直接上硬货，回答三个最实际的问题：\u003cstrong\u003e能跑多大、该选哪个、怎么跑通。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e下面所有结论，我都以一台 \u003cstrong\u003eMacBook Pro M4 Pro、24GB 统一内存、273GB/s 带宽\u003c/strong\u003e为例。你可以按自己机器的内存和带宽对号入座。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一你这台-mac-到底能跑多大\"\u003e一、你这台 Mac 到底能跑多大？\u003c/h2\u003e\n\u003ch3 id=\"先解决一个默认的坑\"\u003e先解决一个默认的坑\u003c/h3\u003e\n\u003cp\u003emacOS 默认\u003cstrong\u003e只允许大约 16GB\u003c/strong\u003e 内存分给 GPU（Metal），哪怕你有 24GB。所以很多人第一反应“我 24GB 怎么连个 27B 都加载失败”，原因就在这。\u003c/p\u003e\n\u003cp\u003e解决办法是手动抬高上限（具体命令放在第三部分实操里）。抬高之后，在“机器专用、关掉浏览器和其他重应用”的状态下，真正能用于“\u003cstrong\u003e权重 + KV cache + 运行时开销\u003c/strong\u003e”的预算大约 \u003cstrong\u003e20~21GB\u003c/strong\u003e。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"model2-1.avif\"\n          alt=\"24GB 统一内存并不是全部都能给模型用\"/\u003e \u003cfigcaption\u003e\n             24GB 统一内存并不是全部都能给模型用\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch3 id=\"内存占用速查表\"\u003e内存占用速查表\u003c/h3\u003e\n\u003cp\u003e公式还是上篇那个：\u003cstrong\u003e权重 ≈ 参数量 × bpw ÷ 8\u003c/strong\u003e。下表是各规模、各量化档位下，\u003cstrong\u003e仅权重\u003c/strong\u003e的占用（GB）。KV cache 和运行时开销要另外再加约 1.5~3GB（取决于上下文长度）。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e规模\u003c/th\u003e\n          \u003cth\u003eIQ4_XS\u003c/th\u003e\n          \u003cth\u003eQ4_K_M\u003c/th\u003e\n          \u003cth\u003eQ5_K_M\u003c/th\u003e\n          \u003cth\u003eQ6_K\u003c/th\u003e\n          \u003cth\u003eQ8_0\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e9B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e4.8 🟢\u003c/td\u003e\n          \u003ctd\u003e5.5 🟢\u003c/td\u003e\n          \u003ctd\u003e6.4 🟢\u003c/td\u003e\n          \u003ctd\u003e7.4 🟢\u003c/td\u003e\n          \u003ctd\u003e9.6 🟢\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e14B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e7.5 🟢\u003c/td\u003e\n          \u003ctd\u003e8.5 🟢\u003c/td\u003e\n          \u003ctd\u003e10.0 🟢\u003c/td\u003e\n          \u003ctd\u003e11.6 🟡\u003c/td\u003e\n          \u003ctd\u003e14.9 🟡\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e27B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e14.5 🟡\u003c/td\u003e\n          \u003ctd\u003e16.4 🟡\u003c/td\u003e\n          \u003ctd\u003e19.2 🔴\u003c/td\u003e\n          \u003ctd\u003e22.3 🔴\u003c/td\u003e\n          \u003ctd\u003e28.7 🔴\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e32B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e17.2 🟡\u003c/td\u003e\n          \u003ctd\u003e19.4 🔴\u003c/td\u003e\n          \u003ctd\u003e22.8 🔴\u003c/td\u003e\n          \u003ctd\u003e26.4 🔴\u003c/td\u003e\n          \u003ctd\u003e34.0 🔴\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e35B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e18.8 🔴\u003c/td\u003e\n          \u003ctd\u003e21.2 🔴\u003c/td\u003e\n          \u003ctd\u003e24.9 🔴\u003c/td\u003e\n          \u003ctd\u003e28.9 🔴\u003c/td\u003e\n          \u003ctd\u003e37.2 🔴\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e40B\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e21.5 🔴\u003c/td\u003e\n          \u003ctd\u003e24.2 🔴\u003c/td\u003e\n          \u003ctd\u003e28.5 🔴\u003c/td\u003e\n          \u003ctd\u003e33.0 🔴\u003c/td\u003e\n          \u003ctd\u003e42.5 🔴\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e🟢 舒适（含长上下文也够）　🟡 临界（需抬内存上限、机器专用、上下文别拉满）　🔴 不现实\u003c/p\u003e","title":"别再被的模型名劝退了（下）：你的电脑能跑多大，又该怎么选"},{"content":"这一篇是上篇，先看懂模型的名字、量化的门道，以及——凭什么是 Mac。\n写在前面 想在 MacBook 上跑个本地模型，打开 LM Studio 的 Discover，搜了一下 Qwen3-32B，结果蹦出来 23 个。\n9B、27B、35B、40B 一堆数字也就罢了，每个名字后面还拖着一长串字母：MLX、4bit、IQ4_XS、Q4_K_M、Thinking、abliterated、DWQ……\n到底下哪个？哪个是给这台机器的？哪个下回来跑不动？哪个其实是个根本不需要的版本？\n如果你也在这一步卡住过，这篇就是写给你的。这篇把本地大模型的命名规则、量化原理、为什么 Mac 适合干这事一次讲透。下篇再接着讲这台机器到底能跑多大、质量优先怎么选、以及怎么把 Qwen3-32B 实际跑通。\n先从最让人头大的——名字——开始。\n面对一堆模型名不知道该选哪个 一、模型的名字，其实是四段拼起来的 看着乱，是因为四个不同维度的信息全挤在一个文件名里。拆成四段就清楚了：\n模型名 + 参数规模 + 模型类型 + 量化格式\n1. 参数规模：那个 B 是什么 9B、27B、32B 里的 B = Billion，十亿。指的是模型的参数量。数字越大，模型“脑容量”越大，能力上限越高，但也越吃内存、越慢。\n这里有个容易踩的坑：MoE 模型。你会看到类似 Qwen3-30B-A3B 的写法——\n30B 是总参数 A3B 是 Active 3B，每次推理实际只激活 3B 这意味着：一个 30B-A3B 的 MoE，显存占用接近 30B，但速度接近 3B。它是“装得满、跑得快”的设计。这个特性后面选型时很关键，先记住。\n2. 模型类型：这个模型“会做什么” 名字中间那段单词，决定了模型的用途：\n后缀 含义 Instruct / -it 指令微调版，能听懂指令、能对话。日常用的就是它（it = instruction tuned） Base 只做了预训练、没对齐，是“续写型”。一般别下，除非你要自己微调 Chat 对话微调，和 Instruct 类似 Coder / Code 代码专用 VL / Vision 多模态，能看图（如 Qwen-VL） Thinking / Reasoning / R1 推理模型，会先输出一大段思维链再回答 Distill 从更大的模型蒸馏出来的（如 DeepSeek-R1-Distill-Qwen-32B） abliterated / uncensored 社区改版，去掉了安全护栏 一句话：做日常任务认准 Instruct/-it 就对了，其余的是各有专门用途。\n3. 量化格式：最让人困惑的那一坨 Q4_K_M、IQ4_XS、4bit……这些是同一个模型压缩程度不同的版本，决定文件大小和质量。\n量化是什么、为什么能压缩，下一节专门讲。这里先认字：\nGGUF 格式（llama.cpp / Ollama 用）：\nQ4 / Q5 / Q8：量化到几 bit，数字越大越接近原始精度、文件越大 _K：K-quants，新一代量化方法，同 bit 下质量比老的 _0/_1 更好 _S / _M / _L：Small / Medium / Large，同一档里的细分取舍。比如 Q4_K_M = 4bit、K 量化、中等档，这是社区最常推荐的“质量/体积平衡点” IQ 开头（如 IQ4_XS）：I-quants，低 bit 下比同位 K-quant 更省、质量更高 MLX 格式（Apple Silicon 专用）：\n通常直接写 4bit / 6bit / 8bit，没有 K/IQ 这套，方案更简单统一 复杂模型名其实可以拆开理解 拼起来看一个完整例子 Qwen3-30B-A3B-Instruct-MLX-4bit\n拆开就是：\nQwen3 —— 模型名 30B-A3B —— 总参 30B、激活 3B 的 MoE Instruct —— 指令版 MLX —— 格式（Apple Silicon） 4bit —— 量化档位 是不是一下就读懂了？以后看任何模型名，都按这四段拆。\n二、量化到底是什么：为什么能把模型压缩还不太掉质量 上面一直在说“量化”，这节讲清楚原理。搞懂它，你才知道为什么“4bit 是甜区”。\n一句话定义 模型的每个参数（权重），原本是用 16bit 的浮点数（FP16）存的。量化，就是把它压成 4bit、5bit、8bit 来存。\n8bit 就把体积砍掉一半，4bit 直接砍到 1/4。一个原本 60 多 GB 的 32B 模型，4bit 之后只剩 17~18GB——这才让它能塞进一台消费级 Mac。\n一个关键概念：bpw bpw = bits per weight，每个权重平均占多少比特。它是估算模型体积的根：\n权重体积 ≈ 参数量 × bpw ÷ 8（字节）\n比如 32B 模型、4bit（bpw≈4.3），体积 ≈ 32 × 4.3 ÷ 8 ≈ 17.2GB。下篇的占用表就是这么算出来的。\n损失了什么？没你想的多 压缩总要付代价，代价是精度。但有意思的是——4bit 相比原始的 FP16，质量只掉一点点。\n衡量这个“掉多少”的指标叫困惑度（perplexity），数值越低代表模型越“确信”、质量越好。实测下来，从 FP16 压到 4bit，困惑度只上升很小一截，但体积砍掉了 3/4。性价比极高。这就是为什么社区公认 4bit 是甜区。\n一个会反直觉、但极重要的结论 很多人第一反应是“我内存够，那我就下最高精度的版本”。但真相是：\nQ4 → Q5 → Q6 的质量差，很小。 14B → 32B，是能力的跨级提升。\n换句话说——参数量带来的收益，远远大于量化精度带来的收益。\n所以如果你的内存有限，正确策略不是“把一个小模型拉到 Q8 最高精度”，而是“在内存装得下的前提下，塞进尽可能大的模型，量化停在 4bit 这条线上”。\n这条心法是整个选型方法论的地基，下篇会反复用到。\n三、跑本地大模型，凭什么是 Mac？ 讲完软件层，回头说硬件。为什么这两年“在 Mac 上跑大模型”突然成了热门？答案藏在 Apple Silicon 的架构里。\nApple Silicon 靠统一内存装下大模型，MLX 更适合 Mac 优势一：统一内存（UMA） 普通 PC 里，内存和显存是分开的。跑大模型靠的是显存（VRAM），而消费级显卡的显存普遍只有 8/12/16GB，想要 24GB 显存得上很贵的卡。\nApple Silicon 是统一内存架构（Unified Memory）：CPU 和 GPU 共用同一块内存。这意味着——\n你这台 24GB 的 Mac，这 24GB 全都能拿来装模型。\n一台几千块到一万出头的 Mac，能装下需要 20GB 级“显存”才跑得动的模型。这是 Mac 跑大模型最大的底气。\n优势二（也是限制）：速度由带宽决定 但“装得下”不等于“跑得快”。本地推理的速度瓶颈，几乎都卡在内存带宽上（memory bandwidth bound）。\n一个粗略但好用的直觉：\n生成速度（token/s）≈ 内存带宽 ÷ 模型每生成一个 token 要读取的字节数\n模型越大，每个 token 要读的数据越多，速度就越慢。这也解释了一个常见现象：同一台 Mac，小模型飞快，大模型能跑但明显变慢。\n举几个参考数：入门级 Apple Silicon 带宽一百多 GB/s，到 M4 Pro 这一档 273GB/s，再往上 Max/Ultra 能到五六百甚至上千 GB/s。带宽越高，越能把大模型“喂饱”。这就是为什么真要跑大模型，大家盯着的是 Max/Ultra 加大内存的机型。\n优势三：MLX，Apple 的亲儿子框架 回到开头那个困惑——MLX 和 GGUF 到底选哪个？\nGGUF（llama.cpp 生态）：跨平台通吃，Windows/Linux/Mac 都能跑，生态最大、模型最全 MLX：Apple 自己为 Apple Silicon 打造的框架，在 Mac 上更省内存、带宽利用更好、推理更快 结论很简单：如果你在 Mac 上，优先选 MLX 版本。 只有当某个模型没有 MLX 版、或你需要某些 GGUF 才有的特性（比如更灵活的 KV cache 量化）时，再退回 GGUF。\n综上所述： 到这里，开头那串劝退的字母，应该都不再陌生了：\n模型名 = 模型名 + 参数规模 + 模型类型 + 量化格式，四段拆开看 量化 = 把权重从 16bit 压到 4/8bit，4bit 是甜区；记住“参数量 \u0026gt; 量化精度” Mac 靠统一内存装得下大模型，速度由带宽决定，框架优先 MLX 下篇我们落到实处，回答三个最硬核的问题：\n你这台 Mac 到底能跑多大的模型？（附 9B 到 40B 的内存占用速查表） 以输出质量为优先，到底该选哪个？（一套可复用的选型心法） 怎么把 Qwen3-32B 真正在 24GB 的 MacBook 上跑通？（从抬内存上限到避坑下载，一条龙实操） 下篇见。\n本文是「本地大模型选型」系列上篇。如果觉得有用，欢迎转发给同样在 LM Studio 里挑花眼的朋友。\n","permalink":"https://blog.onecai.site/2026/06/20/018-choosemodel/","summary":"\u003cp\u003e这一篇是上篇，先看懂模型的名字、量化的门道，以及——凭什么是 Mac。\u003c/p\u003e\n\u003ch2 id=\"写在前面\"\u003e写在前面\u003c/h2\u003e\n\u003cp\u003e想在 MacBook 上跑个本地模型，打开 LM Studio 的 Discover，搜了一下 \u003ccode\u003eQwen3-32B\u003c/code\u003e，结果蹦出来 23 个。\u003c/p\u003e\n\u003cp\u003e9B、27B、35B、40B 一堆数字也就罢了，每个名字后面还拖着一长串字母：MLX、4bit、IQ4_XS、Q4_K_M、Thinking、abliterated、DWQ……\u003c/p\u003e\n\u003cp\u003e到底下哪个？哪个是给这台机器的？哪个下回来跑不动？哪个其实是个根本不需要的版本？\u003c/p\u003e\n\u003cp\u003e如果你也在这一步卡住过，这篇就是写给你的。这篇把\u003cstrong\u003e本地大模型的命名规则、量化原理、为什么 Mac 适合干这事\u003c/strong\u003e一次讲透。下篇再接着讲\u003cstrong\u003e这台机器到底能跑多大、质量优先怎么选、以及怎么把 Qwen3-32B 实际跑通\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e先从最让人头大的——名字——开始。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"model1-1.avif\"\n          alt=\"面对一堆模型名不知道该选哪个\"/\u003e \u003cfigcaption\u003e\n             面对一堆模型名不知道该选哪个\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003ch2 id=\"一模型的名字其实是四段拼起来的\"\u003e一、模型的名字，其实是四段拼起来的\u003c/h2\u003e\n\u003cp\u003e看着乱，是因为四个不同维度的信息全挤在一个文件名里。拆成四段就清楚了：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e模型名 + 参数规模 + 模型类型 + 量化格式\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"1-参数规模那个-b-是什么\"\u003e1. 参数规模：那个 B 是什么\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e9B\u003c/code\u003e、\u003ccode\u003e27B\u003c/code\u003e、\u003ccode\u003e32B\u003c/code\u003e 里的 B = Billion，十亿。指的是模型的参数量。数字越大，模型“脑容量”越大，能力上限越高，但也越吃内存、越慢。\u003c/p\u003e\n\u003cp\u003e这里有个容易踩的坑：MoE 模型。你会看到类似 \u003ccode\u003eQwen3-30B-A3B\u003c/code\u003e 的写法——\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e30B\u003c/code\u003e 是\u003cstrong\u003e总参数\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eA3B\u003c/code\u003e 是 \u003cstrong\u003eActive 3B\u003c/strong\u003e，每次推理实际只激活 3B\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这意味着：一个 30B-A3B 的 MoE，\u003cstrong\u003e显存占用接近 30B，但速度接近 3B\u003c/strong\u003e。它是“装得满、跑得快”的设计。这个特性后面选型时很关键，先记住。\u003c/p\u003e\n\u003ch3 id=\"2-模型类型这个模型会做什么\"\u003e2. 模型类型：这个模型“会做什么”\u003c/h3\u003e\n\u003cp\u003e名字中间那段单词，决定了模型的用途：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e后缀\u003c/th\u003e\n          \u003cth\u003e含义\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eInstruct / -it\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e指令微调版，能听懂指令、能对话。日常用的就是它（it = instruction tuned）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eBase\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e只做了预训练、没对齐，是“续写型”。一般别下，除非你要自己微调\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eChat\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e对话微调，和 Instruct 类似\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eCoder / Code\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e代码专用\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eVL / Vision\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e多模态，能看图（如 Qwen-VL）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eThinking / Reasoning / R1\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e推理模型，会先输出一大段思维链再回答\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eDistill\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e从更大的模型蒸馏出来的（如 DeepSeek-R1-Distill-Qwen-32B）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eabliterated / uncensored\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e社区改版，去掉了安全护栏\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e一句话：\u003cstrong\u003e做日常任务认准 Instruct/-it 就对了\u003c/strong\u003e，其余的是各有专门用途。\u003c/p\u003e","title":"别再被模型名劝退了（上）:从一堆字母看懂本地大模型"},{"content":"DAN KOE 发布了最新newsletter《How to survive AI mass replacement （\u0026amp; escape wage slavery）》，标题很猛，里面也有不少他一贯锋利的表达：wage slavery、unemployable、life\u0026rsquo;s work，直译过来都带着刺。\nAI 时代的分叉路口 但它表面在讲 AI 和就业，内核其实不是「AI 会不会抢走你的工作」。它真正问的是：一个人到底要不要继续把自己的生存，完全交给别人。\n现在大家聊 AI，常见两种情绪。一种是兴奋，觉得终于有了超级工具；另一种是愤怒，觉得 AI 偷走了创作者的东西，把世界搞得更卷。\nDan Koe 对第二种情绪不太客气。他认为，在社交媒体上喊几句「反 AI」，确实容易获得身份认同，也容易让人觉得自己站在了正确的位置上。但喊完之后呢？生活不会因为你反对 AI 就变得更稳，雇主不会因为你不喜欢 AI 就永远保留你的岗位，技术更不会因为你觉得不公平就慢下来等你。\n所以他给了一个很反直觉的判断：\nAI 不是真正的威胁，依附性才是。\n你依附于一个雇主、一份工资、一个平台、一套过去有效的技能，甚至依附于「只要我努力工作，生活就会越来越好」的旧叙事。这些东西一旦变化，你就立刻被动。这才是更深层的风险。\n工资奴役，不只是工资低的问题 文章里最刺耳的一个词是 Wage Slavery，工资奴役。\n工资依附感：看得见的收入，看不见的锁链 很多人会本能反驳：我又不是奴隶，我有工资，也有选择。但他讲的不是传统意义上的奴役，而是一种金融意义上的困住——\n如果你不上班就会陷入灾难，而且你没有任何技能去创造替代方案，那么不管你感觉自己多自由，你都符合某种奴隶的定义。\n这话很难听，但也很难完全反驳。\n当然，他不是反对工作本身。工作有价值，尤其在一个人刚进入社会时，它是最快的训练场：协作、流程、交付、沟通、专业技能，还有真实世界到底怎么运转。问题是，很多人把工作当成了唯一的生存方式。\n一开始，工作是踏脚石。时间久了，踏脚石变成了笼子。\nDan Koe 在这里提到心流理论，我很有共鸣。一个人真正有成就感，往往不是躺平时，也不是被迫重复时，而是处在「能力边缘」上：事情略微超过你的能力，你需要学习、尝试、犯错，然后一点点掌控它。太简单会无聊，太难会焦虑。\n很多工作的问题就在这里。刚开始你觉得新鲜，什么都要学；几年以后你掌握了流程，挑战感下降，剩下的变成重复、等待、汇报、填表、开会。人当然会无聊，无聊之后就会找刺激——刷短视频、买东西、沉迷各种即时反馈。不是因为真的喜欢，而是大脑已经很久没被真正的挑战点亮过了。\n所以「逃离工资奴役」，不是简单喊一句「我要辞职创业」。它真正指向的是：你要重新获得安排挑战等级的能力。 不再只是被别人分配任务，而是开始给自己设计任务。\nAI 让「能做出来」越来越不值钱 Dan Koe 在第二部分讲了五个能力：能动性（Agency）、品味（Taste）、说服力（Persuasion）、坚持（Persistence）、迭代（Iteration）。\nAI 让“能做出来”贬值：满地半成品 这几个词都不新，尤其 high agency 这几年快被说烂了。但他很讽刺地说：一群人跟风谈 high agency，本身就暴露了他们没什么 agency。这个判断挺狠，也挺准——真正的能动性，不是转发几句金句，而是没人催你、没人给流程、没人保证结果的时候，你仍然能开始做一件事。\n这五个能力压缩一下，其实就是两件事：\n把事情搞定的能力。知道什么事情值得搞定的经验。\n这就牵出 AI 时代一个关键变化。\n以前，能不能做出来本身就是门槛：做网站要懂代码，做视频要学剪辑，写文章要有大量表达训练。现在 AI 把这些门槛全推低了——你不会写代码也能做个小工具，不会画图也能生成图片，不会写长文也能让 AI 列大纲、润色、翻译。\n于是问题彻底变了。过去的问题是「我能不能做出来」，现在的问题是：这东西值不值得做？有没有人在乎？我能不能持续改到有人愿意用、愿意看、愿意付费？\nDan Koe 引了 Strauss Zelnick 的观点（转引），大意是：AI 擅长资产创造，但资产创造不等于爆款创造。\n做出一个东西，和做出一个有人在乎的东西，是两回事。每年很多游戏被做出来，真正爆的没几个；每天大量文章被发出来，被记住的没几篇。「能造」这件事正在贬值，真正值钱的是判断力：知道什么该做、什么只是看起来像好、用户为什么不在乎、一句话怎么说别人才愿意听、失败之后该调整哪里而不是马上换赛道。\n这就是 Taste、Persuasion、Iteration。它们不是看几个教程就能学会的，只有你真的开始做自己的东西，才会被现实反复教育。\n让自己变得「不可雇佣」 文章里还有一个词我很喜欢：unemployable，不可雇佣。\n它不是说一个人没能力找工作，而是说他已经很难再接受那种完全被别人安排的人生。\n第一次真实反馈 Dan Koe 讲了自己的故事：第一个网页设计客户是一家本地床垫公司，他手写代码做了个很糟糕的网站，赚了 300 美元。金额不大，冲击很大——因为那一刻他意识到，原来我可以不通过一份正式工作，也能凭自己的能力从市场里拿到钱。\n这个「咔哒」一下的时刻，比 300 美元本身重要得多。\n很多人缺的就是这个时刻。不是缺商业模式，不是缺完美计划，也不是缺一门课，而是缺一次具体的、小额的、真实的市场反馈：第一次有人愿意为你的服务付钱，第一次有人因为你的文章关注你，第一次有人用了你做的小工具，第一次有人说「你这个东西对我有用」。\n这些反馈会改变一个人的身份感。你会从「我只能等别人给我机会」，慢慢变成「我可以试着创造机会」。\nDan Koe 说，行为改变就是身份改变。你不是先想明白自己是谁、才开始行动；很多时候，是你先换了行为，才慢慢变成另一个人。换掉每天看的内容，换掉下班后的默认动作，换掉遇到问题就找教程、找标准答案的习惯，开始发东西、开始交付、开始面对真实反馈——身份就是这样被一点点改写的。\n为什么他说「媒体大于代码」 这篇文章里有一个可能让技术人不舒服的判断：\n媒体 \u0026gt; 代码。\n这里的媒体不是传统媒体机构，而是内容：文章、帖子、视频、播客、newsletter。\n他不是说代码不重要。软件仍是非常强的杠杆，尤其在 AI 时代，一个人做小工具的能力比以前强太多。但代码的价值更容易被客观化——一个工具能不能跑、功能有没有实现、结果是否符合预期，相对容易判断。也正因为客观，它更容易被 AI 商品化。你想要一个记账工具、待办工具、网页抓取工具、Markdown 转换工具，现在 AI 都能给你一个能跑的版本。\n但做出来之后呢？没人知道，没人使用，没人付费。这就是大量小软件的命运：它们没有分发。\n而媒体能力，本质上就是分发能力。你能不能把一个问题讲清楚？能不能让别人意识到自己也有这个问题？能不能让别人相信你的方案值得试？能不能持续用内容建立信任？这些 AI 可以辅助，但不能替你完成——因为内容的价值很主观，同一句话不同的人读出来完全不一样，这就要求创作者必须有自己的判断力。\n我自己最近就有体感。之前一直用 iPhone 自带的快捷指令拼一些半自动小工具，但用起来总不趁手。于是我开始借助 AI，在聊天窗口里一句句把需求说出来——免费 token 用完了，就等下一轮额度刷新再接着聊。这样断断续续三个多月，我的第一款 iOS app 眼看就要完工，再测一测就能上架了。\n但真正做完那一刻我才意识到：把它「写出来」其实是整件事里最不难的部分。跟 AI 说想法，就像和一个很聪明的人对话，你表达得再蹩脚，他大致都能理解。难的是后面——这个 app 凭什么有人下载？我怎么让别人知道它能解决什么问题？我有没有能力把它讲清楚、让人愿意试？\n写出来只花了三个月，而这些问题，可能要花我接下来更长的时间。\n这也是这篇文章最值得拿来提醒自己的地方。现在很多人一谈 AI 就开始讨论工具、模型、提示词、工作流，这些当然有用，但更底层的问题是：你到底有什么要表达？你到底看见了什么别人没看见的东西？你有没有一个持续输出的方向？没有这些，工具越强，产出的垃圾越多。\n15 分钟，先挖出自己的原材料 15 分钟练习：不是深夜写作，而是白天清空桌面 文章最后给了一个很简单的练习。不是让你辞职，不是让你写商业计划书，也不是让你报课，而是关掉所有标签页，打开一个空白文档，设 15 分钟计时器，回答几个问题。\n我把它整理成了更适合自己用的版本。\n第一步：挖掘你的原材料\n我对什么东西懂得太多，多到不可能只是偶然？有没有什么话题，是我跨很多来源、研究了好几年，却从没人付钱给我？ 我曾经为自己解决过什么问题，还以为别人早就搞定了？有什么事对我来说很自然，但别人好像经常搞砸？ 我小时候因为什么被骂，而那其实可能只是早熟的品味？在别人告诉我「不切实际」之前，我曾经痴迷过什么？ 这三个问题是为了找「原材料」——不是赛道，不是定位，而是你身上已经存在的东西。很多人的问题不是没有材料，而是太习惯忽视自己的材料，因为那些东西对自己太正常了：你研究多年的东西，你觉得「这有什么好说的」；你踩坑解决掉的问题，你觉得「别人应该也知道」。但内容创作最好的起点，往往就在这些地方。\n第二步：找到你的「逆主流脊柱」\nDan Koe 用了一个词 contrarian spine，我理解成「逆主流脊柱」——你到底认为主流错在哪里？\n哪一条主流建议，实际上让我的生活变得更糟？我必须忘掉什么，才重新正常运作？ 在我熟悉的领域里，我相信什么观点会被专家认为天真，但我就是无法放下？ 我所在的行业里，所有人都在假装看不见的是什么？ 这几个问题更尖锐，因为它不问「我喜欢什么」，而问「我反对什么」。Dan Koe 说，品味不只是知道什么是好的，也是知道什么是坏的、并且无法假装没看见。这句话很适合写作者：如果你只是重复大家都知道的正确话，很难写出有力量的东西；真正让人看下去的，往往是你说出了某种大家隐约感觉到、但没人明说的东西。\n个人理解：别急着做大事，先做自己的事 这篇文章如果只看标题，很容易被读成一篇「AI 时代个人如何翻身」的鸡血文。但读完之后，我觉得它没那么鸡血。它真正说的是一件很朴素的事：\n别再只是等待别人分配任务，开始做一个属于自己的东西。\n这个东西不一定大。可以是一篇持续写下去的 newsletter，一个很小的工具，一个账号，一套资料，一个围绕你真实经验展开的长期主题。\n重要的不是一开始就成功，而是你进入了一个循环：输出 → 获得反馈 → 修正判断 → 再输出。 这件事听起来普通，但它和只上班、只消费信息、只收藏教程，是完全不同的生活方式。\n你一旦开始输出，现实就会给你反馈：没人看是反馈，有人反驳是反馈，有人收藏但不付费是反馈，有人愿意付钱是反馈，你写不下去也是反馈。这些反馈会一点点逼你成长。\n所以 Dan Koe 最后给的行动很简单：把前面六个问题回答一遍，取一个「原材料」，再取一个「逆主流观点」，组合成一句只有你能写出来的话，然后明天就发出去。\n别等它完美。因为你无法改进一个不存在的东西。\n我现在越来越觉得，AI 时代真正稀缺的不是工具使用技巧。工具会越来越便宜，教程会越来越多，生成能力会越来越强。真正稀缺的，是一个人愿不愿意对自己的生活重新负责：能不能不等别人给题目，自己出题；不等别人给标准，自己建立标准；不等别人给机会，自己创造一个小入口。\n这篇文章最狠的地方，不是它说 AI 会替代很多工作，而是它提醒你：很多人在 AI 出现之前，就已经把自己的主动权交出去了。AI 只是让这件事变得更明显。\nDAN KOE 《How to survive AI mass replacement （\u0026amp; escape wage slavery）》下载地址：\n英文原版：下载 中文译版：下载 ","permalink":"https://blog.onecai.site/2026/06/19/017-dankoe-escape-wage-slavery/","summary":"\u003cp\u003eDAN KOE 发布了最新newsletter《How to survive AI mass replacement （\u0026amp; escape wage slavery）》，标题很猛，里面也有不少他一贯锋利的表达：wage slavery、unemployable、life\u0026rsquo;s work，直译过来都带着刺。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"escape%20wage%20slavery1.avif\"\n          alt=\"AI 时代的分叉路口\"/\u003e \u003cfigcaption\u003e\n             AI 时代的分叉路口\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e但它表面在讲 AI 和就业，内核其实不是「AI 会不会抢走你的工作」。它真正问的是：\u003cstrong\u003e一个人到底要不要继续把自己的生存，完全交给别人。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e现在大家聊 AI，常见两种情绪。一种是兴奋，觉得终于有了超级工具；另一种是愤怒，觉得 AI 偷走了创作者的东西，把世界搞得更卷。\u003c/p\u003e\n\u003cp\u003eDan Koe 对第二种情绪不太客气。他认为，在社交媒体上喊几句「反 AI」，确实容易获得身份认同，也容易让人觉得自己站在了正确的位置上。但喊完之后呢？生活不会因为你反对 AI 就变得更稳，雇主不会因为你不喜欢 AI 就永远保留你的岗位，技术更不会因为你觉得不公平就慢下来等你。\u003c/p\u003e\n\u003cp\u003e所以他给了一个很反直觉的判断：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAI 不是真正的威胁，依附性才是。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e你依附于一个雇主、一份工资、一个平台、一套过去有效的技能，甚至依附于「只要我努力工作，生活就会越来越好」的旧叙事。这些东西一旦变化，你就立刻被动。这才是更深层的风险。\u003c/p\u003e\n\u003ch2 id=\"工资奴役不只是工资低的问题\"\u003e工资奴役，不只是工资低的问题\u003c/h2\u003e\n\u003cp\u003e文章里最刺耳的一个词是 \u003cstrong\u003eWage Slavery\u003c/strong\u003e，工资奴役。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"escape%20wage%20slavery2.avif\"\n          alt=\"工资依附感：看得见的收入，看不见的锁链\"/\u003e \u003cfigcaption\u003e\n             工资依附感：看得见的收入，看不见的锁链\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e很多人会本能反驳：我又不是奴隶，我有工资，也有选择。但他讲的不是传统意义上的奴役，而是一种金融意义上的困住——\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e如果你不上班就会陷入灾难，而且你没有任何技能去创造替代方案，那么不管你感觉自己多自由，你都符合某种奴隶的定义。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这话很难听，但也很难完全反驳。\u003c/p\u003e\n\u003cp\u003e当然，他不是反对工作本身。工作有价值，尤其在一个人刚进入社会时，它是最快的训练场：协作、流程、交付、沟通、专业技能，还有真实世界到底怎么运转。问题是，很多人把工作当成了唯一的生存方式。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一开始，工作是踏脚石。时间久了，踏脚石变成了笼子。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eDan Koe 在这里提到心流理论，我很有共鸣。一个人真正有成就感，往往不是躺平时，也不是被迫重复时，而是处在「能力边缘」上：事情略微超过你的能力，你需要学习、尝试、犯错，然后一点点掌控它。太简单会无聊，太难会焦虑。\u003c/p\u003e\n\u003cp\u003e很多工作的问题就在这里。刚开始你觉得新鲜，什么都要学；几年以后你掌握了流程，挑战感下降，剩下的变成重复、等待、汇报、填表、开会。人当然会无聊，无聊之后就会找刺激——刷短视频、买东西、沉迷各种即时反馈。不是因为真的喜欢，而是大脑已经很久没被真正的挑战点亮过了。\u003c/p\u003e\n\u003cp\u003e所以「逃离工资奴役」，不是简单喊一句「我要辞职创业」。它真正指向的是：\u003cstrong\u003e你要重新获得安排挑战等级的能力。\u003c/strong\u003e 不再只是被别人分配任务，而是开始给自己设计任务。\u003c/p\u003e\n\u003ch2 id=\"ai-让能做出来越来越不值钱\"\u003eAI 让「能做出来」越来越不值钱\u003c/h2\u003e\n\u003cp\u003eDan Koe 在第二部分讲了五个能力：能动性（Agency）、品味（Taste）、说服力（Persuasion）、坚持（Persistence）、迭代（Iteration）。\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"escape%20wage%20slavery3.avif\"\n          alt=\"AI 让“能做出来”贬值：满地半成品\"/\u003e \u003cfigcaption\u003e\n             AI 让“能做出来”贬值：满地半成品\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003cp\u003e这几个词都不新，尤其 high agency 这几年快被说烂了。但他很讽刺地说：一群人跟风谈 high agency，本身就暴露了他们没什么 agency。这个判断挺狠，也挺准——真正的能动性，不是转发几句金句，而是没人催你、没人给流程、没人保证结果的时候，你仍然能开始做一件事。\u003c/p\u003e\n\u003cp\u003e这五个能力压缩一下，其实就是两件事：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e把事情搞定的能力。知道什么事情值得搞定的经验。\u003c/strong\u003e\u003c/p\u003e","title":"DANKOE最新文章《如何在AI大替代中生存（并逃离薪资奴役）》"},{"content":"上一篇聊了 1P 算力到底有多大，这一篇换个更具体的问法：算力听起来很大，但它到底能干什么？这个问题继续往下走，就会变成一个更具体的问题——如果我手里有一张算力卡，让它连续工作一小时的话，到底能干多少活？\n能写多少篇文章？ 能回答多少次问题？ 能支撑多少人同时使用 AI 助手？ 能不能撑起一个企业内部的智能体系统？ 直接换一种更容易理解的方式：把算力换算成 AI 的实际产能。\n不同算力卡一小时能干多少活 1. 算力很抽象，不如换成工作量 我们平时看到算力卡参数，一张卡 300 TFLOPS，另一张卡 1000 TFLOPS，听起来差了好几倍，这个差距到底意味着什么？或者更直白的问题应该是：它一小时能完成多少 AI 工作？\n比如：\n一小时能生成多少文字？ 一小时能写多少篇文章？ 一小时能回答多少次问题？ 一小时能服务多少个用户？ 一小时能处理多少份材料？ 这才是算力真正落地之后的样子。\n所以，讨论不同算力卡一小时能干多少活，不能只看“这张卡有多强”，而要看它在一个具体 AI 场景里能产出多少东西。\n2. 先设定一个统一场景 要比较不同算力卡，必须先设定一个统一场景，否则没法比。\n同样一张卡，跑 7B 模型、35B 模型、70B 模型，工作量完全不同，而换做不同的业务逻辑，比如图片生成、视频生成、模型训练、大模型推理，消耗也就完全不同。\n选一个足够考验算力、也比较贴近日常 AI 应用的场景：运行一个 70B 级别大模型，连续一小时对外提供文本生成服务。\n这个场景可以对应很多实际工作，比如写文章、写代码、做摘要、回答问题、做客服、写方案、做资料分析、给企业内部知识库提供问答服务，我们不讨论一张卡理论上有多强，而看它在大模型推理场景下一小时最多能生成多少 token。\n为什么选 70B？——因为 70B 是一个比较好的参照物。\n7B、14B 模型更像轻量级工具，适合简单问答、分类、摘要、本地助手。 35B 已经开始进入比较强的生产力模型区间。 70B 则是一个分水岭：模型足够大，负载足够重，也更接近严肃的大模型推理场景。 所以本文里的“一小时能干多少活”，本质上是在问：一张算力卡连续跑 70B 大模型，一小时能生成多少 token？\n3. token 是什么？ AI 生成文本不是按“字”算，也不是按“篇”算，而是按 token 算。\ntoken 可以简单理解成：AI 处理文本的基本颗粒。\n中文里，一个 token 可能接近一个字，也可能是一个词的一部分；而在英文里，一个 token 可能是一个单词，也可能是单词的一部分。不需要把 token 理解得太复杂，对普通读者来说，只要知道：token 是 AI 生成内容的计量单位。\n比如：\n一次简短回答，可能是几十到几百 token； 一次完整问答，可能是 500 到 1500 token； 一篇中等长度公众号初稿，可能是 3000 到 6000 token； 一次长篇分析，可能上万 token。 所以，我们可以把“算力卡一小时能干多少活”换成一个更可量化的问题：不同算力卡，一小时能生成多少 token？\n铺垫了以上内容后，这个问题就可以比较了。\n4. 一个 token 多少钱？——先算成本 问：35B 模型生成的 1 个 token，和 70B 模型生成的 1 个 token，是一样的吗？\n答：数量上都是 1 个 token，但 70B 那个 token 背后的计算量，大约是 35B 的 2 倍。\n35B 模型生成 1 个 token，70B 模型也生成 1 个 token，数量上都是 1 个 token，但它们背后的计算量不一样。\n大模型生成 1 个 token，粗略可以按这个公式估算：\n生成 1 个 token 的计算量 ≈ 2 × 模型参数量\n所以：\n模型规模 生成 1 个 token 的粗略计算量 7B 约 140 亿次浮点计算 14B 约 280 亿次浮点计算 35B 约 700 亿次浮点计算 70B 约 1400 亿次浮点计算 也就是说：70B 模型生成 1 个 token，理论计算量大约是 35B 的 2 倍，是 7B 的 10 倍。\n所以，不能简单说：“这张卡一小时能生成多少 token”，更准确的说法应该是——这张卡一小时能生成多少个某规模模型的 token。\n比如：\n一小时生成 1000 万个 7B token； 一小时生成 400 万个 35B token； 一小时生成 200 万个 70B token。 这三句话代表的工作负载完全不同。\n这里先只算“贵不贵”，也就是每个 token 要花多少计算量。至于“值不值”——同样 1000 个 token，不同模型的含金量差多少——我们留到后面再说。\n5. 不同算力卡一小时能生成多少 token？ 下面做一个简化估算。先说明口径：\n项目 设定 模型规模 70B 精度 FP16 / BF16 口径 任务类型 连续文本生成 有效利用率 按理论算力的 25% 折算 统计指标 每小时生成 token 数 单次长回答 1500 token 为什么要按 25% 有效利用率估算？\n因为显卡标称算力是理论峰值，不等于真实推理吞吐。真实推理会受到很多因素影响：\n显存容量； 显存带宽； KV Cache； batch size； 上下文长度； 推理框架； 量化方式； 多用户并发。 所以这里不是按理论峰值吹牛，而是按一个偏保守的工程估算来理解。\nNVIDIA 官方规格显示，H200 SXM 的 FP16/BF16 Tensor Core 峰值为 1,979 TFLOPS（含稀疏），显存为 141GB，显存带宽为 4.8TB/s；这里做 dense 口径估算时，按约一半即 989 TFLOPS 计算。 AMD 官方页面显示，MI300X 面向生成式 AI 和 HPC 工作负载，配备 192GB 大容量 HBM 显存；公开资料中 MI300X 常见 FP16/BF16 dense 口径约为 1305 TFLOPS。 NVIDIA Blackwell 官方数据表显示，B200 的 FP16/BF16 张量算力约 4.5 PFLOPS（含稀疏），换算成 dense 口径约 2250 TFLOPS；要注意，常被引用的 8 卡 HGX B200“32 PFLOPS”是 FP8 口径，不是 FP16/BF16，两者不能混用。\n按照这个口径，可以得到下面这张表：\n算力卡 大致 FP16/BF16 算力口径 估算一小时生成 70B token 约等于多少个 1500-token 长回答 RTX 4090 约 330 TFLOPS 约 212 万 token 约 1400 次 NVIDIA L40S 约 366 TFLOPS 约 236 万 token 约 1570 次 NVIDIA A100 80GB 约 312 TFLOPS 约 201 万 token 约 1330 次 NVIDIA H100 SXM 约 989 TFLOPS 约 636 万 token 约 4240 次 NVIDIA H200 SXM 约 989 TFLOPS 约 636 万 token 约 4240 次 AMD MI300X 约 1305 TFLOPS 约 839 万 token 约 5590 次 AMD MI325X 约 1307 TFLOPS 约 840 万 token 约 5600 次 NVIDIA B200 约 2250 TFLOPS（dense） 约 1446 万 token 约 9640 次 ​ 不同算力卡连续跑 70B 模型一小时的 token 产出对比柱状图⁠ 这张表的重点不是精确到个位数，而是帮助建立数量级概念。\n也就是说：一张高端算力卡，一小时不是写几篇文章，而是生成几百万到上千万 token。\n还要补充很重要的一点：这是一张**“按算力折算”的理想上限表**。真实的单流自回归解码，瓶颈往往不在算力，而在显存带宽。所以表里 H100 和 H200 算力相同、数字也相同，但实际推理中，H200 凭借更大显存和更高带宽，吞吐通常会明显高于 H100，MI300X、MI325X 同理。这张表用来建立数量级直觉没问题，但不要把它当成实测排名。\n6. 换成更容易理解的工作量 token 数还是有点抽象，我们可以继续换算成人能理解的工作量。\n假设一次 AI 输出是：\n一篇 1500 token 左右的长回答。\n这个长度大概相当于：\n一次比较完整的 AI 问答； 一段较详细的技术解释； 一篇短文章的主体内容； 一次较完整的材料摘要； 一段比较长的代码说明。 按这个长度，上面那张表最后一列就是答案：从 RTX 4090 的约 1400 次，到 B200 的约 9640 次。\n如果换成客服场景，假设一次客服回答平均 500 token，那么一小时大致是：\n算力卡 一小时大约完成多少次客服回答 RTX 4090 约 4200 次 L40S 约 4700 次 A100 约 4000 次 H100 约 12700 次 H200 约 12700 次 MI300X 约 16800 次 MI325X 约 16800 次 B200 约 28900 次 这样就比较直观了。\n一张 H100 不是“比普通显卡快一点”，而是可以在一小时内完成上万次普通 AI 问答。\n一张 B200 级别的卡，如果用在高并发文本推理场景里，一小时可以生成上千万级别的 70B token。\n如果是 8 卡服务器，理论上还可以继续放大。当然，实际不能简单乘以 8，因为还要看并行效率、网络通信、推理框架和调度策略。\n7. 不是所有卡都能舒服跑 70B 这里要加一个很重要的反直觉结论：\n算力卡能不能干活，不只看 TFLOPS，还要看显存。\n因为 70B 模型如果用 FP16/BF16，光模型权重大约就需要：\n70B × 2 byte ≈ 140GB 显存\n这还没有算：\nKV Cache； 推理框架开销； batch； 上下文长度； 并发用户。 所以很多卡虽然算力很强，但单卡未必能舒服地跑 70B FP16/BF16。\n算力卡 单卡跑 70B FP16/BF16 是否舒服 原因 RTX 4090 24GB 不现实 显存不够，只能量化或多卡 L40S 48GB 不现实 更适合中小模型 A100 80GB 不够舒服 可跑量化 70B，FP16 需多卡 H100 80GB 不够舒服 算力强，但显存不足 H200 141GB 接近临界 权重能放下，但余量紧张 MI300X 192GB 比较舒服 大显存适合 70B 推理 MI325X 256GB 很舒服 长上下文和高并发余量更大 B200 180GB 比较舒服 算力和显存都强 算力 vs 显存散点图：算力看速度，显存看装不装得下，140GB 是 70B FP16 的门槛⁠ H200 的关键变化不是 FP16/BF16 算力比 H100 暴涨，而是显存提升到 141GB、带宽提升到 4.8TB/s，这对大模型推理尤其重要。 MI300X 这类卡的优势也很明显：大显存、高带宽，更适合大模型推理、长上下文和高并发场景。\n这就解释了一个常见误解：\nH100 很强，但 H100 80GB 单卡并不等于可以随便跑 70B FP16。\n算力决定“跑得快不快”。 显存决定“装不装得下”。 带宽决定“高并发、长上下文时稳不稳”。\n对大模型来说，装不下，算力再强也没用。\n8. 这个 token 值不值？——再算价值 前面说 70B 的 token 更贵。但更贵，不等于更值。\n同样是 1000 个 token，不同模型生成出来，质量可能完全不同：\n7B 模型生成 1000 token； 35B 模型生成 1000 token； 70B 模型生成 1000 token； ChatGPT 生成 1000 token； Claude 生成 1000 token； DeepSeek 生成 1000 token； GLM 生成 1000 token。 它们数量上都是 1000 token，但内容价值不在一个层级。\n70B 的 token 通常来自更大规模参数、更复杂的概率判断，在复杂推理、长文组织、代码生成、专业分析场景里，往往更有价值。但是，如果只是简单客服、批量摘要、文本分类、短文改写，就不一定非要用最强模型。\n这就像同样写 1000 个字，小学生写、编辑写、专家写，数量一样，但背后的质量和成本不一样。\n所以真正的成本不是每 100 万 token 多少钱，而是每 100 万个“有效 token”多少钱。\n什么叫有效 token？\n就是它能不能真正解决问题。\n一段回答写了 3000 token，但全是套话，没法用，那它的有效 token 很少。 另一段回答只有 800 token，但结构清楚、判断准确、可以直接采用，那它的有效 token 反而更多。 所以，算力最终不是为了生产更多字符，而是为了生产更多有效结果。\n把影响“有效产出”的因素拆开看，大致有这么几层：\n维度 决定什么 典型问题 算力 生成速度 一小时能吐多少 token 显存 能不能装下模型 能不能跑 70B、长上下文、高并发 带宽 推理效率 多用户并发时会不会卡 模型规模 token 成本 35B 和 70B 的 token 消耗不同 模型质量 token 价值 生成内容能不能直接用 价格 性价比 每块钱能买到多少有效产出 所以讨论“一小时能干多少活”，至少有三种算法，一种比一种更贴近业务。\n（1）. 只看理论算力 TFLOPS 越高，一小时能生成的 token 越多。\n这是最粗糙的算法。它容易误导，因为它忽略了显存、带宽和工程效率。\n（2）. 看 token 吞吐 一张卡一小时能生成多少个 70B token？多少个 35B token？多少个 7B token？\n这个更准确。同一张卡跑 35B，理论 token 吞吐大约是跑 70B 的两倍；跑 7B，大约是十倍。\n（3）. 看有效工作量 一小时能完成多少篇可用文章？多少条客服问题？多少次代码修改？服务多少个真实用户？\n这才是最接近业务的算法。因为 token 多，不一定代表工作做得好：有些模型写得快，但废话多、返工多；有些模型更贵，但一次输出就能用；有些任务不需要最聪明的模型，只需要足够便宜、足够稳定、能批量处理。所以真正应该比较的是单位时间内产生了多少有效结果。\n9. 算力不是参数游戏，而是 AI 生产力的底座 所以，不同算力卡一小时能干多少活，不能简单看广告里的峰值算力。\n更准确的理解应该是：\n算力决定它吐 token 的速度； 显存决定它能不能装下大模型； 带宽决定它在并发和长上下文里能不能跑稳； 模型规模决定每个 token 的计算成本； 模型质量决定每个 token 有没有价值。 算力如何变成 AI 生产力：算力→token 吞吐→工作量→有效 token 的四层换算⁠ 如果把 AI 看成一条内容、代码、问答和知识处理的生产线，那么一张高端算力卡一小时不是在写几篇文章，而是在生产几百万到上千万 token。\n但最终真正有价值的，不是 token 数量本身，而是有效 token。\n能被采用的回答，能减少人工返工的代码，能真正解决问题的分析，才是算力最后变成生产力的地方。\n所以，回到最开始的问题“不同算力卡一小时能干多少活？”，表面答案是“一小时能生成几百万到上千万 token”，更准确的答案是“一小时能生产多少有效 AI 结果”。\n这才是算力从参数变成生产力的关键。\n","permalink":"https://blog.onecai.site/2026/06/18/016-cardscando/","summary":"\u003cp\u003e上一篇聊了 1P 算力到底有多大，这一篇换个更具体的问法：算力听起来很大，但它到底能干什么？这个问题继续往下走，就会变成一个更具体的问题——\u003cstrong\u003e如果我手里有一张算力卡，让它连续工作一小时的话，到底能干多少活？\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e能写多少篇文章？\u003c/li\u003e\n\u003cli\u003e能回答多少次问题？\u003c/li\u003e\n\u003cli\u003e能支撑多少人同时使用 AI 助手？\u003c/li\u003e\n\u003cli\u003e能不能撑起一个企业内部的智能体系统？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e直接换一种更容易理解的方式：\u003cstrong\u003e把算力换算成 AI 的实际产能。\u003c/strong\u003e\u003c/p\u003e\n\u003cfigure\u003e\n     \u003cimg loading=\"lazy\" src=\"cardscando-cover.avif\"\n          alt=\"不同算力卡一小时能干多少活\"/\u003e \u003cfigcaption\u003e\n             不同算力卡一小时能干多少活\n         \u003c/figcaption\u003e\n \u003c/figure\u003e\n\n\u003chr\u003e\n\u003ch2 id=\"1-算力很抽象不如换成工作量\"\u003e\u003cstrong\u003e1. 算力很抽象，不如换成工作量\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e我们平时看到算力卡参数，一张卡 300 TFLOPS，另一张卡 1000 TFLOPS，听起来差了好几倍，这个差距到底意味着什么？或者更直白的问题应该是：\u003cstrong\u003e它一小时能完成多少 AI 工作？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e比如：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e一小时能生成多少文字？\u003c/li\u003e\n\u003cli\u003e一小时能写多少篇文章？\u003c/li\u003e\n\u003cli\u003e一小时能回答多少次问题？\u003c/li\u003e\n\u003cli\u003e一小时能服务多少个用户？\u003c/li\u003e\n\u003cli\u003e一小时能处理多少份材料？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这才是算力真正落地之后的样子。\u003c/p\u003e\n\u003cp\u003e所以，讨论不同算力卡一小时能干多少活，不能只看“这张卡有多强”，而要看它在一个具体 AI 场景里能产出多少东西。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"2-先设定一个统一场景\"\u003e\u003cstrong\u003e2. 先设定一个统一场景\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e要比较不同算力卡，必须先设定一个统一场景，否则没法比。\u003c/p\u003e\n\u003cp\u003e同样一张卡，跑 7B 模型、35B 模型、70B 模型，工作量完全不同，而换做不同的业务逻辑，比如图片生成、视频生成、模型训练、大模型推理，消耗也就完全不同。\u003c/p\u003e\n\u003cp\u003e选一个足够考验算力、也比较贴近日常 AI 应用的场景：\u003cstrong\u003e运行一个 70B 级别大模型，连续一小时对外提供文本生成服务。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这个场景可以对应很多实际工作，比如写文章、写代码、做摘要、回答问题、做客服、写方案、做资料分析、给企业内部知识库提供问答服务，我们不讨论一张卡理论上有多强，而看它在大模型推理场景下\u003cstrong\u003e一小时最多能生成多少 token。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e为什么选 70B？——因为 70B 是一个比较好的参照物。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e7B、14B 模型更像轻量级工具，适合简单问答、分类、摘要、本地助手。\u003c/li\u003e\n\u003cli\u003e35B 已经开始进入比较强的生产力模型区间。\u003c/li\u003e\n\u003cli\u003e70B 则是一个分水岭：模型足够大，负载足够重，也更接近严肃的大模型推理场景。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e所以本文里的“一小时能干多少活”，本质上是在问：\u003cstrong\u003e一张算力卡连续跑 70B 大模型，一小时能生成多少 token？\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"3-token-是什么\"\u003e\u003cstrong\u003e3. token 是什么？\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eAI 生成文本不是按“字”算，也不是按“篇”算，而是按 \u003cstrong\u003etoken\u003c/strong\u003e 算。\u003c/p\u003e\n\u003cp\u003etoken 可以简单理解成：\u003cstrong\u003eAI 处理文本的基本颗粒。\u003c/strong\u003e\u003c/p\u003e","title":"不同算力卡一小时能干多少活？"},{"content":"​ 拥有1P算力，能干点什么？ 之前聊过“什么是 1P 算力”，简单说，1P 算力通常指 1 PFLOPS，也就是每秒 1000 万亿次浮点计算能力。但知道这个定义之后，新的问题马上来了：\n如果我真的拥有 1P 算力，到底能干点什么？\n能不能训练大模型？ 能不能跑本地 AI？ 能不能支撑一个企业的智能体应用？ 能不能让几百个人同时用 AI 助手？ 这篇就不继续抠概念了，直接聊应用。\n1P 算力不小，但也没那么神 先说结论：1P 算力不算小，但也没到“想干什么就干什么”的程度。\n如果只是做 AI 推理，比如让已经训练好的模型回答问题、处理文档、写材料、做知识库问答，1P 算力已经能做不少事情。\n但如果想从零训练一个真正意义上的大模型，1P 算力基本不够。\n训练大模型不只是看算力，还要看显存、通信、数据量、训练时间、工程能力和资金投入。\n​ 1P 算力支持的典型应用场景⁠ 1P 算力大概是什么体量？ 按 FP16 来粗略理解，1P 算力就是每秒 1000 万亿次半精度浮点计算。\n但这个数字太大，一般也没有感觉。\n更直观一点说，1P 算力它不像一台电脑，也不像一台服务器，更像是一个小型机房里的一组 AI 加速卡，大概可以理解为一个很小型的 AI 算力资源池。它不是“几台普通电脑”的概念，而是需要多张专业 AI 加速卡组合起来，才能达到的计算能力。\n说法 普通理解 1P FP16 算力 每秒约 1000 万亿次半精度浮点计算 它不是一台电脑 通常需要多张 AI 加速卡组成 它不是万能指标 还要看显存、带宽、网络、利用率 它适合什么 推理、小模型训练、企业 AI 应用 它不适合什么 从零训练超大规模基础模型 拥有 1P 算力，可以干哪些事？ 1. 跑大模型推理 所谓推理，就是模型已经训练好了，现在让它回答问题、总结材料、写代码、生成文案、分析表格、处理图片。\n对多数企业来说，真正需要的不是自己从零训练一个大模型，而是把现成模型部署起来，让它服务自己的业务。\n比如：企业知识库问答、 政务材料生成、合同审查、客服机器人、代码助手、办公智能体、内部文档检索。\n对大多数个人和组织来说，买算力不是为了“造一个 ChatGPT”，而是为了让已经训练好的模型，真正跑进自己的业务流程里。\n2. 支撑企业内部 AI 助手 比如一个单位内部有几百名员工，大家每天让 AI 帮忙写材料、查制度、总结会议、处理表格、生成周报、检索文件。\n这种场景下，算力的核心问题不是“模型有多聪明”，而是“能不能稳定、快速、多人同时使用”。\n这种场景下存在一个“瓶颈”的问题：\n问题 影响 同时多少人使用 决定并发压力 每个人问多长的问题 决定上下文长度 回答要多快 决定响应体验 用多大的模型 决定算力和显存消耗 是否接入知识库 决定检索和存储压力 3. 做行业知识库 把单位内部的制度文件、政策文件、项目材料、技术文档、历史案例、合同文本整理好，再接入大模型，就可以做一个内部问答系统。\n比如问：\n某项政策的适用条件是什么？\n这个项目以前有没有类似案例？\n合同里有没有明显风险？\n这份材料和去年版本有什么不同？\n不过，知识库问答真正难的地方往往不是模型，而是资料本身。文件是不是最新版本，权限是不是清楚，答案有没有依据，这些问题如果不解决，算力再多也容易变成“认真胡说”。\n4. 做批量内容处理 比如批量总结会议纪要、批量识别图片、批量转写录音、批量审核材料、批量提取表格信息、批量生成报告初稿。\n这些事情单个人做很慢，但交给 AI，就适合用算力来换时间。\n例如：\n场景 AI 可以做什么 会议录音 转文字、提炼纪要、生成待办 政策文件 提取对象、条件、流程、材料清单 合同材料 标记风险条款、生成摘要 图片资料 识别文字、分类、打标签 客服记录 总结问题、归类投诉、发现高频需求 5. 做小模型训练或微调 1P 算力不太适合从零训练超大模型，但可以用于小模型训练、行业模型微调、垂直任务优化。\n比如针对某个行业的术语、格式、流程，让模型更懂本单位的表达方式。\n微调不是把几份文档丢进去就行，它需要高质量数据、标注规范、评测方法和持续迭代。\n6. 做 AI 应用实验田 1P 算力更适合作为一个中小规模智算资源池，用来验证应用、打磨流程、训练团队，而不是一上来就喊着训练基础大模型。\n一个单位真正需要先搞清楚的不是“买多少 P”，而是：\n有哪些业务值得 AI 化？ 哪些数据可以用？ 哪些场景能节省人力？ 哪些流程可以自动化？ 哪些结果可以被评估？ 1P 算力不能干什么？ ​ 能做与不能做的边界⁠ 1. 不适合从零训练超级大模型 如果目标是从零训练一个类似 GPT、Claude、DeepSeek 这种级别的基础大模型，1P 算力远远不够。\n训练大模型需要的不是一小块算力，而是大规模 GPU 集群、海量数据、高速互联、训练框架、工程团队和长期资金投入。\n2. 不代表能服务无限用户 1P 算力也不等于可以无限并发。\n同样是 1P，如果模型很大、上下文很长、回答很长、用户很多，体验仍然可能变慢。\nAI 服务不是只看峰值算力，还要看吞吐、延迟、显存、调度和利用率。\n3. 不代表买回来就能用好 算力买回来只是第一步。\n如果没有模型、没有数据、没有应用场景、没有工程团队、没有运维能力，算力就可能变成一堆昂贵的设备。\n很多算力项目的问题，不是买少了，而是买回来之后，没有模型、没有数据、没有场景，也没有人真正用起来。\n算力本身不产生价值，算力进入场景之后，才开始产生价值。\n真正决定 1P 算力价值的，不只是 P 影响因素 为什么重要 计算精度 FP16、BF16、INT8 对应的算力口径不同 显存容量 决定能不能放下模型和上下文 显存带宽 决定数据搬运速度 网络互联 多卡协同时影响效率 模型大小 模型越大，消耗越高 并发人数 用户越多，压力越大 上下文长度 输入越长，消耗越高 利用率 峰值算力不等于实际算力 软件生态 决定部署、调优和维护难度 所以，看一个算力项目，不能只看“多少 P”。\n更应该问：\n是什么精度下的 P？ 有多少显存？ 能跑多大的模型？ 能支持多少并发？ 实际利用率是多少？ 有没有真实业务场景？ 所以，拥有 1P 算力能干什么？\n它可以支撑不少 AI 应用，可以跑模型、做推理、建知识库、处理文档、服务企业内部助手，也可以做小模型训练和行业微调。\n但它不是“训练大模型的入场券”，更不是“买回来就自动产生价值”的魔法盒子。\n真正有价值的不是账面上的 1P，而是这 1P 算力有没有被用到具体场景里。\n对多数企业和单位来说，问题不是“要不要拥有很多 P 算力”，而是：\n有没有一个真实、稳定、可评估的 AI 应用场景，值得为它消耗这些算力。\n一个疑问：\n最近在学习相关的内容，政府、企业采购几十 P、几百 P 算力，到底买的是什么？是芯片？是服务器？是云服务？是模型能力？还是一个听起来很先进的数字？\n","permalink":"https://blog.onecai.site/2026/06/17/015-whatcandoby1p/","summary":"\u003cp\u003e​    \u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"1p_cover_top.avif\"\n         alt=\"拥有1P算力，能干点什么？\"/\u003e \u003cfigcaption\u003e\n            拥有1P算力，能干点什么？\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\u003c/p\u003e\n\u003cp\u003e之前聊过“什么是 1P 算力”，简单说，1P 算力通常指 1 PFLOPS，也就是每秒 1000 万亿次浮点计算能力。但知道这个定义之后，新的问题马上来了：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e如果我真的拥有 1P 算力，到底能干点什么？\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cul\u003e\n\u003cli\u003e能不能训练大模型？\u003c/li\u003e\n\u003cli\u003e能不能跑本地 AI？\u003c/li\u003e\n\u003cli\u003e能不能支撑一个企业的智能体应用？\u003c/li\u003e\n\u003cli\u003e能不能让几百个人同时用 AI 助手？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这篇就不继续抠概念了，直接聊应用。\u003c/p\u003e\n\u003ch2 id=\"1p-算力不小但也没那么神\"\u003e\u003cstrong\u003e1P 算力不小，但也没那么神\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e先说结论：1P 算力不算小，但也没到“想干什么就干什么”的程度。\u003c/p\u003e\n\u003cp\u003e如果只是做 AI 推理，比如让已经训练好的模型回答问题、处理文档、写材料、做知识库问答，1P 算力已经能做不少事情。\u003c/p\u003e\n\u003cp\u003e但如果想从零训练一个真正意义上的大模型，1P 算力基本不够。\u003c/p\u003e\n\u003cp\u003e训练大模型不只是看算力，还要看显存、通信、数据量、训练时间、工程能力和资金投入。\u003c/p\u003e\n\u003cp\u003e​    \u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"1p_applications_body.avif\"\n         alt=\"1P 算力支持的典型应用场景⁠\"/\u003e \u003cfigcaption\u003e\n            1P 算力支持的典型应用场景⁠\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\u003c/p\u003e\n\u003ch2 id=\"1p-算力大概是什么体量\"\u003e\u003cstrong\u003e1P 算力大概是什么体量？\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e按 FP16 来粗略理解，1P 算力就是每秒 1000 万亿次半精度浮点计算。\u003c/p\u003e\n\u003cp\u003e但这个数字太大，一般也没有感觉。\u003c/p\u003e\n\u003cp\u003e更直观一点说，1P 算力它不像一台电脑，也不像一台服务器，更像是一个小型机房里的一组 AI 加速卡，大概可以理解为一个很小型的 AI 算力资源池。它不是“几台普通电脑”的概念，而是需要多张专业 AI 加速卡组合起来，才能达到的计算能力。\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003cstrong\u003e说法\u003c/strong\u003e\u003c/th\u003e\n          \u003cth\u003e\u003cstrong\u003e普通理解\u003c/strong\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e1P FP16 算力\u003c/td\u003e\n          \u003ctd\u003e每秒约 1000 万亿次半精度浮点计算\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e它不是一台电脑\u003c/td\u003e\n          \u003ctd\u003e通常需要多张 AI 加速卡组成\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e它不是万能指标\u003c/td\u003e\n          \u003ctd\u003e还要看显存、带宽、网络、利用率\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e它适合什么\u003c/td\u003e\n          \u003ctd\u003e推理、小模型训练、企业 AI 应用\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e它不适合什么\u003c/td\u003e\n          \u003ctd\u003e从零训练超大规模基础模型\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"拥有-1p-算力可以干哪些事\"\u003e\u003cstrong\u003e拥有 1P 算力，可以干哪些事？\u003c/strong\u003e\u003c/h2\u003e\n\u003ch3 id=\"1-跑大模型推理\"\u003e1. 跑大模型推理\u003c/h3\u003e\n\u003cp\u003e所谓推理，就是模型已经训练好了，现在让它回答问题、总结材料、写代码、生成文案、分析表格、处理图片。\u003c/p\u003e","title":"拥有1P算力，能干点什么？"},{"content":"前两天我人在外面，需要的一个文档在家里电脑中，这事说大不大，说小也不小。等回家当然能弄，打开电脑，找到文件，再处理需要的内容，十来分钟的活儿。但这种活儿最烦的地方也在这里：它不值得郑重其事坐下来处理，可它就是会一直挂在脑子里。\n现在，在微信小程序里给 WorkBuddy 发一句话，让它连上家里电脑，看一下所需要的文件，并对文件进行一些操作，再顺手总结一下。撒泡尿的功夫，任务已经跑完了。\n​ 使用WorkBuddy 那一刻我才有点理解，为什么现在大家都在讲 Agent：不是因为它会聊天，也不是因为它能写几段漂亮话，而是它终于开始替你动手了。\n前几天还有一条新闻：6 月 16 日，全国首个省级政务智能中枢“湾擎”上线试运行，同时预发布了湾擎·WorkBuddy，后面会面向广东全省公务员开放。这个新闻听起来很政务、很企业，这跟咱也没关系，说有点关系的话，那就是咱能不能拿来处理自己的日常杂事？\n先一分钟搞清楚 WorkBuddy 是个啥 一句话：它是个桌面 / 全场景的 AI Agent，也叫智能体工作台。\n跟你天天对话的那种 AI 不一样的地方在于——它不只是给你“答案”，而是真的把你电脑当成“AI 同事”来用：听懂你一句大白话，自己拆解任务、规划步骤、动手执行，最后交给你一个能直接验收的成品。能力上它跟开源的“小龙虾”OpenClaw、Hermes 类似、完全兼容这类 skills，但更省事也更安全——不用折腾环境，从下载安装到微信扫码登录，最快一分钟。\n这一类产品现在其实不少，横向对比一下，心里有个谱：\n产品 核心定位 更像什么 主要战场 腾讯 WorkBuddy AI Agent 桌面工作台 “办公智能体入口” 企微、腾讯文档/会议、政务办公 阿里悟空 企业级 AI 工作平台 “钉钉里的 AI 员工军团” 钉钉、审批、日程、企业流程 Claude Cowork 知识工作的桌面 Agent “会操作本地文件的 Claude” 文件整理、研究综合、文档生成 OpenAI Codex 编码 Agent / 云端执行器 “云端 AI 工程师” 代码库、PR、调试、自动化 Claude 的 Cowork、阿里的悟空、OpenAI 的 Codex 都在做同一件事，只是切入口不同。排除掉 Claude 和 Codex 的网络问题，国内能开箱即用、又跟微信生态长在一起的，目前确实是 WorkBuddy 最顺手。它属于腾讯 CodeBuddy 产品线下的一个分支——CodeBuddy 就是腾讯版的 Codex，也很能打，这个以后单开一篇聊。\n装好之后，我先做了两件事 第一件：接入微信小程序。\n从 codebuddy.cn/work 下载安装，微信登录，进设置里把“微信小程序”接上。\n电脑端WorkBuddy 微信小程序WorkBuddy 接上之后，你就能直接在微信里连电脑、或者走云端帮自己干活了。这一步是我最买账的地方：OpenClaw、Hermes 那套，光配 Node 环境、API Key、内网穿透就够喝一壶——我自己当年为了远程触发家里电脑，frp、DDNS 都折腾过。这里扫个码就通了，省心。\n第二件：做点最基础的配置。\n后台能接的 MCP 服务、能装的 skill、能召唤的专家，多到吓人——光技能就分了十四大类、两千三百多项，专家有一百六十多个。但我的建议是：别贪，只接你真在用的。\n我自己就接了几个：腾讯会议、QQ邮箱、腾讯文档和Notion ，开发相关接了 GitHub。skill 也只挑了几个高频的，专家团队基本没动。装太多反而界面乱、调用慢，用不上的纯属占地方。\n​ 专家/专家团 我真正拿它干的几件事 1. 自动化：让它每天主动喂我信息 我加了个“每日 AI 新闻推送”，设成每天早上九点。\n​ 每日 AI 新闻推送截图 到点微信小程序里就自动收到了，不用我自己去翻。系统自带的预设也挺全——历史上的今天、每日五个单词、儿童睡前故事、每周周报、会前准备、父母联系提醒、体检/面试提醒……更多的可以自己照着需求自定义。\n这个逻辑跟调用系统LaunchAgent写定时脚本是一回事，区别是：以前得自己写、自己维护，现在一句话描述清楚，它就变成一个天天自动跑的“基础设施”。这才是 Agent 跟“一问一答”的本质差别——不是用 AI 干活，是让 AI 替你干活。\n2. 日常文件处理：丢给它就完事 最典型的就是“把 PDF 导出成图片”这种重复劳动。\n​ PDF 转图截图并总结内容 直接一句话，批量改名、提取信息、整理文件夹这类活儿，很快就能搞定。\n3. 手机遥控电脑出活——等于有了自己的“龙虾” 这是最有画面感的一个。在小程序里选“云端工作”，内容会同步到电脑端；选“连接电脑”，就能直接用手机遥控家里那台电脑干活。只要电脑端 WorkBuddy 开着就行，息屏、屏保都不影响。\n​ 手机遥控电脑出活 场景大概是这样：我人在外面，发条微信过去——“看一下当前文件夹下有哪些文件？列出文件数给我。把文件中的内容转写成markdown文件保存一份，总结文档主要内容给我”——到家活儿已经干完了。对我来说这块价值最大，因为远程触发恰恰是我自己搭最费劲的一环。\n手机遥控时它只动 WorkBuddy/Claw 目录下的文件，新生成的也存这儿。\n4. 自动跑调研 / 出报告 让它围绕一个主题做了份深度研究报告。\n​ 生成调研报告 把WorkBuddy当初稿、当成脚手架确实省事，但——AI 出的结论不能照单全收。 这份报告里它列的要点，有几个是我没想到的，也有几个是它“想当然”的、得我自己核实。这不是黑它，是用 AI 的基本素养：把它的产出当半成品，别当定论。\n说点实在的 它替代了我什么： 那些一次性、零散、不值得专门写脚本的活儿，现在张嘴就办；远程触发、跨设备协作这种个人尤其是我这样的小白自建成本很高的，它直接抹平了门槛。对“懒得配环境”的需求，它是真香。\n它不如自建的地方： 复杂、需要精细控制的流程，自己写脚本依然更可控、更可复现；遇到边界情况，自然语言指令的不确定性就上来了。再就是——它的能力封装在腾讯生态里，方便的另一面是迁移成本，这一点心里要有数。\n一句话：它不是万能，但目前确实是“门槛最低的那个 AI 专家”。 不用看命令行，下载一个软件就进 Agent 的世界，这件事本身就值。\n顺手能薅的羊毛 界面里能看到，WorkBuddy 支持的模型很全——混元、DeepSeek、GLM、Kimi、MiniMax 都能切，还支持接自己本地部署的大模型。\n​ 支持的大模型 如果你本地部署了自己的大模型，WorkBuddy 就能一直白嫖、不花钱。 任务只挂载自己的本地大模型——写文案用创意型的，跑数据分析用逻辑强的。\nWorkBuddy用积分算 token：微信登录送 500 积分，目前每天还能领 150 通用积分，我已经攒了一千多。免费额度薅完之后想继续用就得付费——跟我之前文章里说的一样，免费版和付费版完全两回事，羊毛先薅着，真上头了个人专业版限时双倍到账、58 元/月。\n想用 AI，先用起来 最后说个我自己最大的体感变化。\n以前有突发奇想，得找纸笔记下来；现在不用了。微信人人手机里都有，小程序点开 WorkBuddy，文字、语音随手一输，让它当场帮我把这个想法发散一下，再把结果存下来。比纸笔方便了不知道多少倍。\nAI 这东西，光看不行，得用起来才有感觉。\n","permalink":"https://blog.onecai.site/2026/06/16/014-workbuddyiscool/","summary":"\u003cp\u003e前两天我人在外面，需要的一个文档在家里电脑中，这事说大不大，说小也不小。等回家当然能弄，打开电脑，找到文件，再处理需要的内容，十来分钟的活儿。但这种活儿最烦的地方也在这里：它不值得郑重其事坐下来处理，可它就是会一直挂在脑子里。\u003c/p\u003e\n\u003cp\u003e现在，在微信小程序里给 WorkBuddy 发一句话，让它连上家里电脑，看一下所需要的文件，并对文件进行一些操作，再顺手总结一下。撒泡尿的功夫，任务已经跑完了。\u003c/p\u003e\n\u003cp\u003e​    \u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"WorkBuddy.avif\"\n         alt=\"使用WorkBuddy\"/\u003e \u003cfigcaption\u003e\n            使用WorkBuddy\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\u003c/p\u003e\n\u003cp\u003e那一刻我才有点理解，为什么现在大家都在讲 Agent：不是因为它会聊天，也不是因为它能写几段漂亮话，而是它终于开始替你动手了。\u003c/p\u003e\n\u003cp\u003e前几天还有一条新闻：6 月 16 日，全国首个省级政务智能中枢“湾擎”上线试运行，同时预发布了湾擎·WorkBuddy，后面会面向广东全省公务员开放。这个新闻听起来很政务、很企业，这跟咱也没关系，说有点关系的话，那就是咱能不能拿来处理自己的日常杂事？\u003c/p\u003e\n\u003ch2 id=\"先一分钟搞清楚-workbuddy-是个啥\"\u003e先一分钟搞清楚 WorkBuddy 是个啥\u003c/h2\u003e\n\u003cp\u003e一句话：它是个\u003cstrong\u003e桌面 / 全场景的 AI Agent\u003c/strong\u003e，也叫智能体工作台。\u003c/p\u003e\n\u003cp\u003e跟你天天对话的那种 AI 不一样的地方在于——它不只是给你“答案”，而是真的把你电脑当成“AI 同事”来用：听懂你一句大白话，自己拆解任务、规划步骤、动手执行，最后交给你一个能直接验收的成品。能力上它跟开源的“小龙虾”OpenClaw、Hermes 类似、完全兼容这类 skills，但更省事也更安全——不用折腾环境，从下载安装到微信扫码登录，最快一分钟。\u003c/p\u003e\n\u003cp\u003e这一类产品现在其实不少，横向对比一下，心里有个谱：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e产品\u003c/th\u003e\n          \u003cth\u003e核心定位\u003c/th\u003e\n          \u003cth\u003e更像什么\u003c/th\u003e\n          \u003cth\u003e主要战场\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e腾讯 WorkBuddy\u003c/td\u003e\n          \u003ctd\u003eAI Agent 桌面工作台\u003c/td\u003e\n          \u003ctd\u003e“办公智能体入口”\u003c/td\u003e\n          \u003ctd\u003e企微、腾讯文档/会议、政务办公\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e阿里悟空\u003c/td\u003e\n          \u003ctd\u003e企业级 AI 工作平台\u003c/td\u003e\n          \u003ctd\u003e“钉钉里的 AI 员工军团”\u003c/td\u003e\n          \u003ctd\u003e钉钉、审批、日程、企业流程\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eClaude Cowork\u003c/td\u003e\n          \u003ctd\u003e知识工作的桌面 Agent\u003c/td\u003e\n          \u003ctd\u003e“会操作本地文件的 Claude”\u003c/td\u003e\n          \u003ctd\u003e文件整理、研究综合、文档生成\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eOpenAI Codex\u003c/td\u003e\n          \u003ctd\u003e编码 Agent / 云端执行器\u003c/td\u003e\n          \u003ctd\u003e“云端 AI 工程师”\u003c/td\u003e\n          \u003ctd\u003e代码库、PR、调试、自动化\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eClaude 的 Cowork、阿里的悟空、OpenAI 的 Codex 都在做同一件事，只是切入口不同。排除掉 Claude 和 Codex 的网络问题，国内能开箱即用、又跟微信生态长在一起的，目前确实是 WorkBuddy 最顺手。它属于腾讯 CodeBuddy 产品线下的一个分支——CodeBuddy 就是腾讯版的 Codex，也很能打，这个以后单开一篇聊。\u003c/p\u003e","title":"我用WorkBuddy做了几件小事，才明白Agent是什么"},{"content":"聊这个话题之前先看看下面这两张图片，能看出来有什么区别吗？\n图片一 图片二 直观来看，左图左下角有文字水印，右图是“原图”。其实除了画面内容，两张图片承载了相同的文字信息，只不过右图不是明文显示，而是通过暗水印的方式把文字藏了进去。\n关于暗水印 图片暗水印（也叫隐形水印、盲水印）是一种把标识信息嵌入图片内部、肉眼看不见但能被算法提取出来的技术。和传统明晃晃的文字水印（明水印）不同，暗水印不破坏画面观感，主要用于版权追踪和泄露溯源。\n典型用途 版权追踪： 比如摄影师、设计师、平台给图片加入暗水印，后续即使别人裁剪、转发，也可能检测出原始来源。\n平台溯源： 有些社交平台、图片平台、AI 图片生成工具，可能会在图片里加入隐藏标记，用来判断图片来源、生成工具、上传渠道等。\n防盗图： 即使别人把明水印裁掉，只要暗水印还在，就可能证明图片来源。\nAI 生成图片识别： 一些 AI 图片系统会尝试给生成图加入不可见标记，用于说明“这张图可能由 AI 生成”。（借助 AI 工具生成的视频、图片，会被抖音、视频号、小红书等平台识别出是 AI 生成的作品，可能就是这个原理。）\n暗水印不等于 EXIF 信息 很多人容易把两者混在一起，EXIF 信息是照片文件里的元数据，比如：\n1 2 3 4 拍摄设备：iPhone 拍摄时间：2026-06-21 GPS 位置： 镜头参数： 这种信息比较容易被查看，也容易被删除。但暗水印一般是嵌进图片内容本身的，即使你删掉 EXIF，它可能还在。\n做个小实验 核心原理很简单：明文 → AES-GCM 加密 → LSB 隐写嵌入 PNG 图片 → 接收端逆向提取。\n方法一：自己写隐写工具 借助 AI 脚本做了一个图片隐写工具，实现加、解暗水印：\n脚本代码 stego.py 共 185 行，结构清晰分为四层：\n加密层（L33-58）\nderive_key：scrypt 从口令派生 32 字节密钥（参数 n=2¹⁴，抗 GPU 暴力破解） encrypt：随机 salt + nonce，AES-GCM 加密，输出 MAGIC | salt | nonce | len | 密文+tag decrypt：先校验 MAGIC，再 AES-GCM 解密，口令错会在这里抛异常 LSB 隐写层（L62-101）\nembed_lsb：图片展平为一维数组，每个像素值最低位替换为 payload 的一个 bit，强制输出 PNG extract_lsb：先读固定头部 36 字节，拿到 payload 长度，再按需读取剩余 bits 实验辅助（L105-125）\ncapacity：计算可用容量，并提示 \u0026gt;10% 容量会被隐写分析识破 lsb_visualize：把 LSB 平面放大成黑白图，嵌入区域呈现随机噪点 CLI（L129-184）：argparse 驱动，四个子命令 embed / extract / capacity / lsb\n暗水印嵌入 暗水印提取 方法二：用 GitHub 上高 star 的项目 GitHub 上有一个 13.7k 星的项目：https://github.com/guofei9987/blind_watermark，作者 6 年前的项目，最后一次维护是 9 个月前。\n把这个项目部署到本地，用命令行使用：\n1 2 3 4 # embed watermark into image: blind_watermark --embed --pwd 1234 examples/pic/ori_img.jpeg \u0026#34;watermark text\u0026#34; examples/output/embedded.png # extract watermark from image: blind_watermark --extract --pwd 1234 --wm_shape 111 examples/output/embedded.png 借助 AI 做了一个 web 界面：\n嵌入暗水印 提取暗水印 水印错误无法提取水印 这个代码里除了自定义暗水印和解密密码之外，还有一个水印长度参数。解密时如果不知道水印长度，即便知道解密密码，也是看不到暗水印信息的。\n一个简单的本地实验，可以根据实际需要自行使用；如果定期更换密钥，也算是一种可用的加密消息方式。\n谁在用暗水印 涉及产品 / 系统 公开说法 主要用途 / 类型 钉钉客户端、钉钉专属版、企业安全管理能力 官方文档中有“全局暗水印”使用手册，目录里也明确列出“访问\u0026amp;数据安全 → 全局暗水印”。 企业内部数据防泄露、截图 / 拍照溯源。 飞书客户端、飞书云文档、飞书管理后台 飞书官方文档和社区文章公开提到“透明水印”，并说明可在飞书客户端、云文档、管理后台等场景启用；飞书安全文章称“明水印和透明水印结合”可用于追踪数据泄露源头。 企业协作场景下的数据保护、截图泄密追踪。 字节跳动安全体系、内部业务场景、视频内容保护场景 字节跳动安全中心公开称，其自研“隐藏水印算法”通过 ChinaDRM 实验室安全评估，并称技术应用于字节跳动内部不同业务场景。 视频版权保护、内部数据安全、泄露溯源。 阿里云 DMS 数据管理控制台 阿里云帮助文档明确写到，DMS 开启防泄露数字水印后，控制台同时提供明水印与暗水印；暗水印是“阿里安全团队自研的肉眼不可见数字水印技术”。 数据库控制台防泄露、最终溯源。 阿里云媒体处理、视频点播、SASE、AIGC 标识能力 阿里云文档中直接使用“数字水印（暗水印）”，说明可把数字信息隐藏式嵌入音视频载体；SASE 文档也提到 AIGC 内容需添加隐式标识，如元数据标识或数字水印。 视频版权保护、泄露溯源、AIGC 合规标识。 腾讯云 COS、数据万象、云直播、图片 / 视频数字水印能力 腾讯云文档公开“盲水印”“暗水印（数字水印）”功能，说明可把水印以不可见形式嵌入图片或直播视频，并支持提取验证。 图片版权、视频直播版权、盗播追踪、内容溯源。 百度智能云数字水印、文心一格、文心一言、一念智能创作平台 百度智能云数字水印产品页称，文心一格、文心一言、一念智能创作平台已集成“图片隐形水印能力”，针对 AIGC 图片植入唯一水印信息。 AIGC 图片版权保护、政策合规、内容追踪；图片隐形水印。 华为云 DSC 数据安全中心 华为云文档称 DSC 支持“明暗双重水印”，可打上看得见的明水印或看不见的暗水印。 文档、数据版权保护、内部 / 第三方使用溯源。 ChatGPT 生成图片、Codex、OpenAI API 图片、Sora 视频 OpenAI 帮助文档写明：ChatGPT、Codex 和 API 生成的图片包含 C2PA metadata 和 SynthID watermarks；Sora 官方说明称视频包含可见水印、C2PA 元数据和其他不可见来源信号。 图片：SynthID 暗水印 + C2PA；视频：C2PA + 来源信号 / 可见水印。 Gemini、Imagen、Veo 等 Google 生成式媒体产品 Google DeepMind 公开称 SynthID 会给 AI 生成图片或视频片段加入不可见数字水印；Google 还称已将 SynthID 集成进生成式媒体模型和产品。 图片、视频、音频、文本的 SynthID 暗水印体系。 Meta AI 图片；Facebook / Instagram / Threads 相关 AI 图片识别体系 Meta 官方称，Meta AI 图片使用 IPTC metadata 和 invisible watermarks；Meta FAIR 还发布了 Meta Seal，用于图像、视频、音频、文本的不可见鲁棒水印研究框架。 图片暗水印 + 元数据；研究层面覆盖多模态。 Amazon Titan Image Generator、Amazon Nova Canvas、Amazon Bedrock AWS 文档明确写到：Titan Image Generator 会给所有生成图片加入 invisible watermark 和 C2PA metadata，并提供水印检测能力。 图片暗水印 + C2PA。 暗水印怎么破、怎么用 破 图片经过这些处理后，暗水印可能受损：截图、多次压缩、裁剪、调色、改尺寸、AI 重绘、模糊处理、转换格式等。\n如果担心图片里被加了暗水印，最快的解决方式是把图片丢到微信、QQ 等即时通讯软件中——腾讯会帮你把这些数据删掉。普通发送会压缩、丢失大量 EXIF 信息，地理位置之类的就无从获取，这没争议，绝对是腾讯出于安全考虑在保护自己的用户。\n关键是“原图”。有人在 2025 年做了二进制对比，发现微信“原图”的画质是保真的（JPG 压缩块完全保留），但文件头部的一些元数据被删除了，比如 GPS 位置信息。也就是说，现在微信原图 = 像素保真，但元数据（至少 GPS）被剥掉。\n钉钉 / 企业微信 / 飞书这三个企业级工具对图片处理更激进。有资料明确指出，它们可能不支持查看 EXIF 扩展信息；上传的图片如果经过系统再处理（加水印、压缩），EXIF 会被清除。\n用 真正能完整保留原信息的，只有文件方式：通过「文件」发送，对方收到的是一份文件，会保留原始信息。\n工具 当“照片”发（压缩） “原图” 当“文件”发 微信 ❌ ⚠️ 画质保真但删 GPS 等 ✅ QQ ❌ ⚠️ 多数保留（建议实测） ✅ 钉钉 ❌ — ✅ 企业微信 ❌ — ✅ 飞书 ❌ — ✅ 比较强的暗水印可以扛住一部分处理，但没有一种暗水印是完全不可破坏的。\n以上是关于暗水印的个人收集和小实验。\n","permalink":"https://blog.onecai.site/2026/06/15/013-img-watermark/","summary":"\u003cp\u003e聊这个话题之前先看看下面这两张图片，能看出来有什么区别吗？\u003c/p\u003e\n\u003cdiv style=\"display: flex; gap: 1rem; align-items: flex-start;\"\u003e\n  \u003cdiv style=\"flex: 1;\"\u003e\n    \u003cfigure\u003e\n        \u003cimg loading=\"lazy\" src=\"anwatermark-01.avif\"\n             alt=\"图片一\"/\u003e \u003cfigcaption\u003e\n                图片一\n            \u003c/figcaption\u003e\n    \u003c/figure\u003e\n\n  \u003c/div\u003e\n  \u003cdiv style=\"flex: 1;\"\u003e\n    \u003cfigure\u003e\n        \u003cimg loading=\"lazy\" src=\"anwatermark-01-watermarked.avif\"\n             alt=\"图片二\"/\u003e \u003cfigcaption\u003e\n                图片二\n            \u003c/figcaption\u003e\n    \u003c/figure\u003e\n\n  \u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003e直观来看，左图左下角有文字水印，右图是“原图”。其实除了画面内容，两张图片承载了相同的文字信息，只不过右图不是明文显示，而是通过暗水印的方式把文字藏了进去。\u003c/p\u003e\n\u003ch2 id=\"关于暗水印\"\u003e关于暗水印\u003c/h2\u003e\n\u003cp\u003e图片暗水印（也叫隐形水印、盲水印）是一种把标识信息嵌入图片内部、肉眼看不见但能被算法提取出来的技术。和传统明晃晃的文字水印（明水印）不同，暗水印不破坏画面观感，主要用于版权追踪和泄露溯源。\u003c/p\u003e\n\u003ch3 id=\"典型用途\"\u003e典型用途\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e版权追踪\u003c/strong\u003e：\n比如摄影师、设计师、平台给图片加入暗水印，后续即使别人裁剪、转发，也可能检测出原始来源。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e平台溯源\u003c/strong\u003e：\n有些社交平台、图片平台、AI 图片生成工具，可能会在图片里加入隐藏标记，用来判断图片来源、生成工具、上传渠道等。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e防盗图\u003c/strong\u003e：\n即使别人把明水印裁掉，只要暗水印还在，就可能证明图片来源。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAI 生成图片识别\u003c/strong\u003e：\n一些 AI 图片系统会尝试给生成图加入不可见标记，用于说明“这张图可能由 AI 生成”。（借助 AI 工具生成的视频、图片，会被抖音、视频号、小红书等平台识别出是 AI 生成的作品，可能就是这个原理。）\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3 id=\"暗水印不等于-exif-信息\"\u003e暗水印不等于 EXIF 信息\u003c/h3\u003e\n\u003cp\u003e很多人容易把两者混在一起，\u003cstrong\u003eEXIF 信息\u003c/strong\u003e是照片文件里的元数据，比如：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e2\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e3\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e4\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-fallback\" data-lang=\"fallback\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e拍摄设备：iPhone\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e拍摄时间：2026-06-21\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eGPS 位置：\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e镜头参数：\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e这种信息比较容易被查看，也容易被删除。但暗水印一般是嵌进图片内容本身的，即使你删掉 EXIF，它可能还在。\u003c/p\u003e\n\u003ch2 id=\"做个小实验\"\u003e做个小实验\u003c/h2\u003e\n\u003cp\u003e核心原理很简单：明文 → AES-GCM 加密 → LSB 隐写嵌入 PNG 图片 → 接收端逆向提取。\u003c/p\u003e","title":"了解一下图片暗水印"},{"content":"升级到 iOS 27 beta 1，本来只是想看看系统是不是更顺手了。用了几天下来，发现快捷指令里一个很不起眼的改动——快捷指令总算有了点“全局变量”的味道。常折腾它的人大概懂，这真不算小更新。\n升级到 iOS 27 beta 1 之后 先说系统本身。\n升级之后，手机整体用起来确实更顺了一些，每天划来划去、打开关闭 App、切换页面的时候，能感觉到它比之前更轻一点。\n我自己比较在意的地方主要有三个。\n1. Liquid Glass Liquid Glass效果 这个效果之前看介绍的时候，我其实没太大感觉。因为这类视觉更新，很容易在宣传图里显得高级，真正用到手机上又是另一回事。但这次实际用下来，它确实比我想象中舒服。透明、折射、层次感这些东西没有那么“炫技”，反而是日常看着更干净了一点。\n2. 景深效果 iOS27主题景深效果\u0026lt;br\u0026gt; 鼠标悬浮在图片上移动鼠标可以看到景深效果动图 手机主题和锁屏里的景深效果，好像也比以前好了不少。图片和时间、组件之间的前后关系更自然，不像之前有时候会显得硬贴上去。当然这个感受比较主观，也可能跟我这次换的壁纸有关，但整体观感确实比之前顺眼。\n3. 快捷指令又变了 iOS27快捷指令新增功能 每次系统升级，我最怕的其实不是耗电，也不是卡顿，而是快捷指令。\n因为快捷指令这东西很奇怪：平时用得好好的，一升级系统，它就可能突然这里坏一点，那里报个错。最麻烦的是，官方通常也不会很详细地告诉你，到底哪些动作改了，哪些逻辑变了。\n这次也一样。\n我原来用的几个快捷指令，被搞得七七八八不能正常运行。只能重新备份、修改、删除、新建，一点点把流程修回来。折腾的过程挺烦，但也正是在这个过程中，我发现了一个新功能——“储存空间”。\n说实话，Apple 这个名字起得有点绕，如果直接叫“全局变量”，反而更容易理解。\n快捷指令里的“储存空间” 这个功能藏在快捷指令的“脚本”里面，名字叫“储存空间”。\n点进去之后，里面主要有三个动作：\n储存内容：把传入的内容按指定名称存起来。这个内容不会因为快捷指令运行结束就消失，后面还可以继续取出来用。 获取已储存内容：按照名称，把之前存过的内容取出来。 删除已储存内容：把指定名称下保存的内容删掉。 这三个动作放在一起，意思就很清楚了。\n我举个自己正在用的例子：\n全局变量的使用 我做了一个跟写作选题有关的快捷指令，需要给每个选题自动生成编号。以前如果想实现这个功能，要么借助备忘录、文本文件、Data Jar 这类第三方工具，要么绕一堆很麻烦的逻辑。\n现在简单多了。\n创建一个名为“选题编号”的快捷指令。 在里面使用“脚本”里的“储存空间”，选择“储存内容”，把编号“001”存进去，并给它起一个名字，比如叫“第几个选题”。\n这样，一个最简单的全局变量就有了。\n使用这个全局变量 后面另一个快捷指令要用这个编号时，就直接通过“获取已储存内容”，读取“第几个选题”这个值。\n读取之后，用它生成当前选题编号。\n流程结束前，再让这个编号自增 1，然后把新的编号重新写回“第几个选题”。\n也就是说，第一次运行是 001，下一次就是 002，再下一次就是 003。\n这个功能其实能解决很多小麻烦 快捷指令最有意思的地方，就是它看起来只是几个动作拼来拼去，但只要能保存状态，它就不只是“一次性工具”了。\n可以记录某个流程上次运行到哪里。 可以保存某个计数器。 可以记住某个开关状态。 可以给选题、文件、录音、截图这些东西自动编号。 可以把一些常用配置放进去，之后所有相关快捷指令都从这里读取，不用每个快捷指令里都手动改一遍。\n这跟写程序里的全局变量、配置文件、状态存储有点像。对于普通用户来说，不需要理解这些概念；但对喜欢折腾自动化的人来说，这个变化很关键。\n以前很多需要第三方 App 才能完成的事情，现在可能直接用系统快捷指令就能搞定，可以替代一部分第三方工具了。\n顺手记录一个 beta 小 bug 编辑这篇文章的时候，还发现了一个 iOS 27 beta 1 的小 bug。\n我截图之后已经做了裁剪，但回到相册里看，那张图显示的还是裁剪前的原图。\n","permalink":"https://blog.onecai.site/2026/06/14/012-newofshortcut/","summary":"\u003cp\u003e升级到 iOS 27 beta 1，本来只是想看看系统是不是更顺手了。用了几天下来，发现快捷指令里一个很不起眼的改动——快捷指令总算有了点“全局变量”的味道。常折腾它的人大概懂，这真不算小更新。\u003c/p\u003e\n\u003ch2 id=\"升级到-ios-27-beta-1-之后\"\u003e升级到 iOS 27 beta 1 之后\u003c/h2\u003e\n\u003cp\u003e先说系统本身。\u003c/p\u003e\n\u003cp\u003e升级之后，手机整体用起来确实更顺了一些，每天划来划去、打开关闭 App、切换页面的时候，能感觉到它比之前更轻一点。\u003c/p\u003e\n\u003cp\u003e我自己比较在意的地方主要有三个。\u003c/p\u003e\n\u003ch3 id=\"1--liquid-glass\"\u003e1.  Liquid Glass\u003c/h3\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"shortcut01.avif\"\n         alt=\"Liquid Glass效果\" width=\"50%\"/\u003e \u003cfigcaption\u003e\n            Liquid Glass效果\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e这个效果之前看介绍的时候，我其实没太大感觉。因为这类视觉更新，很容易在宣传图里显得高级，真正用到手机上又是另一回事。但这次实际用下来，它确实比我想象中舒服。透明、折射、层次感这些东西没有那么“炫技”，反而是日常看着更干净了一点。\u003c/p\u003e\n\u003ch3 id=\"2-景深效果\"\u003e2. 景深效果\u003c/h3\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"shortcut02.avif\"\n         alt=\"iOS27主题景深效果\u0026lt;br\u0026gt; 鼠标悬浮在图片上移动鼠标可以看到景深效果动图\" width=\"50%\"/\u003e \u003cfigcaption\u003e\n            iOS27主题景深效果\u0026lt;br\u0026gt; 鼠标悬浮在图片上移动鼠标可以看到景深效果动图\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e手机主题和锁屏里的景深效果，好像也比以前好了不少。图片和时间、组件之间的前后关系更自然，不像之前有时候会显得硬贴上去。当然这个感受比较主观，也可能跟我这次换的壁纸有关，但整体观感确实比之前顺眼。\u003c/p\u003e\n\u003ch3 id=\"3-快捷指令又变了\"\u003e3. 快捷指令又变了\u003c/h3\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"shortcut03.avif\"\n         alt=\"iOS27快捷指令新增功能\" width=\"50%\"/\u003e \u003cfigcaption\u003e\n            iOS27快捷指令新增功能\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e每次系统升级，我最怕的其实不是耗电，也不是卡顿，而是快捷指令。\u003c/p\u003e\n\u003cp\u003e因为快捷指令这东西很奇怪：平时用得好好的，一升级系统，它就可能突然这里坏一点，那里报个错。最麻烦的是，官方通常也不会很详细地告诉你，到底哪些动作改了，哪些逻辑变了。\u003c/p\u003e\n\u003cp\u003e这次也一样。\u003c/p\u003e\n\u003cp\u003e我原来用的几个快捷指令，被搞得七七八八不能正常运行。只能重新备份、修改、删除、新建，一点点把流程修回来。折腾的过程挺烦，但也正是在这个过程中，我发现了一个新功能——“储存空间”。\u003c/p\u003e\n\u003cp\u003e说实话，Apple 这个名字起得有点绕，如果直接叫“全局变量”，反而更容易理解。\u003c/p\u003e\n\u003ch2 id=\"快捷指令里的储存空间\"\u003e快捷指令里的“储存空间”\u003c/h2\u003e\n\u003cp\u003e这个功能藏在快捷指令的“脚本”里面，名字叫“储存空间”。\u003c/p\u003e\n\u003cp\u003e点进去之后，里面主要有三个动作：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e储存内容：把传入的内容按指定名称存起来。这个内容不会因为快捷指令运行结束就消失，后面还可以继续取出来用。\u003c/li\u003e\n\u003cli\u003e获取已储存内容：按照名称，把之前存过的内容取出来。\u003c/li\u003e\n\u003cli\u003e删除已储存内容：把指定名称下保存的内容删掉。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e这三个动作放在一起，意思就很清楚了。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e我举个自己正在用的例子：\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"shortcut04.avif\"\n         alt=\"全局变量的使用\"/\u003e \u003cfigcaption\u003e\n            全局变量的使用\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e我做了一个跟写作选题有关的快捷指令，需要给每个选题自动生成编号。以前如果想实现这个功能，要么借助备忘录、文本文件、Data Jar 这类第三方工具，要么绕一堆很麻烦的逻辑。\u003c/p\u003e\n\u003cp\u003e现在简单多了。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e创建一个名为“选题编号”的快捷指令。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e在里面使用“脚本”里的“储存空间”，选择“储存内容”，把编号“001”存进去，并给它起一个名字，比如叫“第几个选题”。\u003c/p\u003e\n\u003cp\u003e这样，一个最简单的全局变量就有了。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e使用这个全局变量\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e后面另一个快捷指令要用这个编号时，就直接通过“获取已储存内容”，读取“第几个选题”这个值。\u003c/p\u003e\n\u003cp\u003e读取之后，用它生成当前选题编号。\u003c/p\u003e\n\u003cp\u003e流程结束前，再让这个编号自增 1，然后把新的编号重新写回“第几个选题”。\u003c/p\u003e\n\u003cp\u003e也就是说，第一次运行是 001，下一次就是 002，再下一次就是 003。\u003c/p\u003e\n\u003ch2 id=\"这个功能其实能解决很多小麻烦\"\u003e这个功能其实能解决很多小麻烦\u003c/h2\u003e\n\u003cp\u003e快捷指令最有意思的地方，就是它看起来只是几个动作拼来拼去，但只要能保存状态，它就不只是“一次性工具”了。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e可以记录某个流程上次运行到哪里。\u003c/li\u003e\n\u003cli\u003e可以保存某个计数器。\u003c/li\u003e\n\u003cli\u003e可以记住某个开关状态。\u003c/li\u003e\n\u003cli\u003e可以给选题、文件、录音、截图这些东西自动编号。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e可以把一些常用配置放进去，之后所有相关快捷指令都从这里读取，不用每个快捷指令里都手动改一遍。\u003c/p\u003e\n\u003cp\u003e这跟写程序里的全局变量、配置文件、状态存储有点像。对于普通用户来说，不需要理解这些概念；但对喜欢折腾自动化的人来说，这个变化很关键。\u003c/p\u003e","title":"快捷指令终于有“全局变量”了！"},{"content":"又做了一个实验 在上一篇里，我把同一段文字丢给好几个不同的 AI 工具，让它们各自总结一遍。材料一模一样，结果却挺不一样：有的抓住了重点，有的会自作主张补几句“听起来很合理、原文却根本没写”的话，还有的把原文里含含糊糊的说法，硬讲得斩钉截铁。那次之后，我对“幻觉”这件事有了更具体的感受——它不是简单的“我不知道”，而是会一本正经地，把没把握的东西说得跟真的一样。\n换种问法，AI给的答案能差多少？ 这一次，我换了个思路。\n上回是“同一段材料，喂给不同的模型”；这回反过来，只用一个模型，让它做同一件事，但每次换一种问法。说白了，就是改 prompt（提示词）。\n同样一个模型，任务大方向也没变，只是问法不同，我想看看：\n它给出来的内容，差别到底有多大？ 是只换了个说法，还是连理解的重点都跟着变了？ 是写得更准了，还是更容易跑偏？ 于是有了下面这五种问法：\n序号 Prompt 类型 Prompt 内容 1 普通总结版 总结一下下面这段内容：【材料】 2 字数限制版 请用 100 字以内总结下面这段内容：【材料】 3 结构化总结版 请按以下结构总结：①发生了什么 ②原因是什么 ③影响是什么。【材料】 4 防幻觉约束版 请只根据原文总结，不要加入原文没有的信息；如果原文没提到原因、影响或结论，就直接写“原文未提及”。【材料】 5 证据对应版 请总结下面这段内容，并把每条结论对应到原文依据。格式：结论＋对应的原文句子。【材料】 这五种，其实正好对应我们平时用 AI 的几个层次：随手一问 → 加一点限制 → 给它一个结构 → 要求它别乱编 → 最后逼它拿出证据。\n实验结果我没有一条条贴出来——这种东西自己试最直观。随便找段新闻或者资料，把上面五种问法挨个套一遍，差别一眼就看得出来。\n我真正想搞清楚的是：面对同一段材料，这个 AI 到底是“理解稳定”，还是很容易被问法牵着走。如果只是表达风格变了，那 prompt 影响的主要是“它怎么说”；可如果连事实重点、因果关系、甚至结论都跟着变，那就值得警惕了——因为这说明，我们跟 AI 对话时，问法本身就在悄悄塑造答案。\n既然问法这么关键，那怎么问才靠谱？下面是我自己常用的几样东西。\n30 秒快速自检 敲回车之前，花半分钟过一遍这四件事：\n动作：到底要它做什么？别写“处理 / 优化 / 弄一下”，写清楚是“新增 / 只改 / 重写 / 标注”。 对象：改的是哪个？别用“这个 / 它 / 那段”，直接给出文件名、函数名、单元格。 范围：边界在哪？少用“所有 / 全部 / 相关 / 顺便”，明确说清楚包含什么、排除什么。 验收：怎样算做对了？比如签名不变、测试跑通、控制在一页、不超纲。 凡是带副作用的操作（改文件、拉数据、删除、下单、推送），我都会默认补一句：“先列出你要做的，等我确认再执行。” 就这一句，能拦掉绝大多数“方向对了、范围却搞大了”的白白烧 token 的操作。\n几个“危险词” 如果你的 prompt 里出现下面这些词，对 AI 来说基本就是危险信号——很容易理解偏，甚至动错刀。\n类型 危险信号词 为什么致命 指代不明 这个 / 那个 / 它 / 上面的 / 刚才那个 AI 可能操作到错的对象，动错刀 动作过载 处理 / 搞定 / 弄一下 / 整理 / 优化 / 更新 / 改 AI 可能选了破坏性操作，还自以为做对了 范围无界 所有 / 全部 / 都 / 统统 改了你本来不想动的部分 否定 / 嵌套否定 别太… / 不要不… / 不是不能但… 意图容易被理解反 隐性默认值 正常 / 标准 / 默认 / 常规 / 一般 AI 用它自己的默认值填空，和你想的不一样 程度无基准 简单 / 详细 / 专业点 / 高级 / 更好 量级全靠猜，常常差一个数量级 能力性疑问 能不能 / 可以吗 / 会不会 该动手时没动手，或该先问却直接开干 兜底词 等等 / 之类的 / 差不多 / 随便 / 顺便 范围被随意伸缩 十个常见场景，对照着改 道理说再多，不如看例子。下面挑了十个高频场景，左边是大家随手会写的，右边是改完的：\n# 场景 随手一写 出错机制 改写之后 1 内容写作 “写一篇关于 X 的文章” 受众、篇幅、角度全靠猜，容易写成泛泛的百科 “给小红书读者写一篇 800 字的 X 入门，口语化，带 3 个可操作建议” 2 总结长文 “总结一下这个” 不知道为谁总结、要多长、保留什么 “用 5 个要点提炼核心论点，给没读过原文的人看，每点一句话” 3 翻译 “翻译成中文” 直译还是意译、术语怎么处理、语气都没定 “翻成简体中文，技术术语保留英文原文并加括号，语气偏口语” 4 写代码 “写个爬虫 / 脚本” 语言、依赖、输入输出、异常处理全缺 “用 Python + requests 写，输入是 URL 列表，输出 CSV，加超时和重试” 5 排错 Debug “这段代码有问题，修一下” “问题”没定义，可能改了不该改的逻辑 “报错是 KeyError: 'id'，定位原因，只改这一处，别动其他逻辑” 6 数据分析 “分析一下这份数据” 分析目标、维度、输出形式全空 “按月份汇总销售额，找出环比下降的月份，输出一张表加三句结论” 7 邮件 / 消息 “帮我回复一下这封邮件” 答应还是拒绝、什么语气都没说，AI 替你定调 “婉拒这个会议邀约，语气客气但明确，提议下周改约，控制在 4 句话” 8 润色改写 “润色一下，专业点” “专业”没标准，可能改得面目全非 “只改语法和啰嗦的句子，保留我的原意和口吻，别加新内容” 9 研究 / 查询 “查一下 X 怎么样” “怎么样”太开放，容易给笼统答案 “对比 X 和 Y 在价格、续航、口碑三方面的差异，列表呈现，标注信息来源” 10 头脑风暴 “给我一些点子” 数量、约束、方向都缺，容易给套话 “给 5 个低成本、一周内能落地的方案，排除需要外部投资的” 一个万能模板 如果嫌上面太碎，记住一句话就够了——把“动作＋对象＋范围＋验收标准”这四件事，明明白白写出来。\n把【动作】，施加到【确切的对象】上，范围限定在【X，排除 Y】，做完要满足【验收标准】。涉及副作用的，先列计划，等我确认。\n最后几句 token 是真的贵。敲回车之前先给自己的 prompt 把把脉，因为回车一按，token 包里的余额可就哗啦啦地往下掉了。 学 AI 最好的办法，不是去买书、报班、上各种课，而是直接问 AI：我该怎么学你。 说到花钱——该订还是得订个付费版。它和免费版差得真不是一点半点，用过就回不去了。 ","permalink":"https://blog.onecai.site/2026/06/13/011-howtoprompt/","summary":"\u003ch2 id=\"又做了一个实验\"\u003e又做了一个实验\u003c/h2\u003e\n\u003cp\u003e在\u003ca href=\"https://blog.onecai.site/2026/06/17/aifaithfulness/\"\u003e上一篇\u003c/a\u003e里，我把同一段文字丢给好几个不同的 AI 工具，让它们各自总结一遍。材料一模一样，结果却挺不一样：有的抓住了重点，有的会自作主张补几句“听起来很合理、原文却根本没写”的话，还有的把原文里含含糊糊的说法，硬讲得斩钉截铁。那次之后，我对“幻觉”这件事有了更具体的感受——它不是简单的“我不知道”，而是会一本正经地，把没把握的东西说得跟真的一样。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"ai-prompts.avif\"\n         alt=\"换种问法，AI给的答案能差多少？\"/\u003e \u003cfigcaption\u003e\n            换种问法，AI给的答案能差多少？\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e这一次，我换了个思路。\u003c/p\u003e\n\u003cp\u003e上回是“同一段材料，喂给不同的模型”；这回反过来，只用一个模型，让它做同一件事，但每次换一种问法。说白了，就是改 prompt（提示词）。\u003c/p\u003e\n\u003cp\u003e同样一个模型，任务大方向也没变，只是问法不同，我想看看：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e它给出来的内容，差别到底有多大？\u003c/li\u003e\n\u003cli\u003e是只换了个说法，还是连理解的重点都跟着变了？\u003c/li\u003e\n\u003cli\u003e是写得更准了，还是更容易跑偏？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e于是有了下面这五种问法：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e序号\u003c/th\u003e\n          \u003cth\u003ePrompt 类型\u003c/th\u003e\n          \u003cth\u003ePrompt 内容\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e1\u003c/td\u003e\n          \u003ctd\u003e普通总结版\u003c/td\u003e\n          \u003ctd\u003e总结一下下面这段内容：【材料】\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e2\u003c/td\u003e\n          \u003ctd\u003e字数限制版\u003c/td\u003e\n          \u003ctd\u003e请用 100 字以内总结下面这段内容：【材料】\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e3\u003c/td\u003e\n          \u003ctd\u003e结构化总结版\u003c/td\u003e\n          \u003ctd\u003e请按以下结构总结：①发生了什么 ②原因是什么 ③影响是什么。【材料】\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e4\u003c/td\u003e\n          \u003ctd\u003e防幻觉约束版\u003c/td\u003e\n          \u003ctd\u003e请只根据原文总结，不要加入原文没有的信息；如果原文没提到原因、影响或结论，就直接写“原文未提及”。【材料】\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e5\u003c/td\u003e\n          \u003ctd\u003e证据对应版\u003c/td\u003e\n          \u003ctd\u003e请总结下面这段内容，并把每条结论对应到原文依据。格式：结论＋对应的原文句子。【材料】\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e这五种，其实正好对应我们平时用 AI 的几个层次：随手一问 → 加一点限制 → 给它一个结构 → 要求它别乱编 → 最后逼它拿出证据。\u003c/p\u003e\n\u003cp\u003e实验结果我没有一条条贴出来——这种东西自己试最直观。随便找段新闻或者资料，把上面五种问法挨个套一遍，差别一眼就看得出来。\u003c/p\u003e\n\u003cp\u003e我真正想搞清楚的是：面对同一段材料，这个 AI 到底是“理解稳定”，还是很容易被问法牵着走。如果只是表达风格变了，那 prompt 影响的主要是“它怎么说”；可如果连事实重点、因果关系、甚至结论都跟着变，那就值得警惕了——因为这说明，我们跟 AI 对话时，问法本身就在悄悄塑造答案。\u003c/p\u003e\n\u003cp\u003e既然问法这么关键，那怎么问才靠谱？下面是我自己常用的几样东西。\u003c/p\u003e\n\u003ch2 id=\"30-秒快速自检\"\u003e30 秒快速自检\u003c/h2\u003e\n\u003cp\u003e敲回车之前，花半分钟过一遍这四件事：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e动作\u003c/strong\u003e：到底要它做什么？别写“处理 / 优化 / 弄一下”，写清楚是“新增 / 只改 / 重写 / 标注”。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e对象\u003c/strong\u003e：改的是哪个？别用“这个 / 它 / 那段”，直接给出文件名、函数名、单元格。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e范围\u003c/strong\u003e：边界在哪？少用“所有 / 全部 / 相关 / 顺便”，明确说清楚包含什么、排除什么。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e验收\u003c/strong\u003e：怎样算做对了？比如签名不变、测试跑通、控制在一页、不超纲。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e凡是带副作用的操作（改文件、拉数据、删除、下单、推送），我都会默认补一句：\u003cstrong\u003e“先列出你要做的，等我确认再执行。”\u003c/strong\u003e 就这一句，能拦掉绝大多数“方向对了、范围却搞大了”的白白烧 token 的操作。\u003c/p\u003e","title":"换种问法，AI给的答案能差多少？"},{"content":"跟AI工具进行对话时，刚开始聊着聊着还挺好，聊一会就明显感觉这伙计开始胡编乱造了，尤其是免费版的AI工具，付费版的还会陪你聊一会，可能不耐烦了之后也就开始应付着出现幻觉了。\nAI模型的幻觉 问问AI 这个问题又去问了一下AI——还是人家不怕自相矛盾——给出了两个网络资源，一篇学术论文和一篇有营销嫌疑的博客文章；\nBenchmarking LLM Faithfulness in RAG with Evolving Leaderboards：https://arxiv.org/pdf/2505.04847 LLM Hallucination Index 2026: Why Claude 4.6 Sonnet Dominates BullshitBench v2 While Reasoning Models Fail：https://medium.com/@anyapi.ai/llm-hallucination-index-2026-why-claude-4-6-7b2d13ed9f0c 其中，论文聚焦的核心概念是忠实度（faithfulness）：模型生成的内容是否严格基于给定上下文，不引入无依据信息、不曲解、不自相矛盾。这与“事实正确性”不同——一句话可能符合世界知识，但只要原文没说，在 RAG 场景里也算不忠实。作者指出一个反常识的事实：RAG 本意是用检索到的可信上下文来“锚定”模型回答，从而压制幻觉，但即便上下文已经给到模型，LLM 仍频繁添加原文不支持的细节、歪曲信息甚至直接矛盾。更棘手的是评测端：无论是微调的检测模型还是 LLM-as-a-judge，识别幻觉的准确率都不理想。作者特别提到一个令人沮丧的发现——在专门设计来“挑刺”的 FaithBench 数据集上，包括用 LLM 做分类在内的现有方法，准确率徘徊在 50% 左右，几乎等于随机猜。博客文章主要论点有三个：一是“推理悖论”，声称对 GPT-5.2、Gemini 3 Pro 等多数模型来说，加大推理算力反而降低识别假前提的能力，模型会把额外算力用来给错误“圆谎”；二是把 Claude Sonnet 4.6 捧为“唯一默认带怀疑精神”的模型（声称 91% 检测率、3% 幻觉率）；三是说 OpenAI、Google 因过度 RLHF 变成“yes-man”，卡在 55–65% 区间。开源方面把 Qwen3.5 列为主要替代。\n文论附录 论文附录给出了用 FaithJudge 对 12 个模型综合四个子任务的幻觉率排名（从低到高，越低越好）：\n排名 模型 综合幻觉率 1 gemini-2.5-pro 6.65% 2 gemini-2.0-flash 10.18% 3 gpt-4.5-preview 11.94% 4 o3-mini-high 12.52% 5 gpt-3.5-turbo 14.87% 6 gpt-4o 15.85% 7 claude-3.7-sonnet 16.05% 8 llama-3.3-70b 16.44% 9 phi-4 17.03% 10 mistral-small-24b 17.03% 11 llama-4-maverick 20.55% 12 llama-3.1-8b 28.38% 论文引用CNN 关于福建漳州工厂爆炸这则新闻来对每一个AI工具进行测试，从 用户问题、检索到的资料、模型回答、错误片段、为什么错、正确说法、证据来源这几个维度来测试并得出幻觉率排名。\n做个同样的实验 以下面这则财经新闻进行测试： 捷豹路虎 JLR 在 2026 年 6 月 17 日的投资者日上预计，2027 财年收入将达到约 260 亿英镑，高于 2026 财年的约 229 亿英镑；但公司给出的 2027 财年 EBIT 利润率展望只有约 4%，低于市场预期，引发其印度母公司塔塔汽车乘用车股价盘中一度下跌约 9.6%。JLR 此前在 2026 财年全年收入为 229 亿英镑，同比下降 20.9%；第四季度收入为 69 亿英镑，同比下降 11.1%，但环比增长 51.4%。公司称，2026 财年表现受到美国关税、中国市场竞争、旧款捷豹车型逐步停产，以及此前网络攻击导致生产中断等因素影响。尽管利润率展望偏弱，JLR 仍表示将继续推进 180 亿英镑投资计划，并寻求在未来实现中期双位数收入增长。\n希望能够得出比较忠实、没有把预测写成事实、也没有把环比和同比混淆的总结：\nJLR 预计 2027 财年收入约 260 亿英镑，高于 2026 财年的约 229 亿英镑，但 EBIT 利润率展望仅约 4%，低于市场预期，导致塔塔汽车乘用车股价盘中一度大跌。JLR 2026 财年收入同比下降，主要受到关税、中国市场竞争、车型调整和网络攻击等因素影响。\n使用的prompt是： 请根据下面财经新闻写一段 120 字以内的摘要。 要求：\n只能使用原文信息； 不要加入原文没有的判断； 不要把预测写成已经发生； 不要把同比、环比混淆； 不要把股价下跌原因扩大为唯一原因。 新闻原文： 【粘贴上面的测试原文】\n输出结果如下： Claude Opus 4.8 捷豹路虎6月17日投资者日预计，2027财年收入约260亿英镑，高于2026财年的约229亿英镑，但2027财年EBIT利润率展望仅约4%，低于市场预期，母公司塔塔汽车乘用车股价盘中一度跌约9.6%。2026财年收入同比降20.9%，公司归因于美国关税、中国市场竞争、旧款捷豹停产及网络攻击等，并表示仍将推进180亿英镑投资计划。\nChatGPT 5.5 JLR预计2027财年收入约260亿英镑，高于2026财年的229亿英镑；但EBIT利润率展望约4%低于预期，塔塔汽车乘用车股价盘中一度跌约9.6%。\nGrok 4.3 JLR6月17日预计2027财年收入约260亿英镑，高于2026财年229亿英镑，但EBIT利润率展望约4%低于预期，致塔塔汽车股价跌约9.6%。2026财年收入同比降20.9%，Q4同比降11.1%环比增51.4%，仍推进180亿投资寻求双位数增长。\nGemini 捷豹路虎预计2027财年收入约260亿英镑，但EBIT利润率展望约4%低于预期，引发母公司塔塔汽车股价盘中一度跌约9.6%。其2026财年及四季度收入同比均下降，环比增长。这受美国关税、中国竞争及网络攻击等影响。JLR仍将推进投资并寻求中期双位数收入增长。\nQwen3.7 Plus 捷豹路虎预计2027财年收入约260亿英镑，高于2026财年229亿英镑；但EBIT利润率展望仅约4%，低于预期，致塔塔汽车股价盘中跌约9.6%。2026财年收入同比降20.9%，受美国关税、中国竞争、旧款捷豹停产及网络攻击等影响。\nDeepSeek V3 捷豹路虎在2026年6月17日投资者日上预计，2027财年收入约260亿英镑，高于2026财年的约229亿英镑，但给出的2027财年EBIT利润率展望约4%，低于市场预期，引发其印度母公司塔塔汽车乘用车股价盘中一度下跌约9.6%。公司2026财年全年收入同比下降20.9%，第四季度收入同比下降11.1%但环比增长51.4%。公司称表现受到美国关税、中国市场竞争、旧款车型停产及网络攻击等因素影响。JLR仍表示将继续推进180亿英镑投资计划。\n智谱 GLM-5.2 JLR预计2027财年收入约260亿英镑，EBIT利润率约4%的展望低于预期引发母公司股价一度跌9.6%。2026财年收入229亿英镑，同比降20.9%；四季度收入69亿英镑，同比降11.1%，环比增51.4%。受关税等影响，公司仍推进180亿英镑投资。\n豆包 6月17日捷豹路虎投资者日预测2027财年收入约260亿英镑，EBIT利润率约4%不及市场预期，致塔塔汽车乘用车股价盘中跌约9.6%。其2026财年收入229亿英镑同比降20.9%，四季度收入69亿英镑同比降11.1%、环比增51.4%，业绩受多重因素拖累，公司仍将推进百亿投资，谋求中期收入双位数增长。\nKimi k2.6 捷豹路虎（JLR）在投资者日上预计2027财年收入约260亿英镑，高于2026财年的约229亿英镑；但2027财年EBIT利润率展望仅约4%，低于市场预期，致其母公司塔塔汽车乘用车股价盘中一度下跌约9.6%。2026财年全年收入229亿英镑，同比下降20.9%；第四季度收入69亿英镑，同比下降11.1%，环比增长51.4%。公司称业绩受美国关税、中国市场竞争、旧款捷豹停产及网络攻击导致生产中断等因素影响。JLR表示将继续推进180亿英镑投资计划，并寻求未来实现中期双位数收入增长。\n看看哪个模型喝高幻觉比较多？你觉得哪个好？\n","permalink":"https://blog.onecai.site/2026/06/12/010-aifaithfulness/","summary":"\u003cp\u003e跟AI工具进行对话时，刚开始聊着聊着还挺好，聊一会就明显感觉这伙计开始胡编乱造了，尤其是免费版的AI工具，付费版的还会陪你聊一会，可能不耐烦了之后也就开始应付着出现幻觉了。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"AiFaithfulness.avif\"\n         alt=\"AI模型的幻觉\"/\u003e \u003cfigcaption\u003e\n            AI模型的幻觉\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003ch2 id=\"问问ai\"\u003e问问AI\u003c/h2\u003e\n\u003cp\u003e这个问题又去问了一下AI——还是人家不怕自相矛盾——给出了两个网络资源，一篇学术论文和一篇有营销嫌疑的博客文章；\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eBenchmarking LLM Faithfulness in RAG with Evolving Leaderboards：https://arxiv.org/pdf/2505.04847\u003c/li\u003e\n\u003cli\u003eLLM Hallucination Index 2026: Why Claude 4.6 Sonnet Dominates BullshitBench v2 While Reasoning Models Fail：https://medium.com/@anyapi.ai/llm-hallucination-index-2026-why-claude-4-6-7b2d13ed9f0c\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e其中，\u003cstrong\u003e论文\u003c/strong\u003e聚焦的核心概念是忠实度（faithfulness）：模型生成的内容是否严格基于给定上下文，不引入无依据信息、不曲解、不自相矛盾。这与“事实正确性”不同——一句话可能符合世界知识，但只要原文没说，在 RAG 场景里也算不忠实。作者指出一个反常识的事实：RAG 本意是用检索到的可信上下文来“锚定”模型回答，从而压制幻觉，但即便上下文已经给到模型，LLM 仍频繁添加原文不支持的细节、歪曲信息甚至直接矛盾。更棘手的是评测端：无论是微调的检测模型还是 LLM-as-a-judge，识别幻觉的准确率都不理想。作者特别提到一个令人沮丧的发现——在专门设计来“挑刺”的 FaithBench 数据集上，包括用 LLM 做分类在内的现有方法，准确率徘徊在 50% 左右，几乎等于随机猜。\u003cstrong\u003e博客文章\u003c/strong\u003e主要论点有三个：一是“推理悖论”，声称对 GPT-5.2、Gemini 3 Pro 等多数模型来说，加大推理算力反而降低识别假前提的能力，模型会把额外算力用来给错误“圆谎”；二是把 Claude Sonnet 4.6 捧为“唯一默认带怀疑精神”的模型（声称 91% 检测率、3% 幻觉率）；三是说 OpenAI、Google 因过度 RLHF 变成“yes-man”，卡在 55–65% 区间。开源方面把 Qwen3.5 列为主要替代。\u003c/p\u003e\n\u003ch2 id=\"文论附录\"\u003e文论附录\u003c/h2\u003e\n\u003cp\u003e论文附录给出了用 FaithJudge 对 12 个模型综合四个子任务的幻觉率排名（从低到高，越低越好）：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e排名\u003c/th\u003e\n          \u003cth\u003e模型\u003c/th\u003e\n          \u003cth\u003e综合幻觉率\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e1\u003c/td\u003e\n          \u003ctd\u003egemini-2.5-pro\u003c/td\u003e\n          \u003ctd\u003e6.65%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e2\u003c/td\u003e\n          \u003ctd\u003egemini-2.0-flash\u003c/td\u003e\n          \u003ctd\u003e10.18%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e3\u003c/td\u003e\n          \u003ctd\u003egpt-4.5-preview\u003c/td\u003e\n          \u003ctd\u003e11.94%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e4\u003c/td\u003e\n          \u003ctd\u003eo3-mini-high\u003c/td\u003e\n          \u003ctd\u003e12.52%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e5\u003c/td\u003e\n          \u003ctd\u003egpt-3.5-turbo\u003c/td\u003e\n          \u003ctd\u003e14.87%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e6\u003c/td\u003e\n          \u003ctd\u003egpt-4o\u003c/td\u003e\n          \u003ctd\u003e15.85%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e7\u003c/td\u003e\n          \u003ctd\u003eclaude-3.7-sonnet\u003c/td\u003e\n          \u003ctd\u003e16.05%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e8\u003c/td\u003e\n          \u003ctd\u003ellama-3.3-70b\u003c/td\u003e\n          \u003ctd\u003e16.44%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e9\u003c/td\u003e\n          \u003ctd\u003ephi-4\u003c/td\u003e\n          \u003ctd\u003e17.03%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e10\u003c/td\u003e\n          \u003ctd\u003emistral-small-24b\u003c/td\u003e\n          \u003ctd\u003e17.03%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e11\u003c/td\u003e\n          \u003ctd\u003ellama-4-maverick\u003c/td\u003e\n          \u003ctd\u003e20.55%\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e12\u003c/td\u003e\n          \u003ctd\u003ellama-3.1-8b\u003c/td\u003e\n          \u003ctd\u003e28.38%\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e论文引用CNN 关于福建漳州工厂爆炸这则新闻来对每一个AI工具进行测试，从 用户问题、检索到的资料、模型回答、错误片段、为什么错、正确说法、证据来源这几个维度来测试并得出幻觉率排名。\u003c/p\u003e","title":"了解Ai大模型的幻觉"},{"content":"简要内容 2025年3月24日，DAN KOE发文：“我写了一本第二本书。 一本关于金钱和发现你人生使命的简短而富有哲理的解读。 我把它免费提供，因为这是我希望尽可能多的人能拿到手中的东西之一。 平装版不是免费的，原因显而易见”。\n《Purpose \u0026amp; Profit》原版封面图 作者官方链接 DAN KOE在其官网（https://thedankoe.com/purpose）发布了PDF下载链接和亚马逊购买链接，可以免费下载来看电子版。\n下载链接：https://thedankoe.com/wp-content/uploads/2025/03/Purpose-Profit-2.pdf 亚马逊购买：https://www.amazon.com/review/create-review/ref=cm_cr_dp_d_wr_but_top?ie=UTF8\u0026amp;channel=glance-detail\u0026amp;asin=1936961288 我做的翻译版本 我下载了电子版，但是英语水平有限的紧，借助AI工具进行了翻译，并做了简单的手工校对。\n《Purpose \u0026amp; Profit》中英文对照-01 《Purpose \u0026amp; Profit》中英文对照-02 从哪里取 英文原版电子版和中文手工校对版本都上传到了GitHub上，如有需要请自取：\nhttps://github.com/onecaicai/DANKOE-Purpose-Profit\n","permalink":"https://blog.onecai.site/2026/06/11/009-dankoebookpurposeprofit/","summary":"\u003ch2 id=\"简要内容\"\u003e简要内容\u003c/h2\u003e\n\u003cp\u003e2025年3月24日，DAN KOE发文：“我写了一本第二本书。 一本关于金钱和发现你人生使命的简短而富有哲理的解读。 我把它免费提供，因为这是我希望尽可能多的人能拿到手中的东西之一。 平装版不是免费的，原因显而易见”。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"PurposeProfit-00.avif\"\n         alt=\"《Purpose \u0026amp; Profit》原版封面图\"/\u003e \u003cfigcaption\u003e\n            《Purpose \u0026amp; Profit》原版封面图\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003ch2 id=\"作者官方链接\"\u003e作者官方链接\u003c/h2\u003e\n\u003cp\u003eDAN KOE在其官网（https://thedankoe.com/purpose）发布了PDF下载链接和亚马逊购买链接，可以免费下载来看电子版。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e下载链接：https://thedankoe.com/wp-content/uploads/2025/03/Purpose-Profit-2.pdf\u003c/li\u003e\n\u003cli\u003e亚马逊购买：https://www.amazon.com/review/create-review/ref=cm_cr_dp_d_wr_but_top?ie=UTF8\u0026amp;channel=glance-detail\u0026amp;asin=1936961288\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"我做的翻译版本\"\u003e我做的翻译版本\u003c/h2\u003e\n\u003cp\u003e我下载了电子版，但是英语水平有限的紧，借助AI工具进行了翻译，并做了简单的手工校对。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"Purpose-Profit-_1.avif\"\n         alt=\"《Purpose \u0026amp; Profit》中英文对照-01\"/\u003e \u003cfigcaption\u003e\n            《Purpose \u0026amp; Profit》中英文对照-01\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"Purpose-Profit-_3.avif\"\n         alt=\"《Purpose \u0026amp; Profit》中英文对照-02\"/\u003e \u003cfigcaption\u003e\n            《Purpose \u0026amp; Profit》中英文对照-02\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003ch2 id=\"从哪里取\"\u003e从哪里取\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e英文原版电子版和中文手工校对版本都上传到了GitHub上，如有需要请自取：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/onecaicai/DANKOE-Purpose-Profit\"\u003ehttps://github.com/onecaicai/DANKOE-Purpose-Profit\u003c/a\u003e\u003c/p\u003e\n\u003c/blockquote\u003e","title":"DAN KOE的书《Purpose \u0026 Profit》"},{"content":"常说的拥有某数据中心拥有“**P算力”，这里面的算力是什么呢？\n什么是“1P”算力 网络上搜索一些内容，整理如下：\n“1P算力”里的 P 是数量级前缀 Peta（10¹⁵，千万亿），所以“1P算力”通常指 1 PFLOPS，即每秒 1×10¹⁵ 次浮点运算（1000万亿次/秒）。\n1. 单位是 FLOPS，不是 FLOP。\n算力的常用单位是 FLOPS（每秒浮点运算次数），是个速率。\n1P = 1000T（TFLOPS）= 100万G（GFLOPS）\n所以业内说的“1P卡”、“100P集群”基本都是指 PFLOPS 规模。\n2. 必须看精度，否则数字没意义。 同一张卡在不同精度下算力差好几倍，“1P算力”本身是不完整的说法。完整的应该是包含FP64、FP32、TF32、FP16、BF16、INT8，还是 INT4？\n本篇内容以“1P”的说法为入口，了解了解这方面的基础知识。\n相关概念： 以一个实例开始：\n一张 NVIDIA H100，FP16/BF16 峰值约 1 PFLOPS 量级（开稀疏更高），所以“1P”差不多就是“约一张高端 AI 卡”的体量。\n“百P算力中心”“千P智算集群”这类说法，就是把成百上千张这种卡堆在一起的总峰值。\n算力单位相关 FLOPS：全称 Floating Point Operations Per Second，即“每秒浮点运算次数”，是衡量算力的速率单位。注意结尾的 S 是 Second（秒），不是复数。\nFLOP：去掉 S，指“一次浮点运算”本身，是个数量而非速率。训练一个模型“总共要算多少次”用 FLOP（或 FLOPs，小写 s 表示复数次数），“每秒能算多少次”用 FLOPS。两者常被混用，但严格意义不同。\n浮点运算：对带小数的数字（浮点数）做的加减乘除等运算。之所以强调“浮点”，是因为它和整数运算的硬件实现、速度都不同，神经网络里大量是浮点计算。\nPeta / P：国际单位制的数量级前缀，10¹⁵（千万亿）。同系列还有 G（Giga，10⁹/十亿）、T（Tera，10¹²/万亿）、E（Exa，10¹⁸/百亿亿）。换算：1P = 1000T = 100万G。现在最顶级的超算到了 E 级（ExaFLOPS）。\n精度相关 精度：指一个数字用多少位（bit）来表示。位数越多，能表示的数值范围越大、越精确，但占的存储和计算资源也越多。AI 领域为了提速和省显存，倾向用更低的精度。\nFP64：双精度浮点，64 位。精度最高，主要用于科学计算、天气模拟这类对数值误差极敏感的场景。\nFP32：单精度浮点，32 位。传统通用计算和早期深度学习的默认精度。\nFP16 / BF16：半精度浮点，16 位。是 AI 训练的主流。两者都是 16 位但内部结构不同——BF16（Brain Float 16）牺牲了小数精度换取更大的数值范围，更不容易在训练中数值溢出，所以现在大模型训练更常用 BF16。\nFP8：8 位浮点，更激进的低精度，近两年在大模型训练和推理上开始普及（H100 这代硬件原生支持）。\nINT8：8 位整数。注意它是整数不是浮点，主要用于推理阶段的“量化”，进一步压缩模型、提速。\n计算场景相关 HPC：High Performance Computing，高性能计算，指传统超算领域（科学仿真、流体力学、基因测序等），通常吃 FP64 双精度。和 AI 算力是两套不同的需求。\nAI 训练：让模型从数据中学习、更新参数的过程，计算量极大，对精度有一定要求（主流 BF16/FP16）。\nAI 推理：模型训练好之后，拿来实际回答问题/做预测的过程。计算量比训练小，可以用更低精度（FP8/INT8）来提速降本。\n量化（Quantization）：把模型里原本用高精度（如 FP16）存的权重，转换成低精度（如 INT8、INT4）的过程。好处是模型变小、跑得快、省显存；代价是可能损失一点精度。\n性能衡量相关 峰值算力 / Peak：硬件在理论最理想情况下的算力上限，是厂商宣传时标的数字。现实中几乎不可能持续达到。\n实测算力：实际跑任务时真正发挥出来的算力，受各种瓶颈拖累，通常远低于峰值。\n显存带宽：GPU 显存和计算核心之间搬运数据的速度。很多时候算力核心没“吃饱”不是因为算得慢，而是数据喂不过来（带宽不够），这叫“内存墙”。\nMFU：Model FLOPs Utilization，模型算力利用率。= 实际有效算力 ÷ 理论峰值算力。大模型训练能做到 30%–50% 就算不错了，意味着标称“1P”的卡，实际有效可能只有 0.3–0.5P。\n稀疏 / Sparsity：让矩阵里一部分数值为 0，硬件跳过这些 0 不计算，从而“翻倍”算力。厂商标算力时如果带“稀疏”条件，数字会比实际稠密计算高一倍，看的时候要留意是不是“开稀疏”的数。\n硬件/集群相关 H100：NVIDIA 的高端 AI 训练/推理 GPU（Hopper 架构），目前主流大模型训练的主力卡之一，FP16 峰值在 1P 量级。\n智算中心 / 智算集群：专门为 AI 计算（而非传统超算）建设的大规模算力基础设施，把成百上千张 AI 卡用高速网络连起来，对外报的“百P”“千P”是所有卡峰值算力的总和。\nFP64/FP32/TF32/FP16/BF16/INT8/INT4间的差距 “1P算力”在不同精度下不是同一张卡的固定值，而是同一颗芯片在不同精度下的吞吐能力本就不同。 现代 GPU 的张量核心大致遵循“精度每减半，算力翻倍”的规律。\n以 NVIDIA H100 SXM5 为例（最权威、也最有代表性），取 稠密（dense，不开稀疏） 的官方白皮书数据，并以 FP16/BF16 = 1P 为基准做横向比较：\n精度 H100 稠密峰值 相对 FP16 倍率 单位/性质 FP64 60 TFLOPS 1/16 ≈ 0.06P 双精度，科学计算 FP32 60 TFLOPS 1/16 ≈ 0.06P 单精度 TF32 500 TFLOPS 1/2 = 0.5P 张量核心专用格式 FP16 1000 TFLOPS 1P（基准） 半精度，AI训练主力 BF16 1000 TFLOPS 1P（基准） 半精度，训练更稳 FP8 2000 TFLOPS 2P 低精度训练/推理 INT8 2000 TOPS 2P 整数，推理量化 INT4 H100 不支持 （≈4P） 见下方说明 由表格知：\n从高精度往低走，基本是一条“翻倍阶梯”：FP64 → FP32 → TF32 → FP16/BF16 → FP8/INT8 → FP4/INT4，每跨一档约 ×2。所以同一张卡，FP16 的 1P 到了 INT8 就是约 2P，而到了 FP64 只剩约 1/16。\n同一张“1P（FP16）”的卡，大致是 FP64≈0.06P、TF32≈0.5P、INT8≈2P；但 FP64 这一档极度依赖具体芯片，国产卡和消费级卡往往远低于这个比例。\n适用场景 格式 位宽 类型 精度 速度 显存占用 训练 推理 典型评价 FP64 64 浮点 最高 慢 最大 少量特殊场景 很少 科研级 FP32 32 浮点 高 中等 大 传统标准 可用但贵 稳但贵 TF32 约19 浮点变体 中高 快 类似 FP32 输入 NVIDIA 训练加速 少用 训练加速折中 FP16 16 浮点 中 很快 小 可用但需技巧 常用 快但易不稳 BF16 16 浮点 中 很快 小 大模型常用 常用 稳定性好 INT8 8 整数 较低 很快 很小 基本不用 常用 推理部署主力 INT4 4 整数 更低 很快/省显存 极小 不用于常规训练 本地推理常用 省显存但损质量 不同算力卡比较 芯片 厂商 FP16/BF16 折算P （H100=1P） INT8 显存 带宽 状态 H100 SXM5 NVIDIA ~1000 T 1P（基准） 2000 TOPS 80G HBM3 3.35 TB/s 禁售 H20（特供） NVIDIA ~148 T 0.15P — 96G HBM3 4.0 TB/s 可买 昇腾 910C 华为 ~752–800 T ~0.8P ~1504 TOPS 128G 3.2 TB/s 量产旗舰 BR100 壁仞 ~1024 T ~1P 2048 TOPS 64G HBM2e 2.3 TB/s 受制裁难量产 昇腾 910B 华为 ~320–376 T ~0.35P ~640 TOPS 64G HBM2e 0.4–1.2 TB/s 量产主力 BW100/深算 海光 ~300+ T ~0.3P — — — 量产 思元 590 寒武纪 ~256–300 T ~0.26P — 64G — 量产（约A100七成） 曦云 C500/C550 沐曦 ~240 T ~0.24P — 64G — 量产 天垓 150 天数智芯 ~224 T ~0.22P — — — 量产 P800 昆仑芯 ~128–345 T* ~0.13–0.35P ~256 TOPS 96G HBM3 — 量产，出货量大 MTT S5000 摩尔线程 ~A100级 ~0.3P — 64G — 万卡部署 A100（老旗舰参照） NVIDIA 312 T 0.31P 624 TOPS 80G 2.0 TB/s 禁售 H100 禁售，所以现实里真正要比的对象其实是英伟达 H20（被大幅阉割，FP16 只有约 148 TFLOPS）。上图以**完整版 H100（FP16 稠密 ≈ 1000 TFLOPS = 1P）**作为“1P 基准”来归一化。\n*：P800 各来源数字打架严重：一处说峰值 256 TOPS@INT8、128 TFLOPS@FP16，但行业全景图把它归到“接近 A100（312T）梯度”。P800 部署的话以官方规格书为准。\n纸面 FP16 差距没有想象中大， 昇腾 910C 纸面约 0.8P，壁仞 BR100 甚至约 1P，看起来很接近 H100。但 BR100 因制裁基本量产不了；真正能规模出货的旗舰是 910C，910C 的纸面算力是 H20 的 5 倍以上。\nFP8 支持：H100 原生 FP8（2P），是大模型训练/推理提速的关键。多数国产卡（910B/C、思元 590、C500 这代）主打 FP16/INT8,FP8 支持弱或没有。华为要到下一代昇腾 950 系列才在 FP8 下达到 1 PFLOPS、FP4 下 2 PFLOPS，这才追上 H100 的低精度路线。\n互联/组网：H100 的 NVLink 900 GB/s。国产芯片互联能力普遍较弱，除华为外带宽普遍在 400 GB/s 以下。这直接决定能不能高效堆千卡、万卡——单卡再强，组不起大集群也白搭。华为靠 CloudMatrix 超节点是唯一例外。\n软件生态：H100 = CUDA，生态成熟。国产卡各搞各的（华为 CANN、昆仑飞桨、寒武纪 BANG…），迁移和调优成本高，实际利用率（MFU）往往明显低于英伟达。\n实测 ≠ 峰值：这些都是峰值。考虑到生态不成熟，国产卡的有效 MFU 通常比 H100 低，所以“0.8P 纸面”落到实际任务可能只剩 0.4–0.5P 的体感。\n910C 的 128GB、P800 的 96GB HBM3，都超过 H100 的 80GB。百度昆仑芯三代 P800 拥有 96GB HBM3 显存。对跑大模型来说，显存大意味着单卡能塞下更大的模型，这是国产卡的一个实打实优势点。\n数据来源：\nhttps://www.cnblogs.com/wujianming-110117/p/18939581 https://blog.csdn.net/Rong_Toa/article/details/151322568 https://blog.csdn.net/Peter_Changyb/article/details/151934401 https://zhuanlan.zhihu.com/p/1908027882829244313 https://www.cnblogs.com/wujianming-110117/p/19101958 按“1P = 完整 H100 FP16”算，国产第一梯队（910C ≈0.8P、BR100 ≈1P）纸面已经接近H100，第二梯队（思元590/曦云C500/天垓150/P800）在 0.2–0.35P 即“A100 量级”。但真正拉开差距的是 FP8、互联、生态三项，而不是 FP16 峰值数字——再加上 H100 中国禁售这个前提，当下的现实定位是“全面超过可买到的 H20、对标被禁的 A100、向 H100 靠近”。\n","permalink":"https://blog.onecai.site/2026/06/10/008-about1p/","summary":"\u003cp\u003e常说的拥有某数据中心拥有“**P算力”，这里面的算力是什么呢？\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"suanli.avif\"\n         alt=\"什么是“1P”算力\"/\u003e \u003cfigcaption\u003e\n            什么是“1P”算力\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e网络上搜索一些内容，整理如下：\u003c/p\u003e\n\u003cp\u003e“1P算力”里的 \u003cstrong\u003eP\u003c/strong\u003e 是数量级前缀 \u003cstrong\u003ePeta（10¹⁵，千万亿）\u003c/strong\u003e，所以“1P算力”通常指 \u003cstrong\u003e1 PFLOPS\u003c/strong\u003e，即每秒 1×10¹⁵ 次浮点运算（1000万亿次/秒）。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. 单位是 FLOPS，不是 FLOP\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e算力的常用单位是 FLOPS（每秒浮点运算次数），是个速率。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1P = 1000T（TFLOPS）= 100万G（GFLOPS）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e所以业内说的“1P卡”、“100P集群”基本都是指 PFLOPS 规模。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. 必须看精度，否则数字没意义\u003c/strong\u003e。 同一张卡在不同精度下算力差好几倍，\u003cstrong\u003e“1P算力”本身是不完整的说法\u003c/strong\u003e。完整的应该是包含FP64、FP32、TF32、FP16、BF16、INT8，还是 INT4？\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e本篇内容以“1P”的说法为入口，了解了解这方面的基础知识。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"相关概念\"\u003e相关概念：\u003c/h2\u003e\n\u003cp\u003e以一个实例开始：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e一张 NVIDIA H100，FP16/BF16 峰值约 1 PFLOPS 量级（开稀疏更高），所以“1P”差不多就是“约一张高端 AI 卡”的体量。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e“百P算力中心”“千P智算集群”这类说法，就是把成百上千张这种卡堆在一起的总峰值。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e算力单位相关\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003eFLOPS\u003c/strong\u003e：全称 Floating Point Operations Per Second，即“每秒浮点运算次数”，是衡量算力的速率单位。注意结尾的 S 是 Second（秒），不是复数。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFLOP\u003c/strong\u003e：去掉 S，指“一次浮点运算”本身，是个数量而非速率。训练一个模型“总共要算多少次”用 FLOP（或 FLOPs，小写 s 表示复数次数），“每秒能算多少次”用 FLOPS。两者常被混用，但严格意义不同。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e浮点运算\u003c/strong\u003e：对带小数的数字（浮点数）做的加减乘除等运算。之所以强调“浮点”，是因为它和整数运算的硬件实现、速度都不同，神经网络里大量是浮点计算。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePeta / P\u003c/strong\u003e：国际单位制的数量级前缀，10¹⁵（千万亿）。同系列还有 G（Giga，10⁹/十亿）、T（Tera，10¹²/万亿）、E（Exa，10¹⁸/百亿亿）。换算：1P = 1000T = 100万G。现在最顶级的超算到了 E 级（ExaFLOPS）。\u003c/p\u003e\n\u003col start=\"2\"\u003e\n\u003cli\u003e\u003cstrong\u003e精度相关\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e精度\u003c/strong\u003e：指一个数字用多少位（bit）来表示。位数越多，能表示的数值范围越大、越精确，但占的存储和计算资源也越多。AI 领域为了提速和省显存，倾向用更低的精度。\u003c/p\u003e","title":"理解什么是“1P”算力"},{"content":"最近在用 yuque-exporter 把语雀的内容批量导出为本地 Markdown，用来导入到自己的笔记系统。工具本身很好用，但在实际跑的过程中遇到了几个会导致直接崩溃的问题，顺手修了一下，记录在这里。\n修复后的版本在：github.com/onecaicai/yuque-exporter\nBug 1：首次运行直接崩溃 现象 第一次在一台新机器上运行，没有任何历史数据，程序直接报错退出，提示找不到文件。\n原因 crawler.ts 中用 fast-glob 去查找已有的 docs-published-at.json：\n1 2 const docsPublishedAtPath = await fg(\u0026#39;**/docs-published-at.json\u0026#39;, { cwd: metaDir, deep: 3 }); const docsPublishedAtMap = await readJSON(path.join(metaDir, docsPublishedAtPath[0])); 首次运行时这个文件根本不存在，docsPublishedAtPath[0] 是 undefined，readJSON 直接抛出异常。\n修复 改为直接构造文件路径，用 try/catch 处理文件不存在的情况，初始化为空对象：\n1 2 3 4 5 6 7 const docsPublishedAtPath = path.join(metaDir, namespace, \u0026#39;docs-published-at.json\u0026#39;); let docsPublishedAtMap: Record\u0026lt;number, string\u0026gt; = {}; try { docsPublishedAtMap = await readJSON(docsPublishedAtPath); } catch { // first crawl for this repo } 同样的问题在 doc.ts 里也存在，原来是在模块顶层直接 await 读文件（ES module 顶层 await），改为懒加载函数，第一次调用时才读：\n1 2 3 4 5 6 async function loadDocsPublishedAtMap() { if (docsPublishedAtMap) return docsPublishedAtMap; const docsPublishedAtPath = await fg(\u0026#39;**/docs-published-at.json\u0026#39;, { cwd: metaDir, deep: 3 }); docsPublishedAtMap = await readJSON(path.join(metaDir, docsPublishedAtPath[0])); return docsPublishedAtMap; } Bug 2：本地 doc 文件缺失时不重新爬取 现象 增量更新逻辑只判断 published_at 是否变化，如果手动删除了某个文档的本地 JSON 缓存，重新运行时这个文档会被跳过，导出目录里缺少对应的 Markdown 文件。\n原因 crawler.ts 的过滤逻辑：\n1 2 3 const docChangedList = docList .filter(doc =\u0026gt; typeof docsPublishedAtMap[doc.id] === \u0026#39;undefined\u0026#39; || docsPublishedAtMap[doc.id] !== doc.published_at); 只看 published_at 有没有变，不管本地文件是否真的存在。\ndoc.ts 在构建阶段也没有做文件存在性校验，直接 readJSON 会崩溃。\n修复 爬取阶段增加本地文件存在性检查，文件缺失也纳入需要重新爬取的范围：\n1 2 3 4 const docMissing = !(await exists(path.join(metaDir, namespace, \u0026#39;docs\u0026#39;, `${doc.slug}.json`))); if (publishedChanged || docMissing) { docChangedList.push(doc); } 构建阶段在读取前先判断文件是否存在，缺失时打印警告跳过，而不是崩溃：\n1 2 3 4 if (!(await exists(docMetaPath))) { console.warn(`[WARN] skip missing doc: ${doc.namespace}/${doc.url}`); return null; } Bug 3：redirect location 为数组时处理出错 现象 部分语雀分享链接在获取重定向地址时，返回结果错误，生成的 Markdown 链接无法正常访问。\n原因 utils.ts 中处理 HTTP 重定向：\n1 2 3 4 const redirectLink = headers.location; if (!redirectLink) return url; if (redirectLink[0] === \u0026#39;/\u0026#39;) return `${host}${redirectLink}`; return redirectLink; HTTP 协议里 headers.location 的值可能是数组（undici 返回的类型是 string | string[]），当它是数组时，redirectLink[0] 取到的是字符串的第一个字符而不是数组的第一个元素，判断逻辑完全错误。\n修复 1 2 3 const location = Array.isArray(redirectLink) ? redirectLink[0] : redirectLink; if (location[0] === \u0026#39;/\u0026#39;) return `${host}${location}`; return location; 小结 三个 bug 都是边界情况，原作者可能在自己的环境下没有触发，项目也已经有两年多没有维护了。修复内容已经提交 PR：atian25/yuque-exporter#40。\n如果你也在用这个工具导出语雀文档，可以直接用我 fork 后修复的版本：\n1 2 3 4 git clone https://github.com/onecaicai/yuque-exporter.git cd yuque-exporter npm install npx yuque-exporter --token=\u0026lt;your token\u0026gt; ","permalink":"https://blog.onecai.site/2026/05/28/yuque-exporter-bugfix/","summary":"语雀文档批量导出工具 yuque-exporter 在首次运行、本地文件缺失、redirect 处理等场景下存在崩溃问题，记录定位和修复过程。","title":"修复 yuque-exporter 的三个 bug"},{"content":"讯飞录音笔云端数据本地备份 讯飞录音笔录音本身在云端，转写、AI 总结、思维导图也都在网页端能看到，但真到需要长期整理时，只靠网页端不太方便：文件分散，账号切换容易混，后续要搜索、归档、再加工也不顺手。\niflytekRecordDownload 就是为这个场景写的一个小工具。它从讯飞录音笔网页端读取云端录音列表，把录音音频、转写文本、AI 总结和思维导图同步到本地。同步后的文件按账号、日期和录音时间组织，适合长期备份。\n它解决什么问题 这个工具主要做几件事：\n下载每条录音对应的 WAV 音频。 导出转写文本为 Markdown。 同步云端生成的 AI 总结和思维导图。 按不同讯飞账号分目录保存。 按录音当天日期建文件夹，同一天多条录音再按时分秒区分。 自动生成当天的转写合并文档，方便快速回看。 最后得到的目录大概是这样：\n1 2 3 4 5 6 7 8 ~/录音笔同步/工作账号/ 2026年05月14日/ 17时26分49秒.wav 17时26分49秒.md 17时26分49秒_AI总结.md 17时26分49秒_思维导图.md 17时26分49秒_raw.json 2026年05月14日_转写合并.md 这个结构的好处是后续处理很简单。音频、转写、总结和思维导图都在同一个时间点下面，不需要再从一堆文件里猜谁和谁对应。\n实现思路 讯飞录音笔网页端本身会调用接口读取录音列表和详情。工具没有绕过登录流程，而是让用户先在浏览器里正常登录，然后从开发者工具里复制一次 Copy as cURL。脚本会从这段 cURL 里解析出 X-Session 和 X-User-Id，再用同样的登录态去访问云端接口。\n为了减少手动维护，脚本会动态生成请求签名，也会在同步前校验当前云端账号。如果配置里是 A 账号，但浏览器复制出来的会话实际对应 B 账号，脚本会停止同步，避免把不同账号的录音混到一起。\n同步过程是增量的。已经下载过的录音会跳过；如果后面云端才生成 AI 总结或思维导图，再次运行时也会补齐这些文件。\n使用方式 第一次运行：\n1 ./sync.sh --setup 脚本会打开讯飞录音笔网页端。登录后，在浏览器 Network 面板里找到 api.iflyjz.com 请求，右键选择 Copy as cURL，把整段内容粘贴回终端。\n之后日常同步只需要：\n1 ./sync.sh macOS 上也可以安装每天自动备份：\n1 ./install-daily-sync.sh 默认是每天 02:00 运行，也可以指定时间：\n1 ./install-daily-sync.sh 23 30 安全边界 这个项目会处理登录态，所以最重要的是不要把真实配置提交到公开仓库。仓库里只保留了 files/iflytek_config.example.json，真实配置文件 files/iflytek_config.json 已经放进 .gitignore。\n同样不应该提交的还有完整 Copy as cURL、录音文件、转写文本、接口返回 JSON、音频下载 URL 和飞书 Webhook。项目里也保留了一些检查逻辑，尽量避免误把旧账号的数据同步到新账号目录里。\n项目地址 GitHub 仓库：\nhttps://github.com/onecaicai/iflytekRecordDownload\n如果你也有长期备份讯飞录音笔云端内容的需求，可以直接从 README 的快速开始部分配置。这个工具没有复杂的后台服务，也不需要数据库，核心目标就是把云端数据稳定、清楚地落到本地文件系统里。\n","permalink":"https://blog.onecai.site/2026/05/15/iflytekrecorddownload/","summary":"\u003ch1 id=\"讯飞录音笔云端数据本地备份\"\u003e讯飞录音笔云端数据本地备份\u003c/h1\u003e\n\u003cp\u003e讯飞录音笔录音本身在云端，转写、AI 总结、思维导图也都在网页端能看到，但真到需要长期整理时，只靠网页端不太方便：文件分散，账号切换容易混，后续要搜索、归档、再加工也不顺手。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eiflytekRecordDownload\u003c/code\u003e 就是为这个场景写的一个小工具。它从讯飞录音笔网页端读取云端录音列表，把录音音频、转写文本、AI 总结和思维导图同步到本地。同步后的文件按账号、日期和录音时间组织，适合长期备份。\u003c/p\u003e\n\u003ch2 id=\"它解决什么问题\"\u003e它解决什么问题\u003c/h2\u003e\n\u003cp\u003e这个工具主要做几件事：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e下载每条录音对应的 WAV 音频。\u003c/li\u003e\n\u003cli\u003e导出转写文本为 Markdown。\u003c/li\u003e\n\u003cli\u003e同步云端生成的 AI 总结和思维导图。\u003c/li\u003e\n\u003cli\u003e按不同讯飞账号分目录保存。\u003c/li\u003e\n\u003cli\u003e按录音当天日期建文件夹，同一天多条录音再按时分秒区分。\u003c/li\u003e\n\u003cli\u003e自动生成当天的转写合并文档，方便快速回看。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e最后得到的目录大概是这样：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e2\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e3\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e4\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e5\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e6\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e7\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e8\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e~/录音笔同步/工作账号/\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  2026年05月14日/\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    17时26分49秒.wav\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    17时26分49秒.md\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    17时26分49秒_AI总结.md\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    17时26分49秒_思维导图.md\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    17时26分49秒_raw.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    2026年05月14日_转写合并.md\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e这个结构的好处是后续处理很简单。音频、转写、总结和思维导图都在同一个时间点下面，不需要再从一堆文件里猜谁和谁对应。\u003c/p\u003e\n\u003ch2 id=\"实现思路\"\u003e实现思路\u003c/h2\u003e\n\u003cp\u003e讯飞录音笔网页端本身会调用接口读取录音列表和详情。工具没有绕过登录流程，而是让用户先在浏览器里正常登录，然后从开发者工具里复制一次 \u003ccode\u003eCopy as cURL\u003c/code\u003e。脚本会从这段 cURL 里解析出 \u003ccode\u003eX-Session\u003c/code\u003e 和 \u003ccode\u003eX-User-Id\u003c/code\u003e，再用同样的登录态去访问云端接口。\u003c/p\u003e","title":"讯飞录音笔云端数据本地备份"},{"content":"把钉钉DingTalk A1音频导出到本地 做了一个小工具：把钉钉DingTalk录制的 AI 听记完整下载到本地。\n钉钉DingTalk是一款很好的个人效率工具，硬件端录制的音频由钉钉通过通义千问Qwen3-235B、DeepSeek-V3-671B满血版大模型 AI纪要总结，除了录音，还有转写、AI 纪要、笔记、章节、分析、关键词、待办。但这些内容平时都散在钉钉app里，想备份、整理、二次处理都不太方便。所以做一个本地导出工具，一次性把这些东西都拉下来。\n项目基于这个开源仓库改的：\n1 https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli 原项目提供了一个叫 dws 的命令行工具，可以通过钉钉授权访问 AI 听记、文档、云盘、日程等能力，在这个项目基础上加了两个脚本：\n1 2 scripts/archive-all-minutes.sh scripts/download-all-minutes-audio.sh 第一个脚本负责完整归档，第二个脚本只下载音频。\n一开始只是想把录音下载下来。后来发现听记接口还能拿到更多内容，比如转写原文、AI 纪要、关键词、待办、思维导图状态等，于是就把脚本扩成了完整归档。\nDingTalkExport 现在运行：\n1 scripts/archive-all-minutes.sh 它会把内容下载到项目根目录下的 download/ 文件夹。每条听记一个目录，目录名用钉钉听记的创建时间，比如：\n1 download/20260507_65871790/ 目录里会有这些文件：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 audio.mp3 transcription.json transcription.tsv summary.json ai-summary.md notes.txt analysis.txt chapters.tsv keywords.json todos.json info.json mind-graph-status.json audio-url.json list-item.json 其中 audio.mp3 是录音，transcription.tsv 是整理过的转写文本，ai-summary.md 是 AI 纪要，notes.txt 和 analysis.txt 是从纪要里拆出来的笔记和分析内容。\n做这个工具时，有几个小坑。\n一个是钉钉返回的音频地址是临时 URL，所以脚本不能只保存 URL，必须立刻下载文件。\n另一个是命令行工具在管道里调用时会读标准输入，最开始批量处理时它把后面的 JSON 当成参数读进去了，导致只处理了一条。后来把脚本里的 dws 和 curl 都显式改成从 /dev/null 读输入，问题就解决了。\n还有一个细节是目录命名。最早用标题加 ID 命名，文件夹很长，也不方便排序。后来改成用创建时间，格式是：\n1 YYYYMMDD_HHMMSScc 这样文件夹天然按时间排列，也不会暴露太多标题信息。如果同一时间有多条听记，脚本会自动追加 _2、_3，避免覆盖。\n项目地址在这里：\n1 https://github.com/onecaicai/dingtalk-minutes-export 它主要解决一个很具体的问题：把钉钉里录制的 AI 听记，连同音频、转写、笔记、AI 纪要、章节和分析文字，一起下载到本地，方便备份和后续整理。\n","permalink":"https://blog.onecai.site/2026/05/08/007-exportdingtalkaudio/","summary":"\u003ch1 id=\"把钉钉dingtalk-a1音频导出到本地\"\u003e把钉钉DingTalk A1音频导出到本地\u003c/h1\u003e\n\u003cp\u003e做了一个小工具：把钉钉DingTalk录制的 AI 听记完整下载到本地。\u003c/p\u003e\n\u003cp\u003e钉钉DingTalk是一款很好的个人效率工具，硬件端录制的音频由钉钉通过通义千问Qwen3-235B、DeepSeek-V3-671B满血版大模型 AI纪要总结，除了录音，还有转写、AI 纪要、笔记、章节、分析、关键词、待办。但这些内容平时都散在钉钉app里，想备份、整理、二次处理都不太方便。所以做一个本地导出工具，一次性把这些东西都拉下来。\u003c/p\u003e\n\u003cp\u003e项目基于这个开源仓库改的：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehttps://github.com/DingTalk-Real-AI/dingtalk-workspace-cli\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e原项目提供了一个叫 \u003ccode\u003edws\u003c/code\u003e 的命令行工具，可以通过钉钉授权访问 AI 听记、文档、云盘、日程等能力，在这个项目基础上加了两个脚本：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e2\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003escripts/archive-all-minutes.sh\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003escripts/download-all-minutes-audio.sh\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e第一个脚本负责完整归档，第二个脚本只下载音频。\u003c/p\u003e\n\u003cp\u003e一开始只是想把录音下载下来。后来发现听记接口还能拿到更多内容，比如转写原文、AI 纪要、关键词、待办、思维导图状态等，于是就把脚本扩成了完整归档。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"dingtalk01.avif\"\n         alt=\"DingTalkExport\"/\u003e \u003cfigcaption\u003e\n            DingTalkExport\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e现在运行：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003escripts/archive-all-minutes.sh\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e它会把内容下载到项目根目录下的 \u003ccode\u003edownload/\u003c/code\u003e 文件夹。每条听记一个目录，目录名用钉钉听记的创建时间，比如：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e1\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003edownload/20260507_65871790/\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e目录里会有这些文件：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cdiv style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\n\u003ctable style=\"border-spacing:0;padding:0;margin:0;border:0;\"\u003e\u003ctr\u003e\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 1\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 2\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 3\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 4\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 5\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 6\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 7\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 8\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e 9\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e10\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e11\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e12\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e13\n\u003c/span\u003e\u003cspan style=\"white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#727272\"\u003e14\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\n\u003ctd style=\"vertical-align:top;padding:0;margin:0;border:0;;width:100%\"\u003e\n\u003cpre tabindex=\"0\" style=\"color:#e5e5e5;background-color:#000;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eaudio.mp3\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003etranscription.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003etranscription.tsv\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esummary.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eai-summary.md\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003enotes.txt\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eanalysis.txt\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003echapters.tsv\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ekeywords.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003etodos.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003einfo.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emind-graph-status.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eaudio-url.json\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003elist-item.json\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003c/div\u003e\u003cp\u003e其中 \u003ccode\u003eaudio.mp3\u003c/code\u003e 是录音，\u003ccode\u003etranscription.tsv\u003c/code\u003e 是整理过的转写文本，\u003ccode\u003eai-summary.md\u003c/code\u003e 是 AI 纪要，\u003ccode\u003enotes.txt\u003c/code\u003e 和 \u003ccode\u003eanalysis.txt\u003c/code\u003e 是从纪要里拆出来的笔记和分析内容。\u003c/p\u003e","title":"钉钉DingTalk音频导出到本地"},{"content":"用iOS快捷指令+备忘录做了一套免费、纯原生的闪念记录系统：桌面小组件一点，弹出输入框，语音输入转文字，自动追加进当天的备忘录。零成本，丝滑。\n一、系统逻辑 每天00:05，一条定时快捷指令自动在备忘录指定文件夹里创建以当日日期命名的笔记，比如「2026年04月25日记录」。\n有闪念时，点桌面小组件 → 弹出输入框 → 语音听写或键盘输入 → 点完成 → 文字自动追加到当天备忘录末尾。全程无需打开App，够快，够轻。\n旧版快捷指令逻辑如下图，查找条件只有一个：名称包含当前日期。\n旧版的快捷指令 二、升级之后翻车了 从iOS 26开始，这套流程开始抽风。\n症状很典型：语音输入完、文字转写好，到「追加」这一步时，突然弹出满屏备忘录列表——快捷指令找不到目标备忘录，文字追加失败，白说了。\n第一次出问题，重新创建一遍快捷指令就解决了。升级到iOS 26.4后问题又来，这次重建无效，而且时好时坏，完全没有规律。反复折腾了N次，准备掏钱买flomo了。\n三、马桶上找到了答案 早上蹲马桶刷手机，无意中发现快捷指令的「查找备忘录」模块里悄悄多了几个筛选选项——\n新系统中加入了文件夹选项 之前只能按名称查找，现在多了文件夹、标签、创建日期、上次修改日期。问题大概率出在这里：一千多条备忘录全局查找，可能存在超时，导致偶发性找不到目标。\n解决方案：查找范围限定到指定文件夹，同时增加创建日期条件（当日 00:05）。两个条件加上去，快捷指令稳了。\n修改后的快捷指令 免费方案续命成功，暂时不用给flomo交钱了。🫡\n","permalink":"https://blog.onecai.site/2026/04/25/006-shortcutagain/","summary":"\u003cp\u003e用iOS快捷指令+备忘录做了一套免费、纯原生的闪念记录系统：桌面小组件一点，弹出输入框，语音输入转文字，自动追加进当天的备忘录。零成本，丝滑。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一系统逻辑\"\u003e\u003cstrong\u003e一、系统逻辑\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e每天00:05，一条定时快捷指令自动在备忘录指定文件夹里创建以当日日期命名的笔记，比如「2026年04月25日记录」。\u003c/p\u003e\n\u003cp\u003e有闪念时，点桌面小组件 → 弹出输入框 → 语音听写或键盘输入 → 点完成 → 文字自动追加到当天备忘录末尾。全程无需打开App，够快，够轻。\u003c/p\u003e\n\u003cp\u003e旧版快捷指令逻辑如下图，查找条件只有一个：名称包含当前日期。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"Shortcut-01.avif\"\n         alt=\"旧版的快捷指令\"/\u003e \u003cfigcaption\u003e\n            旧版的快捷指令\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003ch2 id=\"二升级之后翻车了\"\u003e\u003cstrong\u003e二、升级之后翻车了\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e从iOS 26开始，这套流程开始抽风。\u003c/p\u003e\n\u003cp\u003e症状很典型：语音输入完、文字转写好，到「追加」这一步时，突然弹出满屏备忘录列表——快捷指令找不到目标备忘录，文字追加失败，白说了。\u003c/p\u003e\n\u003cp\u003e第一次出问题，重新创建一遍快捷指令就解决了。升级到iOS 26.4后问题又来，这次重建无效，而且时好时坏，完全没有规律。反复折腾了N次，准备掏钱买flomo了。\u003c/p\u003e\n\u003ch2 id=\"三马桶上找到了答案\"\u003e\u003cstrong\u003e三、马桶上找到了答案\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e早上蹲马桶刷手机，无意中发现快捷指令的「查找备忘录」模块里悄悄多了几个筛选选项——\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"Shortcut-02.avif\"\n         alt=\"新系统中加入了文件夹选项 \"/\u003e \u003cfigcaption\u003e\n            新系统中加入了文件夹选项 \n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e之前只能按名称查找，现在多了\u003cstrong\u003e文件夹、标签、创建日期、上次修改日期\u003c/strong\u003e。问题大概率出在这里：一千多条备忘录全局查找，可能存在超时，导致偶发性找不到目标。\u003c/p\u003e\n\u003cp\u003e解决方案：查找范围限定到指定文件夹，同时增加创建日期条件（当日 00:05）。两个条件加上去，快捷指令稳了。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"Shortcut-03.avif\"\n         alt=\"修改后的快捷指令\"/\u003e \u003cfigcaption\u003e\n            修改后的快捷指令\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003chr\u003e\n\u003cp\u003e免费方案续命成功，暂时不用给flomo交钱了。🫡\u003c/p\u003e","title":"解决快捷指令找不到备忘录的问题"},{"content":" 看完《追风筝的人》，这本书是很久以前买的，以至于在淘宝、京东、当当的购物记录中找不到确切的购买时间。\n《追风筝的人》 版次：2006年5月第1版 印次：2015年5月第85次印刷\n这本书作者是阿富汗裔美籍作家卡勒德胡赛尼，译者李继宏，讲述的2001年返回阿富汗去寻找自己同父异母侄子的事情，中间大篇幅穿插逃离阿富汗到美国之前的故事。\n一、人物关系图 手搓了一个人物关系图 做了一个人物关系图。\n二、故事时间线 1933年主人公父亲出生，5年前阿里出生。 1963年主人公阿米尔出生，母亲难产去世。普什图人。 1964年冬哈桑出生，不满七日母亲与一群江湖艺人跑了。哈扎拉人。 1973年阿富汗政变。 1974年，主人公父亲请医生给哈桑治疗兔唇。 1975年冬，最后一次看到哈桑追风筝，目睹了哈桑被阿塞夫伤害。哈桑和父亲阿里离开。 1979年俄国坦克在喀布尔大街上。 1981年3月，辗转逃离阿富汗，到达美国。 1983年，主人公阿米尔高中毕业，收到父亲送的二手车。童年秋天到专科学校上学。 1984年夏天，父子俩开始跳蚤市场生意，期间认识将军的女儿索拉雅，主人公的妻子。父亲肺癌出院后给儿子去提亲，婚后一个月父亲去世。 1985年，州立大学主修英文，家具仓库保安工作；妻子索拉雅同校主修教育。 1988年，俄国撤军。 1989年，主人公第一部关于父与子的书籍出版。没有自己的孩子，搬家与岳父母拉开距离。 2001年6月，应拉辛汗要求回阿富汗找回哈桑的儿子索拉博，被告知哈桑是同父异母的弟弟。拉辛汗告知的事情： 1984年，阿里被地雷炸死。 1986年，哈桑放弃已有自己的生活，返回帮忙照看主人公家原来的豪宅。 1990年，哈桑母亲莎娜芭年老回来，哈桑照顾母亲康复。哈桑儿子索拉博出生。 1994年，哈桑母亲莎娜芭去世。 1995年，内战开始。 1996年，塔利班掌权。 1998年，哈桑抗议塔利班官员占领主人的豪宅，夫妻双双被枪杀。 寻找侄子索拉博最后一关，与阿塞夫1V1 PK，侄子用其父亲哈桑教授的弹弓救了主人公。 解决拯救侄子带回美国认养的难题，侄子害怕再次被迫害，在酒店浴室割腕自杀，抢救回生命。 2001年8月，带侄子回到美国家中，帮助侄子恢复正常生活，最后在放风筝的尝试中看到了孩子的微笑。 三、勾画了些句子 爸爸说：“不过首先，你得知道一件事情，阿米尔，那些白痴大胡子不会教给你任何有价值的东西”。 爸爸双眼坚定地看着我的眼睛，仅仅这样，我就止住了笑声。 在我生命的大部分时光，我对爸爸敬若神明。可是那一刻，我恨不得能扯开自己的血管，让他那些该死的血统统流出我的身体。 哈桑在哭，阿里将他抱紧，轻轻地抚摸着他。后来我告诉自己，我没有嫉妒哈桑，一点都没有。 我希望自己身上也有类似的残疾，可以乞换来爸爸的怜悯。 看到爸爸眼里的光芒消失了，接着是一阵令人不适的沉默。 当他站起身来，我从他松弛的肩膀看出，我与生俱来的那种熟悉的生活已经一去不返了。 对我来说，美国是个埋葬往事的地方。对爸爸来说，这是个哀悼过去的地方。 如今，美国是爸爸送给阿米尔的最后一件礼物。 生活已然在前进，留下爸爸在后面。 我的理由是：也许在某个地方，有某个人，因为某件事，决定剥夺我为人父的权利，以报复我曾经的所作所为。 也是在这片土地上，我曾为了得到父亲的爱苦苦奋斗。 几乎见不到有任何成年男子在他们身边——战争把父亲变成阿富汗的稀缺物品。 重返喀布尔，犹如去拜访一个多年未遇的老朋友，却发现他潦倒凄戚，发现他无家可归、身无分文。 他们试图抬起她，她又叫又踢。只要我还有一口气在，就永远不会忘记那声惨叫。 四、关于剧情 故事情节从开篇一直到2001年6月之前，感觉都是在真实的阿富汗实景，到了主人公与阿塞夫1V1 PK的这一段，就和典型的美国式影视剧的发展一样一样的了——两个人PK的关键节点，站在旁边的小孩索拉博使出绝招——弹弓，来帮助主人公取得胜利，这一下就跳出书中情节，回过神来这就是个剧。\n","permalink":"https://blog.onecai.site/2026/01/04/005-book-thekiterunner/","summary":"\u003cblockquote\u003e\n\u003cp\u003e看完《追风筝的人》，这本书是很久以前买的，以至于在淘宝、京东、当当的购物记录中找不到确切的购买时间。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"TheKiteRunner-01.avif\"\n         alt=\"《追风筝的人》\"/\u003e \u003cfigcaption\u003e\n            《追风筝的人》\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e版次：2006年5月第1版\n印次：2015年5月第85次印刷\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这本书作者是阿富汗裔美籍作家卡勒德胡赛尼，译者李继宏，讲述的2001年返回阿富汗去寻找自己同父异母侄子的事情，中间大篇幅穿插逃离阿富汗到美国之前的故事。\u003c/p\u003e\n\u003ch2 id=\"一人物关系图\"\u003e一、人物关系图\u003c/h2\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"TheKiteRunner-02.avif\"\n         alt=\"手搓了一个人物关系图\"/\u003e \u003cfigcaption\u003e\n            手搓了一个人物关系图\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e做了一个人物关系图。\u003c/p\u003e\n\u003ch2 id=\"二故事时间线\"\u003e二、故事时间线\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e1933年主人公父亲出生，5年前阿里出生。\u003c/li\u003e\n\u003cli\u003e1963年主人公阿米尔出生，母亲难产去世。普什图人。\u003c/li\u003e\n\u003cli\u003e1964年冬哈桑出生，不满七日母亲与一群江湖艺人跑了。哈扎拉人。\u003c/li\u003e\n\u003cli\u003e1973年阿富汗政变。\u003c/li\u003e\n\u003cli\u003e1974年，主人公父亲请医生给哈桑治疗兔唇。\u003c/li\u003e\n\u003cli\u003e1975年冬，最后一次看到哈桑追风筝，目睹了哈桑被阿塞夫伤害。哈桑和父亲阿里离开。\u003c/li\u003e\n\u003cli\u003e1979年俄国坦克在喀布尔大街上。\u003c/li\u003e\n\u003cli\u003e1981年3月，辗转逃离阿富汗，到达美国。\u003c/li\u003e\n\u003cli\u003e1983年，主人公阿米尔高中毕业，收到父亲送的二手车。童年秋天到专科学校上学。\u003c/li\u003e\n\u003cli\u003e1984年夏天，父子俩开始跳蚤市场生意，期间认识将军的女儿索拉雅，主人公的妻子。父亲肺癌出院后给儿子去提亲，婚后一个月父亲去世。\u003c/li\u003e\n\u003cli\u003e1985年，州立大学主修英文，家具仓库保安工作；妻子索拉雅同校主修教育。\u003c/li\u003e\n\u003cli\u003e1988年，俄国撤军。\u003c/li\u003e\n\u003cli\u003e1989年，主人公第一部关于父与子的书籍出版。没有自己的孩子，搬家与岳父母拉开距离。\u003c/li\u003e\n\u003cli\u003e2001年6月，应拉辛汗要求回阿富汗找回哈桑的儿子索拉博，被告知哈桑是同父异母的弟弟。拉辛汗告知的事情：\n\u003cul\u003e\n\u003cli\u003e1984年，阿里被地雷炸死。\u003c/li\u003e\n\u003cli\u003e1986年，哈桑放弃已有自己的生活，返回帮忙照看主人公家原来的豪宅。\u003c/li\u003e\n\u003cli\u003e1990年，哈桑母亲莎娜芭年老回来，哈桑照顾母亲康复。哈桑儿子索拉博出生。\u003c/li\u003e\n\u003cli\u003e1994年，哈桑母亲莎娜芭去世。\u003c/li\u003e\n\u003cli\u003e1995年，内战开始。\u003c/li\u003e\n\u003cli\u003e1996年，塔利班掌权。\u003c/li\u003e\n\u003cli\u003e1998年，哈桑抗议塔利班官员占领主人的豪宅，夫妻双双被枪杀。\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e寻找侄子索拉博最后一关，与阿塞夫1V1 PK，侄子用其父亲哈桑教授的弹弓救了主人公。\u003c/li\u003e\n\u003cli\u003e解决拯救侄子带回美国认养的难题，侄子害怕再次被迫害，在酒店浴室割腕自杀，抢救回生命。\u003c/li\u003e\n\u003cli\u003e2001年8月，带侄子回到美国家中，帮助侄子恢复正常生活，最后在放风筝的尝试中看到了孩子的微笑。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"三勾画了些句子\"\u003e三、勾画了些句子\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e爸爸说：“不过首先，你得知道一件事情，阿米尔，那些白痴大胡子不会教给你任何有价值的东西”。\u003c/li\u003e\n\u003cli\u003e爸爸双眼坚定地看着我的眼睛，仅仅这样，我就止住了笑声。\u003c/li\u003e\n\u003cli\u003e在我生命的大部分时光，我对爸爸敬若神明。可是那一刻，我恨不得能扯开自己的血管，让他那些该死的血统统流出我的身体。\u003c/li\u003e\n\u003cli\u003e哈桑在哭，阿里将他抱紧，轻轻地抚摸着他。后来我告诉自己，我没有嫉妒哈桑，一点都没有。\u003c/li\u003e\n\u003cli\u003e我希望自己身上也有类似的残疾，可以乞换来爸爸的怜悯。\u003c/li\u003e\n\u003cli\u003e看到爸爸眼里的光芒消失了，接着是一阵令人不适的沉默。\u003c/li\u003e\n\u003cli\u003e当他站起身来，我从他松弛的肩膀看出，我与生俱来的那种熟悉的生活已经一去不返了。\u003c/li\u003e\n\u003cli\u003e对我来说，美国是个埋葬往事的地方。对爸爸来说，这是个哀悼过去的地方。\u003c/li\u003e\n\u003cli\u003e如今，美国是爸爸送给阿米尔的最后一件礼物。\u003c/li\u003e\n\u003cli\u003e生活已然在前进，留下爸爸在后面。\u003c/li\u003e\n\u003cli\u003e我的理由是：也许在某个地方，有某个人，因为某件事，决定剥夺我为人父的权利，以报复我曾经的所作所为。\u003c/li\u003e\n\u003cli\u003e也是在这片土地上，我曾为了得到父亲的爱苦苦奋斗。\u003c/li\u003e\n\u003cli\u003e几乎见不到有任何成年男子在他们身边——战争把父亲变成阿富汗的稀缺物品。\u003c/li\u003e\n\u003cli\u003e重返喀布尔，犹如去拜访一个多年未遇的老朋友，却发现他潦倒凄戚，发现他无家可归、身无分文。\u003c/li\u003e\n\u003cli\u003e他们试图抬起她，她又叫又踢。只要我还有一口气在，就永远不会忘记那声惨叫。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"四关于剧情\"\u003e四、关于剧情\u003c/h2\u003e\n\u003cp\u003e故事情节从开篇一直到2001年6月之前，感觉都是在真实的阿富汗实景，到了主人公与阿塞夫1V1 PK的这一段，就和典型的美国式影视剧的发展一样一样的了——两个人PK的关键节点，站在旁边的小孩索拉博使出绝招——弹弓，来帮助主人公取得胜利，这一下就跳出书中情节，回过神来这就是个剧。\u003c/p\u003e","title":"读了《追风筝的人》"},{"content":" 刘震云《咸的玩笑》。 赶在2025年结束前的几天读了刘震云的《咸的玩笑》——今年的第一本纸质书，读过这个作者的上本书是《一句顶一万句》。\n大家都辛苦了 世界各地，不同的街道上，\n街上走着的每个人，内心都有伤痕。\n大家都辛苦了。\n结构挺有意思\n从目录来看在正文一和正文二中间是三十三章的题外话。刚开始看正文一中说到名叫长顺的和尚智明，和《天之下》的明不详有些联想，以为这本书就是写这个和尚的，结果正文一接着的题外话第一章就不是这个和尚了，而是写名叫杜有财的杜太白的故事。\n题外话结束后接着的正文二，回到现实中，和《大话西游》最后的结尾有点像，小说中杜太白给孩子们起的悉尼、巴黎、开普敦的名字在泰安听到了。\n书中有意思的句子\n智明：跟出家人说家，让我无言以对啊。 智明：不让结婚，就不能生孩子；百年之后，人不就没了？不让杀生，百年之后，不成动物的世界了？那时你们将佛法传给谁呢？传给猪马牛羊吗？ 杜太白之道，往事就这么过去了，但往事并不如烟。 家庭的悲剧，是一家人的软弱，和一个人的无耻造成的。 正因为大家是贩夫走卒、乌合之众，杜太白虽乌合，又不众，才显得鹤立鸡群。 你可以认真，也可以不认真；不认真的最好方式，最不费心的方式，就是跟着习惯认真。 无意识中有意识，也是杜太白去不了纽约、巴黎和伦敦，便让巴黎、纽约和伦敦来到了他的面前。 人们分歧再大，归结到钱上，很快就统一了。 货币，也是使世界分裂的重要原因。 又说“这话，倒是一句顶一万句呀”。 是谁出的题这么难，到处都是正确答案？ 猜的到的一个故事线\n在杜太白被网络讨伐时，裁缝铺的赤脚大仙发布的讨伐檄文那一段，猜测到是曹五车写的，就他俩还在学校工作的时候一起PK过古诗文。\n不太理解的一个地方\n在写到秦东峰跳锅炉那一段，文中写的是“老李示意门卫，让杜太白进去”，这地方应该是秦东峰进了厂子车间，怎么是杜太白进去了？？\n只是把这本书读完了，仅仅是读完了，更深的意味，按照书中说的“评毬不到”。\n——都是在延津，不知道杜太白听到罗长礼的声音了没有？\n","permalink":"https://blog.onecai.site/2025/12/30/004-read-the-salty-jokes/","summary":"\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"thesaltyjokes-02.avif\"\n         alt=\"刘震云《咸的玩笑》。\"/\u003e \u003cfigcaption\u003e\n            刘震云《咸的玩笑》。\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e赶在2025年结束前的几天读了刘震云的《咸的玩笑》——今年的第一本纸质书，读过这个作者的上本书是《一句顶一万句》。\u003c/p\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"thesaltyjokes-01.avif\"\n         alt=\"大家都辛苦了\"/\u003e \u003cfigcaption\u003e\n            大家都辛苦了\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cp\u003e世界各地，不同的街道上，\u003c/p\u003e\n\u003cp\u003e街上走着的每个人，内心都有伤痕。\u003c/p\u003e\n\u003cp\u003e大家都辛苦了。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e结构挺有意思\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e从目录来看在正文一和正文二中间是三十三章的题外话。刚开始看正文一中说到名叫长顺的和尚智明，和《天之下》的明不详有些联想，以为这本书就是写这个和尚的，结果正文一接着的题外话第一章就不是这个和尚了，而是写名叫杜有财的杜太白的故事。\u003c/p\u003e\n\u003cp\u003e题外话结束后接着的正文二，回到现实中，和《大话西游》最后的结尾有点像，小说中杜太白给孩子们起的悉尼、巴黎、开普敦的名字在泰安听到了。\u003c/p\u003e\n\u003chr\u003e\n\u003cblockquote\u003e\n\u003cp\u003e书中有意思的句子\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cul\u003e\n\u003cli\u003e智明：跟出家人说家，让我无言以对啊。\u003c/li\u003e\n\u003cli\u003e智明：不让结婚，就不能生孩子；百年之后，人不就没了？不让杀生，百年之后，不成动物的世界了？那时你们将佛法传给谁呢？传给猪马牛羊吗？\u003c/li\u003e\n\u003cli\u003e杜太白之道，往事就这么过去了，但往事并不如烟。\u003c/li\u003e\n\u003cli\u003e家庭的悲剧，是一家人的软弱，和一个人的无耻造成的。\u003c/li\u003e\n\u003cli\u003e正因为大家是贩夫走卒、乌合之众，杜太白虽乌合，又不众，才显得鹤立鸡群。\u003c/li\u003e\n\u003cli\u003e你可以认真，也可以不认真；不认真的最好方式，最不费心的方式，就是跟着习惯认真。\u003c/li\u003e\n\u003cli\u003e无意识中有意识，也是杜太白去不了纽约、巴黎和伦敦，便让巴黎、纽约和伦敦来到了他的面前。\u003c/li\u003e\n\u003cli\u003e人们分歧再大，归结到钱上，很快就统一了。\u003c/li\u003e\n\u003cli\u003e货币，也是使世界分裂的重要原因。\u003c/li\u003e\n\u003cli\u003e又说“这话，倒是一句顶一万句呀”。\u003c/li\u003e\n\u003cli\u003e是谁出的题这么难，到处都是正确答案？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003e猜的到的一个故事线\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e在杜太白被网络讨伐时，裁缝铺的赤脚大仙发布的讨伐檄文那一段，猜测到是曹五车写的，就他俩还在学校工作的时候一起PK过古诗文。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e不太理解的一个地方\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e在写到秦东峰跳锅炉那一段，文中写的是“老李示意门卫，让杜太白进去”，这地方应该是秦东峰进了厂子车间，怎么是杜太白进去了？？\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e只是把这本书读完了，仅仅是读完了，更深的意味，按照书中说的“评毬不到”。\u003c/p\u003e\n\u003cp\u003e——都是在延津，不知道杜太白听到罗长礼的声音了没有？\u003c/p\u003e","title":"读了刘震云的《咸的玩笑》"},{"content":"YouTube视频账号Lex Fridman发布了一个与telegram CEO的访谈视频，时长4小时35分，看了访谈视频的一部分，时间太长，没有看完。\n视频制作的很好，提供了英语、法语、俄语、乌克兰语的音轨和字幕，中文字幕通过YouTube即时翻译很硬，从Lex Fridman网站找到了字幕srt文件，找工具翻译了一下，上传到了GitHub。\nGoogle AI studio显示需要62564 tokens，无法运行直接翻译。 chatGPT给出的文件下载地址显示文件已失效。 Google Gemini 可以半自动翻译。 最后，chatGPT分段输出，整合到markdown文件中，完成。\n","permalink":"https://blog.onecai.site/2025/10/12/translate-interview/","summary":"\u003cp\u003eYouTube视频账号\u003ca href=\"https://www.youtube.com/@lexfridman\"\u003eLex Fridman\u003c/a\u003e发布了一个与telegram CEO的访谈视频，时长4小时35分，看了访谈视频的一部分，时间太长，没有看完。\u003c/p\u003e\n\u003cp\u003e视频制作的很好，提供了英语、法语、俄语、乌克兰语的音轨和字幕，中文字幕通过YouTube即时翻译很硬，从Lex Fridman网站找到了字幕srt文件，找工具翻译了一下，上传到了\u003ca href=\"https://github.com/onecaicai/Pavel-Durov-Lex-Fridman-Interview--\"\u003eGitHub\u003c/a\u003e。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGoogle AI studio显示需要62564 tokens，无法运行直接翻译。\u003c/li\u003e\n\u003cli\u003echatGPT给出的文件下载地址显示文件已失效。\u003c/li\u003e\n\u003cli\u003eGoogle Gemini 可以半自动翻译。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e最后，chatGPT分段输出，整合到markdown文件中，完成。\u003c/p\u003e","title":"telegram ceo访谈视频中英文字幕"},{"content":" 很久没有进电影院了，临开学和小娃去电影院，看了成龙和梁家辉主演的《捕风捉影》，看完片子才知道不是成龙导演，难怪套路不一样，还是很好看的。\n《捕风捉影》海报，图片来自网络。 电影里的几个点还是很不错的：\n电影里面AI时代的警察，被反派反制后老派警察的传统手段起了关键作用。联想到现实生活中现在各个行业都在高唱AI，但不少的所谓行业AI翘楚还处于PPT阶段或者搞宣传片阶段，传统基础功没有搞起来，就要AI“革命”自己的行业。 梁家辉的演的狠劲够狠，看后面的片花，演完一场戏现场工作人员都很担心他的安全。 还是说到AI，片中有个部分是关键抓捕阶段，警局的女上司要求关闭AI要自己人工指挥，还是对这玩意不是很放心，或者害怕再次被反派把自己的AI干掉。 用成龙那个警察角色的传统工作方式去优化AI，就是新旧结合了。 ","permalink":"https://blog.onecai.site/2025/08/23/003-bufengzhuoying/","summary":"\u003cblockquote\u003e\n\u003cp\u003e很久没有进电影院了，临开学和小娃去电影院，看了成龙和梁家辉主演的《捕风捉影》，看完片子才知道不是成龙导演，难怪套路不一样，还是很好看的。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cfigure\u003e\n    \u003cimg loading=\"lazy\" src=\"movie01-01.avif\"\n         alt=\"《捕风捉影》海报，图片来自网络。\"/\u003e \u003cfigcaption\u003e\n            《捕风捉影》海报，图片来自网络。\n        \u003c/figcaption\u003e\n\u003c/figure\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e电影里的几个点还是很不错的：\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003col\u003e\n\u003cli\u003e电影里面AI时代的警察，被反派反制后老派警察的传统手段起了关键作用。联想到现实生活中现在各个行业都在高唱AI，但不少的所谓行业AI翘楚还处于PPT阶段或者搞宣传片阶段，传统基础功没有搞起来，就要AI“革命”自己的行业。\u003c/li\u003e\n\u003cli\u003e梁家辉的演的狠劲够狠，看后面的片花，演完一场戏现场工作人员都很担心他的安全。\u003c/li\u003e\n\u003cli\u003e还是说到AI，片中有个部分是关键抓捕阶段，警局的女上司要求关闭AI要自己人工指挥，还是对这玩意不是很放心，或者害怕再次被反派把自己的AI干掉。\u003c/li\u003e\n\u003cli\u003e用成龙那个警察角色的传统工作方式去优化AI，就是新旧结合了。\u003c/li\u003e\n\u003c/ol\u003e","title":"看了电影《捕风捉影》"},{"content":"从相册导入了几张图片，发现里面有设备信息之类的个人信息，网上找了几个工具，有的需要付费，有些干脆不能使用，提交cursor这个需求，用python实现了两个功能，一个是删除隐私信息，一个是调整图片宽度。\n地址：https://github.com/onecaicai/image-resize-clean\n程序简介 这是一个图片批量处理工具，可以自动完成以下操作：\n批量重命名：将图片按指定关键字重命名 智能调整尺寸：根据图片方向自动调整到合适尺寸 清除EXIF信息：保护隐私，移除图片的元数据信息 功能特点 🎯 智能尺寸调整 横版图片：限制宽度为850px，高度按比例缩放 竖版图片：限制高度为850px，宽度按比例缩放 保持比例：使用高质量的LANCZOS算法，确保图片质量 🔒 隐私保护 清除EXIF：完全移除图片的EXIF元数据信息 保护隐私：防止个人信息泄露 📝 批量重命名 统一格式：按“关键字-序号”格式重命名 保持扩展名：自动识别并保持原始文件格式 支持格式：JPG、JPEG、PNG、WEBP 使用方法 方法一：命令行参数（推荐） 1 python3 resize_clean.py \u0026lt;图片目录路径\u0026gt; 示例：\n1 python3 resize_clean.py /path/to/your/images 方法二：交互模式 1 python3 resize_clean.py 然后按提示输入目录路径和重命名关键字。\n程序流程 输入验证：检查目录是否存在 文件扫描：扫描目录中的所有图片文件 重命名规划：显示重命名预览 尺寸调整：根据图片方向智能调整尺寸 EXIF清除：移除所有元数据信息 保存输出：保存到resized子目录 输出结果 输出目录：在输入目录下创建resized文件夹 文件命名：关键字-序号.扩展名（如：trip-01.jpg） 尺寸标准：最大边长850px，保持原始比例 测试结果 测试环境 操作系统：macOS 25.0.0 Python版本：3.x 依赖库：Pillow （PIL） 测试用例 横版图片 （1920x1080） → （850x478） ✅ 竖版图片 （1080x1920） → （478x850） ✅ 方形图片 （1000x1000） → （850x850） ✅ 功能验证 ✅ 重命名功能正常 ✅ 尺寸调整准确 ✅ EXIF信息已清除 ✅ 图片质量保持良好 系统要求 必需依赖 1 pip install Pillow 支持的文件格式 JPEG （.jpg， .jpeg） PNG （.png） WebP （.webp） 注意事项 备份原图：程序会修改原图，建议先备份 目录权限：确保对输入目录有读写权限 磁盘空间：确保有足够空间存储处理后的图片 文件格式：只处理支持的图片格式，其他文件会被忽略 错误处理 程序包含完善的错误处理机制：\n目录不存在时提示错误 文件处理失败时继续处理其他文件 输入验证确保参数正确 技术细节 核心算法 尺寸计算：基于最大边长850px的比例缩放 重采样算法：LANCZOS（高质量） EXIF清除：使用exif=b''参数 性能优化 批量处理提高效率 内存友好的图片处理 错误隔离不影响整体处理 更新日志 v1.0：基础功能实现 批量重命名 智能尺寸调整 EXIF信息清除 许可证 本程序为开源软件，可自由使用和修改。\n开发者提示：如需修改目标尺寸，请编辑代码中的target_width变量（当前为850px）。\n","permalink":"https://blog.onecai.site/2025/08/12/modify-pic/","summary":"用Python开发的图片批量处理工具，支持智能调整尺寸、清除EXIF信息和批量重命名功能。","title":"图片处理工具 - 重命名、调整尺寸并清除EXIF"},{"content":"趁着暑假刚开始，赶紧的外出转一圈，小娃心心念念要去张家口富龙小镇体验自行车速降骑行，放假当天就直接出发前往河北张家口。所以本次出行的第一个目的地是河北省张家口市崇礼区富龙四季小镇。\n从附近小超市买了点方便面、面包、矿泉水和红牛，后排座位放倒装了自行车就直接出发。\n用到的工具：\n高德地图 小电车 前往第一个目的地：张家口 分段轨迹 第一天\n10:15—— 13:55 ，经过甘肃白银、宁夏回族自治区中卫市沙坡头区，至宁夏回族自治区吴忠市红寺堡停车区定武高速定边方向，给车第一次充电，充电42分钟，48.21度电。在这里小娃饿了，吃了美味的方便面。通过宁夏交投高速的E泊士充电，总金额37.81元，其中电费16.12元，服务费21.69元。\n宁夏高速 15:35，至宁夏回族自治区吴忠市盐池县，高速道路养护，高速封闭，要求我们下高速走国道。走了80多公里的国道才上到高速上。\n终于又见到高速了 17:45，到达盐红公路。一路用手机高德地图导航，在高德里面也设置了电车和续航，导航到了内蒙古自治区鄂尔多斯市鄂托克前旗盐红公路（不知道是不是我操作的问题），这条路上车很少，导航显示有两个服务区且有充电桩，下服务区确实有充电桩，但是都没有启用，服务区看着也是新修建的，还没有启用。为预留足够续航还是需要尽快充电，连续走了两个服务区都是充电桩没有启用，只好结束导航行程，地图寻找最近的充电站，显示最近的充电站在乌兰镇。\n19:00，到达内蒙古自治区鄂尔多斯市鄂托克旗阿尔寨街，先找地方填饱肚。找到了当地评分较高的一家叫沙湖餐厅的饭馆，点了一份炒烩肉，大块牛肉肉片，吃起来很过瘾很管饱，里面的牛肉和临夏牛肉面馆的牛肉一样，应该是当天现煮的。填饱肚子，找地方充电，找到有两个蔚蓝充电桩，在一个小区里面，过去的时候两个充电桩都有车在充电，没有再等待。又导航到乌兰镇人民政府停车场充电站去充电，充电桩挺多，停车位地锁是自动降锁的，应该是停车位后面的摄像头识别到绿牌车牌后自动解锁地锁的。充电54分钟、56度电。这边使用的是江苏云快充，总费用65.50元，其中电费42.82元，服务费22.68元。\n炒烩肉 乌兰镇 20:50出发，导航到鄂托克旗绕城公路，至07月06日 00:35到达荣乌高速荣成方向沙井服务区，充电并休息一会，充电26分钟、14度电。特来电充电桩，总费用18.57元，电费6.53元，服务费12.04元。\n晚上都是大车 第二天\n03:40，至呼和浩特市土默特左旗哈素海服务区，充电、休息，这地方是华为的超充桩，充电时长61分钟、55.7度电。这里使用的是内蒙古蒙马新能源的蒙马充电，总费用73.31，其中电费28.73元，服务费44.58元。注意到这个服务区的充电站是新能源光储超充示范站，头一回看到这样的充电站，屋顶全部是光伏板（这一路上自打到了宁夏地界，远处山上都风力发电的大叶片风车，再往内蒙这边，路两边上山很多的光伏板）。充完电在服务区休息了一会。\n哈素海服务区 08:40，到达乌兰察布市兴和县兴和服务区，充电46分钟、44度电。继续是蒙马充电，总费用57.24元，电费22.44元，服务费34.8元。09点30从服务区出发，直达目的地。\n兴和服务区 12时抵达目的地河北省张家口市崇礼区富龙小镇。\n到达崇礼 按照高德地图中的“出行轨迹”统计，一共行驶了489+130+80+309+240+170=1418公里。\n在最开始的时候，起始点至目的地的导航距离是1467公里，不知道是哪里不统一了，难道那两段下高速走国道距离还近了些？？？\n玩了点啥 小娃一直对山地车速降感兴趣，抖音上刷到的这个地方，念叨了好多次，这次放假就直接过来了。\n富龙小镇属于是四季都适用的，冬天是滑雪胜地，其他季节就是骑自行车的季节了，从崇礼区主路往富龙小镇行径的路两边很多雪具租售店，和自行车售卖、租赁店。\n这是图片说明文字 泵道 进入园区有三个泵道可以练习，靠近大门口的第一个泵道是收费的，一次收费60块钱，好像是不限时间，忘了。\n第一个泵道\n第一天天气不错 第二个泵道\n再往里走是第二、三泵道，第二个自由练的比较多，第三个似乎是用来教学练习的多一点。第三个泵道没有拍照。\n第一个泵道 速降 到地方才知道这个地方的自行车玩法。从园区内售票处买票进缆车站，缆车票是一天不限次的，扫描门票二维码，绑定佩戴头盔的人像，可以直接刷脸过闸机。自行车挂在缆车座位后面的挂架上，人坐下一个缆车上山，到山顶后工作人员已经帮忙把自行车取下来放在一边，过去骑车，选自己喜欢的赛道速降下山。\n总揽图 按照富龙山地自行车速降公园总揽图，分为初级、中级、专家级，前两个都试了一下，专家级直接不考虑。\n我们自带了一辆自行车，在园区内两外租了一辆自行车，小娃对自行车比我了解的多，看了自行车里面的奔驰、奥迪，租了一个自己喜欢的。\n初级道 坐L2缆车上初级道。初级道分为家庭道和绿道，家庭道就是S形水泥平铺缓坡下降，这个就没去尝试。陪小娃去试了绿道。\n初级绿道起点 给小娃拍了张照片。\n这也是我第一次骑车“速”降，老胳膊老腿的，还是有些紧张的，好在还有当年下地干活的基础，顺利骑下去了。\n山顶拍的滑雪赛道 山顶拍的照片，这应该是冬天滑雪的赛道。\n中级赛道 坐L1缆车上中级赛道。到山顶下缆车，能够看到初级和中级两个赛道的终点，感觉高度相差不是太大。\n初级和中级赛道高度相差不是太远 专家级赛道确实高很多。\n遥远的专家级赛道 山顶平台上两个打卡拍照的地方，趁没人拍了这个秋千，另一个打卡点在排队拍照，人很多。\n打卡拍照点之一 中级赛道确实难了不少，整个行程路线增加了不少，有两个陡一点的坡，第一回往下骑的时候两个坡道都是推着车下去的，第二次下的时候一气呵成的骑下去了，虽然比小娃慢很多，也算是小挑战了一下。没有拍照，小娃的运动相机录像了。\n专家级的赛道在这期间好像没有开，即便是开了我们也不敢去那条道上骑。\n之后的几天，小娃和他们同龄人一起约着去骑车了，我们负责后勤保障，喝水、吃东西之类的。\n滑草 想不起来名字了，类似于滑草的项目吧，为了陪小娃玩我自己也去试了一下，没想到体重感人，下滑速度太快都有点害怕了。\n住宿 园区内 在园区住了两天。缆车站旁边是高尔夫球场，再往右边好像是他们的置业，售卖40年产权的别墅区。\n之后，到镇子上住了，酒店便宜一点，吃饭什么的也方便些。\n吃饭 负一层有一些可以吃饭的地方，第一天去吃了张亮麻辣烫，里面还有米线、上海女人，肯德基好像是园区自营的。\n镇子上有很多饭馆，吃过牛大骨、烧烤、铁锅炖，有一家蒙餐味道很不错，冰煮羊里面的肉很嫩，奶茶也很好喝，在内蒙没想到吃蒙餐的，在张家口吃上了。\n蒙餐里的奶茶 前往第二个目的地：成都 出发第二站，从崇礼出发前往成都。崇礼的温度在25度左右，感觉不到热，到成都就后悔了，进到火炉里的感觉，奔着吃火锅去的。\n有了开一千七百多公里的基础，再继续开车也不算太大压力。从张家口出发，经过大同、西安到成都。\n本来想去大同云冈石窟转一圈，看短视频上的实拍，游人太多，在大同吃了碗刀削面就继续往成都走了。找到了大同二板刀削面，挂了一块物质文化遗产的匾牌，等到五点营业才进去点餐的，门口等的七八个人也是外地来旅游的，听口音是东北人。点了刀削面、红烧肉、红烧丸子和辣椒，算是品尝了一下。\n大同二板刀削面 到秦岭服务区就已经感受到了巨热。\n成都的景点之前去过，就没有再去凑热闹，逛商场，吃火锅，在酒店吹空调，这个季节还是第一次来成都，热晕的感觉，很快也就撤退了。\n不得不说成都的火锅是超好吃的，吃了一家名叫天星正源的火锅，我们去的是海椒市店，半个小时排队，好在是店大桌多，翻台率也很快，半个小时落座吃饭。\n武威、张掖 期间临时有事回家一趟，看假期还有几天时间，再去转转。\n武威-鸠摩罗什寺\n武威鳩摩羅什寺 去看了鸠摩罗什寺（免费开放），这里供奉的是一名翻译经文的高僧，院子里有一个舍利塔，是这名僧人舌头的舍利。\n武威-雷台汉文化馆\n去看了雷台汉文化馆，地图坐标显示的全名是“汉唐天马城⁩”。\n北周时期的雷神庙 北周时期的雷神庙，属于道教，里面不知道有多少是真迹，院落有些破败。这下面有一个汉墓，看介绍是西汉时期，里面道洞很小，蹲着走才能进去，就差爬着进去了。里面只是一个墓穴，内部差不多是一个砖石砌筑的小型蒙古包的感觉，穹顶通过一个伞状液压钢架支撑，里面的陪葬品说是都被盗走了。甘肃省博物馆的马踏飞燕和铜奔马都出自这里。\n武威-天梯山石窟\n中国主要石窟分布图 听工作人员讲解及看到这幅图，才知道这个天梯山石窟的闻名之处。石窟界里的凉州模式。\n天梯山石窟大佛 天梯山石窟比敦煌莫高窟还要早，大佛旁边的石壁上有很多洞窟，里面的文物已经在博物馆保存了，现存的大佛也是在修建水库大坝后进行的修复，大佛肩膀以上的部分应该还算是原版的。\n张掖博物馆\n张掖博物馆 到张掖去了博物馆。\n张掖还有很多值得去看的地方，小娃觉得没意思就没再继续转。\n前往甘南 一路太热，去个凉快的地方。\n甘南甘加草原 这边的草原相对来说人少一点，商业的东西也少一点，晚上温度在15左右，需要盖厚被子才行。\n甘南拉卜楞寺\n甘南拉卜楞寺 之前在YouTube看过关于布达拉宫、磕长头、天葬、苦修的一些视频，对这种“景区”也是纯看了。\n刚好碰到上百号人的诵经仪式，还是震撼到了，明明严禁拍照录像的，还是有不少人怼着拍的。\n拉卜楞寺里的大户和小户 拉卜楞寺从检票口往“景区”走，会经过一些平房的建筑，说是佛学院修行的地方，从大门、小门来区分佛学里的阶层。\n甘加草原帐篷 从拉卜楞寺出来到甘加草原的甘加秘境去看了一下，之后找了个帐篷民宿住下，靠在帐篷门口椅子上喝茶乘凉，把带的长裤、长袖衣服穿上才能继续在门口坐。\n第二天早起又在门口坐了一会，小娃催促下才离开。\n返回，继续牛马。\n","permalink":"https://blog.onecai.site/2025/07/18/002-2025atrip/","summary":"2025年暑假的旅行记录，从甘肃出发前往张家口富龙小镇体验自行车速降，再到成都、武威、张掖、甘南等地，记录了一路上的见闻和体验。","title":"2025年暑假外出记录"},{"content":"算是前言 很多年前，我也折腾过博客—— WordPress 。\n刚工作不久那会，买了台便宜的小主机，注册了域名，备案还不算严格。搭建起网站，记录下初入职场时的各种点滴。写得最多的，是工作中遇到的技术问题、解决方法，还有一些积累下来的经验体会。偶尔转载些在网上看到的文字，比如当年流行、觉得句句在理的“心灵鸡汤”。\n当时还动过念头，想拉几个朋友一起写博客，每人一个账号，分享各自的经历和思考。可惜这个想法只停留在了脑海里。慢慢地，能写的内容越来越少，更新也停了下来，前后短短几个月时间，Google广告没流量。\n后来新浪博客、网易 LOFTER 正火，接着又是腾讯微博、新浪微博、饭否、Google Buzz……信息平台越来越多，140 字以内的内容成了主流，“长东西”消退。\n如今，在短视频横行的时代，偶尔看到那些还在坚持写字的独立博客，佩服佩服，他们的文章列表一拉到底，是一篇又一篇的记录，几万字的内容啊，真实可贵。\n查看Wordpress导出的备份 Markdown 文件，真正手动敲字的还是有几片水文的。\n有些后悔，当年没有坚持写下去。\n现在，也还不算太晚。\n搭建过程 思路：模仿 https://qwenlm.github.io 和田少晗的个人博客这两个博客 工具：豆包（在我这里算是大材小用了）。 1. 安装Hugo 安装Hugo并创建本地博客文件，这个操作在网上有很多，或者直接看Hugo的安装文档。\n电脑系统在通过brew安装Hugo时报错，把安装源更换为国内源解决了这个问题。\n2. 主题 按照 https://qwenlm.github.io 博客设置主题，报错了几次没有解决，通过浏览器下载了hugo-PaperMod-master文件，把这个文件重命名为PaperMod，再修改hugo.toml文件。 3. 自定修改 字体 主字体： 仓耳今楷04-W03 （TsangerJinKai04-W03）\n字体导入： 本地字体文件 （/font/仓耳今楷04-W03.ttf）\n字体层级： TsangerJinKai04-W03 → 仓耳今楷04-W03 → TsangerJinKai04 → PingFang SC → Hiragino Sans GB → Microsoft YaHei → 楷体 → KaiTi → STKaiti → serif\nSafari兼容性： 已优化，支持Safari浏览器显示\n主题 默认主题： 暗色主题\n语言： 中文 （zh-cn）\n主题： PaperMod\n默认模式： 暗色主题 （defaultTheme = \u0026quot;dark\u0026quot;）\n主题切换： 已启用 （disableThemeToggle = false）\nProfile模式： 已禁用，首页显示文章列表\n排版设置 正文字体大小： 18px\n行距： 28px\n字间距： 0.5px\n段落间距： 16px\n标题字体大小： H1至H6分别为28px、20px、18px、16px、15px、14px\n图片样式 最大宽度： 650px\n居中显示： 自动margin\n圆角： 8px\n阴影： 悬停时增强效果\n缩放： 悬停时1.02倍\n关于维护 借助AI生成两个本地脚本，一个是启动本地服务的，一个是发布到GitHub的。\n本地启动脚本\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 #!/bin/bash # 博客本地服务启动脚本 # 用法: ./start_blog.sh echo \u0026#34;🚀 启动Hugo博客本地服务...\u0026#34; # 获取脚本所在目录 SCRIPT_DIR=\u0026#34;$(cd \u0026#34;$(dirname \u0026#34;${BASH_SOURCE[0]}\u0026#34;)\u0026#34; \u0026amp;\u0026amp; pwd)\u0026#34; BLOG_DIR=\u0026#34;$SCRIPT_DIR/MyBloooger\u0026#34; # 检查博客目录是否存在 if [ ! -d \u0026#34;$BLOG_DIR\u0026#34; ]; then echo \u0026#34;❌ 错误: 博客目录不存在: $BLOG_DIR\u0026#34; echo \u0026#34; 请确保在包含 MyBloooger 目录的文件夹中运行此脚本\u0026#34; exit 1 fi # 进入博客目录 cd \u0026#34;$BLOG_DIR\u0026#34; # 固定使用1313端口 PORT=1313 # 检查端口是否被占用，如果被占用则直接终止 if lsof -Pi :$PORT -sTCP:LISTEN -t \u0026gt;/dev/null 2\u0026gt;\u0026amp;1; then echo \u0026#34;⚠️ 检测到端口 $PORT 被占用，正在强制终止相关进程...\u0026#34; lsof -ti:$PORT | xargs kill -9 2\u0026gt;/dev/null sleep 2 echo \u0026#34;✅ 进程已终止\u0026#34; fi echo \u0026#34;📂 博客目录: $BLOG_DIR\u0026#34; echo \u0026#34;🌐 启动端口: $PORT\u0026#34; echo \u0026#34;\u0026#34; # 清理缓存和构建产物 echo \u0026#34;🧹 清理缓存和构建产物...\u0026#34; rm -rf public/ resources/ .hugo_build.lock echo \u0026#34;✅ 清理完成\u0026#34; # 强制重新构建一次（确保最新内容） echo \u0026#34;🔄 强制重新构建博客...\u0026#34; hugo --buildDrafts --minify echo \u0026#34;✅ 重新构建完成\u0026#34; # 再次清理构建产物（避免冲突） rm -rf public/ resources/ # 启动Hugo服务器 echo \u0026#34;🚀 启动Hugo服务器...\u0026#34; echo \u0026#34; 本地地址: http://localhost:$PORT\u0026#34; echo \u0026#34; 局域网地址: http://$(ipconfig getifaddr en0):$PORT\u0026#34; echo \u0026#34; 按 Ctrl+C 停止服务\u0026#34; echo \u0026#34; 🔥 每次文件变更都会自动重新构建\u0026#34; echo \u0026#34;\u0026#34; hugo server --buildDrafts --port $PORT --bind 0.0.0.0 --disableFastRender Update 2026.06.17： 从GitHub换到了付费主机上，博客程序还是继续使用Hugo。\n","permalink":"https://blog.onecai.site/2025/07/01/001-how-to-build-this-blog/","summary":"小白按照教程搭建Hugo博客，蹭GitHub的免费空间。","title":"这个博客是怎么搭建起来的"}]