主要是不好换算。没有一个合适的基准。我觉得一个比较好的基准是，未缓存输入 token 与 credit 的交换比例，接近 1:1 。

cached input: 1000 万
non-cached input：20 万
output：5 万

这样非常容易在 token 和花费之间估算，上面的都折算成 non-cached input：1000 万/50 + 20 万 + 5 万*2 = 50 万。对于 DeepSeek V4 Flash ，就是 0.5 元。

内卷是说效率低，把大量时间或资源，耗费在很小的提升上，比如农业上的精耕细作，比如为了竞争分数而鸡娃学习和考试那些不必要的东西。为这些东西的大量付出带来的价值微乎其微。

AI 编程是这样吗？感觉这 2 个不搭边啊。个人或者公司消耗 token ，肯定是为了带来价值，比如节省开发时间或精力，这些省下来的当然是价值。也一定会产生对应的后果，比如总财富增加，总劳动时间减少。换句话说，如果没有带来任何改变，你为什么要用 AI 编程呢？假如你说是为了不落后于同事，那好，假如你们公司所有人都是因为竞争压力而采用 AI 编程，那这种竞争带来了什么呢？公司的生产效率有没有提高？公司的产出有没有增加？增加了的话，社会总财富就会增加，那么要么工资增加，要么就是工资不变但购买力增加了。你说的「时间和钱也没变多」，是不符合常理的。

@TuTouPower 反正雷死人不偿命。。实际是现在区分了缓存 input 和未缓存 input ，但大众哪懂这个，直接简单粗暴 2 亿->110 亿，7 亿->380 亿，多直接！等你把中转站挂出去，回过味来，你也不能骂他，因为它用量确实比以前多了几倍。厉害吧。

又一个被小米套路到的😓，不是一千亿 token ，是一千亿 credits 。每个 token 现在消耗几百个 credits 了。

@sillydaddy #4 上面的例子算错了😓，10 轮命中率=550000/650000=85%。

一般用 claude code 这类 agent ，缓存会占比很大，一般都会在 90%以上。因为它要经历 thinking..action..thinking..action 这样很多轮，轮次越多，缓存占比越大，因为每一轮都会把之前轮的那些输入喂给大模型，这些就是缓存。

假如每轮新输入 10000 个 token ，那么 10 轮后，未缓存的就是 100000 个 token ，缓存的呢？ 10000+20000+30000+...+100000=5550000 ，缓存命中率=5550000/5650000=98%

实际要考虑上下文超出会压缩，导致原来的缓存失效。但缓存命中率只跟 Agent 工具的用法有关系，Agent 模式一般都能到 90%以上，除非你特意优化 Agent 的流程，减少缓存的占用，比如使用定制的流程去处理，例如那些 AI 视频生成管线，把流程前一环节的输出经过筛选，作为下一环节 API 调用的输入，而不是堆积信息，这样会减少缓存。

这是我用 claude code 调用小米 token plan 处理文本提取信息，这个场景下的消耗（缓存占比非常大，命中率 97%，这种情况下，可用量确实提高了 10 倍左右）：
https://v2ex.com/t/1215750#r_17686925

不过，小米套路多倒是真的。

@LittleTree 可能是国内国外的不匹配？我的 token plan 是走的新加坡。

谢谢 OP ，麻烦填我的吧，早知道调价这么低，就不那么早用完了。邀请码：A2ZFD2 。注册： https://platform.xiaomimimo.com?ref=A2ZFD2 （注册后点控制台左下方入口填入，体验金 40 天有效）

小米套路真多：先 0 元赠送，再趁剩 3~4 天时，重置额度，让人感激。再趁热乎把价格调到和 DeepSeek 一样。还有 7 亿->380 亿 credits 的营销噱头，你直接把缓存 token 的价格调降到 0.02credit 不就行了吗。

确实是 5~8 倍的提升！看图：
https://i.v2ex.co/yOG9s3dCl.jpeg

token plan 的话，使用 mimo-v2.5 ，把现在的 380 亿，除以 100Credits/token ，想当于原来的 3.8 亿 Credits 。

未缓存输入 = 640 万
+ 缓存输入折合 = 200 万（ 22436 万/120 倍）
+ 输出折合 = 140 万（ 73 万*2 倍）
-----
总消耗 = 1000 万，占 3.8 亿 token 的 1/38 。

而按旧方式，上图的 2.3 亿 credits ，占了赠送的 7 亿 token 的 1/3 。
等于用量提升了 12 倍（当然，我的缓存命中率比较高，占 97% 。但一般 Agent 使用场景，缓存输入都是占大头。）

@icew23 #26 而且，即使是建立了结构化信息，仍然要使用 ReACT 模式。比如我提到的标签网络，搜索一个句子，可以转化成搜索多个标签，通过搜索多个标签，找到这些标签关联节点集合，然后对它们取交并差，问题在于，每个标签所关联到的节点集合，都是非常多的，就像向量搜索时匹配到的句段一样。这就让最后的筛选结果，仍然面临 topK 类似的困境。需要由 AI 来 ReACT ，决定是否继续筛选，是否要调整筛选条件。

@icew23 #26 感觉有达成共识了，对于知识库这种，用向量数据库+结构化信息。结构化信息需要 AI 跑一遍来提取。我在那篇笔记标签网络的主题里面，就是在手动建标签网络，现在有了 AI ，跑一遍就可以把标签网络建立起来了。你觉得那篇的想法怎么样？对于这个主题里搜集信息这种一次性的，AI 驱动的 ReACT 模式，应该比较省成本，不用考虑无关的内容。

@PiersSoCool #17 我算了一下，DeepSeek V4 Flash ，百万输入 token 是 1 块钱，我单单 govmap 这个项目就要花费三千块左右。

@Morriaty 太感谢了！看样子最优解就是这个了。我把它作为附言吧，标记为已解决。

这样 token 数量应该是比较少的，配合 DeepSeek 的低缓存价格，完全足够了，token 数量基本取决于未缓存的输入 token ，而这些 token 基本就是那些包含有效信息的文字量，最多增加一个常数倍。

而且这种方式，应该就是向量数据库的最优解了：因为向量数据库只是给出一种渐进的匹配度。不存在机械式的程序可以客观判定的分割线，所以，最终的截止需要由人类来决定，或者由类似于人类理解力的 LLM 来决定。你说的 ReACT 模式，渐进式，恰恰符合这个模式。

@nomagick @sillydaddy #13 当然也不止这一个项目。而且我感觉所有需要从互联网收集、整理信息的，都会遇到类似的需求：不能漏掉关键信息，不能消耗太多 token 。

@nomagick 对了，补充一下这件事的背景，其实我在做一个 govmap 项目，需要搜集国省市县乡的各机构的职责、构成、编制等等：
https://v2ex.com/t/907899#r_12559610

涉及到的文档处理比较多，需要不少的搜索工作量和整理工作量。还是希望能尽量减少一些 token 的消耗。所以，需要一个比较流程化的处理过程，比如搜索、下载、抽取关联片段、提取信息、整理为格式化数据。

@Morriaty 你的意思是不是，让大模型自己根据搜索匹配的过程，来适应性的查找？比如搜索到某些关键字，然后再扩展它的范围？也很道理。因为我的目的就是节省 token ，如果不用读全文，那就满足我的需求了。

@maolon #6 这个把关键词改写成长句的，还是第一次见到，应该是叫 HyDE 吧，还挺神奇的！我感觉挺适合我的需求的，感谢！

@IsaacYoung 感谢分享，里面提到的「父子文档」，其实跟楼上提到的依赖预制的语义结构是一样的。这个依赖条件，其实本身也需要 LLM 的介入，否则只凭借解析文本的结构、网页的结构来确定，并不稳定。

所以，感觉还是需要 LLM 的理解能力来介入，提取多层的抽象信息。但这里有个悖论，如果是整理出的知识，需要多次检索，那 LLM 介入一次，后续多次使用，效率比较高。但如果是我这种，只需要提取一次，那直接让 LLM 提取所需的信息就可以，就没必要再让向量数据库转一次手了。

前者抽取多层抽象信息，感觉跟我之前提到的笔记的网状 tag 系统，不谋而合了： https://v2ex.com/t/825142

@IsaacYoung
@cryptovae
这些方法应该能缓解，但是没有从根儿上解决。比如，如果恰好关键信息不在重叠的 token 里面呢？

关键在于，向量搜索它会漏掉。

如果是人来交互式的查看结果，可以把最匹配的 topK 个，优先展示出来，如果不满意，再动态增加 topK 。
可如果是程序来处理呢？怎么保证不会漏掉呢？