LLM Cost Optimization 是一个用于降低大语言模型 API 与基础设施成本的技能，目标是通过缓存、模型选择、提示优化与自托管的合理组合，将 LLM 成本削减 50%–90%。
适用场景 当出现以下情况时可以使用该技能：LLM API 支出增长快于收入；需要将 AI 成本归因到团队、产品或客户；实施缓存以避免重复的 LLM 调用；决定何时从 API 提供商切换到自托管模型；在不牺牲质量的前提下优化提示长度。
按影响排序的成本杠杆 资料给出各策略的典型节省与实施难度：语义缓存节省 20–50%，难度低；模型右尺寸化节省 30–70%，难度低；提示压缩节省 10–30%，难度中；提供商缓存（提示缓存）节省 10–25%，难度低；离线工作负载批处理节省 50%（Batch API），难度中；规模化自托管 7–8B 模型节省 80–95%，难度高；量化节省 30–50% 的显存成本，难度中。
先追踪成本 使用 LiteLLM 的成本追踪（自动按模型定价），通过 litellm.completion 调用后使用 litellm.completion_cost 获取单次成本，并可添加自定义成本回调（success_callback）将成本记录到分析数据库，按用户、模型等维度记录。
模型右尺寸化 按任务复杂度路由模型，不要所有任务都用 GPT-4o。示例路由：分类、摘要、抽取、简单问答使用 gpt-4o-mini；复杂推理使用 gpt-4o；代码生成使用 claude-sonnet-4-6；创意写作使用 claude-opus-4-6。资料给出的 2025 年近似价格（每 100 万 token）：gpt-4o-mini 输入 $0.15 / 输出 $0.60；gpt-4o 输入 $2.50 / 输出 $10.00；claude-sonnet-4-6 输入 $3.00 / 输出 $15.00；llama-3.1-8b 自托管约 $0.05–0.10 全包（GPU 摊销）。
提供商侧提示缓存 Anthropic 可缓存长系统提示，对缓存 token 节省 90%：在 system 数组中对大段文本设置 cache_control 为 ephemeral，首次调用全价，后续调用对缓存部分享 90% 折扣，可通过 response.usage.cache_read_input_tokens 查看缓存读取 token。OpenAI 对超过 1024 token 的重复前缀自动进行提示缓存，无需改代码，可检查 usage.prompt_tokens_details.cached_tokens。
使用 OpenAI Batch API 批处理（50% 折扣） 将请求组织为 JSONL 文件，每条包含 custom_id、method、url 与 body；通过 client.files.create 上传（purpose 为 batch），再通过 client.batches.create 创建批处理任务，completion_window 设为 24h，使用 client.batches.retrieve 轮询状态。
语义缓存 结合 Redis 与 sentence-transformers 嵌入模型（示例使用 BAAI/bge-small-en-v1.5）实现：先做精确匹配（SHA-256 哈希键），命中直接返回；再做语义匹配，对查询编码后与缓存中的嵌入计算余弦相似度，达到阈值（示例 0.92）即返回缓存响应；未命中则调用 LLM，并将精确匹配与语义嵌入分别写入 Redis，设置 TTL（示例 24 小时）。
提示压缩 使用 LLMLingua 的 PromptCompressor（示例模型 microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank），通过 compress_prompt 设置 ratio（如 0.5 保留 50% token）与 rank_method（如 longllmlingua），可将长提示压缩 3–20 倍且质量损失最小，并输出节省信息。
自托管盈亏平衡计算 提供 break_even_analysis 函数，输入月度 API 支出、GPU 每小时成本（示例 A10G 为 $2.50）、利用率（示例 70%），计算月度 GPU 成本与占 API 支出的比例，并给出建议：比例低于 0.5 建议立即自托管；低于 0.8 建议流量翻倍后自托管；否则继续使用 API。示例：每月 $5k OpenAI 支出、$2.50/小时 A10G，GPU 成本约 $1,260/月，占 API 支出 25%，建议立即自托管。
成本仪表盘（Grafana） 通过 prometheus_client 定义 Counter 指标（如 llm_cost_usd_total 按 model、team、task_type 标签；llm_tokens_total 按 model、token_type 标签），在 track_call 中计算成本并递增相应指标，用于 Prometheus/Grafana 可视化。
最佳实践 对 80% 的任务使用 gpt-4o-mini 或 claude-haiku，它们便宜 10–30 倍；对超过 1024 token 的系统提示启用提示缓存（Anthropic 与 OpenAI）；审计 token 数最多的前 5 个提示并进行压缩或缓存；在成本失控前使用 LiteLLM 或 Bifrost 虚拟密钥设置硬性预算限制；当月度 API 支出超过 $2k 时自托管 7B–8B 模型。
相关技能 llm-gateway（集中式成本控制）、llm-caching（语义缓存模式）、vllm-server（自托管推理）、agent-observability（token 与成本遥测）。
限制 该指南针对真实环境执行：应用任何变更前需确认目标、影响范围与回滚计划；未经明确批准不得部署到生产环境。此为仅文档导入，上游脚本与模板未随附。示例命令包括 git status && git diff --stat 与 kubectl diff -f manifest.yaml。该技能改编自 BagelHole/DevOps-Security-Agent-Skills（MIT），为上游合规添加了 frontmatter、When to Use/Limitations 与安全边界。