大模型选型实战：从本地部署到微调的全景指南

最近圈子里聊大模型，已经很少有人再问“什么是大模型”了，大家更关心的是另一类问题：国内外这么多模型，到底选哪个？本地部署和云端调用怎么平衡？微调需要什么显卡？以及最实际的——我的业务场景用哪个模型性价比最高？

这些问题的答案，其实都在“模型维度”和“应用维度”这两个坐标系里。趁着这个时间节点，我把国内外主流的大模型和应用方案做了一次系统梳理，结合我这一年多在真实项目里踩过的坑和验证过的方案，整理成一篇可以当“选型手册”用的内容。不管是做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_url="http://localhost:8000/v1", api_key="EMPTY") resp = client.chat.completions.create( model="Qwen/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 4090（24G显存）微调过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_map="auto") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") tokenizer.pad_token = tokenizer.eos_token lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) peft_model = get_peft_model(model, lora_config) dataset = load_dataset("json", data_files="mydata.jsonl")["train"] trainer = SFTTrainer( model=peft_model, train_dataset=dataset, tokenizer=tokenizer, args=transformers.TrainingArguments( per_device_train_batch_size=2, gradient_accumulation_steps=4, num_train_epochs=3, learning_rate=2e-4, output_dir="./lora_out", logging_steps=20, save_strategy="epoch", ), ) 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_checkpointing（TRL默认就有梯度检查点）。我的原则是：如果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起步；如果客户对响应延迟极度敏感，比如每秒请求上百次，再考虑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也好，先把全流程走一遍。很多时候，行动的密度比选择的质量更能决定结果。