doubao seed 2.0 lite 价格

你多半是在做选型：手头有一批调用量大但难度不高的活，想找个便宜档位的模型顶上，又怕单价看着低、实际账单反而更贵。这篇不给你背数字，因为单价和档位会调，背下来就过期。我们讲的是判断口径：这类轻量档位按什么维度计价、哪些场景适合、哪些场景省不下钱，以及去哪几个站内页面把当时的数字核出来。

做选型时最容易踩的坑，是把「单价低」直接等同于「账单低」。轻量档位的报价通常确实更友好，但你的实际支出取决于输入输出比例、重试率和兜底比例，而不是价目表上那一行。所以正确的做法是先搞清计价口径，再拿自己的真实请求去套，最后才看数字。

这篇不背价格，因为单价和档位会调整，背下来很快就过期。下面讲的是判断口径和一套可执行的算账流程，当期具体数字请到站内对应页面核对。

这类轻量档位的价格，按哪几个维度读

看一个模型的价格，别只盯一个数。先确认输入和输出是不是分开计价，很多档位输出单价明显高于输入，而你的任务如果是长输入短输出，实际成本结构和直觉完全相反。再确认缓存命中是否有单独价格，如果同一段系统提示反复发送，这一项能直接改变量级。

轻量档位便宜通常不是厂商让利，而是参数规模小、上下文窗口短、部分高级能力不支持的自然结果。所以看到低价先别高兴，先对照模型规格页确认它到底支不支持你需要的输出格式和上下文长度。

• 把单价拆成输入侧和输出侧两个数，分别代进你的任务画像
• 确认缓存命中是否单独计价，有就按你的重复前缀比例估算
• 确认是否有阶梯折扣，按你预估的月调用量判断落在哪一档
• 确认上下文窗口，长文档场景要先把切分成本算上
• 当期数字去 /official-api 和 /price-watch 核对，厂商入口在 /providers 里找

什么活适合放给它，什么活别放

判断标准只有一条：这个任务的输出能不能被程序快速验证。能验证的，错了重跑一次成本可控；不能验证、要靠人读的，重试和返工成本会迅速吃掉单价优势。

适合的场景有共同特征——答案短、去向明确、格式固定。比如分类打标、信息抽取、格式转换、短文本改写、路由判断。这类任务即使模型偶尔跑偏，用规则或关键词也能兜住，不会影响下游。

不适合的场景也很清楚。长文档通读总结、多轮复杂推理、对措辞质量要求高的对外文案，这些活轻量档位更容易跑偏，而且一旦跑偏你很难快速发现，等人工审出来时成本已经发生。需要严格遵循超长指令或大量示例的任务也一样，指令越长，轻量档位的稳定性越差。

• 适合：分类打标、信息抽取、短文本改写、格式转换、路由判断
• 适合：高并发低延迟的第一道过滤，明显简单的问题挡在前面，难的转更强模型
• 不适合：长文档通读总结、多轮复杂推理、对外文案这类靠人读的产出
• 不适合：需要遵循超长指令或大量示例的场景，重试本身就是开销
• 边界情况：任务本身简单但输出要被直接展示给终端用户，这时先小流量对比再决定

上线前把账算一遍：四步走

1. 抽真实请求做样本从日志里抽 20 到 50 条真实请求，逐条记录输入 token 和输出 token。别用平均长度的直觉，输入输出的比例往往和想象差很远。
2. 代入当期单价算单次成本用站内工具把当期单价代进去，算出单次调用成本，再乘以预估月调用量。输入输出分开算，别用合并后的一个数。
3. 加上失败与兜底成本把解析失败重试、超时重发、以及需要转强模型的兜底比例乘上去。兜底比例哪怕不高，乘上强模型单价后也可能成为主要支出。
4. 跑一周后对账上线后拿真实账单和预估对一遍。差异明显就回到第一步重新抽样，通常是任务画像变了或者兜底比例被低估。

这套流程的关键是第三步。很多人算成本只算成功请求，忽略了重试和兜底，结果真实账单比预估高出一截。兜底比例需要靠压测或者灰度期观察，不能拍脑袋。

哪里能查到当期数字，别信二手截图

价格是动态的，二手截图和聊天记录里的报价都不能作为依据。核对时优先看官方条目，再看价格变动记录，最后才看第三方渠道的折算口径。

第三方渠道的倍率折算容易让人误判。中转报价通常是在官方价基础上乘系数，系数本身也会变，而且可能不含缓存折扣。拿它做选型参考可以，做预算依据不行。真实预算还是要回到官方条目和价格变动记录上核对。

单价是厂商定的，账单是你自己的请求结构决定的，两者不是一回事。