训练贵在一时，推理贵在每天
卡时、电费、值班人力、外部 API 的 token 费，叠在一起才是真实账单。运维如果讲不清「钱花在哪」，优化基本会变成拍脑袋关功能。
自建大致是：请求占用了多少卡时 × 卡时单价。商用 API 就按 prompt/completion token。先有这两个数，再谈优化。
真正有用的几刀
能小组件别上大模型。 简单问答走小模型，复杂推理再上大模型或推理模型。路由会错，所以要抽检，但大部分流量离开贵模型，账面会好看一截。
量化和引擎效率。 AWQ/FP8、连续批处理、前缀缓存，十月部署笔记写过。运维侧只认结果：SLO 还在不在，单位 token 卡时有没有掉。
缓存。 FAQ 可精确缓存；长系统提示、工具定义重复多，前缀缓存很香。语义缓存要谨慎，相似问复用答，偶发串台很烦。
管住输出长度。 很多浪费是 max_tokens 太大、提示词鼓励长篇。看 completion token 长尾，往往比再买一张卡先见效。
Dify 里常见的漏点
工作流里无条件串多个 LLM 节点；工具失败重试打满；知识库 TopK 开很大，prompt 又长又吵；Embedding 全量重刷。这些不一定出在引擎，但一样烧钱。
产品侧也能帮：租户配额、非实时任务转离线、先检索再生成。纯技术省到极限，不如和业务一起砍无效调用。
看板看什么
日 token、日卡时、单成功请求成本；再按模型、租户、应用拆开。告警只加两类：成本突然翘起来、平均输出长度异常变长。后者经常是提示词或产品改动的副作用。
有周会的话就问几句实在的：最贵的三个应用值不值？哪些流量能下沉小模型？量化上线后投诉有没有增多？重试浪费了多少？
别为了省钱关关键告警，也别无评估全局切小模型。省下来的钱如果换成事故，不算赢。
