电厂本地部署大模型实战：从硬件选型到知识库落地

大模型在电力行业的落地速度，比大多数人想象的要慢，也比一些人想象的要值得做。我过去一年深度参与了几个电厂侧的人工智能落地项目，从最初的可行性论证，到硬件选型、模型部署、知识库搭建、业务系统对接，整套流程都实际走了一遍。今天这篇内容，就把这段实操经历里最核心的判断和做法整理出来，重点回答一件事：为什么我建议电厂立即本地部署大模型，以及具体怎么落地。

1. 为什么这件事值得立刻做

1.1 电厂里真正需要大模型的几个地方

先说结论：电厂不是没有大模型的需求，而是需求被藏在了日常繁琐的工作里。我接触到的电厂场景中，有几个地方非常典型。

第一是规程与制度的检索。电厂运行规程、检修规程、安全操作规程加起来往往有几百份文档，动辄几千万字。新员工培训期长达半年一年，即使老师傅也需要翻很久才能找到某台设备的特定操作要求。传统的关键词检索对这种长文档、高相似度内容非常吃力，比如两条操作步骤只差一个词，关键词搜索就很难命中。而大模型结合向量检索，可以直接用自然语言提问，给出带出处引用的答复。

第二是检修记录和缺陷报告的辅助分析。电厂每年会产生大量检修记录、缺陷单、验收报告。这些文本形态不规范，有的写在表格里，有的在纸质扫描件里，很多关键信息是散落的。大模型可以对这些非结构化文本做结构化抽取，比如自动提取缺陷编号、设备名称、故障现象、处理措施、遗留问题。我见过一个项目，用提示词约束模型把过去三年的缺陷单整理成了标准化台账，效率比人工提升了一个量级。

第三是运行值班的问答辅助。值班员在操作时需要快速确认某个参数是否越限、某个报警对应的处置预案是什么。这类问题是固定的、重复的，非常适合做成本地知识库问答。

第四是培训与仿真。电厂对运行人员有严格的持证上岗要求，培训材料庞杂。基于本地大模型做一个内部答疑系统，让培训人员用对话方式学习，比翻手册效率高得多。

这些需求有一个共同点：它们都涉及电厂内部的敏感生产数据。规程文件、真实缺陷记录、设备台账，这些内容按规定不能随意出网。这就是本地部署从“可选”变成“必要”的根本原因。

1.2 云端API方案为什么被卡住

很多人第一反应是：直接用云端大模型API不就行了，为什么要费劲本地部署？我在项目里也评估过云端方案，但实际一测就发现几个绕不开的问题。

第一个是数据出口问题。把规程文档和缺陷台账的内容发送到第三方云端服务，在合规层面就是不清不楚的。哪怕只是用于推理不带训练，生产数据在外网过一遍，很多电厂的信息部门就不会同意。电力监控系统本身有安全分区的要求，生产控制大区与管理信息大区之间是隔离的，数据流向有严格限制。云端API方案在架构上就过不了第一关。

第二个是网络条件。不少电厂的控制系统所在网络是单机隔离或受限联网的，办公网络到外网也有严格的访问控制。云端API需要稳定的可用连接和较低的时延，这在很多厂区环境下并不具备。即使能通，断网断服的风险也让业务部门不敢把关键功能挂上去。

第三个是我个人很在意的点：依赖与可控性。云端模型的能力是黑盒，厂家升级了模型，你的应用可能突然变了行为。而电厂这种行业讲究稳定可靠，一个回答问题的方式前后不一致的系统，很难被现场人员接受。本地部署至少能锁定版本，行为可复测、可回归。

当然，本地部署有成本，有技术门槛。但把这几个约束摆在一起，你会发现本地部署不是“更优选择”，而是“唯一可行方案”。剩下的问题就是：怎么用合理的成本把它做起来。

2. 本地部署的硬件选型与算力规划

2.1 模型规模怎么定：7B、13B还是70B

模型规模的选择是第一关，选错了后期会很痛苦。我自己踩过一个坑，最初为了追求效果直接上了一套70B量级的多卡方案，结果因为现场供电和散热条件不足，机器频繁降频，最后被迫换回更小的模型重新适配。所以我的建议是：从实际业务出发倒推模型规模。

先把所需的输入长度、输出长度、知识库检索上下文量估算出来。一般来说，电厂的知识问答场景，输入加输出的上下文窗口在4K到8K token以内就够用。这个量级下，7B到13B参数的对话模型通过微调或配合检索增强，效果已经可以覆盖大部分任务。

我的经验是分三档来看。7B量级的模型，一张主流计算卡就能跑起来，适合简单的问答、文本改写、格式整理。13B到14B量级，两张卡或单张高性能卡加量化就能跑，效果明显上一个台阶，适合规程问答、缺陷抽取这类有一定理解深度的任务。如果要做多文档长文本分析、复杂推理，才需要考虑70B量级，这通常需要多卡并联，预算和运维复杂度都会显著上升。

给一个简单的显存估算方法：模型以FP16精度加载时，参数量乘以2就是需要的显存量。一个7B模型FP16大约需要14GB，13B大约需要26GB，70B大约需要140GB。再加上推理时的KV缓存和激活值，实际需求还要上浮20%到30%。所以选卡的时候，不能只看模型理论占用，要给足余量。

2.2 服务器配置的落地方案

根据我实际的部署经验，不同预算下有三套比较稳妥的配置搭配。

第一套是入门级：单张主流计算卡，搭配几十G内存做推理服务，适合7B量级模型，用于内部知识库问答试点。这套配置的整机成本对电厂来说完全不是负担，而且运维简单，一个信息专员就能管得过来。

第二套是标准级：两张中高端计算卡，可以跑13B到14B量化模型，同时支撑一个几十并发的内部服务。这套配置是我目前推荐的主流方案，基本能覆盖电厂90%的业务场景，也是性价比最均衡的一档。

第三套是增强级：四卡及以上的配置，服务70B量级模型，适合要长期做深入场景、有数字化预算的厂级单位。需要特别注意机柜空间、供电和散热，多卡服务器的功耗轻松上千瓦，必须提前评估机房条件。

选型时还要考虑国产化要求。现在很多机组的技改项目对硬件有自主可控要求，我建议提前确认采购目录里是否有对应的加速卡型号，避免方案定了再倒回去换。

2.3 量化是必选项，但不是万能药

显存不够怎么办？最常见的手段是量化。把模型权重从FP16压到INT8或INT4，显存需求大致能降一半甚至更多。7B模型INT4量化后不到5GB，普通的办公显卡都能带起来。

但量化的代价是效果损失，尤其是对复杂推理和长文本理解的影响比较明显。我的建议是：能不用量化就不用，必须用时优先选INT8，且要用业务测试集去对比量化前后的回答质量。不要只看一个指标，最好准备几十条真实业务问题，逐条对比答案的准确性和完整性。

我见过一个失败的案例：某团队为了把模型塞进小显存卡里，用了4比特量化，结果回答规程相关问题时频繁出现数据错误，最后只能加预算换硬件。这件事的教训是：量化省的是钱，花的是效果，这个交换要算清楚。

3. 从零搭建一套可落地的本地部署方案

3.1 基础环境与部署框架

先交代一下我推荐的技术栈：操作系统用主流的Linux发行版，部署工具用容器化方案，模型推理用开源的推理加速框架，知识库用向量数据库加嵌入模型，上层用统一的服务接口对外提供能力。

第一步是装驱动和基础环境。如果是带加速卡的服务器，先确认驱动版本与加速卡匹配，再安装对应的计算库。这个环节最容易出问题，驱动和计算库版本不匹配会导致设备不可用，浪费很多排查时间。

第二步是把推理加速框架跑起来。现在主流的开源推理框架对常见模型格式支持都很好，可以做到一行命令启动一个模型服务。启动后先用一个简单的健康检查接口验证服务是否正常，再逐步加并发压测。压测时重点看两个指标：首token延迟和生成吞吐。对电厂问答场景，首token延迟建议控制在2秒以内，用户体感才不会有明显等待。

第三步是封装统一服务接口。不要直接暴露推理框架的原生接口给业务系统，建议在它上面包一层，统一处理权限校验、知识库检索、提示词组装、敏感信息过滤这些通用逻辑。这样业务系统对接时只需要面对一个简单接口，后续模型升级替换也不会影响上层。

3.2 模型服务的高可用配置

模型服务不能裸奔。实际运行中我至少会做三件事。

第一，加载多个副本，避免单点故障。大规模并发或者长文本生成时，单实例很容易成为瓶颈。用负载均衡把请求分发到多个模型实例上，一个实例重启不影响整体服务。

第二，做限流和超时控制。电厂内部用户不多，但偶尔会有批量导入、集中测试的突发请求。不限制的话，模型服务很容易被大请求堵死，影响正常使用。

第三，日志和监控。记录每一次请求的输入输出、耗时、错误码，方便追溯。我在项目里就遇到过某个问题反复出现但原因不明的情况，最后是靠查询历史请求日志才发现是输入文本编码格式的问题。日志记录本身不产生业务价值，但它决定了系统出问题时你能多快定位。

3.3 知识库：把规程、台账、检修记录变成可检索资产

本地大模型的核心价值，一部分在模型本身的通用能力，更大一部分在知识库。直接裸用基座模型去回答电厂业务问题，准确率会比较尴尬。正确的做法是采用检索增强生成方式：先对查询做语义检索，把最相关的文档片段捞出来，再让模型基于这些片段组织回答。

知识库搭建的完整流程是：文档收集、解析、清洗、切分、向量化、存储。这六步每一步都有坑。

先说文档解析。电厂资料大量是扫描件和历史办公文档，质量参差不齐。扫描件需要先做OCR，这一步的准确率决定了后续所有环节的成败。文件名也经常是乱的，比如“新建文档.doc”这种，需要人工梳理命名规则。我建议先画一张资料清单表，明确每份资料的类型、适用范围、更新责任人，再逐份处理。

文档切分是另一个关键环节。切得太粗，检索时会把大量无关内容一块带进来，浪费上下文窗口也干扰模型判断；切得太细，语义完整性会被破坏，比如一条操作步骤被拦腰截断。我的经验是按章节结构切分，优先保留标题层级信息，每个片段控制在500到1000个字左右，并做小幅重叠，确保跨段落的语义不断裂。

向量化取决于嵌入模型的质量。不同嵌入模型对中文专业术语的理解差异非常大，选型时拿电厂自己的文档去测召回率，比看公开榜单更有参考价值。向量化之后的数据结构入库，用于检索；原始片段同步保存，用于生成时引用和溯源。

3.4 与现有业务系统的对接

模型部署好之后，真正产生价值的是和现有业务系统打通。电厂内部一般有生产管理系统、办公系统、培训系统等。我的建议是不要一开始就走深度集成，先用一个统一入口接进来，把能力暴露成接口，再逐步嵌入业务流。

这里要特别提醒权限设计。检索增强生成系统天然存在越权风险：如果知识库涵盖多个部门的数据，必须做文档级或知识块级的权限控制。用户在问某个敏感问题时，系统只能检索他有权访问的片段，否则一个知识库助手就成了信息泄漏通道。

我做过的一个项目中，把知识库按“公开规程”“部门资料”“班组私有记录”三个级别做了隔离，检索层先过权限过滤，再进模型生成。这个设计虽然增加了一点复杂度，但让信息部门松了一口气，也推动了项目能顺利上线。

4. 实测阶段踩过的坑与排查记录

4.1 高频问题排查速查表

我把实际运行中遇到最多的问题整理成一张速查表，方便大家对照排查。

这张表看着简单，但每一条我都实际碰到过。比如知识库检索不到内容这个事，我排查了两天，最后发现是一批扫描件在OCR时把“风机”识别成了“风*机”，空格导致分词的语义偏移。遇到类似问题，建议先从最原始环节逐段排除，不要一上来就怀疑模型。

4.2 三个容易被忽视的细节

第一个细节是并发压测。很多人部署完模型，单条测试没问题就宣布上线了。实际一到集中使用场景就暴露问题。我建议上线前至少用并发脚本模拟20个用户同时提问，观察延迟和服务稳定性。如果首token延迟从几百毫秒飙升到十几秒，说明并发能力不够，需要调整部署架构。

第二个细节是知识库更新要有发布流程。规程修订是常态，但知识库不能随便覆盖。旧版本在过渡期可能仍然需要被查到，盲目更新会导致答案混乱。我建议版本化管理，每次更新记录变更时间和内容，必要时提供“当前版本”和“历史版本”两套检索入口。

第三个细节是提示词也要做测试。很多人把注意力放在模型和知识库上，忽视了提示词对输出质量的决定性影响。同一个问题，提示词写法不同，回答质量差异巨大。我建议把提示词视为一个需要持续维护的组件，每次修改都要跑回归测试。

5. 部署完成之后怎么用起来

5.1 效果验证：先跑通三个典型场景

模型部署好、知识库建好，这只是开始。真正决定项目成败的，是能不能让一线人员真的用起来。我的经验是先跑通三个典型场景再谈扩展。

第一个场景是规程问答。选一个工段真实发生过的问题，让值班员用自然语言向系统提问，要求回答必须引用具体规程条目。这个场景最容易见效，也最容易获得用户认可。

第二个场景是缺陷单结构化抽取。拿近一年的缺陷记录做测试，让模型自动提取关键字段，人工抽查准确率。这个场景能直观展示大模型处理非结构化文本的能力，也是投入产出比最高的场景之一。

第三个场景是培训答疑。把新员工最常见的问题整理成测试集，验证系统的回答质量。这个场景做得好，培训部门会成为你这个项目的坚定支持者。

三个场景跑通后，你会获得三个东西：一套可复用的测试集、一个能反馈问题的用户群、一份能向上汇报的效果数据。

5.2 从对话助手走向业务流程嵌入

对话式问答只是大模型最浅层的应用形态。我建议在稳定运行一段时间后，思考如何把能力嵌入到业务流程里。

一个方向是把抽取能力嵌入到报表生成流程。比如每天自动汇聚各班组提交的异常信息，生成摘要报告，值班负责人只需要审核确认，而不是从头读一堆原始记录。

另一个方向是把问答能力嵌入到操作辅助系统。操作人员执行标准操作流程时，系统可以在关键步骤主动推送相关风险点和注意事项，这就是从“被动问答”走向“主动辅助”。

再一个方向是基于大模型的设备检修策略辅助分析。结合历史故障记录和设备状态数据，让模型给出初步的检修建议，再由专业工程师复核。这类场景价值高，但对数据质量和模型能力的要求也更高，建议在基础功能稳定后再逐步推进。

我在实际部署中最大的体会是：本地大模型项目能不能成，技术只占一半，另外一半是现场流程和人的配合。模型幻觉可以通过检索增强和测试集控制到可接受水平，但要让值班员信任一个系统、愿意每天用，需要的是持续迭代和坦诚沟通。如果让我给一个优先级排序，我的建议是：先小步快跑做问答场景，把数据治理和知识库管理的基本功练扎实，再往业务流程深处走。这个顺序反过来，大概率会赔钱又赔口碑。