企业官网建设流程全解析

大模型这个词，现在几乎是每个技术团队都绕不开的标配了。过去一年我扎扎实实参与了不少大模型相关的落地项目，从最基础的聊天机器人、企业内部知识库，到多模态图片理解、工业缺陷检测辅助，基本把主流接入方式、部署方案和配套工具都过了一遍。踩的坑不少，但经验也确实攒了一堆。这篇东西不想讲教科书里的“Hello World”，而是想把我实际项目里用到的应用场景、模型选型、部署工具、微调与RAG实践，以及那些文档里不会写的避坑点，系统地盘一遍。不管你是准备入门的新手，还是已经在做应用开发的工程师，应该都能找到一些能直接用起来的思路。

1. 先想清楚：大模型的应用边界到底在哪

1.1 文本生成与理解：当前最成熟的一类应用

绝大多数人第一次接触大模型，都是从文本开始。比如让模型写一段产品文案、做会议纪要、自动回复客户邮件、从长篇合同里抽取关键条款。这类应用技术上是所有大模型场景里最成熟的，不需要自己训练模型，调用API或者本地部署一个开源模型就能跑起来。

我遇到最多的需求其实是“知识库问答”——把公司的规章制度、技术文档、行业报告喂给模型，然后让员工用自然语言提问。这里有个容易忽视的真相：真正的难点往往不在模型本身，而在怎么把文档切片、向量化、召回做得足够准。比如有一次做合同问答，用户问“违约金的计算方式”，如果直接拿这句话去向量检索，效果很差；我会先把问句做一次改写，扩展出“逾期支付违约金的比例”“解除合同赔偿标准”这类同义表述再去检索，召回率马上就不一样了。所以哪怕只是做问答，也别一上来就琢磨微调，先把检索链路调通，问题就解决了一大半。

1.2 多模态大模型：图片、语音、视频一起处理

文本之外，多模态是近几年大模型最亮眼的方向。很多开源模型已经能做到“看图说话”：给一张产品渲染图，它能生成卖点文案；给一张设备故障照片，它能描述故障部位和可能的原因；甚至拿一段监控视频，让它按时间轴输出异常事件。

我在实际项目里跑过两个场景。一个是给电商运营做“穿搭描述”，他们输入一张服装图片，希望自动生成商品详情页里的风格、面料、尺码建议。以前靠人工写，一条商品要十几分钟，换成多模态模型后，五分钟能出十张图的初稿，运营只需要在最后把关。另一个是给设备维护团队做“故障描述助手”，老师傅拍一张磨损零件照片，模型能自动生成包含故障部位、可能失效原因、建议检查项的维修工单草稿。模型输出不一定百分百准确，但能把老师傅的隐性经验“外挂”给新人，这个价值非常直接。

1.3 垂直场景：工业检测这类场景到底用不用大模型

不少朋友在问：像工业AI检测、服装检测这类应用，用的是云端联网还是单机AI？用的大模型够不够？这个问题特别有代表性。先给结论：纯工业质检，比如焊点缺陷、划痕、布匹瑕疵，绝大多数生产线上跑的是YOLO这类轻量目标检测模型，而不是通用大模型。原因很现实——产线要求毫秒级响应和99%以上的稳定性，大模型推理速度现在很难满足；而且产线数据非常敏感，很多工厂不允许数据出厂，所以只能本地单机部署。

但大模型在工业场景里也不是完全没位置。我见过一个很聪明的方案：先用轻量检测模型把可疑区域标出来，再把这小块图像传给多模态大模型做“二次确认”，由它判断缺陷属于哪一类、严重程度如何、是否需要立刻停机。这样既保住了实时性，又用上了大模型的语义理解能力，能帮质检员大幅减少误判。所以关键问题不是“用不用大模型”，而是“把大模型放在整个链路里的哪一层”。

2. 工具选型：本地部署、云端API、私有化，到底怎么选

2.1 三种接入方式对比与决策逻辑

刚接触项目时，团队最常问我的就是“模型到底应该放哪儿”。这里无非三种选择：云端API、本地部署、私有化集群。我习惯用一张表帮他们快速定位：

决策逻辑我一般是三步走：先评估数据敏感度，再算请求并发，最后看团队有没有GPU资源。如果只是内部工具，用Ollama本地部署基本够；如果要做成产品供外部使用，那就要考虑vLLM甚至K8s集群了。

2.2 Ollama：本地部署的首选工具

要说这两年本地跑大模型最“省心”的工具，Ollama排第二没人敢排第一。它把模型下载、依赖管理、推理服务打包成了一个命令，新手也能五分钟跑起一个模型。

我平时最常用的流程是这样：

1. 到Ollama官网下载对应系统的安装包，装完命令行就有ollama命令了。
2. 拉取模型：ollama pull qwen3:8b。
3. 启动对话：ollama run qwen3:8b。

这里多说一句，很多人好奇ollama pull下来的模型文件到底是什么。Ollama用的是一个叫GGUF的格式，它是把模型权重、分词器、配置信息打包成一个文件，方便分发和加载。GGUF本身经过了量化压缩，所以模型文件体积比原始权重小很多。比如8B参数的模型，原始FP16权重约16GB，量化成q4之后只有4.5GB左右，这样普通消费级显卡也能跑。

Ollama还自带一个OpenAI兼容的API服务，跑起来之后，任何能对接OpenAI接口的工具都可以直接把地址指向http://localhost:11434/v1，这一点我在后面接VS Code和Dify时会反复用到。

2.3 vLLM：当并发和吞吐上去了，就要换引擎

Ollama用来做个人工具和内部小范围试用非常舒服，但一旦要让几十上百人同时用，它的吞吐量就有点吃不消了。这时我一般会换到vLLM。

vLLM是一个专门为高吞吐推理设计的引擎，它最核心的优化叫PagedAttention，可以理解为给显存里的KV Cache做“分页管理”，像操作系统管理内存一样。这样显存利用率高很多，同一个GPU上能并发的请求数也更多。

部署vLLM也不复杂，装好Python环境后：

pip install vllm vllm serve Qwen/Qwen3-8B --port 8000

然后你的服务就是一个标准的OpenAI兼容接口。实测下来，同等硬件条件下，vLLM的吞吐能比普通推理方式高出好几倍，适合做生产环境。

2.4 免费API和模型服务：快速试错的捷径

不是所有项目一开始都需要自己部署。很多大模型厂商会提供免费额度，足够你跑完一轮概念验证。另外还有一些开源模型托管平台，把开源模型封装成API，省去自己买显卡的投入。

不过我要提醒一句：用免费API做验证可以，但千万别把核心业务直接挂上去。免费额度往往有并发限制，也不保证服务可用性。正确的姿势是先用API把业务流程想清楚，等模型验证没问题之后，再评估要不要换成本地部署。

3. 从零跑通一个大模型：实操细节与参数计算

3.1 模型参数与显存：先算账再动手

很多人拿到模型就往机器上扔，跑不起来才回来研究显存，这个顺序其实反了。部署前必须先算一笔账：模型需要多少显存。

估算公式很简单：参数量 × 每个权重占用的字节数。

比如一个8B参数的模型：

• FP16精度，每个权重占2字节：8B × 2 = 16GB，再加上推理时需要的KV Cache和中间激活值，实际至少要20GB以上显存。
• 4bit量化，每个权重约0.5字节：8B × 0.5 ≈ 4GB，加上开销，6GB左右就能跑起来。

这就是为什么量化技术这么重要。所谓量化，就是把模型权重从16位降到4位或8位，牺牲一点精度换体积和速度。我自己实测下来，8B模型用4bit量化，在日常任务里精度损失几乎感觉不到，但能把部署门槛从20GB显存拉低到6GB，性价比极高。

3.2 用Ollama跑通Qwen3的完整流程

我强烈建议新手从Ollama开始，下面这套流程我已经带过好几个人走通了。

首先安装Ollama，装完先确认版本：

ollama --version

然后拉取模型。以Qwen3的8B版本为例：

ollama pull qwen3:8b

下载速度取决于网络，但Ollama支持断点续传，中断了重新执行就行。拉完直接运行：

ollama run qwen3:8b

进入交互界面后，你可以直接问它问题，比如让它写一段代码、解释一个概念。退出用/bye，查看已下载模型用ollama list。

如果觉得默认的上下文长度不够，启动时可以设置环境变量。比如我想给模型32K上下文：

OLLAMA_CONTEXT_LENGTH=32768 ollama run qwen3:8b

这个参数设置的是模型能同时参考的最大token数量，后面会专门讲。

3.3 把本地模型接进VS Code：让AI帮你写代码

很多同学问：“VS Code能不能连接本地LM Studio，直接让它生成代码？”答案是能，而且步骤比想象中简单。

先明白原理：LM Studio是一个带图形界面的本地模型运行工具，它启动后会提供一个OpenAI兼容的本地API，默认地址一般是http://localhost:1234/v1。VS Code这边则需要装一个支持OpenAI接口的AI编程插件，比如Continue或者Cline。

配置步骤：

1. 在LM Studio里加载一个模型，比如Qwen3-8B。
2. 打开LM Studio的“Local Server”开关，让它启动API服务。
3. 在VS Code的插件设置里，把API地址填成http://localhost:1234/v1，模型名填成你加载的名字。
4. 重启VS Code，让插件重新连接。

这时你选中代码按快捷键，AI就会基于当前代码上下文给出建议。实测下来，用本地模型做代码补全、生成单测、解释复杂函数，速度虽然比云端GPT-4慢一点，但最大的好处是代码完全不出本机，适合有保密要求的项目。

3.4 上下文长度：别贪多，小心显存爆掉

上下文长度这个参数，很多人只把它当营销数字看，觉得越长越好。实际上它和显存强相关：模型每处理一个token，都要在KV Cache里存一份Key和Value，上下文越长，这部分占的显存就线性上涨。

我自己的习惯是先搞清楚业务场景需要多长的上下文。如果是做客服问答，用户消息加上知识库召回片段，2K到4K完全够；如果是分析一份几十页的报告，那就需要16K甚至32K。给一个经验值：8B量化模型，8K上下文大约额外占1-2GB显存，32K就要再吃4GB以上。显存紧张时，宁愿把文档切成小段分段处理，也不要盲目拉长上下文。

4. 进阶玩法：微调、RAG与智能体

4.1 微调：什么时候必须做，什么时候别碰

模型跑通之后，很多人下一步就会想“我要微调”。我先把话放这儿：微调是最后的手段，不是首选方案。

什么情况下才需要微调？一种是你希望模型稳定输出某种固定风格，比如法律合同必须用严格的法律条款语言；另一种是你的业务有大量专有术语，比如某型号设备故障代码，通用模型完全没见过。这两种情况，用RAG很难根治，因为问题不是“信息不在资料里”，而是“模型不熟悉这种表达方式”。

微调的实操我推荐LoRA，一个非常轻量的微调方法。它不改变原始模型的全部参数，只训练一小部分新增的“低秩适配器”，成本低效果好。我是这样做的：

1. 准备数据。至少几百条到几千条对话样本，格式最好是instruction、input、output三段式。
2. 用开源工具如LLaMA-Factory加载模型和数据集。
3. 配置LoRA参数，r一般设为8到16，学习率3e-4。
4. 训练完成后，导出一个合并后的模型文件，再用Ollama或vLLM部署。

但我也见过不少团队花两周微调，效果还不如直接用RAG，因为他们的数据量只有几十条，模型早就“学会”了通用知识，几十条样本只会把它带偏。所以做微调前，先问自己：手里的数据量够不够？问题是不是真的出在“模型不懂”，而不是“模型没查到”？

4.2 RAG：让大模型学会查资料

RAG（检索增强生成）是当下企业落地大模型最具性价比的方案。核心思路是：不指望模型记住所有知识，而是让它在回答问题前先去资料库检索相关内容，再基于检索结果组织答案。相当于给模型配了一个“随身的文档库”。

我在项目里用的是Dify，它是一个开源的大模型应用开发平台，界面化操作，非常适合快速搭建知识库应用。Dify接入本地大模型有两种方式，我最常用的是先启动Ollama，然后在Dify的设置里填上Ollama的API地址和模型名，这样一个本地知识库应用就通了。

具体流程如下：

1. 在Dify里创建一个“知识库”。
2. 上传PDF、Markdown或Word文档，Dify会自动做切片。
3. 配置向量化模型，这一步负责把文本变成向量。最简单的是用Dify内置的向量模型，或者接入本地Embedding服务。
4. 创建聊天助手应用，在“提示词编排”里关联这个知识库。
5. 发布应用，得到一个可以对话的页面或API。

RAG的调优核心在切片大小和召回数量。切片太大会让检索结果太杂，切片太小会丢失上下文。我一般先用500到800个字符的切片跑一轮，再看回答质量微调。召回数量也别贪多，取3到5个片段通常已经够模型生成高质量回答了。

4.3 AI智能体：从“回答问题”到“解决问题”

如果说RAG让大模型学会了查资料，智能体则是让大模型学会了“干活”。智能体本质上是一个能调用工具的Agent：它接收到用户请求后，会自己规划需要哪些工具，再逐个调用并汇总结果。

我举一个帮客户做的工单处理例子。原来用户报障，需要客服判断问题类型、查知识库、填工单，一套下来要几分钟。用Dify搭了一个智能体后，流程变成：

1. 大模型先理解报障内容，提取关键词。
2. 调用“问题分类工具”，判断是网络问题、硬件问题还是软件问题。
3. 调用“知识库检索工具”，查找对应解决方案。
4. 如果知识库没有答案，调用“建单工具”，自动生成待处理工单并通知负责人。

整条链路跑下来，80%的简单问题可以由智能体直接回复，复杂问题再转人工。关键点在于：智能体不是魔法，它的核心是把一个复杂的业务流程拆成几个清晰的小步骤，然后让模型做决策路由。任务拆得越细，智能体越可靠。

如果你也想自己试，我建议从Coze或Dify这类可视化平台开始，先把工具调用、节点连接的概念跑一遍，再考虑用代码实现自己的Agent框架。

5. 常见问题与避坑指南

5.1 显存不够怎么办

这是本地部署被问得最多的问题。除了前面讲的量化，还有几个思路。一个是换更小的模型，比如7B跑不动就上3B，很多任务3B经过优化后效果也不差。另一个是开启CPU/GPU混合推理，允许模型把部分层放到内存里，牺牲一点速度换容量。还有一个容易被忽略的：检查后台是不是有别的进程占着显存，nvidia-smi看一眼就知道了。

有朋友问过AMD的NPU能不能跑大模型。目前主流推理框架对NPU的支持还不像GPU那么成熟，虽然有些模型能通过优化跑起来，但生态和性能跟N卡相比仍有差距。现阶段预算允许的话，优先考虑N卡；如果只有A卡或NPU，建议先用云端API做验证，别一上来就折腾本地方案。

5.2 生成内容不靠谱，如何提高准确性

大模型幻觉是绕不开的坑。模型看起来说得头头是道，实际可能是编的。我一般会先降低温度参数，比如temperature从默认的0.7降到0.2，让模型输出更保守。其次，如果是知识库问答，检查召回结果是否真的包含正确答案，很多时候问题不在生成而在于检索没召回对。最后，可以在提示词里明确要求“如果资料中没有明确信息，请直接说不知道”，这一招能挡住大半的胡编乱造。

5.3 推理速度太慢，线上体验差

推理慢通常由两个原因造成：一是模型太大或未量化，二是并发上来后引擎调度能力不足。前者用量化解决，后者建议换成vLLM。还有一个点经常被忽略：输入长度越长，首字延迟越高。如果用户咨询内容很长，可以先做一轮自动摘要，再把摘要送进模型，往往能显著提速。

5.4 数据安全与私有化部署的真实代价

很多企业一上来就要求私有化部署，觉得数据在自己手里就安全了。这个方向没错，但要清楚私有化不是免费的：你需要GPU硬件投入、模型运维人员、持续的版本升级，以及模型3-5年内的更新迭代责任。如果只是内部几十个人用，本地部署在Ollama上完全够了；如果数据敏感度没那么高，云端API加上严格的脱敏流程，其实更省钱。我见过一个公司为了“私有化”买了两张昂贵的显卡，跑了半年，使用频率却不到10%，这就是典型的投入产出失衡。

最后再分享一点个人经验：大模型应用和工具升级迭代非常快，与其追着每个新模型换一轮方案，不如先把一套工具链用熟。我是从Ollama起步，跑通之后又接触vLLM、LM Studio、Dify，逐渐形成了“本地推理+可视化编排+API对接”的组合拳。这个路线对大多数团队来说，试错成本最低，见效也最快。你完全可以先从一个小场景开始，用最简单的工具把它跑通，再慢慢叠加能力。等到对这个领域有了手感，再考虑微调或者自研框架也不迟。