输入侧压缩、模型选型、输出控制、缓存复用是豆包api降本四大关键：精简prompt冗余、按需选用lite/minipro/code模型、设stop_sequences与max_tokens、客户端lru缓存哈希化key。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
输入侧压缩：别让 prompt 里塞满“人设废话”
豆包大模型按 prompt + response 的总 token 计费，而实际项目中，60% 以上的账单来自输入侧——尤其是被忽略的冗余内容。
常见错误现象：
- 每轮对话都重复传入完整系统提示词（如“你是一个资深客服…”），导致多轮 token 累积翻倍
- RAG 场景下把检索出的 12 个 chunk 全部丢进上下文，其中 7 个和 query 语义相似度
- 提示词里夹带大量换行、空格、Markdown 标题、注释块，实测可占 15–20% 无效 token
实操建议：
- 系统提示词只在首轮传一次，后续对话用
messages数组维护历史，显式标记role: system仅需保留一次 - RAG 输入前做两级过滤：先关键词粗筛（如匹配用户 query 中的动词+名词），再用豆包自身
embedding接口算余弦相似度，只保留 top-3 chunk - 用正则预处理文本：
re.sub(r'\s+', ' ', text).strip()清除多余空白；删掉所有```python、### 注意类非必要标记
模型选型：别用 Pro 模型干 Lite 就能扛住的活
豆包 2.0 四款模型定价差异极大：doubao-pro 输入 3.2 元/百万 tokens，doubao-mini 只要 0.2 元/百万 tokens——差 16 倍。但很多场景根本不需要长上下文或强推理。
使用场景判断要点：
- 对话类、FAQ、表单填充、简单摘要 →
doubao-lite或doubao-mini足够，实测准确率无损 - 需要 256k+ 上下文（如合同全文比对）、多跳推理（“根据 A 条款推导 B 风险，再结合 C 判例给出建议”）→ 才上
doubao-pro - 纯代码生成、补全、解释 → 优先
doubao-code，它在语法结构建模上专有优化，同样输出长度比doubao-lite少 12–18% token
容易踩的坑：
- 把所有接口默认配成
doubao-pro，结果 90% 请求都在处理“今天天气怎么样”这种单句 - 混淆“能力上限”和“日常需求”：200 万 token 上下文 ≠ 你每次都要喂 200 万 token
输出控制：max_tokens 不是摆设，stop_sequences 得用上
豆包 API 的 max_tokens 参数只限制生成上限，不保证提前停；若没设 stop_sequences，模型可能在结尾反复补“综上所述…”、“如有其他问题欢迎随时联系”，白耗 30–50 token。
典型问题：
- 生成 JSON 时未设
stop_sequences=["}", "]\n"]，模型续写到下一行才断 - 多轮对话中 response 含完整对话历史回溯（如“你刚才说…所以我现在认为…”），属于冗余自我引用
实操建议：
- 所有结构化输出（JSON / XML / 表格 Markdown）必须配置
stop_sequences，至少包含结束符和换行组合 - 若业务允许截断，直接设
max_tokens为预估长度 × 1.2，避免长尾失控 - 对“是/否”、“选项 A/B/C”类极简输出，强制
temperature=0+top_p=1，杜绝发散
缓存与复用：别让相同 query 每次都重算 token
豆包本身不提供服务端缓存，但你在客户端或网关层加一层 LRU 缓存，对高频低变化 query（如“查订单状态”、“退换货政策”）效果极明显。
关键细节：
- 缓存 key 必须哈希化处理
prompt，不能直接拼字符串（避免空格、换行差异导致 cache miss） - 仅缓存
response内容，不缓存整个 API 响应体（避免混入 timestamp、request_id 等动态字段） - 设置 TTL 时，优先按业务时效性定（如价格类 5 分钟，政策类 24 小时），而非统一 1 小时
被忽略的复杂点：
- 缓存命中时，仍要走一遍 token 统计逻辑（记录
prompt长度为 0，response长度为缓存值），否则监控数据失真 - 用户身份、地域等上下文变量若影响输出，必须纳入缓存 key 计算，否则出现张三看到李四的响应
