一位工厂老兵的 AI 登山

曹冬冬在工厂里做了 15 年工业产品，并非算法工程师，也没有专业软件开发经历。他从零开始学习大模型、Python 和本地推理，开发出“Union·由你｜CNC 非标智造炼金术师报价系统”，并获得 AMD 锐龙 AI 智能体应用创新大赛专业组 OPC 一人公司赛道冠军。

这套系统的目标不是让大模型凭空“猜价格”，而是把 CNC 非标加工中分散在图纸、Excel 表格和老师傅经验里的知识，重新组织成一条可执行、可检查、可修改的本地化流程。它读取客户三维图纸、工艺参数、历史报价和工厂设备成本等敏感数据，因此本地部署与离线能力成为重要方向。

核心硬信息如下：

• 系统版本：当前已迭代至第 12 版
• 运行平台：搭载 AMD 锐龙 AI Max+ 395 的本地设备
• 主要推理模型：约 35B 参数的稠密模型（非 7B 小模型，也非 70B 或 MoE 模型）
• 内存配置：最高 128GB LPDDR5x 统一内存
• 推理速度：35B 模型在项目中约 20–30 tokens/秒
• 种子测试：截至采访时，产品正在 3 家工厂测试

大模型的边界：选逻辑，不做心算

曹冬冬做出的第一个版本并不复杂：系统先解析 STEP 格式三维图纸，提取尺寸、孔、基本面、薄壁等几何特征，再由本地模型判断可能采用的工艺，最后调用 Python 公式计算材料、工时和表面处理成本。

这套设计从一开始就划定了边界：大模型不直接负责计算最终价格。

曹冬冬的判断是，大模型更适合做工艺探索，例如判断一个零件可能采用什么加工路线、选择哪些刀具和材料；但涉及材料用量、加工时间和成本加总时，必须交给确定性的程序完成。他说：“把误差直接交给 LLM 去做心算，是算不准的。”

因此，系统会先从图纸中取得结构化数据，再让模型选择或生成计算逻辑，最后调用 Python 执行公式。大模型负责“选”，程序负责“算”。这也是它控制模型幻觉的主要方式。

如果让模型根据一张图纸直接生成报价，数字可能看起来合理，却很难追溯尺寸从哪里来、工时如何推导、损耗率为何这样设置。曹冬冬因此尽量让计算过程“白盒化”：工程师能看到系统识别了哪些特征、选择了什么工艺、调用了哪些公式，也可以在中间环节修改参数。

“你不能只告诉我一加一等于二，还要让我看到它为什么等于二。”他说。

多智能体是流程的数字化复刻，而非架构炫技

在最初的三步闭环跑通后，系统被拆分为图纸解析、DFM 可制造性分析、工艺评估、质检、财务和风险控制等多个智能体模块。每个模块只处理一项相对明确的任务，上一环节输出结构化结果，再交给下一环节处理。

这种架构看起来像大模型行业常见的多智能体协作，但本质上更像是工厂报价流程的数字化重组。工厂原本的报价流程就是串行的：先看懂图纸，再确定工艺和设备，随后估算工时、材料和利润。系统没有凭空创造新方法，而是把原有流程拆开，将其中一部分交给模型和程序。

智能体数量增加后，资源调度问题很快出现。如果图纸分析、工艺判断、财务和风险控制等智能体同时运行，它们会争夺内存和计算资源；如果全部串行，又会拉长等待时间。上下文不断累积，还可能导致模型遗忘前文，或在长链路中调用错误工具。

曹冬冬后来采用折中方案：部分任务并行执行，但结果按顺序返回；智能体之间尽量传递结构化字段，而不是大段自然语言，以减少上下文长度和 Token 消耗。并不是每一步都需要大模型参与：STEP 图纸解析、CAD 库调用和 Python 计算主要由 CPU 完成；小规模知识库检索也可以在 CPU 上运行；只有在需要复杂工艺推理和工具调用时，系统才启用 GPU 上的本地模型。

效率方面，原文提到一套复杂图纸的人工报价可能需要两三个小时；团队测试中，一个简单零件可以在约 3 分钟内完成分析。两者场景并不完全相同，但足以说明：这类系统的价值并不只来自更大的模型，而在于把报价流程拆成稳定、可复用的计算流水线。

从 Demo 到产品，隔着操作系统与工厂大门

曹冬冬最终使用了一台搭载 AMD 锐龙 AI Max+ 395 的设备。该平台集成 CPU、GPU 和 NPU。根据 AMD 公布的信息，它采用 16 核 32 线程 Zen 5 CPU，集成拥有 40 个计算单元的 Radeon 8060S GPU 和最高 50 TOPS 算力的 XDNA 2 NPU，最高可配置 128GB LPDDR5x 统一内存；AMD 开发平台给出的内存带宽为 256GB/s。

对这套报价系统而言，最关键的不是 NPU 的标称算力，而是 128GB 统一内存。传统 CPU 加独立显卡的系统中，系统内存和显存彼此分离；模型权重一旦超过显存容量，就需要频繁搬运数据，或通过量化缩小模型。统一内存让 CPU 和集成 GPU 使用同一个内存池，使一台相对紧凑的本地设备可以同时容纳模型、知识库、图纸解析程序和操作系统。

但模型“装得下”，不代表系统一定跑得顺。

曹冬冬最初按照过去使用 CUDA 的经验配置环境，很快发现 CUDA 不能直接用于 AMD 集成 GPU。要让 PyTorch、llama.cpp 等工具调用锐龙 AI Max+ 395 的 GPU，需要转向 ROCm 或其他受支持后端。在 Linux 环境中，他使用 ROCm 和 llama.cpp 运行本地模型，并通过 ROCm SMI 查看 GPU 利用率、内存占用和温度。经过调试后，35B 模型在其项目中的生成速度约为每秒 20–30 个 Token。

这个速度并不适合承担大量用户同时访问的在线服务，但报价也不是实时聊天。真正的难点反而出现在系统进入工厂之后。

团队最初主要在 Linux 下开发，后来为了适应客户环境，将软件迁移到 Windows 专业版。现场部署时，他们发现部分客户使用的是长期不升级的 Windows 企业版，同时安装了严格的安全软件。原本能正常启动的组件可能被拦截，容器、驱动和依赖库也不一定符合工厂 IT 策略。

另一个挑战来自文件本身：部分 STEP 文件编码不规范，常规解析器可能报错甚至崩溃。团队不得不增加降级策略：标准解析失败后尝试容错读取，再处理缺失字段；无法确认的部分交回人工检查。

曹冬冬总结：“开发环境里跑通，不等于到了客户那里也能跑。”本地部署保护了图纸，也提供了离线能力，但代价是软件提供者必须承担更多适配工作。云端 API 隐藏掉的硬件、框架和运维差异，在本地环境中都会重新出现。

谁该上车？谁该再等等？

曹冬冬并不认为所有任务都应该留在本地。他设想的长期架构仍然是端云混合：涉及工厂商业机密且调用频率较高的任务放在本地，包括图纸解析、专属知识库、历史报价查询和基础工艺判断；对于本地模型难以完成的复杂工艺，或需要更广泛行业知识的任务，再调用云端模型进行校验。

适合优先尝试者：

• 图纸、历史报价和工艺数据敏感，不希望上传外部服务器的加工厂
• 网络环境受限，存在弱网、内外网隔离或离线作业需求的车间
• 愿意投入时间与 IT 资源调试本地部署，并希望掌握全流程控制权的企业

建议谨慎评估者：

• 需要高并发报价服务的场景，本地 20–30 tokens/秒生成速度并不适合在线大规模访问
• 缺乏 IT 支持、希望完全开箱即用的工厂
• 报价场景高度依赖广义行业知识，而不是本厂历史经验和设备能力的团队

目前，曹冬冬提到的 95% 以上报价准确率仍是团队内部测试和规划目标，需要在更多零件类型、不同工厂和真实订单中继续验证。团队也已经根据不同设备和加工能力制作了 10 套初始模板，希望先覆盖一家工厂约 80% 的基础情况，再结合历史订单和实际反馈校准。

写在最后

曹冬冬的实践说明，工业智能体未必始于顶尖算法背景，关键在于能否把老师傅难以言表的经验拆解为可执行、可追溯、可修正的流程。

锐龙 AI Max+ 395 在其中扮演的是计算底座，而不是万能大脑。它解决了“本地装得下”的问题；至于图纸能否读懂、工艺能否判断正确、系统能否真正进入车间，仍需要开发者一层层补上。当工业知识与边缘算力在真实场景交汇，本地化 AI 报价正在从“能跑 Demo”走向“可用产品”。