最近大半年我几乎每周都会收到类似的提问想用大模型做点事情但不知道从哪下手。是直接调API省钱还是用自己的卡跑开源模型微调和RAG到底选哪个多模态是不是就是个噱头这些问题背后其实都指向同一个核心——大模型从“能聊天的演示品”变成“能落地的生产力工具”中间隔着一大堆选型、部署和工程化的细节。这篇文章没有标准答案但我会把这段时间实际用过的工具、踩过的坑、以及在不同场景下做出的选择全部摊开来讲。无论你是刚接触大模型的应用开发者还是已经在尝试本地部署的技术负责人应该都能从中找到几条可以少走弯路的经验。1. 从模型到服务本地部署的主流工具与真实体验1.1 为什么本地部署会重新成为焦点先聊一个很现实的原因数据不能出内网。很多企业想做AI能力升级但业务数据涉及生产参数、库存、客户信息直接丢给云端API根本不现实。于是私有化部署、本地化运行大模型成了刚需。另一个原因则是成本结构的变化。今年开源模型的迭代速度非常快几B到几十B参数的模型在普通工作站上已经能跑得有模有样。虽然质量跟顶级闭源模型还有差距但针对垂直场景加上微调或者知识库增强之后完全够用。尤其是当调用量上去以后按Token付费的云端API费用会让预算部门头疼而本地部署是一次性硬件投入加电费长期来看更可控。本地部署还有一个容易忽略的好处可控性。你可以自主决定升级时间也可以针对模型做手术刀式的微调更可以接上企业内部系统做深层次自动化。这些在云端API里几乎都办不到或者要付出极高成本。1.2 ollama开箱即用的模型运行时如果让我给刚接触本地大模型的人推荐第一个工具那一定是ollama。它解决的痛点是“模型下载、环境配置、启动服务”这条链路中90%的脏活累活。过去想在本地跑一个Llama模型要先装Python环境、装CUDA、下载模型权重、自己写加载脚本再处理GPU显存不足的问题。一套折腾下来光环境就能耗掉一整天。ollama把这些全部封成了一条命令ollama run llama3.2它会自动从模型仓库拉取合适的权重自动做量化适配自动启动一个兼容OpenAI格式的本地API端点。你根本不用关心模型文件是什么格式、放在哪个目录本质上是把模型运行时、模型管理和启动服务整合成了一个整体。不过这里有个坑我要特别提醒ollama默认绑定的端口是127.0.0.1:11434只有本机能访问。如果你想让局域网内的其他机器也能用就要设置环境变量OLLAMA_HOST0.0.0.0:11434。另外ollama默认下载路径在系统盘模型文件动辄几个G建议提前在环境变量里把OLLAMA_MODELS指向一个容量充足的数据盘。1.3 vLLM高吞吐、正式服务的大杀器ollama胜在简单但如果你要把大模型做成一个正式业务服务面对并发请求vLLM是更合适的选择。vLLM的核心优势是PagedAttention显存管理。普通推理框架在生成长序列时显存中会预留整段KV缓存并发一高就把显存打满。vLLM把KV Cache按页管理接近物理显存上限地复用空间同硬件条件下吞吐量能高出好几倍。一个典型的vLLM启动命令长这样vllm serve Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.95 \ --tensor-parallel-size 1实测下来一张24G显存的卡跑7B模型--max-model-len设置到32K并发16路请求显存利用率可以稳定在90%以上响应延迟也不会出现明显抖动。这是ollama那种按需加载的方式很难达到的。我需要补充一句vLLM对显卡的要求相对苛刻老型号显卡可能不支持某些算子的加速AMD显卡的支持也在快速演进但仍有兼容问题。所以如果决定用vLLM先查清楚自家硬件的兼容矩阵。1.4 部署过程中的常见否决点本地部署并不是无脑套工具就完事有几个问题几乎每个人都会遇到显存不够7B模型纯FP16推理约需14G显存4bit量化后大约需要6G。要跑32K上下文KV Cache会额外吃掉2G到4G所以8G显存卡跑7B量化模型刚够边沿。我的建议是显存小于6G就直接选3B或1.5B级别的模型。CPU内存模型AMD NPU、Apple Silicon这类统一内存架构跑中小模型表现不错但纯CPU推理速度会让人焦虑。如果只是测试可以忍生产环境务必上GPU或NPU。模型下载慢国内网络访问境外模型仓库经常拉胯用镜像站或者有人已经下好的共享缓存是常规操作。最终我的选型思路很简单贪方便就ollama要扛并发就vLLM只做演示选小模型做正经事至少7B起步。2. 先分清任务再选路线微调不是万能药RAG也不是2.1 上下文长度和文档理解先从基线开始很多人一上来就说“我要微调大模型让它懂我的文档”。但这句话其实混了两种完全不同的需求一是要求模型记住文档里的事实二是要求模型能从长文档中抽取相关信息回答问题。对于第二种需求优先做的不是微调而是看基座模型的上下文长度够不够。现在主流开源模型的上下文窗口已经从4K扩展到了128K甚至更长。如果你的文档有几十页先把全文塞进上下文让模型直接读可能问题就解决了。大模型理解文档本质上依赖的是注意力机制。它会把文档切分成小块加上位置编码然后让每一层网络在块与块之间建立关联。上下文越长注意力计算量越大模型也越容易“迷失在中间”。所以我在处理长文档时通常会在提示词里明确告诉模型“只关注与XX问题相关的段落”并且用document这样的分隔标签把每一段标出来实测效果提升非常明显。2.2 什么时候该做RAGRAG检索增强生成的核心是给模型外挂一个“可检索的记忆库”。当用户提问时先从知识库中检索出相关片段把片段拼进提示词再让模型基于这些片段生成答案。我做过一个很典型的案例给一家设备厂商做售后知识问答。他们的说明书、维修手册、历史工单加起来几百个G没有任何一个上下文窗口能塞下。这时候RAG几乎是唯一的正确路线。实现RAG的路径也很快用文本嵌入模型把文档切成小块并向量化存入向量数据库查询时先做相似度检索再拼接上下文。整个过程不需要动模型权重只需要一个开源模型、一个嵌入模型、一个向量库一天就能搭出原型。这里最大的坑是“检索质量决定回答质量”。如果你的切片策略不对比如一块切了5000个字里面混了多个主题查回来的内容噪声很大再好的LLM也会一本正经地胡说八道。我的经验是先按标题和段落结构做层次化切块保持块与块之间有一定重叠同时保留标题作为块元数据检索排序时给标题命中加权重。这套做法在小规模知识库上效果立竿见影。2.3 什么时候必须微调RAG能解决知识缺失但解决不了“风格和格式”问题。如果业务要求模型固定以某种表格结构输出或者必须模仿特定行业的报告口吻抑或要让模型学会一套缩写术语体系这就要靠微调。举一个搜索热词里反复出现的场景大模型微调实战。我用的方法是先收集几百条高质量对话——注意是“高质量”不是“够多”。用LoraLow-Rank Adaptation方式在7B模型上跑几个epoch只更新少量附加参数显存占用大约在16G到20G之间单卡就能完成。微调的本质是改变模型的输出分布。LoRA通过低秩分解只学习增量矩阵相当于在原有参数旁边加了一条小旁路。这种做法的一个直接好处是原模型的能力不会发生灾难性遗忘且训练好的LoRA权重只有几百MB部署时和基础模型叠加使用切换不同业务场景非常灵活。但我也要泼一盆冷水微调并不能凭空增加模型的知识量它只是改变模型对已有知识的调用方式和表达方式。如果期望让模型“学会”新行业里大量陌生事实微调的效率远低于RAG。所以我的经验是事实类知识喂RAG输出格式和行为模式用微调两者配合而不是二选一。2.4 知识抽取与结构化oneke这类框架的思路热搜词里有一个“大模型知识抽取框架oneke”这其实是很多实用系统的幕后工作。很多企业并不需要模型直接回答用户问题而是需要模型把非结构化文本变成结构化数据比如从合同里抽出甲方乙方、金额、日期从工单里抽出故障类型和处理结果。这种任务过去需要写一堆正则和规则现在大模型可以做得又快又好。oneke这类框架本质上是围绕“实体识别—关系抽取—事件抽取”建了一套基于LLM的标准化流程。它通常包含两个关键设计一是定义好输出Schema让模型严格按照JSON结构输出二是利用自一致性校验让模型多次生成后投票决定最可信的结果。我在实践中最常用的是更轻量的做法写一个“提取-校验-修正”的三段式提示词。第一轮让模型抽取第二轮把结果回灌给模型要求它比对原文检查是否有遗漏或幻觉第三轮再输出修正后的JSON。这个流程虽然多了两次调用但在抽取类任务上的准确率能稳定提升到95%以上。3. 把大模型接进业务系统从裸API调用到智能体应用3.1 免费API和商用API之间的实际选择自己在本地部署了一个模型之后服务也有了。接着的问题是业务系统该如何调用如果你的应用场景是内部工具、数据分析助手或者模型调用频率不高直接用兼容OpenAI格式的API是最省事的。from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keylocal ) resp client.chat.completions.create( modelqwen2.5-7b, messages[{role: user, content: 总结一下这份文档}] ) print(resp.choices[0].message.content)这几乎是零学习成本地迁移到本地模型。你的代码之前调过GPT现在只需要换一行base_url就行。再看免费API这条线。热搜词里一直存在“免费大模型API”确实现在有些厂商会提供限时限量的免费额度适合做POC验证和低流量应用。但免费API往往不稳定并发限制严格而且服务条款随时可能变化。支撑生产环境时我还是倾向于自建本地服务或者购买商业API的弹性额度。3.2 Dify低代码方式整合模型、知识库和工具如果你不想从零写编排代码Dify是一个绕不开的开源工具。它把大模型应用常见的五个环节集合到一起模型接入、Prompt编排、知识库RAG、工作流、Agent工具调用。用Dify接本地模型的操作我也踩过坑在Dify里选“OpenAI-API-Compatible”类型填入ollama或vLLM的地址和模型名同时注意两个细节。第一模型名称必须完全一致Dify不会自动探测第二如果是vLLM服务要确认服务端支持的上下文长度和Dify侧的“Max Tokens”设置一致否则会出现奇怪的截断或报错。Dify比较大的价值在于可视化地调试提示词。你可以把用户输入、上下文、工具返回结果分别在界面上展开观察快速定位是检索没召回还是模型没理解指令。这种可视化调试能力对于非算法背景的业务同学非常友好。3.3 AI智能体应用案例拆解智能体是搜索热词里另一个高频词。其实智能体并不是什么神秘的东西它就是把大模型从“一个只会问答的程序”变成“一个能调用外部工具去完成任务的执行者”。我最近做了一个内部场景客服工单自动分诊。这个智能体的工作流如下接收用户提交的工单描述。调用一个分类工具识别问题属于“售后故障”“产品咨询”还是“退款退货”。如果是故障类再去检索历史工单中相似的故障解决方案。最后组装一条回复建议推送给人工客服确认。这个流程里大模型负责的是“理解意图 生成文案 选择工具”而不是自己去做所有事情。关键在于给模型定义好工具清单和触发条件。我在提示词里写明了每个工具的输入输出格式并提供了两三条示例对话模型很快就学会了在正确的时机调用正确的工具。这类应用最大的挑战不是模型能力而是容错。工具返回的数据可能是脏的模型也可能会拿一个空值去生成回复。所以我在智能体环节加了一层兜底校验如果工具返回结果为空则强制模型回答“暂无相关信息”并转入人工处理。别小看这个兜底生产中绝大多数错误都是空数据引发的幻觉。3.4 企业私有化部署的流程清单企业级私有化部署比个人跑模型复杂得多。我把常见流程整理成一个清单大家可以照着检查网络规划模型服务节点与业务内网隔离只开放必要端口。模型选择与量化根据业务场景选择基座模型通常至少70B以上才适合做复杂Agent但也要考虑显卡成本7B-14B更适合垂直单任务。推理框架选型高并发选vLLM多变体部署选ollama按需切换。服务化封装把模型服务包一层内部API网关做鉴权、限流、审计。数据安全日志脱敏敏感输入输出不落到明文日志。监控告警关注响应延迟、吞吐、显存占用设置告警阈值。模型迭代预留模型更新和回滚机制。这套流程做下来一次本地模型更新导致的业务不可用是我遇到最多的线上事故所以一定不要把模型文件直接暴露在共享目录里随意覆盖更新必须走版本管理和灰度发布。4. 多模态与专用场景让大模型处理图像、音频和垂直行业问题4.1 多模态大模型的进展与选型思路多模态大模型在这个阶段的含义已经从“看图说话”进化到了“图音文联合推理”。典型的应用包括根据产品图生成描述文案、从监控视频里识别异常行为、把语音实时转写成结构化会议纪要。搜索热词里的“讯飞实时语音转写大模型前端适配”就属于这一类。如果要做中文场景的语音识别与转写有两类选择一类是专用ASR模型比如FunASR、Whisper系列另一类就是端到端的语音大模型。我的经验是别盲目迷信“大而全”。语音转写这种任务专用模型的延迟和准确率通常比通用大模型好得多。正确姿势是先用专用模型把语音转成文字再把文字喂给大模型做意图理解、摘要生成。这种“串联小模型大模型”的架构在成本和效果上最均衡。多模态大模型真正有壁垒的地方在“跨模态对齐”——让模型知道“图片里这只猫的毛色”和“文字描述的蓬松感”是同一个语义。现有开源方案在简单视觉问答上已经很成熟但到工业级的细节识别仍然需要领域数据的微调。4.2 绘图与图像生成模型的落地热搜词里的“造相-z-image-turbo绘图大模型”属于扩散模型阵营。这类模型在本地部署以后可以用来做电商素材生成、设计辅助、甚至动漫风格转换。如果你只是想给文章配图直接用开箱即用的推理管线即可比如在Python里调用diffusers库from diffusers import AutoPipelineForText2Image import torch pipe AutoPipelineForText2Image.from_pretrained( 模型路径或仓库名, torch_dtypetorch.float16, use_safetensorsTrue ) pipe pipe.to(cuda) image pipe( prompt一件红色冲锋衣的电商白底图商业摄影风格, negative_prompt模糊低质量变形, num_inference_steps25, guidance_scale6.0 ).images[0] image.save(output.png)这里我要讲一个实际经验绘图模型对提示词的敏感度极高很多人跑出来的图不满意不是因为模型差而是因为提示词里缺少“风格后缀”和“负面提示词”。电商场景建议固定添加“白底、全局光照、高清细节”等描述负面提示词坚决写上“多余四肢、水印、文字、模糊”。4.3 工业检测和服装检测类AI的模型选择搜索热词里有一类很实在的问题“像工业AI检测、服装检测这类AI用的是云联网还是单机的AI用的什么大模型足够”我直接给结论这类场景几乎都是单机本地部署为主而且通常不是大模型而是“小模型大模型”的组合。工业瑕疵检测的本质是视觉定位和分类传统CNN、YOLO系列在速度和小样本表现上仍然有优势。大模型在其中的角色是理解和描述“为什么这个区域是瑕疵”——例如生成缺陷原因、给出修复建议。所以常见架构是用小目标检测模型把疑似瑕疵框出来再裁剪区域送给多模态大模型做细粒度分析和描述。具体模型选择上YOLOv8/YOLO11这类目标检测模型非常适合第一阶段的定位识别场景中“是什么”第二阶段的缺陷描述可以用Qwen2-VL、LLaVA这类视觉语言模型。如果企业显卡预算有限第二阶段也可以用本地7B多模态模型做量化部署。最关键的并不是某一个模型有多强而是数据闭环。我见过太多案例买了一套商用检测系统上线初期效果不错三个月后良率波动就检测不准了——因为产线新出现了没见过的不良模式。这就要求检测系统必须有在线数据回流和定期增量训练的能力。单纯套一个大模型不建数据闭环迟早要翻车。4.4 其他硬件加速选项AMD NPU与CPU推理搜索引擎里反复出现AMD NPU因为AI PC这个概念越来越普及。NPU神经网络处理单元的优势是低功耗、高能效比尤其适合持续在线的轻量场景比如语音唤醒、实时字幕、摄像头事件检测。但NPU生态尚不统一你对特定NPU的支持要查清楚。目前AMD Ryzen AI系列已经能跑一些轻量模型效果还不错但和N卡的大模型生态相比能用上的算子数量和量化库支持还是明显落后的。纯CPU推理也不是不能跑。我用AirLLM在MacBook上跑过7B模型速度属于“能出结果等不起延迟”的水平。如果只是用来做离线数据处理比如批量打标、非实时文本分类CPU就足够。一旦升级到交互式应用或客服场景必须上GPU或NPU。我总结下来的原则是重交互、高并发上GPU轻交互、低功耗上NPU批量离线任务CPU凑合。千万别在硬件选型上寄希望于“一枚芯片解决所有场景”。5. 关于“选模型”这件事我最后的几句大实话很多人在网上疯狂求“最好用的开源模型排行”实际上模型只是整个系统的一环。同一个7B模型有人用出渣效果有人调得比云端大模型还顺手差距主要在三点提示词工程、RAG质量、部署参数优化。模型的下限由架构决定上线效果由工程决定。如果你现在还在纠结从哪一步开始我的建议非常简单先用ollama拉一个7B模型跑通一个你业务里最频繁的提问场景然后把业务文档切成块做个最朴素的RAG跑不顺再考虑微调。这个顺序能覆盖80%的内部应用需求而且每一步都有大量开源工具支撑。我自己的习惯是每半个月评估一次新发布的模型和工具因为这一两年迭代速度实在太快。但也别太焦虑工具永远在变底层能力不会亏——当你熟悉了“部署、调用、增强、评估”这条链路换什么新模型都只是换一个容器而已。