Token 成本控制，别等账单出来才优化

[王小明明]

我们 demo 期 token 成本没感觉，一开放给 200 个内部用户，账单上来很快。大家怎么提前控？

[rootless]

先做每次请求的 token 日志。输入、输出、模型、场景、用户、是否命中缓存。没有账本就没法优化。

[今天也没睡醒]

输出 token 经常被忽视。模型啰嗦一次 1500 字，比检索多两段还贵。

[小蓝]

我们给不同场景设回答长度。客服短答，内部分析长答，代码解释按需展开。

[melo]

小模型路由很有效。分类、意图识别、标题生成别全上最贵模型。

[阿远]

但路由本身也有成本和错误。早期别 8 个模型乱飞，先找最大浪费点。

[zeroOne]

常见最大浪费是重复发送固定提示、无关历史、过多 RAG chunk、用户点“重新生成”全量重跑。

[林小北]

prompt caching 适合固定前缀稳定的场景。你每次动态拼一大段在前面，就吃不到好处。

[小傅]

RAG TopK 降低会不会影响准确率？

[leaf_1997]

要测。很多系统 TopK=20 只是心理安慰，前 5 段已经够，后面全是噪声。

[葡萄冰]

我们还做了“无答案短路”。检索分数太低，先澄清或说资料不足，不让模型长篇猜。

[小郑]

用户连续追问时，要不要复用上轮答案？

[陈一]

可以复用状态和证据摘要，不要机械塞完整上轮回答。上轮回答很长时尤其浪费。

[王小明明]

我先加 token 日志和场景成本报表，再优化 RAG TopK、固定前缀和回答长度。

[rootless]

对，成本优化先找热区，不要凭感觉砍能力。