一、不要用一个模型打天下
同一个产品里，客服问答、代码补全、文档解析、数据抽取对模型的要求完全不同。用旗舰模型处理所有请求，效果可能不错，但成本会成倍上升；用轻量模型处理复杂推理，又会频繁出错。
二、四类场景的推荐思路
- 对话与客服：优先看响应速度和中文表达，轻量或中等规模模型即可；
- 代码与工具调用：关注指令遵循与结构化输出，选择代码能力强的型号；
- 多模态理解：需要读图、读表格、读截图时，必须选支持图像输入的模型；
- 复杂推理：数学、逻辑、多步规划类任务，选择推理型模型并接受更高的单价与更长的响应时间。
三、上下文长度与价格怎么权衡
上下文越长单价通常越高。做法是先判断任务真正需要多少上下文：合同审查需要长上下文，FAQ 问答不需要。把长文本先切分、摘要，再送入小上下文模型，往往比直接塞进大上下文模型更便宜也更稳定。
四、组合路由更实际
成熟项目的做法是“路由 + 兜底”：简单请求走轻量模型，命中复杂关键词或长文本时切到旗舰模型，全部失败再用一次高可用模型兜底。OjToken 的模型目录里按文本、图像、视频、音频分类，并标注上下文与价格，可以直接用来做路由表。
五、选型之后要复盘
上线两周后回看数据：哪类请求调用最多、哪类模型错误率最高、每万次调用的成本是多少。依据真实数据调整模型组合，比一开始就追求“最强模型”更划算。