曹冬冬和他的"炼金术师" 用锐龙AI Max+ 395重构非标制造报价体系

【ZOL中关村在线原创访谈】一台机床，一张图纸，一个在工厂里摸爬滚打了15年的老曹。这是曹冬冬在成为AMD锐龙AI智能体应用创新大赛OPC一人公司赛道冠军之前的身份标签。

他不是科班出身的算法工程师，也没有互联网大厂履历，而是一个真正"泡"在车间里的工业老兵。从零开始自学AI后，他用一套名为"Union·由你｜CNC非标智造炼金术师报价系统"的产品，把老师傅需2~3小时（120~180分钟）才能完成的非标CNC零件报价，压缩到约3分钟，报价误差控制在5%以内。

这套系统的底座，是基于AMD锐龙AI Max+ 395平台开发。

近期，笔者采访了这位来自工厂一线老兵的AI赛道新人，老曹完整复盘了这套方案从0到1，再到12个版本迭代背后的技术路径和踩过的坑，以及为什么在众多硬件平台中，他最终全部押注在锐龙AI Max+ 395这颗芯片上。

·从"非专业"到"最优解"：128G内存是第一道门槛

非专业程序员的出身，让曹冬冬在获胜者里颇有传奇色彩。但在工业领域，他是实打实做了15年产品的老兵。这个身份让他对“好不好用”格外敏感，对锐龙AI Max+ 395的评价格外朴素、不绕弯子。

在他看来，这颗芯片对开发者最直接的价值，首先是内存容量：128GB统一内存，日常兼容办公，CAD画图，采用64:64比例，分内存/显存，让他在本地就能跑起Qwen3-27B稠密模型——按FP16全精度计算，权重约54GB（27B参数x2字节），Q5量化后仅约19GB，即使叠加场上下文与KV缓存，128GB仍余量充足，不需要像小显存平台那样被迫牺牲精度、砍上下文，或转向MoE架构。这一点对非标制造报价场景至关重要：每一次报价都要重新解析零件的几何特征并计算逻辑关系，不能靠模板套模板，所以模型的精度直接决定了报价结果能不能用。

第二个关键点是生态完整度。AMD提供的ROCm让AI开发接近开箱即用：PyTorch、llama.cpp等框架与工具链被打包进驱动环境，不需要开发者从零搭建环境。对独立开发者而言，这种"拿来就能用"的成熟度，直接决定了他是否把有限的精力放在业务逻辑本身，而不是耗在环境配置与设备调试上。

第三是延迟表现。锐龙AI Max+ 395集成Radeon 8060S iGPU，支持可变显存分配（最高可将96GB统一内存划为显存），叠加128GB超大统一内存与256GB/s内存带宽，大模型的本地推理能够在低延迟环境下进行，正好击中报价、交互这类场景最敏感的痛点。

第四点是CAD生态支持。他的业务离不开STEP图纸的解析、拆图与渲染，这些环节在AMD平台上都能被完整覆盖，尤其是渲染加速配合SOLIDWORKS这类拆图软件，易用性极佳。

老曹还提到一个细节：早期参赛阶段，AMD就直接把真机交到他手里，而不是只提供一个云端测试节点。这需要真机调试、摸透硬件参数的工业场景开发者来说，这种真实的物理反馈不可替代。

·为什么必须是本地？安全、专属、离线可用

如果说内存和生态解决的是“能不能跑起来”，那么选择本地部署而非云端，解决的是"值不值得跑"的问题。

工业领域安全第一。老曹的客户中不少与大厂甚至涉密企业签有保密协议，图纸、工艺参数、历史报价数据本质上都是工厂的专属资产，几乎不可能被允许上云。所以相比调用通用大模型的公有API，工厂更倾向于私有化部署：把专属模型直接放进本地设备微调，训练出真正"懂自己"的AI，而不是依赖一个知识面很广、但与本厂契合度很低的通用模型。

安全之外是延迟。工厂车间往往处于弱网甚至离线状态，云端方案在这种环境下几乎直接失效，所以本地化不是锦上添花，而是制造业场景的最低保障。老曹的回答很朴实：“本地的AMD锐龙AI Max+ 395设备，插上电就能持续运转。”这句话看似平淡，却包含了稳定可靠、离线使用、支持本地AI大模型的部署与推理、确保数据安全四层含义。

成本结构同样关键。严格的说，本地方案并非“零成本”，二是“一次性硬件投入+极低的边际成本”：没有API调用费和token消耗，单次报价的边际成本主要是电费。按整机功耗约200W、单次3分钟、电价0.6元/kWh估算，每次报价耗电约0.01kWh、电费余额0.006元（不足1分钱）；即使把设备购置成本分摊进数十万次报价，单次摊销也仅数毛钱量级——远低于云端API按token计费。这种量级的成本差异，让本地化方案在中小工厂的商业模型里天然占优。

智能体时代对于成本更加敏感：以往大模型推理只在思考和生成时消耗token，而智能体时代每一次调用、交互、思考、推理都会产生更多token消耗，锐龙AI Max+ 395的本地化方案正好规避了这部分持续支出，对个人开发者和企业用户都是实打实的益处。

·把幻觉关进笼子：以图纸为驱动，而非让模型“心算”

非标CNC报价最大的挑战，是每次零件的材质、公差、工艺都可能完全不同，给AI幻觉留下了巨大空间。老曹的解法核心，是不让模型去“心算”。

Union·由你系统先基于STEP图纸做真实的几何解析，提取尺寸、孔位、基本面、薄壁等真实特征，再进行DFM工艺探索。整个系统在明确的工艺边界条件下运行：先用模型生成一套Python公式，再用真实数据执行演算，把误差交给确定性的代码计算，而不是让大模型直接"猜"结果。他把这个逻辑总结为：模型擅长做的是选工艺、选刀具、选材料这类思路探索（TOT，Treeof Thoughts，思维树），不擅长的是精确算数，所以精算环节交给Python，推理探索环节交给模型，两者分工明确。

为了解决信任问题，老曹把整个推理和计算过程全部白盒化：工程师可以看到每一步解析了哪些特征、推荐了什么工艺、用了什么计算公式，同时支持逆向审核、反馈，形成人机协作，而不是一个封闭的黑盒。这一整套“图纸驱动+代码精算+全流程白盒”架构，正是依托锐龙AI Max+ 395充裕的内存和算力空间才得以顺利运行——足够大的内存让它不必在模型精度和推理链条完整性之间做取舍。

·多智能体架构与CPU、GPU、NPU的"智能路由"

系统采用时下流行的多智能体架构：几何解析、报价生成、风控、财务对账各自由独立的智能体负责，以流水线式协作，模拟真实工厂的报价流程。老曹解释：“这不是为了炫技去堆砌多智能体，而是把每个环节交给专门的模块去做，用工具、提示词、Skill针对性强化，比单一大模型笼统处理更准确、更可控。”

这套多智能体系统对硬件资源调度提出了更高要求，锐龙AI Max+395在这方面给了相当大的灵活度：简单的STEP图纸解析、Python和CAD库运算这类计算密集但非AI的任务，交给CPU处理就已经足够高效；而涉及多步骤、多工具调用的复杂推理（如DFM工艺探讨、一句话生图），则必须依赖ROCm+llama.cpp支持下的GPU算力。系统内置一层智能路由，根据任务复杂度自动决定资源分配，既避免了简单任务占用GPU造成浪费，也保证了复杂任务获得足够的算力支撑。

在多智能体之上，老曹还采用了"模型级双开、串行调用"的两级架构：MoE 119B（Q4）负责完成初步方案、打好地基——快速给出几何特征解析框架、工艺路线与报价结构的草稿（实测约30tokens/秒，短链路精度足够）；随后由Qwen3-27B稠密模型（Q4）对草稿逐项修复并精算——校验特征、生成并验证Python公式、给出最终报价（实测约20tokens/秒，长链路工具调用成功率98%以上）。两个模型常驻内存、双工保持：27B Q4约19GB、119B MoE Q4约68GB，合计约87GB，GPU 96GB统一内存仍余约9GB给长上下文、知识库与STEP解析；串行工作保证同一时刻只有一个模型占用内存带宽，每次调用独占256GB/s，因此两个模型的实测速度在双开场景下均不衰减——这是"速度与精度兼得"的结构性解法：MoE用速度打底，稠密用精度封顶，互不冲突。

关于NPU需要补充说明：锐龙AI Max+ 395的NPU算力约50TOPS，跑不动Qwen3-27B主模型，因此智能路由主要在大模型推理（GPU）与脚本/解析运算（CPU）之间调度；NPU可用于语音唤醒、轻量常驻分类等小任务，避免与GPU争抢资源，形成三级分工。

老曹特别强调256GB/s的内存带宽规格：这让本地知识库和模型参数在CPU、GPU之间的搬运流转完全够用，也是他选这颗芯片作智能体基座的核心理由之一。128GB统一内存与Radeon 8060S这颗旗舰级集成显卡，可同时支撑Qwen3-27B稠密模型推理、知识库调用、STEP解析与系统开销；加上CPU与GPU之间可灵活分配的内存空间，能够精确找到甜点区间——最高可将96GB内存分配给显存。

因此，锐龙AI Max+ 395给到老曹这样的开发者，不只是够用的性能支撑，更是灵活多变的解决方案空间：即便一条路被堵死，更大的性能冗余足够“老曹们”找到更加多元化的解法，这才是它最大的价值点。

·踩过的坑：从Windows企业版到MoE模型的死循环

再好的平台，也需要开发者踩过坑才能摸清边界。老曹坦诚分享了几个印象最深的教训。

第一个坑来自对客户真实使用环境的误判。项目最初在Linux上完成开发，Linux生态相对开源、顺畅，但客户实际使用的却大多是Windows企业版——这个版本基本不更新，安全策略也格外严格。老曹最初直接把Linux方案移植到Windows专业版测试，结果到客户现场部署时，系统的安全防护直接把程序杀掉。这次经历让他意识到，必须提前摸清客户的真实运行环境，而不能想当然地按标准版本去适配。

第二个坑是模型架构的选择。团队最初尝试用MoE混合专家架构（Mistral 119B，Q4量化），实测输出约30 tokens/秒，前几步表现流畅，但运行超过10步之后，精度和工具调用成功率就大幅下降——这是MoE架构在长链路复杂任务中的固有弊端。后来转向Qwen3-27B稠密模型，实测约20 tokens/秒，工具调用成功率提升到98%以上（部分场景接近100%），找到了效果与效率的最佳平衡点。最终架构并非彻底弃用MoE，而是"扬长避短"重新分工：MoE保留为快速草稿级——负责初步方案、打好地基（短链路精度足够）；稠密模型负责修复与精算（长链路工具调用成功率98%以上），两者常驻双开、串行调用，速度与精度兼得。

他补充说，“这个决策背后也有硬件层面的考量。Qwen3-27B稠密模型FP16权重约54GB（27B参数x2字节，十进制口径），锐龙AI Max+ 395的128GB统一内存完全装得下；生产环境采用4-bit量化，权重仅约19GB，剩余约113GB可同时承载长上下文、知识库与系统开销。实测速度：Q4量化下输出约20 tokens/秒（256GB/s÷13.5GB≈19 tokens/秒，与实测吻合）；若跑FP16全精度，则每输出一个token需读取全部约54GB权重，理论上限约7tokens/秒（256GB/s÷54GB）。而MoE模型不能按总参数量套用该公式：实测MoE119B（Mistral架构）Q4约30 tokens/秒，因为每token仅读取激活专家的权重（约8~15GB，256GB/s下理论上限约17~30 tokens/秒）——这也解释了当初119B MoE'前几步流畅'的原因：MoE败在长链路精度，而非速度。对于单次3分钟、token量有限的报价任务，20tokens/秒已足够支撑工具调用的流畅完成，工具调用准确率可稳定在98%以上。"

第三个坑是STEP图纸的解析兼容性。部分STEP文件编码不标准，通用解析器容易崩溃。老曹通过分层加固——先确认硬件边界能力，再逐层叠加软件容错策略、设置安全栅栏，配合模型的补全能力——把异常图纸也纳入了可处理范围，极大提升了系统的容错率。

·AMD给的不只是芯片：真机、工具链和渠道支持

对从零起步的独立开发者而言，平台方的支持往往决定了项目能不能真正进行和最终落地。老曹提到，AMD给到的帮助覆盖了产品开发的多个环节：早期直接提供真机用于硬件验证，而不是让开发者在虚拟环境里摸索；技术层面ROCm、PyTorch、llama.cpp等开发工具箱开箱即用，配套的模型引擎基本不需要从零写代码，iGPU状态监控和调节也十分便捷；此外还提供官方活动、展会交流等多种资源，以及对接终端厂商、拿到采购代理价格的渠道支持——这些对采购量小、议价能力弱的初创团队而言，往往比技术本身更难获得。

·下一步：从软件系统到开箱即用的一体报价机

谈及后续规划，老曹的思路清晰而务实。短期内，团队仍以AMD通用机型为基座，先在中小工厂中做深度试点：目前已有3家工厂进入种子测试阶段，计划在接下来一个月内推进至约100家客户，先以整机形式部署、收集反馈。等软硬件方案跑通、验证稳定之后，团队计划直接与AMD合作，基于锐龙AI Max+ 395定制专属的一体化报价终端机，让工厂拿到手就能开箱即用，降低自行运维的成本。

更远期的设想，则是把本地终端与白标接单网站打通，形成从报价、接单到交付的7x24小时闭环服务；工厂在这个过程中还能不断沉淀出自己的专属模型，越用越懂本厂的工艺特点，并构建产能画像。老曹认为，这套模式的核心竞争力仍然要回到锐龙AI Max+ 395本身：大内存、成熟的ROCm生态、开箱即用的工具链，是把一体机方案标准化、把成本压下来的根本前提。

·给还没迈出第一步的人

AI时代，机会重新摆在每个人面前。但很多人虽然有想法，却很难迈出第一步。老曹结合自身经验给出了建议：先从自己熟悉的行业出发，找到行业里真正非用AI不可的痛点，而不是为了AI而AI；如果没有行业背景，先花两三个月真正扎进一个行业里去观察。他还特别提醒，AI更擅长解决的是长尾、非标场景的问题，而标准化场景往往已经有更成熟的自动化方案。

在硬件选择上，他建议开发者先想清楚端侧的真实瓶颈——锐龙AI Max+395首先解决的是内存瓶颈，而非算力：128GB已经能覆盖常规模型的运行需求。在这个前提下，先跑通一个最小闭环再逐步迭代。他自己的第一版产品只有"STEP解析+本地Llama+Python计算"这样极简的三步流程，没有知识库，也没有多智能体，但正是这个最小闭环让他验证了方向的可行性，也为后续12次版本迭代打下了基础。

"你必须得交付。没有交付出来的东西，永远是个想法，停留在PPT上。"这是老曹留给所有还在犹豫的开发者的总结，也是他自己从工厂车间走到AI创业者身份转变过程中最真实的体会。