核心要点

  • 能列出选型维度:任务难度/质量、延迟、成本(token 价)、数据隐私、上下文长度、语言、是否要微调、合规

  • 能讲清闭源 vs 开源取舍:闭源 API 上手快、质量高、免运维;开源可私有部署、控成本、保数据,但要自己搭推理

  • 能给方法论:先用最强模型把效果跑通验证可行性,再按真实流量评估成本,逐步换更小更便宜的模型

  • 知道用评测集对比候选模型,而不是凭感觉拍板

标准回答

先按维度拆需求

任务有多难(简单分类还是复杂推理)决定要多强的模型;延迟要求高(实时对话)就选小模型或快通道;成本看每千 token 单价 × 预估调用量;数据能否出公网决定要不要私有部署;还要看上下文长度、语言支持、是否要微调定制、行业合规要求。

闭源 API vs 开源自部署

闭源(如各大厂 API)质量高、开箱即用、无需运维 GPU,适合快速验证和中小流量;开源权重模型可私有部署,数据不出内网、大流量下单位成本更低,但要自建推理服务、承担运维。隐私敏感或超大流量倾向开源自部署。

落地方法论

第一步用当前最强模型把功能跑通、确认效果天花板;第二步建一个小评测集,让候选的更小/更便宜模型在上面跑分;第三步在满足质量的前提下,选成本和延迟最优的那个,简单任务下沉到小模型、难任务才走大模型。

常见误区

⚠️ 常见踩坑

无脑上最大最贵的模型,导致成本和延迟爆炸;或者只比 benchmark 跑分,不在自己业务的评测集上实测,结果上线效果与预期差很远。

追问

追问 1怎么客观对比几个候选模型,而不是凭感觉?

用业务真实样本建一个几十到几百条的评测集(带标准答案或评分标准),对每个候选模型跑同样的 prompt,用规则指标或 LLM-as-judge 打分,同时记录延迟和 token 成本,综合「质量/延迟/成本」三维做决策。

追问 2什么时候才值得自己微调一个模型?

当 prompt + RAG 都调不到要求、且有稳定且足量的高质量标注数据、任务模式固定(特定风格/格式/领域术语)时才考虑微调,通常优先 LoRA 这类轻量微调。只是想注入知识不该微调,用 RAG 即可。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。