最近圈子里聊大模型已经很少有人再问“什么是大模型”了大家更关心的是另一类问题国内外这么多模型到底选哪个本地部署和云端调用怎么平衡微调需要什么显卡以及最实际的——我的业务场景用哪个模型性价比最高这些问题的答案其实都在“模型维度”和“应用维度”这两个坐标系里。趁着这个时间节点我把国内外主流的大模型和应用方案做了一次系统梳理结合我这一年多在真实项目里踩过的坑和验证过的方案整理成一篇可以当“选型手册”用的内容。不管是做AI产品、企业内部工具还是个人折腾本地部署这篇文章都值得花十分钟看完。1. 模型维度国内外大模型格局与选型逻辑1.1 全球一线模型梯队的现状先说国外。OpenAI的GPT系列仍然是综合能力的标杆GPT-4o之后的多模态能力和推理速度有了明显提升生态也是所有模型里最完整的——插件、API、Assistants API、微调接口都成熟。但它的缺点也很明显贵、封闭、数据出境合规问题。Claude系列在长上下文、代码生成和安全对齐上做得非常出色尤其适合处理超长文档和复杂代码库我实测Claude 3.5 Sonnet在解析一万行以上的老项目代码时比GPT-4o更少“断片”。Google的Gemini系列定位是原生多模态视频理解能力独一档但中文语料的细腻度有时不如本土模型。开源阵营里Llama 3系列的生态影响力最大社区适配、工具链、量化方案几乎都以它为准。Mistral系在欧洲市场强速度快、性价比高。而真正让国内玩家兴奋的还是国产开源模型的崛起。1.2 国内模型矩阵与各自的“舒适区”国内头部的几家各有侧重。阿里的Qwen系列千问是目前开源社区最活跃的从0.5B到72B甚至更大覆盖了从手机端到服务器端的全场景。我自己的经验是Qwen在中文指令遵循和结构化输出上已经超过同参数量的Llama——这不是玄学是分词器和中英文语料配比的差距。DeepSeek系列在推理能力和性价比上打出了口碑尤其是R1系列的思维链推理Math和Code场景是强项。智谱的GLM系列在Agent工具调用上做得很早很多RAG和自动化产品里都能看到它的影子。百度文心、字节豆包、腾讯混元则更多和自家云生态绑定适合企业客户直接买服务。这里要提醒一句不要只看公开榜单分数。同一个模型在百科问答、代码生成、合同抽取、情感客服这些场景下的真实表现差异极大。选型前先拿自己的核心业务数据去测AI领域的“以测代选”比任何宣传都靠谱。1.3 模型维度的关键分类不只看名字真正的“维度”拆开来看至少包括这几层参数规模0.5B到7B适合端侧和低延迟场景13B到34B是个人工作站和中小企业的甜点区70B以上基本得上多卡集群了。别迷信“越大越好”我有一套4K的Mac Studio跑70B量化版处理简单对话是够了但想要快速生成高质量长文还是吃力。开源 vs 闭源开源意味着可控、可私有化、可微调但需要自己运维闭源API开发快、效果稳定但长期成本和数据风险要评估清楚。模态支持纯文本、图片输入、视频理解、语音生成……多模态不是“能看图”这么简单不同模型对图文对齐的细节处理差很多。做UI截图理解、票据识别这类场景必须实测。上下文长度很多模型宣称支持128K甚至200K但实际在长上下文中会出现“中间丢失”现象。做长文档分析时建议用“大海捞针”测试法自己验一遍。有了这个框架再去看“国内外知名大模型及应用”思路就清晰了模型维度解决的是“用什么”应用维度解决的是“怎么用”。2. 应用维度大模型到底在哪些场景真正落地了2.1 对话与助手类应用最成熟但也最卷ChatGPT、Claude、文心一言、豆包等原生对话应用已经成了大众入口。但这个赛道早就从“比拼聊天能力”转向了“比拼工程能力”。记忆、插件、联网检索、多账号协同、知识库绑定每一个功能背后都是复杂的系统工程。我给企业搭内部助手时很少直接调对话API完事通常要加一层RAG检索增强生成把公司文档切成块存进向量库再让模型基于检索结果回答。这样能大幅减少幻觉。2.2 代码开发助手程序员最刚需的场景GitHub Copilot、通义灵码、CodeGeeX、Cursor等工具已经成为日常开发的一部分。我自己重度使用AI辅助编程后的体会是关键不在模型会不会写代码而在IDE的上下文工程做得好不好——模型能否看到当前文件、相关引用、报错信息。同样的Qwen模型在Cursor里和裸API里的表现完全是两个量级。这里说一句题外话很多人在热议“AI会不会取代程序员”我的看法是取代的是不善于用AI的程序员而不是编程这个岗位本身。2.3 企业私有化部署与本地化应用最近搜索热度里“本地部署大模型”“Ollama部署”“Windows11部署大模型”“个人电脑智能化”这些词一直居高不下说明大家对数据主权和控制权越来越在意。企业私有化部署的核心诉求有几个数据不出内网、推理成本可控、可依据业务微调。常见的方案是把开源模型Qwen、LLaMA、GLM等用Ollama或者vLLM跑在内网GPU服务器上通过OpenAI兼容接口接到业务系统里。我实测过在一台双路A6000的机器上用vLLM部署Qwen2.5-32B量化版并发20左右的办公场景完全够用。如果只是个人研究Ollama在Windows 11上安装简单到不可思议下载模型文件就能跑几乎是零门槛。2.4 垂直行业应用工业检测、金融分析、教育科研热词里“像工业AI检测、服装检测这类AI用的是云联网还是单机的AI用的什么大模型足够”这个问题问得特别好。这代表了一批真实需求工业视觉检测绝大多数情况下根本不需要大语言模型传统卷积网络加上YOLO系列就够了。但当你需要把检测结果自动生成缺陷报告、用自然语言和质检系统交互时大模型的价值就出来了。一般做法是用轻量视觉模型做实时检测把结构化结果喂给一个7B级别的小语言模型做解释和汇总这样既保证实时性又省钱。至于写科研论文我常用的组合是用Claude梳理逻辑框架用国产模型精修中文学术表达最后一定自己手动重写关键结论——AI写的综述可以看但能直接投稿的部分很少。2.5 Agent从“聊天的模型”到“干活的系统”“目前主流的Agent框架有哪些”这个问题背后的趋势很明显大模型不再只是问答工具而是变成了能调用工具、规划任务、自我纠错的执行者。我接触过的LangGraph、AutoGen、MetaGPT、国内的Dify/Coze/ElementAI等框架各有侧重点。无论哪个框架核心思路都是把“模型”放进“循环”里让模型反复观察结果、调整行动计划。这里必须泼冷水想让AI Agent真正稳定工作决定性因素不是模型聪明不聪明而是你的任务拆分和工具定义是否清晰。一个垃圾工具API再强的模型也调不明白。其次Agent的失败恢复机制特别重要一旦有一步返回异常要么跳过要么重试否则整条链路就断了。3. 实操笔记部署、微调与上下文工程的几个核心动作3.1 本地部署大模型从Ollama到vLLM的完整路径本地部署是很多人入手的第一步。这里我给出一个稳妥的路线。首先确认硬件。个人电脑部署16GB内存起步最好有NVIDIA显卡6G显存以上。没有GPU也不是不行用CPU跑7B量化版慢但能出结果有GPU就用GPU。企业级部署A100/A800/H800/A6000/4090这些常见选择显存大小基本决定了你能跑多大规模的模型。第二步装环境。本地个人玩强烈推荐Ollama。在Windows 11上去官网下载安装包双击装完然后命令行执行ollama pull qwen2.5:7b ollama run qwen2.5:7b两条命令模型就下载并且跑起来了。Ollama把模型文件、推理引擎、API服务都封装好了还会自带一个聊天界面。它生成的模型文件一般在C:\Users\你的用户名\.ollama目录里是一个经过GGUF格式化的文件。对很多人来说知道这点就够了。如果想要更好的并发性能和兼容性企业级推荐vLLM。它是一个专门为高吞吐推理设计的引擎支持PagedAttention、连续批处理能极大地压榨GPU利用率。启动一个OpenAI兼容接口的流程是pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --port 8000启动后就能用OpenAI的SDK直接访问了比如from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen/Qwen2.5-14B-Instruct, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)关于显存和显存管理的经验我再多说一句。如果你用vLLM部署务必根据实际情况调低gpu-memory-utilization别一根筋填0.95否则一旦遇到长上下文峰值显存就会OOM。我遇到过好几次模型加载完测对话正常但在处理长文档时整个服务卡死最后查出来就是预留显存太小了。3.2 大模型微调别一上来就全参微调先想清楚目标“大模型微调”“GPU微调大模型”“大模型微调技术”热度一直很高但我见过很多翻车案例。微调的核心原则是除非你的业务场景需要模型学会特定的风格、领域术语或输出格式否则优先用提示词工程少量示例来解决。微调的成本不仅是算力还有训练数据的采集清洗和后续效果回归。如果你确认需要微调目前工程上最常用的方案是LoRA低秩适配和QLoRA。它们只训练附加在原始模型上的低秩矩阵训练参数只占不到1%。我用一张RTX 409024G显存微调过Qwen2.5-7B用QLoRA可以把训练batch size压到合理范围效果和全参微调在绝大多数任务上差距很小。下面是一个简单可跑的LoRA微调脚本基于HuggingFace TRL库from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model from trl import SFTTrainer model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, device_mapauto) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) tokenizer.pad_token tokenizer.eos_token lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) peft_model get_peft_model(model, lora_config) dataset load_dataset(json, data_filesmydata.jsonl)[train] trainer SFTTrainer( modelpeft_model, train_datasetdataset, tokenizertokenizer, argstransformers.TrainingArguments( per_device_train_batch_size2, gradient_accumulation_steps4, num_train_epochs3, learning_rate2e-4, output_dir./lora_out, logging_steps20, save_strategyepoch, ), ) trainer.train()训练数据格式一般是JSONL每条包含instruction、input、output三个字段或者直接是对话列表。实战中同样一批数据清洗的精细程度往往比模型的选择更决定效果。我做微调时习惯先从100条高质量数据开始试跑确认loss下降正常后再扩到几千条避免一开始就堆数据。3.3 提示词工程与上下文工程比微调更常用“大模型提示词工程与上下文工程”这个词组我很喜欢它把一个关键事实点明了让模型干活不只是写一段prompt而是要精心设计整个上下文。上下文工程包括任务描述、角色设定、背景材料、示例输入输出Few-shot、格式要求和推理要求。我常用的一个高质量提示词结构是这样的任务“根据给定的合同文本抽取甲方、乙方、金额、期限。”步骤1. 先通读全文2. 定位与任务相关的条款3. 只输出结果不解释。约束金额使用阿拉伯数字期限精确到日。示例输入……输出……输入……实际效果中Few-shot示例的作用比多数人想象的大。一个A股财报问答任务第一版不带示例准确率只有67%加了两组示例后直接跳到89%调的正是上下文工程。很多商业产品所谓“行业大模型”本质上就是大量精调后的上下文工程加上检索增强而不是真的训练了一个新模型。3.4 RAG与知识库解决“模型不知道这张内部文档在说什么”“大模型如何理解文档”“大模型知识抽取框架OneKE”这些热词都指向RAG方向。RAG的标准链路是文档加载→切片→向量化→存向量库→用户提问→检索相关片段→拼进上下文→交给模型生成答案。我实践下来最影响效果的三个因素切片策略。不要固定按字数切而是尽量按语义单元段落、标题、表格切。我用过固定512字符切结果把表头和数据拆得到处都是后来改成先按markdown结构分块再补重叠检索质量提升非常明显。检索召回。只取top-3往往不够top-3到top-8之间的长尾信息经常是答案来源。但也不能盲目取太多上下文塞太满模型反而会迷失。结果后验。让模型在回答中标注引用的来源段落ID这样至少可以追溯到答案是否有据可依。OneKE这个知识抽取框架本质上是把非结构化文档转成结构化知识图谱可以配合RAG使用特别适合做企业档案、合同、研报的深度解析。4. 实战过程中遇到的问题与排查方法4.1 模型加载后推理极慢GPU利用率很低这个问题的最大原因是推理引擎没配置好。常见情况是vLLM或Ollama在实际推理过程中batch太小导致显卡空闲。如果是vLLM可以调整--max-num-seqs参数提高并发批大小。如果用的是Ollama检查是否把GPU内存分配得太少在Ollama的配置里设置OLLAMA_NUM_GPU或者通过环境变量增加KV cache。再有就是模型量化等级4-bit量化在推理速度上可以比8-bit高出不少质量损失在某些任务上小到可以接受。4.2 多轮对话聊着聊着就“失忆”了不是模型失忆而是你没有把历史消息传进去。OpenAI兼容接口中每次请求都是无状态的用户需要自己把多轮对话的messages列表拼接好传给模型。如果你只用最后一条消息就发请求模型当然不知道前文。处理方式在服务端维护会话窗口超过一定长度用“摘要历史最近消息”的方式压缩上下文。用LangChain的ConversationSummaryBufferMemory可以实现自动摘要和滚动窗口。4.3 微调时out of memory这个是新手高频问题。解决办法按优先级排序降低batch size开启梯度累积使用QLoRA的4-bit量化基座降低序列长度使用torch的gradient_checkpointingTRL默认就有梯度检查点。我的原则是如果batch size降到了1还是OOM就换更小的模型或者换更低位数的量化不要死磕。4.4 模型胡言乱语输出格式不稳定如果你希望模型输出严格的JSON不要只靠提示词“请输出JSON”。使用结构化输出功能OpenAI的response_format参数或者让模型做两段式生成——先让模型生成一个内部思考再用一个函数或正则提取。负责任地说加了response_format之后JSON语法错误率基本降到0。千万别用正则去解析自由格式的AI回复那是必踩的坑。4.5 企业私有化部署时模型选择纠结遇到选型纠结我的一般建议是先明确“必须私有化”的边界再按这个优先级测试。第一你要在线上跑多长时间如果是内部员工使用几十人在线并发Qwen2.5-14B或32B量化版本足够。第二你的数据是敏感文本还是代码代码场景可以优先考虑DeepSeek-Coder系列文本场景考虑Qwen和GLM。第三需要多模态还是纯文本纯文本不要硬上多模态模型参数开销大且效果未必更好。第四团队有没有能力维护推理服务如果只有一两个人直接上vLLM Docker别自己折腾底层。4.6 长上下文处理中的“幻觉”问题大模型在处理超过几十页的文档时很容易把不同章节的内容混在一起。解决思路不复杂先对文档做结构拆分按章节、段落分别向量化回答问题时只让模型看到相关的几个片段。不要试图把整个文档一股脑塞进上下文上下文长度是够但注意力会分散。可以想象成你让实习生写综述你把整本书丢给他他只能抄目录但你把相关章节的页码标好他就能写得有模有样。模型也是这个道理。5. 工具与框架选型建议5.1 本地推理与部署工具横向对比工具适用场景优势局限Ollama个人开发、小型实验安装极简命令友好跨平台模型管理方便并发和吞吐上限低功能较少vLLM企业生产环境、高并发吞吐高PagedAttention节省显存兼容OpenAI接口配置稍复杂需Python环境llama.cpp低资源设备、CPU推理对内存极友好支持GGUF量化功能原始无API管理能力LM Studio桌面端零代码图形界面点击下载模型即用不适合服务化部署Triton TensorRT-LLM超大规模生产极致性能多模型管理门槛极高运维成本大我的日常推荐是个人折腾直接用Ollama几个小时内就能跑通对话技术团队的内部工具可以先用vLLM起步如果客户对响应延迟极度敏感比如每秒请求上百次再考虑Triton这种重型方案。5.2 Agent框架怎么选“目前主流的Agent框架有哪些”确实是个经典问题。我的理解是没有最好的框架只有最合适当前任务的框架。LangGraph适合复杂工作流编排节点和状态管理灵活适合有技术累积的团队。AutoGen适合多智能体对话协作适合做辩论式、分角色的任务。MetaGPT适合模拟组织团队的角色协同比如产品经理程序员组合做需求到代码的流水线。Dify / Coze适合快速搭建AI应用低代码为核心业务人员也能上手。ElementAI国内团队做值得关注对私有化场景支持不错。我从实际经验给个建议如果你的Agent只需要3到5步固定流程不要用框架写死直接用手写代码编排就好减少依赖。只有当流程复杂、分支多、需要记忆和迭代时才上框架。不要为了用框架而用框架多一层抽象就多一层bug来源。5.3 如何利用“免费大模型API”和“ollama部署私有大模型”热词里专门有人搜“免费大模型API”。确实很多平台提供免费额度比如一些国内大厂的开发者试用套餐、HuggingFace的Inference API、以及开源模型部署者的公开端点。但免费的意思是有限制的通常只有较低的速率或较低优先级。我个人建议如果是做正经产品直接用付费API省心省力如果是学习那随便薅。“ollama部署私有大模型”是更靠谱的自控路线。把Ollama作为服务常驻系统然后暴露在局域网中配合Open WebUI可以提供Web聊天界面可以给团队内部用。甚至可以在你的一台16G内存的MacBook上跑起来一个7B模型连电费都非常省。这个组合是我见过最快的“快速交付一个私有AI”的路径。6. 一些值得记住的底层原理与长期思路6.1 大模型原理别再被“涌现”和“幻觉”吓到大模型的底层原理说复杂很复杂说简单也简单——它本质上是在一个巨大的语料库上自监督学习学会了“预测下一个词”。但正是这种朴素的训练目标让模型在大规模参数下具备了惊人的模式识别和泛化能力。所谓“涌现”不过是模型在规模越过某个阈值后能力表现出现跃升的宏观现象并不是出现了什么不可理解的魔法。“幻觉”也不是故障而是模型在自己“认为”最合理的路径上走得太远缺少事实核查的护栏。理解原理对实践的最大帮助在于当你面对一个失败案例时可以逼自己判断——是模型的能力边界问题还是我的提示词/上下文工程不到位绝大多数情况都是后者。6.2 从“模型/应用维度”出发的长期策略这个标题我重新解读一下“模型维度”是垂直的研究技术栈本身“应用维度”是水平的覆盖场景覆盖业务层。如果你是一个技术负责人你的策略应该是模型层面的能力跟着开源社区走应用层面的能力自己积累。模型会快速迭代今天最强的开源模型明年可能被新模型取代但你的RAG管道、Agent流程、微调流水线、评估机制这些是真正的资产。我自己在实战里就是这么做的。每次新模型出来我要做的只是重新跑一遍内部的评测集大约两百个问题覆盖代码、公文、抽取、数学推理比较新模型和旧模型的差异然后决定要不要替换。应用层几乎不用动——因为我在设计的时候就遵循了“接口兼容”原则这比什么都重要。我最后想分享的几个体会做了这么久的模型集成和落地我最深的感触是别被“大模型”这三个字吓住它说到底就是一个概率模型。你需要的不是每次都追最新的榜单而是清晰地知道你的业务链条里哪一环真正需要智能哪一环只需要逻辑。我测试过几百个号称“超越GPT-4”的开源模型真实场景全都拉出来遛了才知道绝大多数提升都在假象里。真正稳的做法是构建一个可复现的评测集用你自己的数据说话。也不要轻视上下文工程很多性能问题用上下文工程就能解决压根不需要微调微调要解决的是风格的迁移、专业术语的注入、输出结构的学习。最好是从小处入手从一条提示词开始优化再到一部文档的切片策略再到一个微调实验逐步积累起属于你自己的“模型应用经验”。如果你现在正卡在“这么多模型到底选哪个”的纠结里不妨先找一个同量级的模型跑通工具用Ollama也好vLLM也好先把全流程走一遍。很多时候行动的密度比选择的质量更能决定结果。