最近不少电厂的朋友在问我大模型本地部署的事。有人觉得是跟风想再等等有人觉得直接调云端API更方便不用买显卡还有人纠结是不是非要弄几台八卡服务器才行。我在电力信息化这行干了十多年从两票系统做到智能巡检见过太多厂商把概念包装成产品。但大模型这次不一样尤其是对电厂这种“老师傅经验比标准条文还重要”的行业本地部署的大模型是少数能直接兑现价值的AI技术。而且我说的不是“观望”是“立即”——原因不在硬件多便宜而在知识资产的整理、人员的习惯培养、系统的改造磨合每一件都需要提前启动。这篇文章不兜圈子只讲清楚三件事大模型在电厂到底能干什么、为什么必须本地部署而不是调用云端API、以及从零到一落地一套可用系统要经过哪些步骤和坑。不管你是电厂信息中心的负责人还是准备在班组里做小范围验证的技术骨干读完应该能少走不少弯路。1. 电厂的大模型应用不是赶时髦是知识资产变现1.1 电厂真正的痛点知识难以检索和传承电厂沉淀的知识量是惊人的。每个厂都有几十上百本运行规程、检修规程、设备说明书还有历年的事故分析报告、异常事件记录、技术监督报告以及分散在老师傅脑子里的判断经验。这些内容以前只服务两种场景一是纸面翻阅二是师傅带徒弟。问题在于等到真要查的时候要么不知道关键词要么知道关键词但找不全要么老师傅退休了经验就断档了。大模型擅长的事情正好是“自然语言到信息的转换”。值班员不需要背出规程第几页只要用一句平时说话的方式提问模型就能从知识库里检索到相关条文并组织成可读的回答。这个价值在电力行业是被长期低估的因为大家习惯了“自己翻资料”但其实翻资料的效率损耗已经积压了很久。1.2 最值得先落地的四个场景第一批场景不需要太复杂建议从“只读型、低风险、高频”入手。运行操作辅助问答查询倒闸操作步骤、设备启停条件、保护定值含义、异常处理原则。这类问题每天都有回答错了也不会直接触发控制动作只要标注“供参考、需按规程复核”就相对安全。安全培训与考核新员工入厂培训时问“动火作业需要注意什么”“进入有限空间前要做哪些气体检测”大模型可以结合厂内制度给出针对本厂的答案比通用安全手册更有价值。文档处理助手自动生成检修总结初稿、缺陷描述规范化、会议纪要整理。这些工作占用技术员大量时间模型完成草稿后人工修改能把两小时压缩到二十分钟。报警与日志辅助分析把DCS或SIS的历史报警记录导出让模型帮忙做事件聚类和初步原因排查。注意这里只做离线分析不接入实时控制回路。这四个场景的共同特点是“读多于写”出错后果可控且可以快速验证效果。等运行人员真正用惯了再逐步扩展到更复杂的辅助决策。1.3 为什么非得是“立即”拖一年差距有多大很多电厂想等集团统一规划想等成熟产品想等硬件降价。但问题在于集团统一规划往往意味着标准化的数据平台这本身没错可电厂知识库的清洗、结构化、标签化工作并不会有别人替你做。任何大模型应用要跑出效果底层的知识资产必须提前整理成机器可读的格式。这个工作越早启动越好因为它和模型迭代速度无关。另外一个现实是开源模型的迭代速度已经远超预期。今天一个70亿参数的量化模型就能在1~2秒内返回一段还不错的规程问答一年后能力更强但你的历史数据积累、人员使用习惯、接口对接经验不会自动生成。等到“标准”确定后再动手你会发现模型选型可以很快最难的部分反而是自己厂内的数据整理和业务磨合这些都需要时间。所以我才说“立即”——不是叫你立刻买一堆最贵的卡而是立刻拉一个小团队找一台带显卡的服务器先把第一个原型跑起来。2. 为什么一定是本地部署云上API在电厂行不通2.1 数据敏感性和合规要求决定了数据不能出内网电厂属于关键基础设施运行数据、设备参数、操作记录、保护定值等信息有严格的保护要求。调用云端大模型API即使服务商承诺“不保存、不训练”数据在物理层面也已经离开了内网。对于有监管审计的电力企业来说这是不可接受的风险。很多同行觉得“我传一段规程文本有什么要紧”但在合规视角下只要数据出域这件事本身就构成风险一旦被检查出来责任说不清楚。本地部署意味着模型权重和你的文档都在自己机房数据流全程不出内网这是最稳妥的合规路线。2.2 网络隔离与可用性不允许依赖外网服务电厂网络通常被严格划分为生产控制大区和管理信息大区两个大区之间用单向隔离装置管理信息区对外也有边界防护。要调用云端API必须让内网服务器能够访问公网这本身就破坏了安全分区的基本原则。更要命的是很多电厂位置偏远公网带宽有限链路抖动也不少见。巡检员半夜在现场问一个操作步骤结果API超时三秒这个应用就会被一次否定。本地部署的模型完全依赖内网资源只要服务器不宕机问答服务就一直在线这种可靠性是生产场景的基本要求。2.3 从长期算账本地部署比API便宜得多不少管理者看到GPU服务器报价就心里一紧。但如果把账算到三年结论会反转。以一个三四百人的电厂为例假设有五十个技术岗位经常使用AI问答每月API调用量按中频算token费用可能在一两万元上下再叠加带宽成本、数据脱敏改造成本一年至少二十到三十万。而本地部署一台双路CPU加一张24G显卡的服务器大概十几万到二十几万模型本身几乎免费三年内无需按量付费。更关键的是本地部署之后可以支持不限次数地调试、测试和内部推广不会有“调接口时想着每分钟花多少钱”的心理负担。2.4 只有本地才能把大模型“揉进”现有业务系统电厂的业务系统五花八门EAM、MIS、SIS、两票系统、培训系统。如果大模型在云端要和这些系统深度集成数据链路会非常别扭也不可能做到低延迟的同步调用。本地部署后大模型就是一个运行在内网的标准API服务可以嵌入到已有的门户里或者被各个业务系统直接调用。比如在开工作票的系统里旁边多一个“智能助手”窗口它读取当前页面的设备上下文自动生成票面信息提示。这种体验只有本地化服务才能真正实现云端API做不到。3. 本地部署大模型的选型实务硬件、模型、工具链3.1 硬件规划从16G显存的单卡到多卡先算清账硬件配置是劝退很多电厂的第一道坎其实没有必要一步到位。我给一个经验性的参考表大家按照自己的实际需求定位档位。目标场景模型规模量化精度建议显存整机参考简单问答、知识库查询7B~8BINT4/INT88~16GB单路CPU 一张16G显卡更高质量中文问答、中等知识库14BINT412~16GB一张24G显卡长文档分析、复杂推理32BINT424GB以上两张24G显卡大规模知识库微调预备32BINT4/FP848GB以上双卡或多卡这里的“量化”是把模型的数值精度从FP16压缩到INT8或INT4模型文件变小、显存占用降低、推理速度变快质量损失很小。对于问答和知识库场景完全足够。如果预算有限CPU也能跑七B模型只是速度慢适合先做功能验证不建议直接上生产。内存建议至少64G因为模型推理时除了显存CPU内存还需要存放上下文和中间数据。硬盘一定要用NVMe SSD模型文件动辄几十GB加载速度和日常读取体验差很远。3.2 模型选择别追最大选“跑得动且好用”的开源模型现在开源模型生态已经非常成熟主流的中文开源基座模型有Qwen系列、DeepSeek系列、GLM系列等各有优势。选择原则不是看评测榜单排第几而是看三点中文能力是否够用、上下文窗口是否匹配你的文档处理场景、社区有无成熟的量化版本。比如一个典型场景只做规程问答7B或14B模型完全够如果要经常上传长规程让模型总结就要关注上下文长度选支持32K甚至更长窗口的版本如果硬件只有16G显存则优先选社区已经做过INT4量化且验证稳定的模型不要自己去踩量化兼容性的坑。再强调一句慎用刚发布的最新超大模型。硬件跟不上时一个70B模型在单机上根本跑不动反而会让项目卡壳。务实的做法是“选一台机器能流畅推理的最大模型”而不是“榜单上最强的模型”。3.3 工具链组合Ollama、Dify和向量库各干什么本地部署不是只有一条路工具链大致分三层模型运行层Ollama是目前最简单的方案。它把模型下载、加载、API服务封装成一条命令提供OpenAI兼容接口。适合快速跑通原型。应用构建层Dify、FastGPT这类开源平台可以可视化搭建知识库、Prompt编排、工作流和权限管理。它们能直接对接Ollama也内置了向量数据库。对于缺乏专职AI开发人员的电厂这是最推荐的一层。定制开发层如果现有系统要深度集成也可以用Python直接调用Ollama或vLLM提供的API自己写检索逻辑。但这条路维护成本高建议等前两层跑通后再考虑。我的建议是“Ollama Dify”起步理由很简单Ollama把最难的环境问题解决了Dify把知识库和界面问题解决了剩下你只需要关注业务本身。整个过程不写一行复杂代码。3.4 离线安装并没有想象的难很多电厂内网与公网隔离一看“AI”就先担心没法下载安装。实际上离线部署是完全可控的找一台可以访问互联网的工程机提前下载好模型文件、Docker镜像、安装包通过移动介质或摆渡拷入内网。Ollama的模型目录结构是清晰的可以直接拷贝覆盖。Dify则可以用docker save导出镜像再到内网用docker load导入。这套流程我已经实践过多次只要提前规划好版本离线安装一点也不神秘。4. 落地实操一周时间搭建电厂本地知识问答系统4.1 环境准备内网Linux服务器怎么初始化建议使用Ubuntu 22.04 LTS稳定而且社区资料多。拿到服务器后先装系统再装NVIDIA驱动和CUDA。内网环境怎么装驱动提前在能联网的机器上到NVIDIA官方下载runfile或deb包用U盘拷进去安装即可。装完验证nvidia-smi看到显卡型号、驱动版本、显存容量就说明GPU正常识别了。还要确认一下CUDA版本和后续模型运行要求的匹配关系一般2024年之后的驱动都支持CUDA 12.x满足主流推理框架需求。接下来安装Docker。可以用官方脚本在联网机器上下载好deb包内网中dpkg -i安装然后配置内网镜像仓库或者直接导入镜像。装完后设置systemctl enable docker保证开机自启。4.2 模型服务用Ollama完成离线部署与API发布Ollama的安装同样支持离线。下载对应架构的二进制包放到/usr/local/bin给执行权限然后启动# 监听内网所有地址 export OLLAMA_HOST0.0.0.0:11434 ollama serve为了让服务常驻可以用systemd管理。创建/etc/systemd/system/ollama.service内容里指定EnvironmentOLLAMA_HOST0.0.0.0:11434然后systemctl enable --now ollama。模型文件怎么进内网在能联网的机器上执行ollama pull qwen2.5:7b然后把~/.ollama/models整个目录拷贝到内网服务器的同一位置再执行ollama list就能看到模型。测试一下curl http://127.0.0.1:11434/api/generate -d {model: qwen2.5:7b, prompt: 请介绍一下汽轮机主蒸汽温度过高的常见原因}如果返回一段通顺的文字说明模型服务已经跑起来了。这一步的关键是确认API可以响应后续所有上层应用都靠这个API工作。4.3 知识库用Dify把规程文档变成可检索的库拿到模型API后再部署Dify。Dify官方提供docker compose配置把镜像在联网机器上导出拷入内网后docker compose up -d启动。启动后浏览器访问Dify的Web界面做三件事。第一添加模型供应商。在“设置”中找到Ollama类型填入API服务地址http://服务器IP:11434注意不要填localhost因为Dify容器和Ollama不是同一网络栈要填宿主机IP。第二创建知识库。上传厂内规程文档支持PDF、Word等格式。分段设置里我建议先按500字符分块、overlap重叠设为50。规程类文档通常条目清晰切太碎会丢失上下文切太大又会检索不准。上传后系统会用embedding模型生成向量索引。第三创建应用。选择“聊天助手”类型把知识库挂上去然后在提示词里明确写“你是电厂运行专家回答时必须依据知识库内容如果没有检索到相关依据必须回复‘根据现有资料暂时无法确认’不能编造。”这样能在很大程度上减少模型胡说八道。4.4 应用发布反向代理、权限与审计Dify自己带了基础账号体系但电厂通常希望统一用内部账号登录。建议在Dify前面加一层Nginx反向代理启用TLS设置IP白名单只允许管理信息区内的网段访问。再给Dify里面的应用生成API密钥供门户系统调用。还有一条容易被忽略审计。大模型回答只能是“辅助”不能让一线员工觉得这是“正式指令”。所以要在应用里开启日志功能记录“谁在什么时间问了什么问题、模型依据哪些文档片段生成了什么回答”。一旦出现问题可以追溯。同时在每一条回答下方固定显示免责声明“AI辅助建议仅供参考执行前需按正式规程复核。”5. 运行维护中遇到的坑与排查方法5.1 推理慢的排查清单推理慢先看GPU有没有真正参与。nvidia-smi观察显存占用如果显存为0但CPU使用率很高说明模型跑在CPU上需要检查Ollama是否识别了GPU。再查模型是否完全加载到显存ollama ps可以看到当前加载的模型和显存占用。如果确认在GPU上还是慢检查上下文长度设置。有些应用为了追求“能处理长文”把上下文设到32K这会让计算量成倍增加。对大多数知识库问答场景4K到8K足够了。另外并发不能开太大默认Ollama只加载一个模型、限制并发数可以通过环境变量OLLAMA_NUM_PARALLEL适当提升但别超过显存余量。5.2 回答“一本正经胡说八道”怎么办大模型最让人担心的就是幻觉。解决思路不是完全信任模型而是通过提示词和检索约束它。前面已经提到提示词要严格但只写提示词还不够。知识库回答最好强制引用来源Dify里可以配置“回答中附上引用来源编号”让回复下方显示“依据《汽轮机运行规程》第X章”。如果某次回答没有引用来源说明模型在自由发挥就要人工审视。还可以把温度参数调低。温度是控制随机性的参数设置为0.1到0.3之间模型输出会更保守、更倾向选择高概率词幻觉会明显下降。这是最简单有效的调参手段。5.3 显存和内存不够时的降级方案经常遇到的问题是机器显存16G但想跑14B模型结果OOM。解决路径有几条按优先级排列。第一条换更小的量化版本比如从INT4再压缩到INT3或INT2虽然质量下降但应急可用第二条减小上下文窗口把max context从4096降到2048显存占用会有明显下降第三条让CPU和GPU混合推理即部分层放显存部分层放内存速度会变慢但至少能跑起来。如果彻底不行就换更小的模型7B总比没有强。5.4 知识库检索不到或检索乱怎么办明明上传了规程但问问题却检索不到这是RAG应用最常见的问题。先检查分段参数如果分段太大一个问题可能要检索到几千字的文本块embedding相似度被稀释答案自然不准如果分段太小缺少上下文也匹配不到。500字符左右、overlap 50是经验起点还要根据文档结构调整。规程文档每个章节有标题最好能按标题层级切分而不是纯按字符硬切。如果检索结果里混入大量不相关内容可以把TopK检索返回条数调小比如从5降到3。还可以引入rerank重排序Dify等平台已经支持会先把候选片段粗筛再按相关度精排准确率提升非常明显。embedding模型建议选择针对中文优化的本地模型如bge-m3等不要用默认的英文模型处理中文规程。5.5 安全红线大模型服务和生产控制必须隔离再强调一次部署位置绝对不能乱放。任何本地大模型服务只能部署在管理信息大区不能部署在生产控制大区。模型输出只能作为信息参考不能直接进入DCS、PLC或其他控制回路。如果有系统想从SIS取数据给模型分析只能单向读取数据不允许反向写入。这条底线要写进厂里的AI应用管理制度同时在实际网络策略上强制落地不给任何绕过空间。6. 从RAG到微调什么时候才值得动模型本身6.1 RAG解决了80%的问题为什么要先走这条路对大模型来说知识有两个来源一个存在模型参数里一个存在外部知识库里。RAG就是后者。它相当于给模型配了一个“可随时翻阅的资料室”资料更新只需替换文档模型权重完全不用动。这对于规程频繁升版的电厂来说价值极大。今天是第5版规程明天更新第6版只需要把新版文档传进知识库模型立刻就能引用新内容不用重新训练。所以我的建议是前半年甚至一年不要碰微调先把RAG用透。只有当遇到“模型输出的格式必须固定”或“术语必须按本厂习惯简写”这类问题时才说明外部知识已经无法约束模型的行文方式那时才考虑微调。6.2 当固定输出格式成为刚需时再考虑LoRA微调微调也不是从零训练而是用LoRA这类参数高效微调技术在已有模型基础上“补课”。比如希望缺陷描述输出固定为“现象、原因、措施、建议”四段式并且使用本厂缩写就可以整理几千条历史缺陷案例作为训练集用LoRA训练几小时然后在Ollama中加载新模型。数据准备很关键质量比数量重要。一般准备三千条左右的高质量指令样本就够了。每条数据格式可以采用{ instruction: 请把以下缺陷描述按“现象-原因-措施-建议”格式整理, input: 2号机凝汽器端差偏高巡检发现循环水入口温度异常上升……, output: 现象……原因……措施……建议…… }训练时用4张及以上NVIDIA显卡效果更好没有条件的也可以用云服务训练但注意只把脱敏后的文本传出去。如果担心数据安全那就本地方案买一台双卡服务器用DeepSpeed或peft库跑LoRA也完全可行。微调后的模型记得在验证集上反复测试防止“学会了新格式但忘记了旧常识”。7. 一点真实体会先让班组用起来比什么都重要最后说点实操感受。我给几家电厂做过本地大模型的技术验证项目成败从来不取决于大模型本身多强而取决于有没有一个痛得足够具体的场景。与其一口气建一个“智能电厂大脑”不如找运行值长聊半小时把第一个问题定为“查规程”。每天倒班的人真的会因为少翻两页手册而喜欢上这个工具的时候它才算落地了。还有一个容易被忽视的点让一线人员参与测试。他们提出的问题往往比技术团队自己想的刁钻得多会直接暴露知识库切分不合理、检索不准、回答不专业等一堆问题。模型答错不要紧关键是建立反馈渠道把答错的案例定期回填到知识库和提示词里正确率会螺旋上升。本地部署真正的门槛不是显卡也不是代码而是打破“AI一定得花大钱由大厂来搞”的心理惯性。现在一个熟悉Linux的工程师加上一台有显卡的服务器一周就能做出能用的原型。先跑起来比等什么标准都实在。