企业官网建设流程全解析

最近我花了不少时间整理大模型相关的学习笔记，越整理越觉得这个领域真正难的不是“看懂一个新模型”，而是把工具链和应用场景连起来。同样一个7B模型，有人拿来做个聊天demo，有人用它做私有知识库，有人用它做工业瑕疵描述，差别不在模型本身，而在你周围那套部署、数据、调用和评估的工具到底顺不顺手。这篇笔记就是我学习“大模型应用和工具”过程中的完整记录，从本地部署怎么选、RAG和微调怎么分工，到多模态、Agent和行业落地，尽量把我实际跑过的方案和踩过的坑都写清楚。

普通初学者最容易犯的毛病是把大模型当成一个黑盒API，觉得能调用就等于会了。但真到落地的时候，你会发现每多一个环节都会多出一类问题：模型放本地还是放云端，推理框架用哪个，显存够不够，上下文越长越卡，微调的数据从哪里来，检索出来的东西到底准不准。这些问题没有一个统一答案，全靠对工具和场景的理解去权衡。这篇笔记适合正在学大模型应用开发、准备做本地部署或者企业内部私有化落地的朋友，有基础的可以直接跳到对应章节，零基础的也能当路线图看。

首先我要说的是，别一上来就背工具，先想清楚你的应用到底提的是哪一类需求。

1. 先搞清楚大模型应用到底在解决什么问题

1.1 大模型应用不是“聊天机器人”这一个答案

现在网上一搜“大模型应用案例”，出来的多半是些客服机器人、文档助手、PPT生成器，容易给人造成一个错觉：大模型应用就等于对话。我在整理笔记时把接触到的真实需求重新分了类，发现其实只有几大类，每一类的技术选型差别非常大。

第一类是内容生成，包括文章写作、代码生成、营销文案、报告摘要。这类需求核心看模型的生成质量和指令遵循能力，对事实准确性要求相对宽松。第二类是知识问答，比如企业内部制度问答、产品文档咨询，这类必须控制幻觉，通常要配RAG。第三类是结构化抽取，比如从合同里提取关键字段、从质检报告里抽缺陷描述，这类考的是模型的理解和格式化输出能力，经常用到大模型微调。第四类是图像、音频、视频的多模态理解，比如工业质检、语音转写，除了模型本身，还涉及与其他系统的前后端适配。第五类是自动化操作，也就是Agent，模型要能理解任务、调用工具、串联步骤。

把这五类想清楚之后再决定模型规模就不容易跑偏。内部知识问答可能7B模型就够，生成高质量长文档或者复杂推理可能要32B以上，而工业瑕疵检测可能压根不需要大模型，用传统CV更稳。很多人一来就问“哪个大模型最牛”，这是典型的错位提问，正确的问题是“我这个场景最需要模型具备什么能力”。

1.2 云端API还是本地单机，判断标准是延迟、成本和数据边界

网上经常看到有人问，工业AI检测、服装检测这类AI到底用的是联网AI还是单机AI，用多大的模型才够。这个问题的答案其实不是“哪一个”，而是“分层”。

拿服装检测举例：如果只是检测某一块布料有没有瑕疵、某个衣领是否歪了，这属于目标检测和缺陷定位问题，传统视觉算法或者YOLO系列这类轻量模型已经做得很成熟，推理速度极快，单机一张普通工业相机配合工控机就能跑，数据完全不出厂。但如果要把检测结果自动汇总成中文质检报告，把不同产线的缺陷原因做自然语言归类，这时候才轮到7B到14B的大模型上场，同样可以本地部署。

选择云端API还是本地单机，我个人习惯从三个维度判断。第一是延迟：产线节拍按秒甚至毫秒算，云端网络往返不可控，必须本地。第二是数据边界：涉及客户隐私、工艺参数、未公开设计的场景，数据就不应该出域，本地部署是唯一合规选择。第三是成本与迭代速度：原型验证阶段用云端免费额度最快，规模上来之后如果调用量稳定，本地推理在长期成本上通常更有优势。这个判断逻辑同样适用于企业大模型私有化部署这类场景。

2. 本地部署工具链：从Ollama到vLLM怎么选

2.1 Ollama：五分钟把7B模型跑起来的第一选择

本地部署的工具我接触过一堆，Ollama至今仍然是我个人推荐给新人的第一选择。它把模型下载、环境变量、接口服务全都封装好了，安装之后基本就是两条命令的事。先用ollama pull把模型权重拉到本地，再用ollama run直接进入交互模式；想当服务用的话，装完模型它会自动在11434端口起一个兼容OpenAI格式的HTTP接口，外部程序直接请求/v1/chat/completions就能对话。

很多人第一次跑的时候会在模型选择上犯难，我建议先选一个7B到8B的通用中文模型（比如Qwen系列这类），文件体积大概在4到5GB的4bit量化版，普通16GB内存的电脑就能流畅跑。Ollama的模型文件默认放在用户目录的.ollama/models里，一个模型对应一组blob存储，换机器或者团队共享时可以把它整个拷走，我实测过这在离线内网环境里非常实用，省去重新拉权重的麻烦。

不过Ollama也有明显瓶颈。它更适合单机、少并发、原型验证，当你有几十个并发请求、吞吐要求高、想要动态批处理的时候，它会显得力不从心。这不算缺点，而是它给自己定义的适用边界，认清边界比盲目追求最强性能更重要。

2.2 LM Studio、低显存方案与IDE接入

如果你是在Windows上做学习或开发，LM Studio可能是比Ollama更友好的入口。它带完整图形界面，能直接选模型、管理下载、看推理日志，甚至可以在界面上调整量化级别和上下文长度。我见过很多同事就是用它把一个7B模型跑起来之后，才开始慢慢理解什么叫KV Cache、什么叫temperature。

这里特别想提一个最近的趋势：本地模型接入开发工具已经非常成熟了。比如Visual Studio 2022现在可以连本地LM Studio起的服务，让它辅助生成代码，体验上虽然不一定比云端最强模型好，但代码不用离开本机，这对很多有代码保密要求的团队来说价值很大。游戏引擎一侧也在跟进，Unreal Engine的新版本在探索通过MCP协议把大模型接进编辑器，让模型辅助生成蓝图描述、资产说明、脚本注释。这类IDE接入的本质，是把本地模型当成本机服务访问，协议统一之后，开发工具的想象力一下就打开了。

如果你连普通显卡都没有，也可以试试AirLLM这类低显存推理方案。它的核心思路是把权重按层加载到内存和显存中逐步计算，速度肯定慢，但至少能把几十B的模型在普通机器上跑起来做验证。这本身就是一种很务实的容错手段，尤其是团队的预算只能买一台普通办公机的时候。

2.3 vLLM：生产环境的高并发推理引擎

项目一旦要上生产环境，我通常会切到vLLM。它的核心优势是PagedAttention和Continuous Batching，简单说就是让显存管理更高效、让多个请求拼车处理，吞吐量相比朴素的推理服务能提升好几倍。它启动服务也非常直白，大概是这样：

vllm serve /data/models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name my-llm

其中--tensor-parallel-size是模型并行卡数，显存不够时才需要设成2或更大；--max-model-len控制最大上下文长度，直接决定KV Cache占用；--gpu-memory-utilization表示允许vLLM使用多少比例的显存，0.9是我在单卡部署时的保守选择，留一点余量给其他小任务。

我踩过的坑是：vLLM对模型文件的trust_remote_code依赖比较大，一些网上流传的“特殊结构模型包”加载不了，经常报key错误。后来养成习惯，一切模型先确认来自官方仓库，再考虑用什么框架加载。还有一点，vLLM版本升级很快，API参数偶尔变化，锁定版本再上线比追新更稳。

2.4 显存、量化与上下文长度：预算到底应该怎么算

很多人听到“本地部署大模型”的第一反应是我得买几张显卡，这里给一个比较粗糙但好用的估算方法。模型权重占用的显存大约等于参数量乘以每个字节数：FP16是2字节，INT4量化大约0.5到0.6字节。一个7B模型FP16大概要14GB显存，INT4则压缩到4到6GB，这就是为什么很多消费级显卡明明只有8G甚至6G显存，也能靠量化跑7B模型的原因。往上走，14B模型INT4至少要10GB显存才算舒服，32B以上的模型，没有一张24GB显卡就想跑量化版会非常勉强。

但权重只是显存的一部分，真正吃显存的大头往往是上下文。上下文越长，KV Cache占用越高，这个增长和层数、头数、输入输出长度都有关。我给出的经验是：8B模型如果上下文开到32K，KV Cache可能额外吃掉8到10GB显存，这比很多人想象中多得多。这也是为什么“大模型上下文长度”这个指标看起来很美，实际用起来必须算显存账。

硬件方面我也想补一句AMD NPU的观察。最近笔记本上的NPU话题很热，很多新处理器的AI算力已经不是纯摆设，一些6B到8B的小模型可以在NPU上做低功耗推理。但目前为止它在生态成熟度上还不够高，大厂的推理框架没有完全统一。我的建议是，预算有限优先保证GPU显存，NPU可以作为轻薄本侧推理的补充方案去实验，暂时别当主力。

3. 微调、RAG与数据工程：让模型真正懂业务

3.1 先分清微调和RAG的边界，别重复造轮子

每个刚开始做企业应用的人都会纠结一个问题：到底是微调还是RAG？我自己的判断标准非常简单：知识是“查出来的”还是“长在模型里的”。如果要更新的是事实类知识，比如最新的产品手册、内部制度，用RAG，把文档准备好、检索准，模型不背知识库的锅；如果要改变的是模型的输出习惯，比如必须按固定格式回JSON、必须用特定话术回答、学会调用特定工具，才考虑微调。

打个比方，RAG等于给一个聪明人一本随时能翻的参考书，微调等于改变这个人的说话风格和工作习惯。参考书解决“不知道”，微调解决“不会做”。很多需求其实用RAG就能解决，但大家总觉得“不微调就不够深入”，结果把微调搞成了面子工程。我见过不止一个项目，数据质量一塌糊涂就硬上微调，训完模型不但没学会业务，还把通用能力弄丢了，最后只能回滚。

3.2 微调真正的门槛不在算力，在数据准备

很多人一提微调就想到要多少张A100，其实大部分实际场景用的都是LoRA或QLoRA这类参数高效微调，7B到14B的模型用一张24GB显卡完全能跑。真正的难点是数据。指令微调的数据格式虽然各家略有差异，但核心结构一定要清楚：一条指令、一个输入、一个预期输出。我见过最常见的翻车原因是数据里面的“预期输出”本身写得乱七八糟，模型当然学不会正确的行为，还容易把噪声学进去。

数据数量上，LoRA在小规模任务里几千条高质量样本往往就够用，重点不在数量而在覆盖。要把任务的可能性尽量铺开：正常情况、边界情况、难例、模型容易答错的例子，最好都要有。数据清洗时还要注意答案一致性，同一类型的问题不能出现互相矛盾的输出。我自己做微调项目时，通常会先跑一个50条数据的小实验，看loss下降趋势和输出格式是否稳定，再决定要不要加数据，这个试错成本非常低，但很多人跳过了。

LoRA的rank参数常见用8到64之间，个人经验是任务越简单、数据量越小，rank可以取低；任务复杂度高再往上调。学习率偏高是新手最容易踩的坑，微调阶段学习率比预训练小一到两个数量级，我常见的情况是设在1e-4左右，再配合几百步的短训练。重点观察的指标不是训练loss归零，而是验证集上的输出是否真的变好了。过拟合在微调里非常容易，训练loss再漂亮也不代表模型学到了业务要领。

3.3 RAG的关键：分块、向量化、召回与重排

“大模型如何理解文档”这个问题被问过很多次，本质上一句话：模型并不直接读文档，而是通过检索把最相关的几段文本喂给它。所以RAG决定质量的第一环不是模型，而是检索。文档进来之后先切块，太大则信息太杂、超出模型窗口，太小则语义被切断、召回碎片化；切完块做向量化，把文本变成高维向量，存进向量库；用户提问时同样向量化，从库里召回相近的片段，再拼进Prompt让模型回答。一句话总结就是先把“图书馆”建好，再让模型当“图书管理员加讲解员”。

实践中提升效果最明显的是三件事。第一是分块策略，不要纯按固定长度硬切，尽量配合标题、段落、小标题做语义分块，我常用200到500字为一个块，重叠几十个字防止语义断裂。第二是召回后的重排，向量召回先取前50条，再用重排模型选出最相关的5到10条，效果比单纯靠向量相似度好得多，能解决“向量距离近但语义不对”的老问题。第三是混合检索，BM25的关键词匹配加向量检索一起用，很多明明包含专业术语但语义向量召回效果一般的情况，混合检索有明显改善。

还有些进阶玩法值得记录。比如知识抽取框架OneKE，可以把非结构化文本里的实体、关系、属性抽取成结构化三元组，把这套结构化知识灌到知识库里，只有非结构化文档的团队也能做出高质量知识问答；又比如HyDE思路，先把问题生成一个假设性回答，再用这个回答去检索，改善查询表达不充分的问题。RAG不是搭完就完事的，它本质上是一个持续调优的检索系统，召回质量才是上限。

3.4 上下文长度不是越长越好，要算成本和效果

最近“大模型上下文长度”成了营销重点，看到128K、1M这些数字很容易让人兴奋，但实际工程里越长越贵。上下文输入的每一段都要参与注意力计算，KV Cache占显存、首token延迟高、单次请求费用上涨，对企业来说都是实打实的成本。我自己做RAG时反而更倾向“能短则短”，检索出来的相关片段控制在两三千字以内，让模型聚焦在没有太多噪音的上下文上，回答质量通常比把大段文档全部塞给它更好。

所以看待上下文长度要分两个层面：模型“最多支持多长”和业务“实际需要用多长”。前者是能力上限，后者取决于你的数据特点。做一个长合同审查项目时，可能真的需要32K以上的窗口；做客服知识库时，上下文控制到8K以内就能非常好用。我建议开发者在预算显存时先按实际业务估算最大输入长度，不要一上来就按模型最大值去占用资源，能省下很多钱，也能避开推理速度踩坑。

4. 多模态、Agent与企业场景落地

4.1 多模态模型：从“能聊”到“能看能听能画”

多模态是近两年迭代最猛的方向。图像理解不再只是给个标题，而是能详细描述画面、定位问题区域；语音模型能做到实时转写和对话；绘图模型也能在本地跑起来，像工程里常见的“图生图”“文生设计稿”已经有不少团队在用了。我接触过的图像生成大模型，例如Z-Image这类可以本地部署的加速文件，下载后配合WebUI或ComfyUI这类前端就能跑，生成速度取决于显卡，8到16GB显存可以出图，但批量出图还是需要有规划地用显存。

语音识别方面，很多前端项目会接实时语音转写大模型API，这类适配的要点我踩过几个。一是必须用流式接口，把音频持续送上去，拿边录边转的结果，不要等录完再上传。二是注意音频编码，调用前确认采样率和编码格式是不是接口要求的，常见是16kHz或者8kHz的PCM，否则转出来的文字会乱。三是断句和标点，模型输出通常自带标点，前端要做的是在静音时长和模型输出之间做平衡，不要频繁触发重写导致界面闪烁。多模态项目做起来会有一种明显的体感变化：单一文本模型只能在文字层面帮忙，多模态模型才能真正“看着问题做事”，这也是我认为后续应用面最广的方向之一。

4.2 AI Agent与MCP：让模型学会调用工具

Agent和单轮对话最大的区别是“行动闭环”。一个Agent应用通常包含任务拆解、工具选择、调用执行、结果观察和继续推理这几个步骤。比如一个客服工单助手，用户说“帮我查一下订单又退款失败的原因”，Agent要先判断需要调用订单查询工具，把查询结果跟退款规则做比对，再生成一段回复给用户。这背后就是一个模型在不断被喂工具描述和工具执行结果的过程。

MCP（模型上下文协议）是打通模型与工具的关键尝试，它标准化了模型服务、数据源和工具之间的接口协议。前端工具接入MCP后，模型不需要为每一个工具写一套定制代码，而是通过统一协议直接发现和调用能力。目前IDE、数据平台甚至游戏引擎都在接入，比如Unreal Engine新版在做官方大模型MCP支持，Visual Studio 2022配合本地LM Studio起的模型也可以走类似路子。对我个人判断来说，以后“大模型应用开发”的很大一部分是在做一个MCP服务器，把内部老系统一个个包装成标准工具，剩下的交给Agent编排。

实际做Agent应用时有两点容易翻车。第一是工具描述要写清楚参数和边界，模型不懂隐藏约定，工具描述写得含糊，它就会拿错误参数反复尝试。第二是必须设计好兜底策略，Agent不是每次都成功，要设置最大循环次数、允许它承认失败，而不是死循环刷调用记录。多看AI智能体的实际应用案例，会发现做得好的Agent通常都在“如何优雅地失败”上下了功夫，这才是不容易被看到的工程价值。

4.3 行业场景选型：工业质检、服装检测到底怎么配

前面提到过工业检测的分层思路，这里展开写一下我总结的判断流程。第一步看任务类型：目标定位、尺寸测量、有无缺陷这类问题，优先考虑传统图像处理和轻量目标检测模型；对缺陷归类、原因分析、报告生成这类语义任务，才考虑大模型。第二步看数据边界和实时性：产线数据能出区域吗？出不了就走本地，出得了且需要复杂推理再评估云端方案。第三步看是不是多模态：有些质检需要图片和文本一起理解，那就要上多模态大模型，而不是纯视觉模型。

内部私有化部署大模型时，我通常建议先从一个“够用”的规模起步。7B到14B的量化模型在很多业务场景已经能覆盖知识问答、文本分类、内容摘要、SQL生成，先跑通流程再谈扩大。团队里如果连提示词都还在频繁调整，就直接上几十B的私有化大模型，只会把问题从“模型能力”变成“运维成本”，非常不划算。这个路线也适用于服装领域的自动质检报告、生产知识库、供应商问答等场景。

还有一个容易被忽视的点：无论本地还是云端，效果评估都要提前设计。工业场景尤其需要“可解释”，模型给出缺陷描述后，能不能引用对应的图像区域，敢不敢在低置信度时拒绝回答，这些比模型的“聪明”重要得多。落地任何一个大模型应用，先定义好衡量标准，再调模型和工具，是我从多次失败里学到的最大教训。

5. 学习路线与避坑清单：给后来者的实操心法

5.1 从零到落地的一条实用学习顺序

如果现在有人问我大模型学习路线，我会建议先动手后理论，不要囤资料。第一步，从使用开始，用Ollama或LM Studio把一个7B模型跑起来，理解模型文件、量化、上下文长度这些词的实际含义。第二步，学提示词工程，这不需要写代码，但能让你体会模型的能力边界，也是后面所有应用的基础。第三步，把模型封装成API，写一个简单的对话脚本，熟悉OpenAI兼容接口的请求和返回格式。第四步，做一个带RAG的知识库问答项目，这个阶段你会开始接触向量化、检索、重排这些概念。第五步，做一次LoRA微调，用公开数据集指挥小模型回答问题，感受数据对结果的影响。第六步，再去看Agent和MCP，这时候你已经知道工具调用的必要性了。

这个顺序的好处是每一步的产出都能看到，反馈周期短，不容易中途放弃。网上流传的“从零构建大模型”一类PDF教程，我不太建议去买来囤着，想看原理直接看经典公开课和模型作者的官方论文就够了，实践比原理更容易让人持续学下去。学到后面你会发现，真正的分水岭不是“会不会跑模型”，而是“会不会设计和评估实验”，这只能靠多做项目积累。

5.2 免费API、离线模型下载的正确姿势

学习阶段用好免费API能省不少时间。国内一些大模型开放平台会给新用户提供试用额度，拿来做原型验证、功能测试绰绰有余。要注意的是免费额度通常有每分钟请求次数限制，跑批量测试不要开太多并发，免得被限流了还以为是代码写错了。等业务稳定了，再评估是不是切换到私有化部署或者买更合适的付费档位，这个路线对个人学习和企业小团队都比较平滑。

离线模型下载是被问得最多的一类问题。总有人问Qwen离线版怎么下、某个所谓“私有大模型”网盘包靠不靠谱。我的建议一直很明确：只认两种渠道，一是模型官方发布的仓库，二是可信的模型社区官方入口。以Qwen系列为例，直接去ModelScope或者Hugging Face搜官方组织名，选择对应参数量的instruct版本即可。像“Herdsman”“Agnes”这类名字，我建议下载前先查清楚发布方是谁、有没有官方文档，来历不明的“整合包”“一键包”风险非常高。

这里必须多说一句：大模型投毒不是段子。来路不明的模型权重可能在常规问答里表现正常，但在特定指令下输出恶意内容或者泄露用户数据。下载任何模型文件后，最好比对官方发布的SHA256校验值，加载到本地后先用一组已知的边界输入做测试，确认行为符合预期再接入业务。对这个领域保持基本的敬畏，能帮你避开很多不能回撤的麻烦。

5.3 高频问题排查与避坑清单

最后把我笔记里的高频问题整理成一张速查表，都是我自己和身边同事实际遇到过的情况，你可以先从这几行开始排查。

还有一些常规误区一并写出来：模型服务路径不要放中文和空格，vLLM和Ollama对特殊字符目录非常敏感；做RAG时不要拿着调试期的向量库直接上线，数据更新后要重建索引；微调前备份base model权重，回滚比重新训练省太多事。学习阶段的工具宁可少而精，也不要贪多，把Ollama、vLLM、一个向量库、一个微调框架用透，已经足够支撑绝大多数中小型项目了。

整理完这些笔记，我自己最大的感受是：大模型应用这件事，工具只是放大器，真正决定上限的是你对场景的理解和数据工程的耐心。一个问题如果在提示词层面解释不通，多半是上下文里根本没给够信息；一个模型如果输出格式总是乱，多半是数据里的格式本身就不统一。跑通demo的人很多，把效果做稳定的人很少，差距恰恰在这些看起来不酷的细节里。希望这份笔记能帮你在踩坑之前，先看到坑在哪里。