整理这篇大模型学习笔记，起因是我最近在带项目落地时频繁被问到几个问题：本地部署该用Ollama还是vLLM？Dify怎么接上本地模型？微调和提示词工程到底先学哪个？多模态模型能不能直接用在工业质检上？这些问题看着分散，背后其实是同一张地图——大模型从“能聊天”到“真正进入业务”，中间隔着工具链、部署方案、数据配合和评估体系。这篇笔记就是我对这张地图的完整梳理，结论大多来自我实际跑过的方案、调过的参数、踩过的坑。门槛不高，适合想系统上手大模型应用的人看，也适合正在规划私有化部署或行业AI方案的团队参考。
1. 先看清大模型应用的几条主线
1.1 文本处理是基本功：对话、写作与代码生成
纯文本大模型是当前落地最成熟的一类。常见的应用包括智能客服、文档总结、合同审查、文案生成、代码补全等。它们的共同特点是输入输出都是文本，模型只需要理解指令并生成合规内容，技术链路相对简单：要么调用云端API，要么在本地起一个推理服务。
这一类应用的选型核心是“规模匹配”。一个企业内部知识问答系统，用7B或14B的模型在本地跑，效果和速度往往比什么都往最大的模型上塞要好。因为文本类任务对模型能力的敏感度是分层的：日常沟通和结构化写作，中小模型已经够用；复杂的逻辑推理、长代码生成才需要更大的基座。和硬件成本、推理延迟放在一起看，就不难理解为什么很多团队宁可做模型降级，也不追求参数最大。
文本应用最容易忽略的是提示词设计。大模型本质是预测下一个token的引擎，同样的模型，指令措辞不同，输出质量可能差出一大截。我习惯把提示词当作第一版产品来迭代：先写清楚角色、任务、约束、输出格式，再逐步补充few-shot示例。很多人问我为什么同一个模型在不同项目里表现差距那么大，答案往往不是模型不行，而是输入质量参差不齐。
1.2 多模态模型：从绘画生成到视觉理解
多模态不是只有“图片对话”这一种形态，文生图、语音转写、视频理解都属于这个大方向。最近讨论度很高的Z-Image-Turbo这类绘图模型，走的就是文生图路线，适合做海报素材、电商主图、设计草稿，配合ComfyUI可以搭出可复用的生成工作流。语音方向也一样，讯飞等方案在做实时语音转写时，不仅要考虑识别率，还要解决前端音频采集、流式接口、断句回调这些问题，再把转写文本交给大模型做后续处理。
多模态在企业场景里真正高频落地的，其实是“视觉理解”和“图文混合理解”：比如从产品截图中提取参数、从单据图片里抽取字段、用视觉语言模型对质检图像做描述性复核。选型时不要只看评测榜单，要看输入格式是否匹配业务，输出格式是否方便下游程序消费。很多视觉大模型API虽然能力很强，但如果团队没有做好接口封装和异常兜底，线上效果同样不稳定。
我的观察是，多模态模型的进度比大多数人想象得快，但真正卡住落地的往往不是模型能力，而是数据质量。图片脏、标注乱、业务口径不统一，再强的模型也救不回来。所以多模态项目我更建议先做小范围样板，验证“数据进得来、结果出得去”，再谈规模化。
1.3 智能体：让模型从“回答问题”变成“完成任务”
智能体在2026年已经不算新概念，但它的核心依然清晰：模型通过Function Calling调用外部工具，拿到结果后继续推理，最终完成一个多步骤任务。典型场景是客服工单自动分类后调用CRM查单，或者数据分析Agent连接数据库，按用户的自然语言问题生成查询并返回结论。
实现一个能用的智能体，关键不在模型多大，而在三点：模型能不能稳定输出结构化的工具调用参数，工具执行结果能不能正确回传，以及模型在中间环节报错时有没有重试和降级策略。我在接一个智能体项目时踩过最大的坑，是模型经常“幻觉”出工具参数，比如日期格式不对、字段名拼错，后来通过严格限定工具描述和加few-shot示例，参数错误率才降下来。
智能体应用案例看着花哨，落地时一定要控制自主度。先让模型在限定的工具集内完成任务，再逐步放宽；不要一上来就做完全自主的多Agent协作，否则调试成本会指数级上升。
1.4 行业场景：工业检测不一定需要“大模型”
很多做工业AI检测、服装质检的团队跑来问我：到底该用云联网方案还是单机方案？用的什么大模型才够？
先给结论：工业缺陷检测这类实时任务，主流方案并不是通用大模型，而是专用小模型加传统视觉算法的组合。原因很简单，流水线检测要求毫秒级延迟，而通用多模态大模型的单次推理耗时很难压到这个量级；再加上车间网络不稳定、图像数据敏感，很多客户要求数据不能出厂房。所以实际部署经常是：前端用YOLO系列或分割模型实时框出缺陷，后端用视觉大模型对难例做抽样复核，或者用本地部署的文本大模型生成质检报告、回复工单。
至于“云联网还是单机”，核心看三个问题：数据能不能出去、延迟允许多高、成本能接受多少。没有标准答案，但大多数生产场景会优先选择单机推理，把云端API当作辅助通道。服装检测同样如此，布料疵点、版型残次这类任务更依赖高速检测小模型，而质检报告、客服话术这些文本工作完全可以交给本地大模型。
2. 本地部署是绕不开的第一课
2.1 Ollama安装的大模型到底是什么文件：GGUF解析
本地部署大模型，很多人第一次遇到的困惑是：Ollama安装的大模型到底是什么文件？答案是GGUF格式。GGUF可以简单理解成一个“模型压缩包”，把模型的权重、分词器、超参数和推理所需要的元信息都装进同一个文件里，方便在不同机器之间拷贝和加载。它对CPU推理做了专门优化，也能把部分层放到GPU上加速，适合个人电脑、企业内部服务器这些资源有限的环境。
GGUF还有量化机制。常见的q4_k_m、q8_0这些后缀，代表权重压缩程度不同。量化后的模型体积更小、推理更快，但精度会有轻微损失。以7B模型为例，FP16权重大约14GB，q4_k_m量化后通常在4GB到5GB之间，普通消费级显卡也能勉强跑起来。我在做私有化部署时，通常先拿q4_k_m版本验证效果，再根据硬件资源决定要不要换更高精度的版本。
理解了GGUF，很多操作就顺了：想离线部署，直接把.gguf文件拷到内网机器；想换模型，本质上就是换一个GGUF文件；想自定义配置，可以写Modelfile把GGUF文件包装成Ollama模型。这也解释了为什么私有化部署大模型时，Ollama是最常见的入门工具。
2.2 用Ollama跑通Qwen和Llama的完整步骤
Windows 11上使用Ollama部署本地大模型，流程大概四步：安装Ollama、拉取模型、启动服务、验证接口。
先到Ollama官网下载安装包，装完默认会有一个后台服务监听11434端口。然后在命令行里拉模型，例如Qwen系列可以执行：
ollama pull qwen2.5:7b拉完以后直接运行：
ollama run qwen2.5:7b进入交互式对话界面，说明本地模型已经跑起来了。Llama系列也一样，把模型名换成llama3或llama3.1对应的tag即可。
如果下游应用要通过API调用，Ollama默认提供OpenAI兼容接口，地址是http://localhost:11434/v1，可以先用命令验证：
curl http://localhost:11434/api/tags能列出模型列表就说明服务正常。
实际踩坑点有两个。一是模型下载慢，解决方案是换用ModelScope渠道下载，或在内网搭一个文件服务器手动分发；二是默认模型存储路径经常在C盘，很快撑爆系统盘，建议安装后立刻设置环境变量OLLAMA_MODELS指向大容量磁盘，再重启Ollama服务。
2.3 LM Studio：图形化方案与VS 2022代码生成接入
Ollama对命令行用户很友好，但有些团队更希望有个图形界面来管理模型，这时LM Studio更合适。它可以在界面里浏览、下载模型，也能调整加载参数、查看当前推理占用的显存和内存。最实用的是它同样能启动本地OpenAI兼容服务，默认端口通常是1234。
一个很常见的应用是“VS 2022连接本地LM Studio生成代码”。操作路径不复杂：先在LM Studio里加载一个代码能力强的模型，例如Qwen2.5-Coder或CodeLlama，然后启动本地服务器；接着在VS 2022里安装支持自定义OpenAI兼容接口的AI代码插件，在设置里把Base URL填成http://localhost:1234/v1，再填一个不会校验的API Key即可。
这里要注意三点：第一，VS代码补全对延迟极其敏感，模型太大反而影响体验；第二，代码生成需要足够的上下文窗口，如果模型上下文是8K，贴入较大的文件时会被截断；第三，LM Studio在Windows下的显存调度要留出余量，边开浏览器边跑大模型，显存不够会直接OOM。
2.4 vLLM：高并发和大上下文场景下的部署方式
Ollama和LM Studio适合个人调试、小规模私有化场景，但真正面向多用户、高并发生产环境时，更多人会选择vLLM。vLLM使用PagedAttention技术管理KV Cache，大幅减少了显存浪费，吞吐量通常比普通推理框架高出不少。
部署命令很简洁，例如：
vllm serve Qwen/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.9启动后同样提供OpenAI兼容接口，地址是http://localhost:8000/v1。生产环境可以再加--tensor-parallel-size做多卡并行，或者配合--dtype指定精度。
选型时不必迷信某个框架，我一般按场景区分：
| 工具 | 适用场景 | 主要优势 | 注意点 |
|---|---|---|---|
| Ollama | 个人开发、内网小规模私有部署 | 安装简单、GGUF生态好、CPU/GPU混合推理 | 高并发吞吐能力一般 |
| LM Studio | 可视化调试、单机推理 | 图形化管理、快速启动本地API | 服务化能力较弱 |
| vLLM | 多用户在线服务、高QPS生产环境 | 高吞吐、显存优化好 | 配置更复杂，需要学习和调参 |
显存不足是vLLM部署最常遇到的问题。解决的思路从易到难依次是：换小模型、用更低bit的量化、减少gpu-memory-utilization、开CPU offload、最后再考虑多卡和分布式。
3. 工具链集成：API、平台与MCP
3.1 OpenAI兼容API与免费API：怎么选、怎么避坑
现在市面上的大模型API基本都兼容OpenAI接口风格，这意味着同一套SDK可以切换不同供应商，开发成本很低。对个人学习和原型验证来说，免费大模型API是个很好的起点。一些国内平台如硅基流动、DeepSeek开放平台、智谱、阿里百炼都提供试用额度或免费模型，注册后就能拿到Key。
但免费API有几个坑要提前清楚：一是限流，突发请求会被拒绝；二是可用模型通常是蒸馏版或低配版，效果和生产版本有差距；三是数据合规问题，训练数据有没有被用于改进模型，服务商在条款里通常写得很明白。所以我的建议是：免费API只拿来验证想法，不要直接作为生产环境底座。真要上线，要么买有明确SLA的付费版本，要么自己在内网用Ollama或vLLM部署。
选择模型时，很多团队的误区是只看排行榜分数。更好的做法是把真实业务数据抽几十条，用两个候选模型各跑一遍，人工对比输出的稳定性、格式和错误率。文字任务和代码任务的最优模型往往不一样，不要指望一个模型打天下。
3.2 Dify接入本地大模型：配置步骤与关键细节
Dify是目前很火的开源LLMOps平台，可以编排工作流、管理知识库、发布AI应用。接入本地大模型也简单，这里是完整配置思路。
在Dify右上角“设置”里找到模型供应商，选择“OpenAI-API-compatible”类型，填三样东西：Base URL、API Key、模型ID。如果你用的是Ollama，Base URL填http://localhost:11434/v1，API Key随便填，模型ID和Ollama里拉取的模型名保持一致。如果Dify运行在Docker容器里，需要注意容器访问宿主机不能用localhost，而是填http://host.docker.internal:11434/v1，这是新手最容易掉进去的坑。
配置完成以后，新建一个应用，把模型选成刚才填入的本地模型，就能跑通。正式使用前建议用少量数据先验证一次完整的问答链路，再放真实知识库。Dify本身对知识库做切片、向量化、检索增强，如果切片参数设置不合理，后面的检索质量直接影响回答效果。
3.3 MCP：让UE 5.6、VS 2022这类工具“听懂”大模型
MCP（Model Context Protocol）是模型与工具之间的标准化协议。换句话说，它解决的是“大模型如何安全地调用外部功能”的问题。最近UE 5.6通过官方大模型MCP接入AI，本质就是把虚幻引擎的资产操作、蓝图生成、场景布置这些能力暴露成一套MCP工具，让模型通过工具调用来完成任务。VS 2022连接本地大模型生成代码，也可以走MCP或兼容接口，让IDE把当前文件、编译报错和源码片段传给模型，再把补全结果带回来。
MCP最大的价值是解耦。同一套MCP工具定义，可以对接不同的模型供应商，今天用云端模型，明天换本地模型，不需要重写集成层。但它也有风险：暴露给模型的工具范围越大，被误调用的可能性越高。我在配置MCP服务时，习惯先在最小工具集上测试，确认每个工具的描述、参数格式模型都能正确解析，再逐步开放更多操作权限。
4. 从“会调用”到“懂业务”：RAG、微调与知识抽取
4.1 大模型如何理解文档：RAG的完整链路
很多人以为把PDF丢给大模型，它就能“读懂”，实际并不是这么简单。大模型只能接收token序列，不能直接遍历一本几百页的文档，所以必须借助RAG（检索增强生成）。
RAG的标准流程可以拆成五个环节：先把文档加载进来，然后按段落或固定长度切分成片段；每个片段用embedding模型转成向量；用户提问时，把问题也转成向量，到向量库里检索最相关的TopK片段；最后把这些片段拼进提示词，连同问题一起交给生成模型。
这套链路里，切分策略对回答质量影响最大。切得太碎，语义容易断；切得太整，检索噪音大。我的经验是，技术类文档按三级标题切，合同或报告按章节切，再用带重叠窗口的方式保留上下文。embedding模型的选择也很重要，通用中文场景可以选bge系列或m3e系列，专有领域最好在真实数据上自测。
RAG的局限也很明显：检索不到正确答案时，生成端再强也没用；检索出来的片段互相矛盾时，模型可能自己编一个解释。所以上线前一定要抽样人工检查“检索到的内容是不是真的回答了问题”，不能只看最后生成结果。
4.2 微调实战：什么时候该微调、用LoRA怎么做低成本训练
不少团队做完RAG后，发现模型还是答不出特定领域的术语和输出格式，这时候才会考虑微调。我的判断标准是：如果业务知识需要频繁更新，优先做RAG；如果模型的输出风格、术语体系、固定格式总是不对，微调更合适。
当前最常用的低成本微调方案是LoRA，它只训练一小部分附加权重，显存占用远低于全量微调。实战中我倾向用LLaMA-Factory这个开源工具。步骤大致是：准备几百到几千条高质量的指令数据，选择基座模型（比如Qwen2.5-7B），设置LoRA参数，然后用GPU训练。
LoRA参数不需要改得花哨，常用配置是r=16、lora_alpha=32，学习率设置在1e-4左右，batch size按显存调整。7B模型的LoRA微调，16GB显存可以跑，如果显存更低就用QLoRA，4bit量化后8GB也能启动。训练前一定要清洗数据，我见过很多微调后效果变差的案例，原因不是参数问题，而是数据里有重复样本、错误标签、格式不统一。
训练完成后还要做“合并导出”这一步，把LoRA权重合并回原模型，再用对话模板测试效果；如果展示充分，可以再把模型转成GGUF，交给Ollama部署。
4.3 上下文长度：为什么重要，以及如何应对
“上下文长度”是大模型选型时最常被提到的指标之一。它指模型一次能处理的最大token数量。一个中文汉字大约是1到2个token，所以32K上下文大约能装2万多字，128K可以装一篇长报告。
但更长的上下文并不总是更好。上下文窗口越大，KV Cache占用的显存越高，推理延迟也越长。很多模型宣传200K窗口，实际在长文场景下注意力计算会显著变慢。我的建议是，先统计真实业务里单次问答需要携带的最大文本量，再选择刚好够用的模型。大多数客服、文档问答场景，8K到32K就能覆盖；再大的文档需求，应该用RAG做检索，而不是把全文塞进窗口。
一旦发现上下文超限，常用的处理顺序是：压缩待传入文本、只传摘要、分块多次对话、使用支持更长上下文的模型。不要一发热就换大窗口模型，成本和速度都要算进去。
4.4 OneKE知识抽取框架：把非结构化文本变成结构化知识
在很多项目中，文档里最有价值的信息并不是自由文本本身，而是其中的实体和关系。比如合同中的当事人、金额、期限，研究报告里的机构、指标、关联事件。这类需求可以用知识抽取框架来做，OneKE就是其中一个典型的开源方案。
OneKE基于大模型做开放知识抽取，输入一段文本，输出结构化的三元组，比如“甲方-签署-合同”“模型名称-属于-大模型”。这些三元组可以存入图数据库，形成知识图谱，也可以反哺RAG，让检索结构更清晰。
我在使用OneKE这类框架时，最深的体会是提示词模板决定抽取质量。必须先定义好实体类型、关系类型和输出schema，模型才能稳定抽取；否则它会抽出一堆无用的泛化关系。另一个问题是字段冲突，不同来源文档对同一实体描述不一致，需要做实体对齐。这些工作虽然琐碎，但一旦做好了，后续的问答、审计、BI分析都会顺畅很多。
5. 多模态落地与模型安全
5.1 Z-Image-Turbo这类绘图大模型：文件下载与运行方式
绘图类大模型是2026年应用热度最高的方向之一，像造相系列的Z-Image-Turbo就是典型的文生图模型。很多团队想把它集成到自己的内容生产流程里，但第一步就卡在“模型怎么下载、怎么跑”。
这类模型通常以safetensors格式发布，压缩包里有主模型权重、VAE、文本编码器、tokenizer等部件。运行方式有两种主流选择：一种是直接用ComfyUI，把模型文件放到对应目录，然后搭建文生图工作流；另一种是用Diffusers库写脚本加载，适合需要深度定制的场景。如果硬件有限，也可以直接调用云端API，先验证效果，再逐步迁移到本地。
运行绘图模型时要注意几个实际问题：文件往往有好几GB，下载后一定要核对哈希值，防止文件损坏；显存低于8GB时，能跑但会慢，建议优先用SD1.5系列或turbo版这类轻量模型；生成质量与步数、采样器、负向提示词强相关，不要默认参数一把梭。
绘图大模型参数较多，做产品化时要留好配置入口和版本管理，否则不同批次生成的风格漂移会让人崩溃。
5.2 工业AI检测与服装检测：云联网、单机还是混合
这个问题在实际咨询中出现频率非常高，值得单独讲。
工业缺陷检测、服装疵点检测这类任务的本质是“实时找出图像中的异常”，它和“问答一张图里有什么”是完全不同的技术路线。实时检测通常要求几十毫秒出结果、稳定重复、误报率受控。通用多模态大模型在动态场景下很难同时满足“快”和“准”。
因此我看到的高质量落地项目，几乎都是分层架构：
| 层级 | 任务 | 常用方案 |
|---|---|---|
| 第一层 | 实时目标定位、缺陷框选 | YOLO、RT-DETR、传统图像处理 |
| 第二层 | 缺陷分类、分割 | 专用小模型、自训练分类网络 |
| 第三层 | 难例复核、报告生成 | 本地大模型或云端VLM抽样 |
“用的什么大模型足够”这个问题的答案，应该是“看任务层次说话”。不要试图让一个大模型包办全部，先用专用小模型把准确率做到可控范围，再用大模型处理边缘样本和语义理解，整体成本和效果都会更好。网络层面，在线检测一般留在现场单机推理，采样分析或远程诊断可以走云端API，前提是数据脱敏和传输合规满足客户要求。
5.3 投毒测试与数据安全：上线前的必要检查
大模型上线前，除了跑准确率，至少要做一轮安全测试，而“投毒测试”是里面常被忽视的环节。投毒测试的思路是：在模型训练或微调数据中夹带后门样本，让模型在特定触发词下输出预设的恶意内容或错误结果，然后验证已上线的模型是否被影响。
做私有化部署时，我建议把投毒测试纳入验收流程。具体做法包括：构造一批包含触发词的测试样本，观察模型在触发场景和正常场景下的输出差异；对微调数据集做敏感字段扫描，排查异常重复样本；对推理输入做关键词和格式过滤，防止注入类攻击。
另一个容易忽略的点是权重可信。从第三方渠道下载的模型文件，要确认来源、校验哈希、锁定版本号。团队内部使用模型时不要随意更换权重，否则几个月前发现的问题可能在下一次更新后又出现。大模型的安全不是一次性工作，每次换模型、加数据、改提示词后都应该做一轮回归检查。
6. 常见问题速查与学习路线
6.1 本地部署与运行的常见问题速查表
把我这些年折腾大模型工具遇到的典型问题整理成一张速查表，可以直接抄作业：
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 模型下载慢或卡住 | 网络到默认源不稳定 | 换ModelScope渠道，或手动下载后导入 |
| Ollama模型存在C盘导致空间不足 | 默认存储路径未修改 | 设置OLLAMA_MODELS环境变量后重启服务 |
| 端口11434或1234被占用 | 本地其他程序冲突 | 换端口，或在启动服务时指定新端口 |
| 推理时OOM | 模型过大、上下文过长 | 换小模型、量化模型、缩短上下文、减少并发 |
| LM Studio服务启动但VS 2022连不上 | Base URL或模型ID填错 | 检查http://localhost:1234/v1和已加载模型名 |
| Dify在Docker里连不上Ollama | 使用了localhost | 把Base URL改为http://host.docker.internal:11434/v1 |
| 回答存在大量幻觉 | 检索质量差或提示词不清晰 | 优化RAG切分、补充检索片段、增加约束提示 |
| 微调后效果反而变差 | 数据质量问题 | 清洗数据、去重、纠正错误标签，再重新训练 |
| 免费API突然限流 | 滥用试额度 | 增加缓存、排队、限流，或切付费版本 |
这张表看起来简单，但每一条背后都是真实的生产事故。我的建议是上线前把这些问题提前演练一遍，真到现场才不会手忙脚乱。
6.2 从零开始的学习路线与作品整理建议
很多刚接触大模型的人问学习路线，我给的建议很直接：不要从训练模型开始，先从“用模型”开始。第一步掌握基础理论，理解Transformer结构、tokenizer、注意力机制这些概念，不需要手写实现，读《从零构建大模型》这类资料建立整体认知即可。第二步学提示词工程，把一个模型用好、用稳。第三步本地部署与调用，Ollama和LM Studio在一天内就能跑通。第四步做RAG，这是企业里最常被委托的活儿。第五步学微调，用LoRA试一个小项目。第六步才是智能体和多模态，它们更复杂，最好有前面基础之后再上手。
做项目时，建议每个项目都写一份“作品说明书”。不要只写“我接入了大模型”，要写清楚问题定义、数据规模、模型选择原因、训练或部署参数、评估方式、上线后的成本与效果。这份文档既是自己的复盘，也是面试或向团队汇报时的底气。
我自己的体会是，大模型学习最大的障碍不是资料少，而是信息太杂。与其到处收藏“最强Prompt大全”，不如踏踏实实做完四个小项目：一个本地问答、一个Dify客服、一个LoRA微调模型、一个多模态demo。这四个项目串起来，你就能理解整条技术链路。工具永远在迭代，真正值钱的是判断力——知道什么时候用RAG、什么时候该微调、什么时候只需要提示词就够了。
每次换工具、换模型时，先用最小样本把链路打通，再逐步放大，这个习惯让我少吃了很多亏。整理这篇笔记的过程，也是我对大模型应用和工具的一次重新梳理。如果你正准备在这条路上走下去，希望这些踩过坑的经验能帮你省下一点时间。
