何时使用本场景
客服聊天机器人这一负载形态相当特殊，常常打破"挑最聪明的模型"这种直觉。每轮对话很短（输入 300-800 token，输出 100-250 token）。但量级巨大——一家中型 SaaS 一个月走聊天通道的对话动辄百万，多则千万。延迟很关键，因为用户在屏幕前等着加载圈。而模型之间的质量差距在这种短问短答场景下被压缩得很小：强基础模型与前沿模型对"我的订单在哪"或"密码怎么重置"给出的答案几乎一致。
换种说法——客服是所有常见 LLM 场景里价格/性能不对称最大的那一类。月百万对话的聊天机器人在前沿档输出价位（详见下方实时计算器）很容易在输出上花到四位数美元。换到与 Gemini Flash（<ModelPrice id="google/gemini-2-5-flash" field="output" />）或 DeepSeek V3.5（<ModelPrice id="deepseek/deepseek-v3-5" field="output" />）同档的便宜模型，同样工作量只是它的一小部分。一年下来省的钱够再请一个工程师。
为什么推荐链是这个组合
主用：Gemini 2.5 Flash。 便宜、首 token 快、事实召回与结构化输出遵循度都强。它的弱项——长链路推理——恰恰是客服工作流永远用不上的那一项。
备用：DeepSeek V3.5。 主用模型出错或区域不可用时顶上。token 成本与主用基本持平，质量在边缘表述场景上略高一档。备用模型必须便宜到不会因为每次故障切换就吃掉主用省下来的钱。
基线：GPT-5。 仅作"默认贵的方案"成本参照。本页"月度成本"面板会算出差值——通常是推荐链路的 6-12 倍。
常见踩坑
- 每条回复都用最强模型。 在 LLM 前加一层简单分类器，可以把 85% 的对话路由给更小的模型，体感质量没掉。
- 盯 P50 延迟而不是 P95。 客服是实时的；尾延迟比中位延迟更左右用户体感。比较表里按 P95 过滤。
- 低估多语言切换成本。 部分模型按语言档位定价，或者非英文上下文窗口要加钱。在成本计算器里检查
defaultUsage.languages。 - 忽略审核层。 每百万 5 美分的审核调用是便宜保险，防止一条无礼对话截图传遍社媒。
上线前的质量基线
构建 50 段对话的金标准集，覆盖：退款诉求、密码重置、多轮排障、被辱骂用户、至少一段非英文对话。对每条链路打三个分：（a）事实正确性，（b）被问到超出范围的事时的拒绝模式，（c）语气一致性。推荐链路通常每个维度都在 GPT-5 基线的 2-3 分以内——如果你的金标准集差距更大，说明你的对话推理负担高于平均，应该把主用偏向更聪明的模型。
本场景不覆盖什么
语音客服（使用 voice-assistant 场景）；与产品 UI 交互的应用内引导排障（更接近 agent 形态，参考 code-generation 或 data-extraction 模式）；监管期望主导的高风险金融服务客服（参考 legal-contract-analysis 的拒绝模式）。