这两年做AI应用开发和模型选型我最大的感受是市面上大模型多到让人眼花缭乱真正要落地的时候拼的不是谁的参数大、谁的榜单分高而是你能不能把手头的业务场景和合适的模型对上号。前阵子我集中整理了一份国内外知名大模型及其应用的全景资料从模型维度的能力对比到应用维度的落地方式边整理边踩坑攒了不少一手经验。这篇就把我的梳理思路、主流模型的实际体验、以及本地部署和微调的实操心得一次性讲清楚给正在做技术选型、准备入门大模型应用开发的朋友做个参考。1. 大模型格局先把“谁在台上、各自擅长什么”搞清楚1.1 国外头部模型闭源旗舰与开源标杆的差距在缩小国外大模型这几年迭代速度非常快但我实际用下来真正值得放进选型池子的其实就那么几家。OpenAI 的 GPT 系列依然是绕不开的参照系。GPT-4o 把多模态、低延迟语音、工具调用整合得非常好日常对话和复杂指令跟随的能力在很长一段时间里都是天花板级别的存在。后面对标科研和复杂逻辑推理的 o1 系列又在数学、代码、科学推理这些需要多步思考的任务上拉开了一截。我的真实感受是如果你要做面向海量用户的产品GPT 稳定性和泛化能力是最省心的但它的 API 成本和部分地区访问的网络环境要求一直是两个绕不开的坎。Anthropic 的 Claude 系列则是我个人在编程场景里最偏爱的模型。Claude 3.5 Sonnet 和后来的 3.7 系列代码生成、代码审查、工具调用这三项能力非常扎实长上下文的理解能力也没有明显的“中间遗忘”问题。特别要提的是 Claude Code 这类 agent 式编程工具它让人工智能从“帮你补全代码”进化到“自己读代码库、自己规划、自己调试”实际用下来效率提升非常明显但也对模型上下文长度和指令遵循能力要求极高。Google 的 Gemini 系列尤其是 Gemini 1.5 Pro 之后的版本走的是一条“超长上下文原生多模态”的路线。百万级 token 的上下文窗口在处理超长文档、多轮会议记录、视频内容理解这些场景下确实有碾压性的优势。如果你经常要跟几十万字的法律合同、研究报告打交道Gemini 是我用过的最舒服的选择。Meta 的 Llama 系列则是开源模型的标杆。Llama 3.1 405B 虽然庞大但它真正厉害的地方是带起了一个完整的开源生态后面大量微调模型、量化版本、本地部署工具都以 Llama 为底座。我的评价是闭源模型负责“效果天花板”开源模型负责“场景落地自由”这两者之间的差距正在肉眼可见地缩小。1.2 国内头部模型DeepSeek、Qwen、GLM、Kimi 各有绝活国内大模型过去两年给我的感觉是“卷”出了实际价值不再是简单跟随而是在某些维度上做出了自己的特色还顺手把 API 价格打了下来。DeepSeek 是这里面最让我惊喜的一家。V3 采用了 MoE 架构用很低的训练成本达到了接近一线闭源模型的效果后来的 R1 系列在推理能力上更是把思维链公开化让整个行业都开始重新思考“推理模型”怎么做。关键是 DeepSeek 的 API 价格便宜得离谱我做过对比同样量级的中文对话任务它的成本可能只有 GPT-4 的几十分之一。对于预算有限又有质量要求的团队DeepSeek 几乎是必须考虑的一个选项。阿里系的通义千问 Qwen 家族则是开源阵营里的顶梁柱。Qwen2.5 系列从 0.5B 到 72B 参数全覆盖中文能力扎实英文也稳后面的 Qwen-VL 多模态版本在中文 OCR、文档理解这些场景表现非常实用。我见过大量企业做私有化部署底座清一色选 Qwen原因就是它生态完整、微调工具链完善、社区资料多真出问题了能搜到解决方案。智谱的 GLM 系列在代码和工具调用上做得不错GLM-4 系列对 function calling 的支持很完整这让它在 Agent 类应用里接受度很高。智谱的产品线铺得也全从对话模型到 Agent 开发平台再到视频生成模型都有布局适合想在一个生态里解决多个需求的团队。月之暗面的 Kimi 当初是靠超长上下文出圈的它把“处理超长文本”这个体验做到了极致中文场景下几十万字的文档直接扔进去就能问答。虽然后面各家都在追上下文长度但 Kimi 在“长文本理解的产品化”上依然有积累文档分析、合同审查这类场景我会优先推荐它。百度的文心一言则胜在中文场景的深度优化和企业级生态百度搜索和百度云的能力可以无缝整合对已经在百度体系内的项目团队来说是最顺手的。1.3 开源与闭源的选型逻辑不要为了开源而开源很多团队一上来就纠结“我要不要用开源模型私有化部署”我觉得这个问题的答案完全取决于你的业务约束而不是技术偏好。闭源模型 API 的核心优势是“开箱即用、效果最好、零运维”。你不需要管 GPU、不需要管模型量化、不需要管推理优化写几行代码就能接入。缺点是数据要经过第三方服务、成本随调用量线性增长、而且可能有供应商锁定的风险。开源模型则相反数据完全私有化、长期成本更可控、可以针对自己的业务做微调但你要自己解决推理服务器、显存、并发优化、模型更新维护这一堆问题。我个人的建议是分阶段走产品验证阶段用闭源 API 最快跑通业务逻辑别在部署上浪费宝贵的时间业务模式确认了、用户量起来了、数据安全要求变高了再评估是否切到开源模型做私有化部署。这样既不会因为过早投入基础设施而拖慢进度也不会在数据安全上留下隐患。2. 模型维度选型前必须看懂的几个核心指标2.1 参数量、上下文窗口与成本的真实含义模型参数量是最常被拿出来当卖点的数字但也是被误解最深的数字。参数量大不代表效果一定好因为模型效果还取决于训练数据的质量、训练方法、对齐方式。更值得注意的是很多新模型用的是 MoE混合专家架构参数总量看着吓人但每次推理只激活其中一小部分专家网络实际计算量远低于同等参数量的稠密模型。所以判断模型性能我一般只看“实际激活参数”和“推理速度”而不是总参数。上下文窗口是另一个被营销放大的指标。厂商宣称支持 1M token 上下文不代表它真的能在 1M 长度下保持高质量回答。我实测过不少模型在长上下文下普遍存在“中间遗忘”问题也就是开头和结尾的信息模型记得清楚中间段落的内容经常被忽略。有效上下文长度往往只有宣称值的四分之一到一半。所以选型时如果你的场景确实需要超长文档处理一定要自己构造一份带关键信息在中间位置的长文本实测而不是看宣传页上的数字。成本维度则要算细账。API 计费分输入 token 和输出 token两者价格往往差 3 到 5 倍。对话场景里用户每发一句话你可能要经历系统提示词、历史消息、检索上下文的一轮拼接实际消耗的输入 token 会是用户消息的几十倍。我见过太多项目上线后发现 token 账单远超预估就是因为没算上下文累积的成本。现在很多平台提供 prompt 缓存命中后价格能降到原来的十分之一这也是一个重要的省钱手段。2.2 多模态能力从“看得懂图”到“看得懂视频”多模态大模型已经是标配了但不同模型的多模态能力侧重点差异很大。理解类任务上GPT-4o 和 Gemini 是两项标杆。Gemini 原生就是多模态训练的在处理视频抽帧理解、音视频混合内容上有天然优势GPT-4o 则在图像细节理解和交互式对话上更自然。国内的 Qwen-VL 在中文场景的 OCR、表格识别、文档版面理解上做得非常实用我做过测试中文扫描件里的排版、手写批注、细微字体Qwen-VL 的还原度是国产模型里最稳的。生成类任务则是另一条赛道文生图领域有 Midjourney、Stable Diffusion文生视频领域有 Sora 和一批国内产品但这类模型和语言大模型往往是分开选型的不要指望一个模型全包。业务选型时你要想清楚产品到底需要哪几个模态。如果只是做图文客服那只需要理解能力如果做视频内容分析Gemini 这类原生多模态会省很多事如果做文档资料库那 OCR 强不强比“它能不能看图”重要得多。2.3 排行榜与评测指标别被分数带偏MMLU、HumanEval、GSM8K、LMSYS Chatbot Arena……市面上评测榜单非常多但把榜单分数当选型依据是非常危险的。榜单的常见问题有三个第一是测试集污染有些模型的训练数据里就包含了公开测试集分数自然虚高第二是指标单一HumanEval 考的是代码补全但它考的题目偏简单跟真实工程项目里多文件、依赖复杂、业务场景特殊的代码完全是两回事第三是排行榜榜单一出厂商就会针对性地优化评测集整个过程有点像我以前读书时的“刷题应试”。所以我建议每个团队都建一份自己的“黄金测试集”从真实业务里抽 50 到 100 条有代表性的问题包含正常输入、边界输入、异常输入让候选模型跑一遍再根据实际的输出质量、格式符合度、响应速度综合打分。这个方法比任何公开榜单都可靠。3. 应用维度大模型落地最实的五个方向3.1 对话助手与内容生产最成熟也最内卷对话助手是大众认知度最高的应用场景包括智能客服、营销文案生成、翻译、写作辅助等。这类应用的工程难点已经不在模型本身而在产品层面的设计怎么设计系统提示词让模型保持角色设定、怎么管理多轮对话的上下文、怎么让输出格式稳定可解析。举个例子做电商客服机器人系统提示词里要写明身份、语气约束、知识边界、兜底回答策略用户提问进来先做意图分类是咨询订单、退换货还是投诉再决定要不要调用订单查询工具而不是让模型直接瞎猜订单信息最后在输出环节要求模型必须返回 JSON 格式然后做一层 schema 校验防止模型偶尔输出额外文字把程序搞崩。我踩过的坑是早期为了省 token把系统提示词写得特别短结果客服机器人频繁“越权”回答一些不该承诺的内容。后来把提示词拆成“人设模块业务规则模块兜底策略模块”三段稳定性明显改善。3.2 AI编程从辅助补全到 Agent 式开发AI 编程是这两年落地效果最炸裂的方向从 GitHub Copilot 的代码补全到 Cursor 的对话式修改文件再到 Claude Code 这类能自己读代码库、自己跑测试、自己修 bug 的编程 Agent已经真实改变了开发者的工作方式。我现在的常规工作流是用 Claude Code 或本地 Ollama 接编程插件做代码生成和重构让 AI 先读一遍项目结构理解依赖关系之后实现新功能我再重点 review 核心模块的业务逻辑。像“VS Code Claude Code 插件接入本地 Ollama”这种操作我专门试过配置的核心是让 Ollama 跑一个代码能力够强的模型比如 Qwen2.5-Coder 或者 DeepSeek-Coder 的量化版然后在插件里把 API 地址指向本地服务。这么做的好处是代码不会外传适合有保密要求的项目缺点是本地模型的代码能力和 GPT/Claude 这类一线闭源模型还是有一截差距复杂工程里的表现会有明显落差。3.3 知识库问答与 RAG企业落地的核心玩法RAG检索增强生成是当前企业级知识库问答最主流的技术方案它的思路是不指望模型记住你的私有文档而是先把文档切分成小块、向量化存入数据库用户提问时先检索出最相关的文档片段再把这些片段和问题一起交给大模型生成回答。这样既解决了模型的知识过时问题也解决了私有数据的安全问题。实际做 RAG 项目最影响效果的不是模型而是检索环节。我踩过的坑包括文档切分策略不对把强相关的上下文切碎了导致检索结果不完整只用向量检索关键词匹配能力弱专业术语容易查不到没有做重排召回的前几段内容相关度不够。后来我总结出一套相对有效的参数组合切分 chunk size 用 400 到 600 个字符、重叠 80 到 100 个字符采用“关键词 BM25 向量检索”的混合检索召回 20 到 30 条候选后用 rerank 模型取前 5 条最后再交给大模型生成并附上引用来源。这套流程跑通后知识库问答的可用性会有质的提升。3.4 Agent 与自动化流程让模型动手干活Agent 是大模型从“聊天工具”走向“生产力工具”的关键一步。核心机制是函数调用模型根据用户指令决定调用哪个工具、传入什么参数、拿到结果之后怎么继续最终完成一个多步骤的任务闭环。我做过一个自动生成行业调研报告的 Agent流程是用户输入一个行业主题Agent 先拆分任务为“行业背景、市场规模、主要玩家、趋势总结”几个模块然后并行调用搜索接口获取资料对每部分内容做摘录和归纳最后按预设模板拼接成一份带数据来源的完整报告。这类应用的技术难点有三个一是任务分解的粒度拆得太粗容易让模型“迷茫”拆得太细又费 token二是工具返回结果的解析搜索结果常常有噪声需要设计清晰的结果格式并让模型过滤无关内容三是循环终止条件Agent 容易陷入“调工具-得结果-再调工具”的死循环必须设定最大迭代次数和退出判断逻辑。MCP模型上下文协议这类标准协议出现后Agent 对接外部工具的成本已经大幅降低这块的想象空间非常大。3.5 垂直行业场景农业、教育、医疗等细分突破通用大模型解决的是“通用问题”但真正的商业价值往往藏在垂直场景里。近几年我比较关注的是农业、教育、法律、医疗这四个领域的应用因为它们都有“知识密度高、文本量大、需要专业决策支持”的特点特别适合大模型切入。农业方向的“AI 大模型”是个很有潜力的方向比如把作物生长模型、土壤传感器数据、气象预报数据接入大模型实时监测土壤墒情、气象变化智能给出灌溉、施肥、病虫害防治建议。用户只需用自然语言问“这块地现在的墒情怎么样”系统就能结合实时监测数据和农业知识库生成一份科学决策建议把专家经验转化为可规模化的服务。教育领域可以做错题归因分析和个性化练习生成法律领域可以做合同审查和案例法规检索医疗领域可以做病历结构化和辅助诊断建议这个方向尤其要注意只做辅助、不作诊断界定好责任边界。做垂直应用的核心策略是用通用大模型做“理解与生成”用行业数据构建“知识与规则”两者结合才能既保证泛化能力又保证专业深度。4. 从“用别人的”到“自己部署”本地化与微调实操4.1 Ollama 本地部署从下载到跑通全流程本地部署大模型绕不开 Ollama 这个工具。它最大的价值是把模型的下载、运行、API 暴露这几件事简化成了“一条命令”省掉了原来配置 Python 环境、装 Transformers、管理 CUDA 版本等一系列痛苦。我现在部署模型的首选方式就是 Ollama。基础流程是先装 OllamaLinux 和 macOS 都有现成安装脚本Windows 也有安装包然后用ollama run拉取并运行模型。比如拉取一个中文效果不错的 Qwen2.5 7B 模型执行ollama run qwen2.5:7b第一次会下载模型权重之后启动就都在本地了。如果要在应用里接入Ollama 默认启动一个本地 HTTP 服务地址是http://localhost:11434任何编程语言都可以通过调用它暴露的 OpenAI 兼容接口来完成集成。本地部署的甜头是数据完全自己掌控、可以离线使用、长期没有按量计费的压力。代价是硬件门槛。我的经验是16GB 显存的显卡如 RTX 4090可以流畅运行 7B 到 8B 的量化模型32GB 以上显存可以尝试 14B 到 32B 的量化模型要跑 70B 级别的大模型至少需要双卡或者单张 80GB 显存的专业卡而且推理速度还是不如云端。如果你只有 8GB 显存也别灰心可以跑 1.5B 到 3B 的小模型配合针对性的知识库在特定任务上依然能做出可用的效果。4.2 微调什么时候该做、怎么做最划算微调是很多团队拿到开源模型后第一件想做的事但我要说一句微调不是万能的它解决的问题非常有限很多问题在微调之前就应该通过 Prompt 工程和 RAG 解决。我的判断标准是如果模型指令跟随没问题只是回答不够专业优先加 RAG把专业知识塞进上下文如果模型输出的格式永远不符合要求比如总是忘记按 JSON 输出或者需要模型长期模仿某种特定文风、术语体系这才是微调的主场。微调适合解决的是稳定性问题而不是知识问题。真到要微调的时候我的建议是从 LoRA 这类参数高效微调方法入手。用 QLoRA 技术可以在单张消费级显卡比如 24GB 的 RTX 4090上微调 7B 到 13B 的模型。数据准备上几百到几千条高质量的高质量样本往往就够用了数据质量远比数据量重要我见过有人用几百条精心整理的数据微调出的效果比用几万条劣质数据好得多。工具方面推荐开源的 LLaMA-Factory它把数据准备、训练、评估、导出整个流程图形化了即使没写过多少微调代码的人也能上手。微调之后还有一个容易忽略的步骤评估。不要只看训练 loss 降没降要拿微调前后各跑一遍你的黄金测试集用同样的测试问题对比两版输出确认在指标上真的提升了、以及是否产生了“灾害性遗忘”即老能力反而退化了。我踩过的一个典型坑是让模型学会了新的输出格式结果原有的意图识别能力变差了最后只能混合不同 LoRA 权重来平衡。4.3 硬件选型与成本估算本地部署到底省不省钱本地部署这件事算账要算三笔硬件一次性投入、运维成本、GPU 利用率。硬件选型上我给出一个常见经验表格以量化后的推理为例模型规模推荐显存参考硬件适用场景1.5B - 3B6 - 8 GBRTX 3060 / 4060简单对话、分类、格式化输出7B - 8B12 - 16 GBRTX 4070 Ti / 4090通用对话、RAG、代码补全14B - 32B24 - 48 GBRTX 4090 / 多卡 / A6000高质量生成、复杂推理70B 级别48 - 80 GBA100 / H100 / 多卡接近 GPT-4 级别的体验运维成本经常被忽略。GPU 服务器不像普通云服务器要处理驱动兼容、推理框架配置、并发性能调优、模型升级备份等一系列问题没有专职的算法工程师这块会非常耗时间。GPU 利用率则是另一个隐性成本如果你部署一个 70B 模型但每天只有几千次请求大部分时间 GPU 都在空转这比按量付费的 API 贵得多。我的建议是低并发、重数据安全、离线优先的场景本地部署是合理选择高并发、需求波动大、团队没有运维能力的场景老老实实用 API。两者之间也可以做混合——常见问题走本地小模型复杂问题调用云端大模型把成本和效果做一个平衡。5. 实操中的坑与排查记录5.1 本地部署最常见的三个坑第一个坑是模型下载和依赖安装慢。Ollama 在模型拉取上依赖开源模型仓库国内网络环境经常卡住。解决办法是用支持的镜像源或提前把模型文件转到内网也可以通过在环境变量里指定模型下载目录把模型预置到服务器上。这类问题归根结底是网络和存储规划问题建议部署前先确认目标机器的存储空间一个 7B 模型量化版大约 4 到 5GB70B 模型动辄 40GB 以上。第二个坑是显存溢出OOM和推理速度过慢。这两个问题本质是同一个问题模型太大或并发太高超过了显卡承载能力。解决方案按优先级排是先换更小尺寸的模型再开启量化比如 4bit 量化能把显存占用降到原来的三分之一左右再压缩上下文长度限制最后才是加硬件。我一个项目里就是通过把上下文长度从 32K 降到 8K直接让原本 OOM 的 7B 模型跑得又稳又快。第三个坑是中文效果不如英文。原因往往是原始模型的训练语料里中文占比不足。解决办法有两个方向一是优先选择中文优化模型Qwen、GLM、DeepSeek 这些国内模型的中文能力明显强于同规模的国外开源模型二是通过微调喂一批中文业务语料。千万不要指望靠 Prompt 让一个英文为主训练的模型突然变得很懂中文。5.2 API 接入与应用开发中的高频错误对接大模型 API 的时候我见过团队踩遍也不长记性的问题有这么几个上下文长度超限这是报错频率最高的问题。尤其是实现 RAG 或多轮对话时拼接的历史消息和检索片段很容易超过模型的最大上下文。解决思路是给对话消息做截断策略历史消息太长时优先保留系统提示词和最近的对话中间的旧消息做摘要压缩。JSON 输出不稳定。很多业务要求模型返回结构化数据但模型偶尔会在 JSON 前后附加解释文字导致解析失败。解决办法是启用平台的结构化输出能力或者给系统提示词里加格式硬约束同时在代码里做容错解析截取第一个{到最后一个}之间的内容再解析。调用频率限制和配额管理。免费或低价额度用完后请求直接失败这在生产环境尤其致命。建议设计 API Key 轮换机制和限流重试逻辑把错误按类型分类处理限流类错误可以做指数退避重试鉴权类错误则要立即告警。顺便说一句很多搜索热词里会出现“此版本的应用未配置为通过 Google Play 结算”“Win11 微软账户登录错误代码 0x8004de44”这类问题看着跟大模型开发无关其实它是应用上架、系统环境方面的问题。做 AI 应用上线时如果选择上架安卓应用商店未配置好结算和支付服务就很容易被拒开发环境里用最新系统时也可能冒出来各种账户权限错误。这类问题虽然烦人但通常跟模型本身无关属于开发链路里的环境问题排查思路是先把官方文档里的结算配置项逐条核对一遍再把系统更新和应用权限重置。5.3 选型避坑清单给新入行的团队提个醒最后整理一份我觉得每个大模型应用团队都该打印出来的避坑清单都是我拿钱和时间换来的教训不要为了开源而开源先问自己三个问题数据真的敏感到不能出内网吗团队有人能维护推理服务器吗长期调用量大到 API 费用顶不住吗三个里至少中两个再考虑私有化部署。不要被榜单和宣传文案带偏任何模型发布时的 Demo 都是精挑细选的你的真实业务数据才是唯一的评测标准。不要上来就微调先用 Prompt 和 RAG 试到没有优化空间了再谈微调。不要忽略安全与合规用户输入可能包含 prompt 注入要加输入过滤和输出脱敏尤其是面向 C 端的应用。不要只测“回答得对不对”而忽略“回答得稳不稳”同一个问题跑十次看输出质量和格式的一致性稳定性差的模型在生产里会让你崩溃。还有一点不要为了追求大模型的最新版本而频繁切换底层模型模型更新会带来结果变化这在用户侧往往体现为“怎么今天回答风格跟昨天不一样了”非必要不升级。6. 从资料整理到实际选型的一些个人体会我见过太多人把大模型选型当成“选一个最强的模型”但实际项目里真正重要的从来不是模型本身而是你的业务定义、数据质量、评测方法和工程兜底。强模型能掩盖很多工程缺陷但掩盖不等于解决弱模型配上精准的提示词、扎实的检索和高质量的数据也能做出让用户满意的产品。选型的核心逻辑是先用效果最好的模型验证业务可行性再用成本最低的模型满足业务需求最后用最懂你业务数据的模型形成差异化壁垒。我自己每次做新项目都会先准备一份黄金测试集把国内外主流模型都跑一遍再根据输出质量、成本、响应速度、数据安全四个维度综合打分对照着做决策。这套方法虽然土但从来没有出过大错。希望这篇从模型到应用、从部署到避坑的全景梳理能让你少走几步弯路。