这几年工业软件的圈子变化比我预想的快，CAD、CAE、CAM这些老牌工具，如今都在往界面里塞AI助手。但我跟不少做产线、做设计的工程师朋友聊下来，发现真正能落地、能通过企业IT合规审的方案，几乎都绕开了云端大模型，走的反而是"本地小模型"这条路。原因倒也简单：产线机房不能断网，图纸数据不能上传，交互延迟不能动辄三五秒。

这篇内容就围绕"工业软件 + 小模型 + 端侧智能"这个组合展开，把我自己跑通的流程、踩过的坑、以及硬件选购心得一次性讲清楚。不管你是做CAD二次开发的老工程师，还是正在筹备企业AI知识库的IT负责人，只要能接受"花几千块买台二手笔记本，把模型放在内网跑"，这篇文章都值得你读完。

1. 端侧智能为什么突然成了工业软件的"必答题"

1.1 云端大模型的三个"劝退点"

很多企业不是没用过大模型，而是用了一轮之后就撤了。我自己也经历过这种流程：把产品文档、售后记录、历史方案一股脑推给云API，看着演示效果很惊艳，但一上生产就卡壳。

第一个劝退点是延迟。工业操作员的耐心比办公场景更差，因为很多操作是连续动作，比如在CAM软件里调整切削参数、在CAD里查询标准件，如果点完按钮要等三秒才出结果，操作流就断了。云端API的正常响应时间在1到3秒，遇上高峰期或者跨地域调度，5秒以上是常事。而本地小模型在端侧跑，通常300到800毫秒就能开始吐字，体感完全不同。

第二个劝退点是数据安全。工业图纸、配方、工艺参数、质检记录，这些是企业最核心的资产。图纸上的尺寸公差、材料牌号，单独看似乎无关紧要，但批量上传到第三方接口，等于把工厂的工艺路线和设计意图打包送出去。很多企业有保密协议、出口管制、内部审计的多重限制，这一关在技术选型时就会被直接毙掉。

第三个劝退点是成本。按Token计费看起来便宜，但产线场景是高频调用，一天几千次请求，一个月账单比工程师工资还高。私有化部署一个大模型，动辄需要多卡GPU服务器，软件授权、运维、机房机位，加起来是一笔让人肉疼的开销。相比之下，本地小模型的硬件成本几乎可以忽略不计，一台二手笔记本加一块老GPU就能跑起来。

1.2 工业软件现场的真实约束条件

聊完大模型的劝退点，再说说工业软件场景本身的特殊性。工业现场的IT环境，跟互联网公司的开发环境完全是两回事。

很多工厂的办公网和产线网是物理隔离的，或者只有单向文件摆渡通道。云端API在这种网络里根本走不通，连试用都成问题。但反过来看，这种"网络隔离"反而促成了端侧智能的刚需：模型必须放在本地，数据不能出内网，这是一个硬约束。

从算力分布看，工业现场其实不缺CPU。工控机、设计工作站、老旧的服务器，随便翻一翻就是一堆。缺的是大显存GPU，因为很多企业觉得花几万块买一张显卡只为了跑人工智能，短期内看不到回报。所以适合端侧模型的路线一定是"CPU友好、显存可选"，能在纯CPU环境跑起来，再考虑加GPU加速。

还有一个容易被忽略的约束是软件的形态。工业软件大多是Windows桌面端的重型客户端，SolidWorks、NX、CATIA、AutoCAD、中望CAD这些，界面恨不得占满整个屏幕。用户的操作习惯是鼠标点选、右键菜单、拖拽，而不是在浏览器里开个对话框。所以端侧智能要真正融入工业软件，形式必须轻——悬浮在鼠标旁边的助手、右键菜单里的一个选项、命令行里的一个指令，而不是另开一个网页窗口，让用户来回切。

我特别理解"鼠标运用什么工业软件"这个搜索热度背后的需求。工程师希望的是"少动键盘、多点鼠标就能调出智能能力"，模型内置到软件面板和右键菜单里，用起来才自然。

2. 小模型技术选型与硬件门槛：32GB内存到底能跑什么

2.1 什么样的模型才算"小"

在端侧智能这个语境里，"小模型"没有一个绝对的定义，但可以从几个维度来框定。参数规模上，一般指1B到14B的量级；30B以上的模型虽然也有人在笔记本上跑，但通常要考虑量化后的体积、内存带宽和生成速度，已经不太适合作为"随手可用"的端侧方案。

量化是让小模型真正落地的关键。现在主流的GGUF格式配合Q4_K_M量化，能把一个14B模型压缩到9GB左右，一个7B模型压缩到4.7GB左右。模型体积缩小了，推理速度也更快，代价是精度略有损失。我做过的测试中，Q4_K_M精度在实际工业问答中几乎无感，比完整精度只差不到一个百分点，但速度和内存占用舒服得多。

推理引擎方面，目前最值得关注的是llama.cpp和Ollama。llama.cpp是底层C++推理库，CPU优化做得极好，还支持GPU offload；Ollama本质上是封装了llama.cpp的上层工具，安装简单、命令友好，适合快速上手。两者我都用过，如果只是做技术验证，Ollama就够了；如果要定制推理参数或者做并发优化，建议直接用llama.cpp的server模式。

2.2 32GB内存跑小模型的实操体验

"二手笔记本电脑32G内存能跑小模型的推荐"这个搜索词，最近热度很高。我直接用实际测试数据来说话：一台搭载i7-10750H、32GB双通道DDR4内存的老笔记本，跑Qwen2.5-7B-Instruct的Q4_K_M版本，纯CPU推理，生成速度大概在每秒8到12个token。这个速度用于工业知识问答完全没问题，因为答案一般不会超过几百个token。

如果换成Qwen2.5-14B-Instruct，同样的机器，生成速度会掉到每秒4到6个token，体感明显变慢，但还在能接受的边缘。所以如果你对效果要求很高，14B是可行的；如果你更看重流畅度，7B是更稳的选择。实际操作时，内存占用远比想象中低：7B模型权重约4.7GB，14B约9GB，加上操作系统、开发环境和其他软件，32GB总占用也就12到15GB，剩余空间依然充裕。

如果笔记本上有独立显卡，还可以进一步加速。8GB显存的RTX 4060/4070系列，用llama.cpp的GPU offload机制，把一部分模型层放到GPU上跑，7B模型的生成速度可以跑到每秒25到40个token，14B也能到每秒15到20个token，体验接近云端。

这里要特别提醒一点：同一台笔记本，插电和用电池的性能差距巨大。电池模式下CPU会降频，推理速度可能直接腰斩。所以把笔记本当端侧推理服务器用，一定要长期插电，并且在BIOS里把性能模式调到"最佳性能"。

2.3 主流小模型选型对照

不同模型适合的工业场景不同，我做了一个简单的对照表供参考。

我的偏好很明确：中文工业场景，无脑选Qwen2.5系列。这个系列在中文理解、专业术语、指令遵循上的表现，明显比同量级的Llama和Phi要强。14B在质量和稳定性上比7B高一个档次，如果硬件允许，优先上14B。至于英文环境，Llama-3.1-8B和Gemma-2-9B可以作为备选。

3. 从零搭建端侧智能工作流：部署、知识库与软件集成

3.1 本地推理服务的搭建全过程

我采用的技术方案是Ollama提供模型推理服务，工业软件通过HTTP接口调用。整个部署流程非常简单，新手半小时内就能完成。

先在目标机器上安装Ollama，然后拉取模型并启动服务：

# Windows / Linux 安装 Ollama 后执行 ollama pull qwen2.5:7b ollama serve

ollama serve启动后，默认监听127.0.0.1:11434，提供一个兼容OpenAI格式的HTTP接口。可以通过curl验证服务是否正常：

curl http://localhost:11434/v1/models

如果返回模型列表，说明服务已经就绪。接下来在Python代码里调用，只需要设置base_url和api_key，api_key随意填写"ollama"即可。

我自己更倾向直接使用llama.cpp的server模式，因为可以对参数做更细的调整，比如限制最大上下文长度、固定GPU offload层数、调整线程数。llama.cpp的server同样提供OpenAI兼容接口，启动命令大致如下：

./llama-server -m ./qwen2.5-7b-q4_k_m.gguf -c 4096 -ngl 20 --port 8080

参数里的-c是上下文长度，工业问答场景4096足够；-ngl是GPU offload层数，如果显卡显存不够，可以填0表示纯CPU推理。这里有个心得：上下文长度不是越长越好，长度越长，预填充阶段耗时越高，生成速度也会变慢。我见过有人把上下文设到32k，结果响应慢得没法用，其实完全没必要。

3.2 从grep到语义搜索：本地知识库的搭建思路

"grep在本地小模型"这个说法很形象。在传统工作流里，工程师查阅设备手册，靠的是grep关键词：手册里出现"扭矩"两个字，就把整段内容拖出来。这种机械匹配的缺陷很明显，换个说法就搜不到，比如搜"拧紧力度"，搜不到"扭矩"相关的段落。

用本地小模型搭知识库，本质上是把grep从关键词匹配升级为语义匹配。整个流程分四步：文档切分、向量化、检索召回、合成回答。

文档切分是第一道关键工序。工业手册的PDF往往有大量表格和章节层级，如果直接按固定字符数硬切，很容易把一张完整的参数表劈成两半。我的做法是先用PDF解析工具提取目录结构和段落边界，再按章节切分，每个切片的长度控制在500到1000字左右。如果一块内容是一个完整的表格，就整体保留，不强行拆散。

向量化这一步，我推荐使用国产的bge-small-zh-v1.5作为嵌入模型，体积小、中文效果好，在CPU上也能跑。把所有文档切片向量化后，存入SQLite数据库的向量表里就够用了，几十万条向量以内完全没必要上Milvus或Elasticsearch。检索时，计算用户问题的向量和所有文档切片的余弦相似度，取top-k个片段（通常取5到10个），合并成一个上下文块。

最后一步是合成回答。把检索到的上下文块拼进Prompt，让模型"根据资料回答，资料里没有就直言不知道"。这段逻辑很关键，能显著减少幻觉。卡帕西的知识库能不能用小模型做？完全可以。知识库的核心是检索，不是模型背参数，本地7B模型配合正确的检索链路，回答准确率能做到九成左右。

Python侧的代码非常简洁，我用的是OpenAI兼容客户端：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") def ask_with_context(question, context): prompt = f"""你是一名设备运维专家。请严格根据以下资料回答问题。若资料中没有相关信息，直接说明"资料未提及"。 资料：{context} 问题：{question} 回答：""" resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}], max_tokens=500, temperature=0.2 ) return resp.choices[0].message.content

temperature必须调低，工业问答要的是准确，不是创造力，建议固定在0.1到0.3之间。

3.3 让工业软件"听懂鼠标"：集成方案设计

知识库和模型服务就绪后，最后一步是把它嵌进工业软件里。我遇到过不少团队卡在这一步，其实没有想象中复杂。

主流的CAD/CAM软件几乎都提供二次开发接口。AutoCAD支持AutoLISP和.NET，SolidWorks有官方API，中望CAD有ZRX和LISP兼容层。所有这些接口都能发起HTTP请求，所以技术路线是统一的：在插件里调用本地小模型的HTTP接口，把返回结果显示在对话框或命令面板中。

我举个实际做过的例子。在CAD中选中一个零件视图，右键点击"AI分析零件"，插件会把当前视图的文本描述（比如零件名称、材料属性、尺寸标注）发送给本地模型，同时从知识库召回相关工艺资料，模型输出一份简要的分析建议。整个过程不需要切换窗口，工程师的鼠标操作流完全不会被打断。

更实用的场景是标准件查询。我在CAM软件里做一个对话框，工程师输入"M8内六角螺栓，SUS304，拧紧扭矩参考"，模型结合标准件知识库，直接返回标准件号、扭矩范围、供应商信息和安装注意事项。这套东西跑起来之后，工程师说再也不用在几十本PDF手册里翻来翻去了。

架构上非常简单：桌面客户端（工业软件）通过HTTP请求访问本地小模型服务，小模型服务再访问本地知识库。全程不出内网，所有数据都在企业自己的机器上，合规和审计都容易通过。

4. 常见问题与排查技巧实录

4.1 推理慢到没法用怎么办

这是被问得最多的问题。一个7B模型在老旧CPU上跑得慢得出奇，需要先搞清楚瓶颈在哪。

小模型CPU推理的速度瓶颈不是CPU核心数，而是内存带宽。模型的每一层都要把权重从内存搬到寄存器，内存带宽决定了数据搬运速度。所以说到底，双通道DDR5比单通道DDR4快一大截，高频内存条对推理速度的提升比升级CPU还明显。

具体排查顺序是：先看是不是没有开启GPU offload。如果有独立显卡，尽量把层数多offload到GPU。再看上下文长度，如果设置过高，哪怕只是多出几千个token，预填充阶段的耗时也会成倍增加。

另一个很常见的问题是主板BIOS把CPU锁在了节能模式，或者笔记本电池模式下CPU降频。我在老旧工作站上遇到过很多次，插电后性能提升超过50%。

4.2 回答质量差、幻觉多怎么解决

如果模型回答得不对，先别急着换大模型，按顺序排查原因。

第一步检查知识库召回，把检索到的上下文片段打印出来看看，是不是"该召回的内容根本没召回"。最常见的原因是文档切分太粗或太细，导致语义被割裂。第二步检查Prompt，必须明确要求"资料中没有就直接说没有"，否则模型会一本正经地编造。第三步才是考虑换模型，如果7B确实达不到要求，升级到14B效果会有明显提升。

还有一个我比较推荐的技巧：让模型在回答中引用来源编号，比如"根据资料[3]第2段"，工程师可以在软件里点击编号核对原文。这样既方便验证正确性，也能反向帮助标注出知识库里的坏数据。

4.3 老硬件集成中的几个坑

二手笔记本跑小模型的坑，我几乎都踩过一遍。第一个坑是内存条可能没插成双通道。很多二手笔记本出厂时只有一根内存，加装时没有配对，导致内存带宽只有理论值的一半。用CPU-Z这类工具确认一下，如果显示Single Channel，赶紧去加一条组双通道。

第二个坑是WSL2的坑。很多人习惯在Windows上装WSL2跑Ollama，结果发现文件系统读写性能差、网络代理配置麻烦，推理速度也大受影响。我的建议是放弃WSL2，直接在Windows原生环境跑Ollama或llama.cpp，省心得多。

第三个坑是散热。笔记本长时间满载推理，温度一高就开始降频。我把笔记本架高、外接散热底座，并在BIOS中把功耗限制在45W左右，结果速度几乎没掉，温度却降了十几度。

第四个坑更隐蔽：如果你打算用笔记本长期当服务用，一定要禁用Windows的自动更新重启。设置里改一下"活动时间"，再把电源选项改成"睡眠从不"。不然半夜自动更新重启，第二天产线上的AI助手就失联了。

5. 后续拓展：从问答助手到工业智能体

5.1 让本地模型学会调用工具

问答只是端侧智能的起点。下一步是让本地模型具备工具调用能力，也就是Agent化。现在Qwen2.5和Llama系列都支持原生的function calling，模型可以根据用户指令生成结构化的工具调用参数。

举个具体的场景：工程师对模型说"帮我把这个零件的重量算一下"，模型调用CAD API读取密度和体积，返回计算结果。或者模型根据对话内容生成一个BOM表草稿，调用Excel库导出CSV文件。整个过程不需要工程师动键盘去查手册，鼠标点几下就能完成。

工具调用的部署并不复杂，本质上就是在本地小模型的HTTP接口上，增加一份工具函数定义（JSON Schema）。模型会在回复里输出"该调用哪个工具、参数是什么"，应用层再去执行对应的本地脚本。

5.2 多模态小模型的工业潜力

工业场景里文本只是信息的一半，设备照片、零件图、屏幕截图都是不可或缺的信息。当前已经有一批轻量多模态模型可以本地跑，比如Qwen2-VL系列和MiniCPM-V。这类模型的意义在于：工程师拿着手机拍一张铭牌照片，直接问"这个电机是什么型号、保养周期是多少"，模型结合光学字符识别和知识库，一次给出完整答案。

虽然实现上比纯文本模型复杂一些，但路径是通的。而且端侧多模态模型的资源占用没有想象中夸张，我实测过7B级别的VL模型，在32GB内存的笔记本上也能跑，只是生成速度比纯文本模型慢一些。

5.3 用旧设备建企业"小模型私有云"

很多人不知道的是，一台32GB内存的二手笔记本就能支撑二三十人的团队使用，前提是合理控制并发。以小模型4到6秒生成一个完整回答来算，一台机器同时处理三四个请求是完全不卡的。

如果企业规模再大一些，可以把手头的旧笔记本、旧工作站集中起来，挂一个负载均衡，组成一套"小模型私有云"。这套方案的成本可能只有一台GPU服务器的十分之一，数据全部留在内网，模型可以按业务线分别部署。我在一个朋友的公司见过类似部署，五台旧机器轮询跑同一个14B模型，高峰期同时服务二十多人完全没问题。

最后再分享一点实在的经验

我在这个项目里最大的体会是：别急着追逐最新的模型参数，先把"数据不出内网"这个底线守住，再谈智能化。很多项目死在云端API的演示阶段，是因为技术负责人根本没把数据合规当回事。而当你转回本地小模型这条路线，会发现落地的顺畅程度超乎想象——成本可控、网络隔离、操作流程不断层，这恰恰是工业场景最需要的。

最后一个建议是：从一台二手笔记本开始。花两三千块钱，配好双通道32G内存，拉一个Qwen2.5-7B，把某个产品的故障知识库跑通，让一个班组先试用。等效果被认可了，再决定要不要上更大的模型、要不要做多模态、要不要搭私有云。这个路径，我走过，很稳。