大模型选型双维度指南：模型与应用的全景落地

前阵子给不同团队做大模型选型咨询，前后盘了不下二十个国内外大模型，从闭源 API 到开源权重，从纯文本模型到多模态模型，最后整理成了一份“模型/应用”双维度的对照表。这篇文章就是把我的调研思路、实际测试记录和踩坑经验完整写出来。“模型维度”回答的是“哪个模型能解决我的问题”，“应用维度”回答的是“怎么把模型接到业务里并稳定跑起来”。如果你正在做 AI 应用开发、内容工具、企业知识库，或者只是想让本地电脑也跑起来一个大模型，这篇内容应该能帮你少走不少弯路。

1. 大模型全景：先搞清楚“模型维度”到底在盘什么

模型维度不是简单罗列几个名字就算完事，至少要看四层：能力分层（通用对话、推理、代码、多模态）、部署形态（闭源 API、开源权重）、参数规模（从 7B 到 400B+）以及授权协议（商用是否免费）。只有把这四层叠在一起看，才知道某个模型在你的场景里到底能不能用。

1.1 国际阵营：巨头全能型与垂类专精型并存

国际上现在基本是“三巨头 + 一批开源猛将”的格局。OpenAI 的 GPT 系列依然是综合标杆，尤其是加入了 o 系列之后，在数学、代码、复杂推理这类需要“多步思考”的任务上优势很明显。如果你要做的不是聊天机器人，而是 Agent、任务拆解、自动调用工具，这类推理型模型是首选。

Anthropic 的 Claude 系列在长上下文和代码生成上非常出色，写作质量也一直是第一梯队。实际用下来，Claude 在处理 10 万 token 以上的文档时，细节记忆力比很多同类模型稳得多，做法律合同、研究综述这类内容很合适。Google 的 Gemini 则赢在“原生多模态”，图像、视频、音频从训练的时候就在一起，不是先文本后接视觉那种拼接方案，在视频理解和跨模态检索场景下体验更自然。

开源阵营里，Meta 的 Llama 系列生态最庞杂，社区微调版本最多，适合做私有化部署的底座；Mistral 和微软的 Phi 系列走“小而强”路线，7B 级别就能有不错的常识能力，跑在笔记本上也不至于太吃力。这里要提醒一句：开源模型不是参数越大越好，对大多数内部工具来说，7B 到 14B 的量化模型是最容易落地、也最容易控制成本的区间。

1.2 国内阵营：从通用对话到行业大模型全面开花

国内模型这几年的进步速度比很多人想象的更快。DeepSeek 是最典型的一个，开源权重 + 超低价格 API 双重出击，V3 的综合能力已经摸到闭源第一梯队的边，R1 在推理任务上也很能打。我自己用 DeepSeek 做中文长文本抽取和代码生成，效果经常比部分国际模型还要贴中文语境。

阿里的 Qwen 系列是另一个“必须放在清单里”的名字。Qwen 从 0.5B 到 72B 甚至更大规模都有开源版本，中文能力强，周边工具链也最完整，配合本地部署、微调生态非常顺手。智谱的 GLM 系列在工具调用和 Agent 方向上做得早，API 的 function calling 稳定性很高；Kimi 超长文本能力强，适合喂几十万字资料做问答；字节豆包背靠应用场景，内容创作和娱乐向的产品调用很流畅。此外百度的文心、腾讯的混元、讯飞星火、MiniMax 也都在各自赛道里有固定用户群。

为什么要单列国内阵营？因为选型不只是看“跑分”，还要看数据合规、服务可用性和中文语料贴合度。很多企业内部数据根本不允许出内网，这时候开源国产模型就是最现实的答案。而且国内模型普遍对中文指令、中文格式的理解更好，少了很多 prompt 翻译成本。

2. 应用维度：模型再好，用起来才算数

模型能力是“原料”，应用方式才是“烹饪”。同一个 Qwen 模型，用 API、本地部署、微调三种方式接入，业务效果和成本可能相差好几倍。所以应用维度我拆成三条主路：API 接入、本地部署、微调定制。

2.1 API 接入：最快跑通业务的方式及其关键参数

API 接入最大的价值是快。没有 GPU、不用管运维，注册拿 key，写几十行代码就能把大模型接进你的业务流程。大部分主流厂商现在都提供 OpenAI 兼容接口，切模型搬家成本比想象中低很多。

但快不代表无脑调，有几个参数必须亲手试过才理解：

• temperature：控制随机性。分类、抽取任务建议 0.2 以下，创意写作可以拉到 0.8 以上。我见过很多团队用默认值做知识库问答，结果同一问题每次答案都不一样，误以为模型有问题，其实就是 temperature 没调。
• max_tokens：决定单次回复长度上限。很多人只设几百，长报告直接被截断；但设太大会增加成本和延迟，要按业务量级合理切分。
• response_format / json_mode：做程序对接时一定要开 JSON 模式，否则模型会在答案里夹带解释文字，解析 10 次崩 3 次。
• stream：流式输出能显著降低首字延迟，做对话产品和实时交互体验差别很大。

一个最简单的调用示例（OpenAI 兼容接口）：

from openai import OpenAI client = OpenAI( base_url="https://api.your-provider.com/v1", api_key="sk-xxxx" ) resp = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": "你是一个严谨的助手，只输出判断结果。"}, {"role": "user", "content": "帮我判断这句话的专利风险。"} ], temperature=0.1, max_tokens=1024, stream=False ) print(resp.choices[0].message.content)

我自己的经验是：先用 API 把业务跑通，观察真实数据上的表现，再决定要不要做本地部署或微调。不要一上来就买显卡，很容易投入过大。

2.2 本地部署：数据不出内网，个人电脑也能跑

本地部署的核心动机是隐私、合规和长期成本。企业知识库、医疗数据、金融报表，这些东西发给外部 API 总是让人不放心。而且当调用量足够大之后，API 账单可能比自建 GPU 还贵。

个人电脑部署现在真的门槛低了很多。推荐优先尝试 Ollama，它把模型下载、量化、运行、API 服务全部封装好了，执行三条命令就能起来一个模型：

ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct ollama serve

如果还要走 API 协议，本地会自动在 11434 端口暴露一个 OpenAI 兼容接口，直接换 base_url 就能用。更专业的团队可以用 vLLM 做高并发部署，吞吐量比 Ollama 高几倍，但配置也复杂不少。

这里必须解释一下量化。同样的模型，FP16 精度可能要 16GB 显存，量化到 INT4 可能只要 5GB，内存大幅缩小，性能损失却很小。对 7B~14B 模型来说，int4 量化是个人电脑最合理的平衡点。如果你只有 8GB 显存，跑 qwen2.5:7b-instruct-q4_K_M 基本没问题；想跑 32B 模型，即使量化了也建议至少 24GB 显存，否则只能靠 CPU 硬扛，速度会非常难受。

2.3 微调：让通用模型变成业务专家的主流路径

很多团队有一个误区：模型回答不准确就想着微调。其实第一反应应该是改进 prompt 和检索（RAG），因为 RAG 能在不改模型权重的情况下注入实时知识。只有当模型的“行为风格”或“表达格式”与业务期待不一致时，比如必须按特定模板输出、必须用行业黑话、必须模仿某个客服风格，微调才比 RAG 更直接。

微调技术栈现在非常成熟，首选 LoRA / QLoRA。LoRA 只训练一小部分低秩矩阵，显存占用小；QLoRA 更进一步，把基座量化后再挂 LoRA，单张 24GB 显卡就能微调 70B 级模型。数据格式一般是这样的：

[ { "instruction": "判断以下合同条款是否存在风险", "input": "乙方应在甲方指定日期前交付全部成果。", "output": "风险较低，但缺少违约责任约定，建议补充逾期条款。" } ]

训练时主要盯三条：学习率最好在 1e-5 到 5e-5 之间，太大容易灾难性遗忘；epochs 一般 1~3 轮就够，重复太多会在训练集上背答案而泛化差；验证集一定不能用训练数据，否则你看到的指标全是假的。

3. 选型决策与实操复盘

看完模型维度和应用维度，最核心的问题就是“我到底该选哪个”。这块没有标准答案，但有一个可以反复使用的决策套路。

3.1 需求盘点五步法

第一步，识别任务类型。你是做文本分类、信息抽取、开放问答、代码生成还是多模态理解？不同任务对模型的能力图谱要求完全不同。分类和抽取用中小模型就够，复杂推理和长文写作才需要旗舰模型。

第二步，确定数据边界。数据能不能出内网？用户隐私敏感度多高？只要有一条不允许，就只能在开源模型里挑。

第三步，算清楚预算。API 按 token 计费，本地部署要算显卡折旧和电费。一次 10 万 token 的文档分析，API 成本可能是几毛钱到几块钱，但本地跑可能更慢。模型再强，成本超过收益就是不可用。

第四步，评估延迟和并发。C 端对话要求首字 1 秒内，B 端批处理可以等几分钟。延迟敏感业务优先选闭源大厂的高并发端点，或本地部署小模型；离线批量任务反而可以用大模型精调准确率。

第五步，选择模型层级。先把顶级闭源 API 作为“能力上限”跑通，确认效果可行，再找效果相近但成本更低的开源模型替换。我自己做选型时，经常先用 GPT-4o / Claude 顶配做“黄金测试集”，再拿开源模型对比分数，差得不多就直接切换。

3.2 主流模型对比表

下面这张表是我这段时间反复调整后留下来的精简版本，重点关注“能不能用、划不划算”：

读表的时候不要只看单项最高分，要把自己所在的行列代入进去。举个例子，如果做企业内部知识库，且不允许数据外发，那结论基本就是 Qwen2.5 或 Llama 3 本地部署；如果是给销售写营销话术，CLAUDE 或 GPT-4o 的创意质量会更好。

3.3 一次完整的本地部署实操：Ollama + Qwen

我拿自己踩过一遍坑的流程举例。目标很朴素：在一台 16GB 显存的 Windows 机器上，跑起一个本地问答 API。

第一步，安装 Ollama。Windows 直接下载 exe 安装包，装完命令行里验证ollama --version。第二步，拉取模型，注意带精度标签：

ollama pull qwen2.5:7b-instruct-q4_K_M

这一步我刚开始没带量化标签，直接拉了个 fp16，结果 16GB 显存加载后生成本地早被占满，一跑就 OOM。所以模型标签要看清楚。第三步，启动并调用 API：

ollama serve

终端保持打开，本地服务就在 11434 端口。用 Python 调用时，base_url 改成http://localhost:11434/v1，api_key 随便填一个字符串就能通：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) resp = client.chat.completions.create( model="qwen2.5:7b-instruct", messages=[ {"role": "user", "content": "用一句话介绍知识抽取是什么"} ], temperature=0.3 ) print(resp.choices[0].message.content)

这次部署后还有个小问题：Ollama 默认只监听本机，如果你要在另一台电脑上调用，需要在启动时设置OLLAMA_HOST=0.0.0.0，并且注意防火墙放行 11434 端口。我在这卡了整整半小时，排查了一圈才发现是 Windows 防火墙默认拦截了外部访问。

4. 常见问题与避坑指南

这部分是我实际跑项目时被反复教育的地方，整理成速查表，每一类都值得收藏。

4.1 API 调用最容易踩的四个坑

限流和超时是第一坑。大模型 API 的并发配额比你想象中低，大批量请求时最好做一层“线程池 + 重试 + 指数退避”，每秒请求数控制在厂商建议的 70% 以下，这样既稳又不浪费。

第二坑是内容截断。长文档摘要时，如果只设max_tokens=512，后半段结论经常被切掉。解决方法是把任务拆成多段再合并，而不是无脑调大 max_tokens，后者不仅贵，还容易超过上下文窗口。

第三坑是输出格式不稳定。用 openai 兼容接口做结构化抽取时，我不会信任自然语言输出，而是把 JSON Schema 放在 prompt 里并开启response_format={"type": "json_object"}，返回之后再用json.loads解析并校验必填字段。解析失败就重试一次，这种稳得多。

第四坑是上下文长度认知模糊。你设了 128K 窗口，并不意味着模型真的能有效利用全部内容，实测中很多模型对长文本中间的细节记忆会明显衰减。重要信息要么放开头和结尾，要么先检索再拼接。

4.2 本地部署的五个常见问题

显存不足是最普遍的错误。解决方法按优先级是：降低量化等级（fp16 到 int8 再到 int4）、换更小的模型（14B 换 7B）、开启 GPU offload 部分层跑 CPU。不要一上来就买新卡，先看量化能不能救。

第二是 CPU 推理慢到怀疑人生。如果模型加载后发现 GPU 占用率很低，检查一下是否安装了对应平台的加速后端。NVIDIA 显卡要装 CUDA 版 Ollama，AMD 用户老老实实走 ROCm；Mac 上默认走 Metal 加速，速度通常还不错。

第三是模型“一本正经地胡说八道”。本地开源小模型在没有足够指令约束时，幻觉比大厂 API 更严重。我的应对方法是 system prompt 里强制要求“答案必须基于提供的资料，若信息不足则明确回答不知道”，并且把资料片段直接塞进上下文，而不是让模型凭记忆发挥。

第四是并发能力差。Ollama 单卡处理几个并发请求还行，几十个并发就会排队。如果业务量大，必须上 vLLM + 张量并行，那基本就是真正的私有化大模型平台了。第五是长期运行的内存泄漏。实测某些本地推理进程长时间跑后会越占越多内存，建议加一层每日重启的定时任务，省心很多。

4.3 微调训练里最容易忽视的细节

微调最怕数据泄漏。训练集里如果混入了和验证集同源的句子，验证分数会虚高到没有参考价值。切数据时最好按“文档级”切割，而不是按句子随机切，否则同一个文档的内容会出现在两边，看起来 95 分，上线打回原形。

第二是学习率不匹配 LoRA rank。rank 设 8 但学习率还采用 5e-4 这种大值，训练曲线会剧烈震荡。我习惯 rank=16、lr=2e-4 搭配使用，并在训练中每 100 步打印一次 loss，看到爆涨就立刻停。

第三是“只调思维链格式”的陷阱。很多团队想微调让模型“一步一步思考”，但输出里全是推理过程，业务只需要最终答案。这种情况不一定要微调，一个包含思维链样例的 prompt 往往就够了。别把微调当成万能药。

4.4 提示词工程与上下文工程，其实是低成本高回报的环节

很多模型应用效果不好，问题不在模型，而在你没有先把“提示词工程”和“上下文工程”做扎实。提示词工程里，我常用的三件套是角色设定、指令明确、样例带入：

• 角色设定：告诉模型“你是一个严谨的专利分析师”。
• 指令明确：直接说明“只输出 JSON，不要解释”。
• 样例带入：给一条“输入-输出对照”，模型几乎立刻能对齐格式。

上下文工程则是管理模型的“工作记忆”。大模型的窗口就像一张白板，你把一万条公告全塞进去，模型反而抓不住重点。更合理的做法是先做检索或摘要，只把与当前问题相关度最高的 5~10 个片段放进上下文，并明确标注哪些是资料、哪些是待处理任务。这比无脑扩充上下文窗口有效得多，成本还更低。

5. 多模态与知识抽取：更开放的落地视角

聊完通用文本应用，我想多补一块，因为最近几次选型里，多模态和知识抽取的咨询量明显涨起来了。

5.1 多模态模型带来的新场景

以前想识别一张合同扫描件里的关键条款，得先 OCR 再丢给文本模型，流程又长又容易乱。现在用多模态模型可以直接把图片输入，让它同时读版面、认表格、提取字段。

工业质检是个典型例子，比如服装面料瑕疵检测、安防监控事件识别，传统做法是单独训练一个视觉检测模型，数据标注成本高、迭代慢。现在可以先拿开源多模态大模型做“预筛选”，把明显不合格的图像过滤掉，再对少量疑难样本做人工确认。如果跑通了，再用小模型蒸馏大模型的能力，部署成本能压到很低。

当然多模态模型也有短板，处理高分辨率工业图时显存消耗大，速度慢，所以在实时质检线上，大模型更适合做离线抽检或复杂工单分析，线上实时判断还是留给专用小模型更划算。

5.2 把知识抽取交给大模型：OneKE 更推荐一试

在做企业知识图谱项目时，我关注到开源社区里热度明显上升的 OneKE。它不是通用聊天大模型，而是一个专门做“知识抽取”的模型架构，能从文本中抽实体、关系、事件三元组，把非结构化文档转成结构化图谱数据，很适合合同要素提取、简历解析、政策文件结构化这些场景。

它的价值在于“专”。通用大模型也能抽三元组，但格式变来变去，今天输出列表明天输出 JSON，得花大量时间做解析。OneKE 这类专用抽取模型在稳定性和字段覆盖上更符合程序对接需求。如果你在做知识图谱、语义搜索，非常建议把它作为抽取层 base model，再配合 LLM 做润色和校验，效果比纯靠 prompt 稳定得多。

多模态和知识抽取这两个方向，本质上都是“把大模型用得更深”的尝试。模型已经不是只会聊天的玩具，而是能看、能读、能抽、能建的底座能力。对应用开发者来说，多掌握一种接入姿势，就多一条解决业务问题的路。

最后分享一个我每次都在用的笨办法：在小流量场景先把 3~5 个候选模型接进去，让业务人员用真实数据各跑一周，记录成功率、乱答率、成本，再决定正式模型。盲目相信排行榜没用，排行榜上的分数跟你的业务数据可能根本不是一回事。模型是手段，业务跑得稳才是目的。