LinkAI 模型调用积分消耗过快——定位是哪个环节在烧积分
"积分怎么烧得这么快？"是 LinkAI 用户最常遇到的吐槽之一。积分消耗过快不是一个问题，而是多个环节累积的结果。下面教你按三个维度逐层定位。
定位方法论：从粗到细
1. 哪个应用 / 助理最烧 → 2. 哪个模型最烧 → 3. 哪类 token 最烧维度 1：哪个应用 / 助理最烧
进入 控制台 → 我的账户 → 使用记录，按应用 / 助理分组查看消耗排行。通常会发现消耗高度集中在一两个高活跃的应用上。
维度 2：哪个模型最烧
使用记录里可以看到每个模型的积分消耗明细。对比不同模型的单价和使用量，快速定位。
模型单价参考（大致量级，具体以平台为准）
| 模型类型 | 单价级别 | 典型场景 |
|---|---|---|
| 轻量快速模型（Lite / Turbo） | 1x | 简单问答、日常闲聊 |
| 主流生产模型（Pro） | 3~5x | 日常生产主力 |
| 强推理模型（Plus / Opus / R1） | 10~20x | 复杂推理、代码生成 |
| 文生图 / 视频 | 按次计费，不按 token | 图片 / 视频生成 |
如果某个"不需要强推理的应用"却用了强推理模型，这就是第一个可以优化的地方。
维度 3：请求 token vs 响应 token
一次对话的总 token = 请求 token + 响应 token：
请求 token = 提示词（应用设定） + 历史对话记忆 + 知识库检索片段 + 用户提问
响应 token = 大模型的生成回复消耗大头通常是请求 token 的三个来源
1. 提示词太长
应用设定里写了大量背景知识、规则、示例 → 每次请求都带这段长提示词 → token 白白烧掉。
优化：提示词里只写必须由 AI 记住并遵循的行为规则，背景知识和示例不要写进提示词——如果背景知识重要，放进知识库。
2. 对话历史累积太长
多轮对话中，历史消息会持续累积并随每次请求发送。如果你的应用设了 20 轮记忆，那每次请求都要带 20 轮消息。
优化：降低记忆轮次。大部分场景 5~8 轮记忆就够了。超过这个数量时早期消息的价值大幅降低。
3. 知识库检索召回太多片段
Top N = 10 意味着每次对话都要带 10 个知识库片段（每个片段 200~500 字）——这部分 token 消耗非常可观。
优化：降低 Top N 到 4~6，合理设置相似度阈值，确保召回的片段是真正有价值的。
积分消耗控制手段汇总
| 手段 | 生效范围 | 效果 | 注意事项 |
|---|---|---|---|
| 降模型档次 | 最直接 | 成本差 5~20 倍 | 确认降档后效果能接受 |
| 缩提示词 | 所有对话 | 立竿见影 | 不要丢核心行为规则 |
| 降记忆轮次 | 多轮对话 | 显著减少请求 token | 太低会导致上下文丢失 |
| 降检索 Top N | 知识库应用 | 减少检索片段 token | 太低会导致回答缺信息 |
| 关闭不用的插件 | 应用 | 减少意图识别 + 插件调用开销 | 按需开启 |
| 合并多次调用 | 工作流 / 插件 | 减少零碎消耗 | 适合固定流程 |
| 定期重置会话 | 日常使用 | 清空历史消息累积 | 会丢失上下文 |
积分消耗异常告警
可能的异常情况
- 短时间内消耗异常大增 → 检查是不是某个插件或模型被误配置了自动触发
- 单个应用消耗远高于预期 → 检查是不是有重复对话或无效请求
- 模型消耗突然增加 → 检查是不是后台任务（工作流、定时任务）在高频调用
快速验证
- 用控制台的使用记录按时间粒度（小时 / 分钟）查看消耗曲线
- 突然飙升的时段对应的应用 / 模型就是问题点
长期习惯建议
- 定期检查消费记录——每周花 5 分钟过一遍，异常早发现早处理
- 为不同应用设不同模型档次——简单问答用 Lite，复杂推理才用强模型
- 提示词精简原则——只写规则，不写背景知识
- 知识库 Top N 不贪多——能 4 就不要 8
- 不常用的插件关掉——减少意图识别噪音和可能的误触发