去年下半年开始我陆续走访了几家大型钢铁企业的信息部门几乎每家都在讨论同一个话题大语言模型到底该怎么部署。有的企业直接买了云端API额度用了一两个月发现心里不踏实——数据出了厂安全边界就说不清了有的企业想一步到位私有化部署70B开源模型一打听GPU采购预算就打了退堂鼓还有的在两种方案之间来回摇摆方案改了三四版还没定下来。作为长期跟踪钢铁行业数字化转型的研究人员我觉得有必要把LLM在钢铁企业里的部署路径系统梳理一遍特别是针对冶金行业特有的工况环境、网络隔离要求和数据敏感性给出可落地的技术方案参考。这篇文章不会泛泛地讲大模型有多好而是聚焦在怎么落地这件事上。我会从部署架构、模型选型、推理服务化、知识注入、场景实施五个层面展开结合钢铁企业的实际情况把该避的坑提前标出来。1. 钢铁企业为什么要自建LLM三个躲不开的现实问题1.1 数据不出厂合规与商业机密的底线钢铁企业的数据资产其实比很多人想象的值钱得多。工艺参数、合金配方、炉温曲线、轧制力设定值、客户订单结构、成本核算明细这些数据每一类都直接关系到企业的市场竞争力。如果使用公有云大模型API员工把一段包含工艺参数的生产日志粘贴进去做问答这个数据在传输过程中、在第三方服务器上留下的痕迹都是企业无法控制的。行业内对数据安全的审计要求也越来越严格。等保测评、集团内部安全审计、客户供应链审查都会问到敏感数据流向哪里这个问题。公有云API模式下你很难拿出一份完整的数据流向图。而私有化部署的LLM平台模型权重、推理数据、知识库全部运行在企业自己的服务器上数据生命周期完全可控。这不仅仅是技术选型问题更是合规底线问题。1.2 通用模型解决不了钢铁的方言问题钢铁行业的术语密度极高而且很多是跨学科、跨工序的专业词汇——铸坯中心偏析转炉终点碳热轧卷取温度夹杂物评级RH真空脱气通用大模型在日常语料里见过这些词的频率太低理解经常出现偏差。我实测过一个通用模型让它解释LF精炼工序中白渣操作的目的回答是为了减少炉渣对钢水的污染提高钢水纯净度——这话不算错但完全没有讲到造渣-脱氧-脱硫的工艺逻辑链一线工程师看了只会摇头。更麻烦的是钢厂的规程文件、事故报告、设备说明书里大量内容是半结构化甚至口语化的。放下线代表的可能是产线停机跑钢指的是浇铸事故烂钢是废品的一种。这些只有企业内部文档和老师傅经验里才有的表达方式通用模型根本没机会学到。要让LLM真正在钢铁场景里有生产力必须把企业自身的知识资产注入进去这一点后面第五章展开讲。1.3 从单点工具到系统能力的路径依赖还有一个容易被忽视的问题很多钢企的员工已经在用公共AI工具写材料、做周报这属于野路子应用。好处是让大家快速体验了大模型的能力坏处是这些应用是零散的、不可控的——员工把工艺文件贴进去提问答案被直接复制进工作材料里没有人校验没有留痕出了错也追不到源头。企业级LLM部署的核心价值是把模型从员工的私人工具升级为组织统一的能力底座。这个底座接上企业自己的知识库、数据库、业务系统所有问答可以留痕、可审计、可更新模型输出有权限控制。这一步不做AI在钢铁企业里永远只是玩具。2. 部署架构与算力规划私有化不是唯一答案但是主航道2.1 三种部署形态的对比与适用边界我见过太多企业一上来就问部署要花多少钱其实部署形态决定投入量级先把这个想清楚钱的事自然就有数了。部署形态数据安全初期投入灵活性适合场景公有云API低数据出域低按量付费高模型选择多非敏感场景的先行验证混合部署中核心数据本地中中敏感数据本地通用功能走云私有化部署高全生命周期可控高需采购GPU中受硬件约束数据敏感型制造企业的主航道从我的调研来看钢铁行业头部企业最终都会走向私有化部署但过程往往是公有云API做PoC验证 → 混合部署跑试点 → 私有化全覆盖三步走。拦在企业面前的主要是GPU算力采购周期和运维能力缺口。有一点我建议企业特别关注即便最终目标是私有化也不妨碍前期用API快速验证业务场景价值。场景没验证清楚就砸下几百万买GPU风险极大。2.2 厂级LLM平台的网络拓扑与系统对接钢铁企业的网络环境比一般的政企单位更复杂。典型的大型钢企至少有三套网络办公管理网、生产执行网MES/L2/L3级、基础自动化网PLC/DCS通常在OT域。OT网络与IT网络之间有严格的隔离要求甚至存在物理隔离或工业防火墙管控。这种环境对LLM部署的影响很大——LLM平台不能想放哪就放哪。我的建议是把LLM平台放在管理网的核心区域通过API网关对外提供服务。网关做四件事身份认证对接企业统一身份源比如LDAP/AD、权限控制不同角色能访问不同的知识域、审计日志所有问答记录留痕、限流降级防止并发尖峰打爆推理服务。LLM平台通过网关与MES、ERP、设备管理系统对接时走标准REST API或消息队列避免直接穿透到生产控制网。有一点要提醒LLM平台不应该、也不能直接连接PLC或DCS系统。它输出的建议必须经过人工确认才能进入执行环节。推理系统一旦直接接入控制回路安全等级的要求就完全不同了那已经不是技术问题而是合规红线问题。钢铁企业部署LLM的第一个纪律就是AI可以提建议但最终指令必须由人来下。2.3 算力层GPU服务器在钢铁厂房的特殊要求钢铁厂的机柜环境概不理想。产线附近高粉尘、强震动、环境温度波动大GPU服务器功耗高、散热需求大放在产线旁边大概率会因为积灰导致散热失效。我见过一家企业的边缘AI服务器放在轧线电气室里三个月后GPU温度普遍比安装时高了12度。这不是设备质量问题是工况没考虑到位。最佳做法GPU服务器统一部署在厂区中心机房具备精密空调、UPS、除尘设施通过网络与产线侧的数据采集系统交互。如果产线边缘确有实时推理需求比如视觉质检模型的推理单独部署边缘AI盒子与LLM平台解耦。LLM不是实时控制类负载它需要的是稳定的算力环境而不是靠近数据源的地理位置。电力规划也要提前算。一台配置8张H系列GPU的服务器满负荷功耗能达到5-6kW一个机柜如果放两台这种设备加上空调制冷单柜功耗直奔15kW。很多钢企的旧机房是按3-5kW/柜设计的不加改造直接上GPU供电和散热必然出问题。改造之前先把机柜功耗预算做出来否则设备到了现场拉不起电项目直接停摆。3. 模型选型参数规模、开源路线与行业适配3.1 按场景倒推参数规模别盲目追大很多企业领导只看参数70B比14B大那就用70B。这是典型的选型误区。模型参数的背后是硬件的真金白银70B模型用FP16加载光权重就占140GB显存至少需要2张H系列80GB显卡才能放得下加上KV Cache和推理开销4张卡起步是保守的。而14B模型FP16权重约28GB一张48GB或80GB的卡就能转起来硬件投入差一个数量级。我的选型逻辑是场景倒推法应用场景建议参数规模说明知识库问答基于RAG7B-14B答案主要由检索内容决定模型本身不需要背太多知识会议纪要、公文草拟14B-32B需要较强的语言组织和指令理解能力复杂文档分析设备手册、合同32B-70B长上下文、跨章节信息关联小模型容易丢细节代码生成报表脚本、数据查询14B-32B依赖模型编码能力太小模型容易出错如果企业首次部署我建议从14B级别开始试水。这个量级用消费级或入门级专业卡就能跑成本可控场景验证完再升规模。一次直接上70B的企业多半会死在运维复杂度上。3.2 开源模型家族怎么选Qwen、DeepSeek与Llama的取舍当前主流的开源模型里面向中文场景我会优先考虑阿里Qwen系列和DeepSeek系列。Qwen的指令遵循能力在中文本地化场景一直很稳而且对中文行业术语的理解明显好过以英文为主的模型。DeepSeek在推理链上做得比较扎实代码生成和数理逻辑更强适合需要深度推理的场景。Llama系虽然生态完善、社区资料多但中文能力普遍需要额外的中文语料微调否则在钢铁这种专业中文场景下表现会打折扣。这里要给个实操建议不要凭跑分选模型。Open LLM Leaderboard上的跑分用的是通用英文数据集和钢铁场景相差十万八千里。选模型的正确姿势是建一套自己的评测题库用企业真实的问答对脱敏后来测。具体做法后面5.4节里讲。3.3 量化部署用精度换规模但不能盲目Q4显存不够的时候量化是有效的缓解手段。INT8量化对模型能力的损失通常可以忽略Q44bit量化则要看模型架构和任务类型。对于以知识库问答为主要场景的企业Q4量化后的7B模型放在消费级显卡上完全可用但如果要做长文档复杂推理Q4量化带来的精度损失有时会让模型漏掉关键细节。我的经验首次部署选BF16/FP16作为基准显存不够再考虑AWQ或GPTQ的INT8量化Q4作为备用选项只在硬件边界极限时使用。量化之后务必在评测集上重测一遍不能量完就直接上线。4. 推理服务化从模型文件到可用系统的最后一公里4.1 推理框架选型vLLM、Ollama与TGI怎么选模型文件下载下来只是一个开始真正让模型变成系统的是推理服务。三个主流框架我都有过生产环境的实测vLLM是目前生产环境的首选。它的PagedAttention技术把KV Cache做了分页管理显存利用率明显提升吞吐量在批处理场景下比其他框架高一截。服务化接口直接兼容OpenAI风格API企业现有代码接入成本低。但它对部署环境有一定要求需要Linux服务器和较新的CUDA版本初期配置调试要花些时间。Ollama胜在简单。一条命令就能把模型跑起来适合做PoC验证和科室级小范围试用。但它的并发处理能力和细粒度控制不如vLLM当企业级并发上来之后容易成为瓶颈。我的建议是Ollama用于原型阶段正式投产还是迁到vLLM上。Hugging Face TGI也是个稳妥选项跟Hugging Face生态衔接好部署配置也不复杂适合团队已经熟悉HF工具链的场景。如果企业的技术团队底子比较薄我推荐一条稳妥路径先用Ollama做快速验证业务跑通后由有经验的人或外部服务商迁到vLLM整体风险可控。4.2 并发、延迟与吞吐算一笔实际账很多企业把模型跑起来了但一问能支撑多少并发就懵了。这里有个简单估算方法先看显存。以14B模型FP16权重约28GB加KV Cache为例跑在80GB显存的卡上扣掉权重还剩约50GB给KV Cache。每路会话的KV Cache占用取决于上下文长度4K上下文的场景下一路约占0.5-1GB显存视模型层数而定粗算单卡可以支撑30-50路并发。如果用vLLM的continuous batching实际吞吐还能再优化。延迟方面要分清两个指标首Token延迟和整体生成速度。知识库问答场景下参考文献检索花2-3秒属正常但首Token出来后生成速度一般能达到每秒20-40个Token。如果用户反馈转圈很久才蹦出一个字大概率不是模型慢是检索链路出问题或并发打满导致排队。投产前要做一次简单的压测用脚本模拟并发请求逐级加大到目标并发的1.5倍观察延迟曲线有没有断崖。如果并发到某个临界点延迟从2秒跳到15秒说明资源触顶需要扩容或限流。这一步不做上线当天就可能被用户骂崩溃。4.3 一套贴近钢铁IT习惯的服务封装方案钢铁企业的IT团队普遍熟悉VMware虚拟化、Docker容器和传统的systemd运维方式对Kubernetes的掌握程度参差不齐。LLM推理服务的封装我建议遵循能简单就不复杂的原则GPU服务器装好驱动和容器运行时后用Docker Compose编排推理服务和API网关进程由systemd托管日志输出到统一采集目录告警接入企业已有的监控体系比如Zabbix或Prometheus。如果企业有K8s平台且团队能维护也可以用K8s做资源调度但我不建议为了LLM专门搭一套K8s——推理服务的无状态性决定了它不需要K8s那一套复杂编排Docker Compose加systemd足够稳定。镜像管理也要提前规划。钢铁企业内部网络通常与外网隔离需要搭建内网镜像仓库把推理框架镜像和模型权重提前拉取到内网离线加载。我之前碰到一个项目外部服务商把所有镜像都放在公网仓库到现场才发现内网拉不了白白耽误了一周。5. 知识注入与微调让模型真正懂钢铁5.1 RAG是首选把企业知识库变成模型的外挂大脑对钢铁企业来说RAG检索增强生成是部署LLM最高性价比的方案。它能解决模型没有企业知识这一核心问题而且不需要训练算力。RAG的流程是把企业文档设备手册、工艺规程、事故报告、操作规程切分为片段通过Embedding模型转成向量存入向量数据库。用户提问时系统先把问题转成向量在库里检索最相关的片段把这些片段和问题拼接成Prompt交给LLM生成答案。我的建议是混合检索关键词检索BM25与向量检索并行再把两者结果融合排序。钢铁行业有很多专有名词如精炼连铸退火向量检索经常在这些词上语义漂移而关键词检索可以精准地命中术语所在片段。混合检索在实测中比纯向量检索的准确率高不少这个提升不用改模型就能拿到属于最高性价比的优化。5.2 什么时候才需要微调三种典型情况RAG不是万能的。以下三种情况RAG解决不了得动模型权重第一种需要强指令遵循的特殊格式输出。比如要求模型每次输出的设备点检报告严格按现象描述-原因分析-处理建议-风险等级四段式生成调整Prompt可以达到80%的效果但剩下的20%不稳定。微调之后格式稳定性可以到95%以上。第二种企业专有术语和表达习惯。模型始终把跑钢理解为生产节奏过快而不是浇钢事故的时候说明通用语料里的语义权重太强了需要微调来纠正。第三种需要模型记住固定知识且不能出错的内容。比如企业内部的组织架构、安全生产红线条款。这些内容不该依赖模型记忆记忆是不可靠的但在某些场景下微调可以减少对RAG的依赖提高响应速度。微调的成本不可忽视一次LoRA微调需要2-8张GPU跑几小时到一天数据准备和数据清洗的工作量比训练本身大得多。所以我的原则是能用RAG解决的先用RAG微调是RAG达到天花板之后的补充手段。5.3 钢铁知识库建设的三个难点与对策知识库建设是RAG项目里最耗时、最决定成败的环节三个难点几乎是每家企业都会遇到的难点一私有格式文档。钢铁企业的很多老资料是WPS格式、PDF扫描件甚至还有加密的图纸文件。对策PDF扫描件要先用OCR识别识别准确率直接影响检索效果老图纸这类非文本内容目前的RAG还处理不好建议先排除在知识库之外不要强行加入。难点二表格内容。工艺参数表、成分控制表在切分后容易被截断。对策切分时优先按标题-表格-说明文字的结构进行版面分析把表格作为独立单元存储检索时能整体召回而不是被拦腰截断。难点三知识更新。钢铁企业的规程版本更新频繁旧版本的错误答案如果还留在库里会出现新旧规程内容冲突的情况。对策知识库中每份文档必须有版本号、生效日期、责任部门三个元数据字段检索时按版本生效日期过滤同时每季度做一次知识库内容审计标记过期文档。6. 从试点到全厂90天跑通第一个LLM场景的实施路线6.1 第一个场景为什么推荐设备运维问答首次落地的场景选择很关键。我见过的失败案例普遍是第一个场景就选了大而全的企业知识助手结果知识库没建好模型回答质量差用户试了两周就弃用了。我推荐的第一个场景是设备运维问答——把设备点检标准、维护手册、常见故障案例、备件更换周期录入知识库让维修工和点检员用自然语言查询。选这个场景有三个理由第一知识边界清晰设备手册就那些不会无限膨胀第二答案可验证现场工程师一眼能看出回答对错第三价值可量化设备故障处理效率提升是可以算出来的。第一个场景的价值兑现了后续推广才有说服力。6.2 我建议的实施路线图按周拆解90天计划第1-2周完成需求聚焦和测评集构建。找设备部和信息部各出几个人列100道真实问题作为验收基准。第3-4周部署基础环境。采购或调配GPU服务器部署推理框架跑通一个基础模型的API。第5-8周知识库建设。完成设备手册的收集、清洗、切分、向量化形成第一版知识库。这期间同步做RAG链路的调优。第9-10周联调与内测。选一个维修班组做小范围试用收集反馈修正Prompt和检索参数。第11-12周优化迭代与上线准备。根据试用反馈做针对性优化配置监控告警对运维人员做使用培训。第13周正式上线并设立迭代计划。周计划要写进项目管理看板每周输出明确的交付物。这个节奏经历过多次验证是稳妥务实的节奏它不追求速度但每阶段的产出都是实打实的。6.3 投产之后的三个保障机制上线只是开始。我观察到LLM项目上线后三个月内最容易暴露三个问题一是模型幻觉仍然存在。对策是每个回答必须标注引用来源来源链接可点开核对。当用户能自己验证答案出处时对模型信任度会大幅提高。凡是回复无法附出来源的场景直接不予回答产品设计上要留这个口子。二是知识库老化。对策是把知识更新纳入常规运维流程设立知识库管理员角色每个业务部门指定一个人负责各自领域的文档更新。三是算力水位监测。GPU利用率、显存占用、请求延迟这三个指标必须上监控大屏。推理服务的最大风险不是模型不准而是资源耗尽导致全线不可用。从长期看钢铁企业的大模型部署绝不是一次性工程而是一个持续演进的能力平台。先在设备运维这个场景上跑通全流程积累知识库建设经验和运维体系经验再逐步扩展到工艺问答、安全培训、文档审查、智能报表等场景。基础设施是通用的知识库是逐场景积累的这个路径我验证过是走得通的。最后分享一个心得在钢铁企业推LLM最忌讳的是把它包装成AI项目——那样会被业务部门当成是IT部门自嗨。正确的做法是包装成设备管理效率提升项目或技术传承与知识管理项目让业务部门当主人IT当支撑。技术和业务的双轮驱动才是这艘船能驶向远方的关键。