14.1 节给出了“闭源 API 还是开源私有化”的顶层决策框架。但在真正落地时，同一个“对话”场景和“代码”场景对模型的能力要求截然不同——把最强的通用对话模型硬塞进代码补全环节，不仅浪费算力，体验也未必胜过专门的代码模型。本节从五个高频业务场景出发，给出可直接落地的选型建议。
一、对话场景：通用聊天、角色扮演与内容创作
核心需求：指令遵循精准、上下文连贯、风格可控、安全对齐到位（不输出有害内容）、创意丰富。
选型逻辑：
- 这是大模型最“卷”的赛道，头部闭源模型的体验断层领先。如果你追求开箱即用的对话质量，直接调用闭源 API 是性价比最高的选择。
- 私有化部署只有在数据合规（如金融、政务内网）或角色扮演需要深度定制时才必要。
| 推荐方案 | 适用情况 | 说明 |
|---------|---------|------|
| 闭源首选：GPT-4o / Claude 3.5 Sonnet | 追求顶尖体验、C 端产品、复杂多轮对话 | Claude 在长上下文和安全性上表现突出；GPT-4o 响应速度和多模态融合更好 |
| 国内闭源：通义千问-Max / 豆包-Pro / 文心一言-4 | 国内合规、中文语境优化、成本敏感 | 中文指令遵循和本土知识通常优于海外模型 |
| 开源私有化：Llama 3 70B / Qwen2 72B / GLM-4-9B（轻量） | 必须内网部署、需要微调特定人设 | 70B 级开源模型经高质量 SFT 后，可达到接近 GPT-3.5 水平；小参数模型（9B/13B）适合做垂直角色，但不适合做通用开放域闲聊 |
规模与成本建议：
- 7B–13B 模型：经领域 SFT 后，适合封闭域问答（如只聊美妆、只聊法律），但不要期待它有优秀的开放域闲聊能力。
- 70B 级：当前开源私有化部署达到“可用”门槛的最低规模，需 2×A100 80G 或 8×4090 张量并行。
- 高频 C 端对话产品务必关注推理成本：按百万 Token 计费时，中转一次 70B 模型的成本可能是 3.5-Turbo 的 5–10 倍。
二、代码场景：生成、补全、审查与解释
核心需求：语法正确、支持多语言、理解代码库级上下文（长窗口）、低延迟（IDE 内实时补全）、支持 Fill-in-the-Middle（FIM）。
选型逻辑：
- 代码是规则明确、逻辑性强的任务，中小参数模型（7B–33B）经过代码专用训练后，表现可以非常惊艳，不必盲目追求通用大模型。
- 必须选择支持 FIM（中间填充） 架构的模型，普通文本生成模型在代码补全（Cursor 位置续写）场景下效果差。
| 推荐方案 | 适用情况 | 说明 |
|---------|---------|------|
| 闭源首选：GPT-4o / Claude 3.5 Sonnet / GitHub Copilot | 专业开发者、全栈项目、需要跨文件理解 | Claude 3.5 Sonnet 在 2024 年多项代码基准中表现极强；Copilot 生态最成熟 |
| 国内闭源：通义灵码 / 文心快码 / CodeGeeX | 国内 IDE 集成、中文注释理解、企业合规 | 基于 Qwen/CodeGeeX 等模型，对国内技术栈（小程序、Java 生态）优化更好 |
| 开源/私有化：DeepSeek-Coder / Qwen2.5-Coder / CodeLlama / StarCoder2 | 代码安全审计内网、金融/军工源码不能外传 | 7B–33B 即可满足 90% 代码辅助需求；DeepSeek-Coder 在多种编程语言上接近 GPT-4 水平 |
部署与工程建议：
- IDE 实时补全要求首 Token 延迟 < 300ms，建议用 INT4/INT8 量化或部署 vLLM（23.1 节）做连续批处理。
- 代码审查（Code Review）可接受稍高延迟，建议配合 RAG（24.2 节）接入企业私有代码库和文档，避免模型 hallucinate 不存在的 API。
- 复杂架构设计（如“帮我设计一个分布式事务框架”）仍需 70B+ 通用模型或顶级闭源模型，专用代码模型偏重于“实现”而非“架构”。
三、客服场景：企业智能客服与售后支持
核心需求：事实准确（不能 hallucinate）、高并发低成本、能接入企业知识库（产品手册、订单状态）、情绪稳定、可审计。
选型逻辑：
- 客服是典型的“不需要模型懂一切，只需要模型懂业务”的场景。当前业界共识是：中等规模模型 + RAG + 严格的意图路由，远胜于裸跑一个超大通用模型。
- 客服对话通常有明确边界，适合用开源模型私有化，以节省长期调用成本。
| 推荐方案 | 适用情况 | 说明 |
|---------|---------|------|
| 闭源 API：GPT-3.5-Turbo / 通义千问-Turbo / 讯飞星火 | 快速验证、中小型企业、无运维团队 | 成本低、响应快；适合处理开放式闲聊和简单 FAQ |
| 开源私有化：Qwen2 7B/72B / ChatGLM3-6B / Baichuan2-13B / Llama 3 8B | 大型呼叫中心、金融/政务客服、数据不出域 | 7B–13B 经高质量客服语料微调后，在封闭域准确率可超过通用大模型；72B 用于处理复杂客诉和情绪安抚 |
关键配套技术：
- 意图分类层：先用小模型（BERT 或 1B 级轻量模型）做意图识别，区分“查物流”“退换货”“投诉”，再决定调哪个后端模型或 API。
- RAG 强制接入：客服场景必须外挂企业知识库（24.2 节），让模型基于检索到的标准话术生成回答，而非依赖参数记忆。这是抑制幻觉最有效的手段。
- 安全兜底：设置敏感词拦截和“转人工”触发器。不要用大模型直接处理退款、改订单等写操作，只让它生成话术，由人工或规则引擎确认执行。
四、推理场景：数学、逻辑、金融分析与科研辅助
核心需求：多步推理严谨、减少幻觉、结果可验证、支持长链条逻辑。
选型逻辑：
- 推理是当前大小模型差距最大的能力鸿沟。7B 模型做小学数学题尚可，面对高中奥数或财务报表分析时，准确率会断崖式下跌。
- 如果业务涉及资金风险、医疗诊断、法律判决支持，必须使用当前最强的一批模型，并配合外部工具验证，不可轻信模型直接结论。
| 推荐方案 | 适用情况 | 说明 |
|---------|---------|------|
| 闭源首选：GPT-4o / o1（如可用）/ Claude 3 Opus | 复杂数学、科研推导、金融建模 | OpenAI o1 系列专为推理优化（增加内部思维链长度）；Claude 3 Opus 在长逻辑链上稳定性极佳 |
| 国内闭源：DeepSeek-V2 / Qwen-Max / 通义千问-Max | 中文金融研报、法律逻辑审查 | DeepSeek-V2（MoE 架构）以较低激活参数量实现接近 70B dense 模型的推理能力，性价比突出 |
| 开源私有化：Llama 3 70B / Qwen2 72B / Mixtral 8×22B | 涉密科研、军工、内部审计 | 至少需要 70B 级 dense 模型或等效 MoE；7B/13B 小模型在复杂推理上基本不可用 |
工程与提示策略：
- 强制 CoT（思维链）：在 Prompt 中加入“请逐步思考”（6.2 节），让模型把中间推理步骤显式输出，准确率通常提升 20%–40%。
- 工具调用兜底：对于数学计算，不要信任模型的“心算”，必须通过 Function Calling（6.3 节）调用 Python 解释器或计算器验证。
- Agent 架构：多步金融分析建议采用 ReAct / Plan-and-Execute 模式（24.3 节），让模型自主拆解子任务、调用工具、观察结果、修正路径，而非单轮生成定论。
五、多模态场景：图文理解、视频分析与跨模态生成
核心需求：视觉信息提取准确、跨模态语义对齐、长视频时序理解、生成可控。
选型逻辑：
- 多模态模型目前闭源领先开源约 0.5–1 个身位，尤其是在细粒度 OCR、图表理解、视频长序列方面。
- 开源多模态模型适合标准化视觉问答（如“这张图里有没有违规操作”），不适合创意图像生成（需搭配 Stable Diffusion 等专用生成模型）。
| 推荐方案 | 适用情况 | 说明 |
|---------|---------|------|
| 闭源首选：GPT-4o / Gemini 1.5 Pro / Claude 3 Sonnet | 复杂图文分析、长视频理解、多模态 Agent | Gemini 1.5 Pro 支持百万级 Token 上下文，可输入数小时视频；GPT-4o 音视频端到端延迟极低 |
| 国内闭源：通义千问-VL / 文心一言多模态 / 讯飞星火-V3.5 | 中文文档 OCR、电商商品图理解、教育阅卷 | 对中文排版、表格、手写体识别优化更好 |
| 开源/端侧：Qwen2-VL / LLaVA / GLM-4V-9B / MiniCPM-V | 私有化图文审核、机器人视觉、手机端侧应用 | Qwen2-VL 在多种尺寸下都表现出极佳的视觉理解性价比；MiniCPM-V 可在手机端实时运行 |
成本与部署警示：
- Token 计费陷阱：多模态输入通常按“文本等效 Token”收费。一张高分辨率图片可能被拆成上千个视觉 Token，单次调用成本是纯文本的 3–10 倍。上线前务必做成本测算（18.1 节）。
- 生成 vs. 理解分离：当前开源生态中，“理解”可用 Qwen-VL/LLaVA，“生成”仍需调用 Stable Diffusion 3 或闭源 DALL·E 3。不要期待一个 7B 多模态模型既能精准读图又能高质量生图。
- 端侧多模态：如果做手机 App 或边缘设备（如智能眼镜），首选 MiniCPM-V、Phi-3 Vision（2.7B–8B），配合 NPU 量化推理（25.2 节）。
六、快速选型速查表
| 业务场景 | 推荐规模/类型 | 闭源首选 | 开源/私有化首选 | 必配技术 |
|---------|--------------|---------|---------------|---------|
| 通用对话 | 70B+ 或顶级闭源 | GPT-4o / Claude 3.5 | Llama 3 70B / Qwen2 72B | SFT、安全过滤 |
| 代码辅助 | 7B–33B 代码专用 | Copilot / Claude 3.5 | DeepSeek-Coder / Qwen2.5-Coder | FIM、RAG（代码库） |
| 企业客服 | 7B–13B 够用 | GPT-3.5-Turbo / 千问-Turbo | GLM-4-9B / Baichuan2-13B | RAG、意图路由、人工兜底 |
| 复杂推理 | 70B+ 或专用推理模型 | GPT-4o / o1 / Claude 3 Opus | Qwen2 72B / Mixtral 8×22B | CoT、工具调用、Agent |
| 多模态理解 | 7B–72B 视精度而定 | GPT-4o / Gemini 1.5 Pro | Qwen2-VL / LLaVA | 分辨率控制、OCR 后处理 |
最后一条实用原则：选型时不要只看榜单分数（MMLU、GSM8K 等，见 11.1 节），务必拿真实业务数据做 bad case 测试。一个在你的客服知识库上表现优异的 13B 微调模型，远比一个在你的领域频繁幻觉的 70B 通用模型更有价值。在 14.4 节中，我们将给出具体的评估与选型测试流程。