最早接触 UP Board还是在第一代 Atom 平台的年代彼时它在我眼里就是一个“能跑 Windows 的树莓派”。这几年 UP Board 产品线一步步迭代从 UP Squared 到后来的 UP Xtreme 系列我注意到它在工业场景里被用得越来越多。最近我又在折腾这一代新品它最大的变化是换上了 Whiskey Lake 平台同时把 AI Core X Modules 这类模块化 AI 加速器正式纳入了产品体系。这篇文章我想从实际选型、落地和踩坑的角度聊聊这套组合。1. UP Board 这代产品的底层升级Whiskey Lake 到底带来了什么1.1 先理清 UP Board 家族的产品脉络UP Board 从一开始就打的是“x86 架构单板计算机”这张牌和树莓派、Jetson 这些 ARM 板卡有着本质区别。初代 UP Board 用的是 Atom x5-Z8350定位就是低功耗、能跑 Windows/Linux、接口全。到了 UP Squared换成了赛扬 N3350 和奔腾 N4200性能小幅提升但本质上还是凌动级别的核心。这一代换装 Whiskey Lake 之后产品定位明显从“开发板”往“工业边缘计算节点”上靠了。Whiskey Lake 是 Intel 第八代酷睿家族的工艺改进版制程是 14nm最高可以做到四核八线程TDP 在 15W 到 25W 之间。听起来功耗比之前的凌动高了不少但算力提升是跨越式的单核性能几乎是 N4200 的一倍以上。也就是说同样的散热体积下你能跑的软件复杂度完全不同了。UP Board 这个产品线一直非常坚持“树莓派兼容 GPIO”这个设计。新的 Whiskey Lake 板卡仍然保留了 40-pin 的树莓派兼容排针这就意味着以前给树莓派写的 GPIO 控制代码只要做很小的移植就能跑在 x86 平台。我见过不少做原型验证的团队先用树莓派做传感器采集然后把整个程序无缝搬到 UP Board 上直接进小批量产。这种路径的平滑程度是纯 ARM 方案给不了的。1.2 Whiskey Lake 这颗处理器对 AI 边缘节点意味着什么很多人一看 Whiskey Lake 是八代酷睿就下意识觉得“这个 U 有点老”。但在工业单板市场这类处理器的生命周期反而更长、供货更稳定这恰恰是工业客户最看重的东西。具体到 AI 计算场景Whiskey Lake 有两个容易被忽略的优势。第一个是核显UHD 620 支持 VP9 和 H.265 的硬件解码。这点在你做视频流分析时极其重要——解码不占 CPUCPU 可以全力跑前处理和调度逻辑VPU 或核显再做推理。第二个是 AVX2 指令集OpenVINO 的预处理插件、一些传统的 CV 算法在 AVX2 下能获得接近翻倍的加速。像图像缩放、归一化、颜色转换这些 AI 前处理步骤在 ARM 板子上经常成为性能瓶颈但在 Whiskey Lake 上几乎可以忽略。另外这一代普遍支持 vPro也就是带外管理。工业现场部署了十几台设备后你就知道 IPMI/AMT 这种远程管理能力有多重要。设备在客户现场出了问题不用专门跑一趟直接带外重启、看启动日志。这个功能在消费级板卡上根本见不到但在真正使用时属于“用了就回不去”的功能。1.3 工业场景为什么认准 x86 而不是 ARM 开发板这个问题我在好几个项目里被问过。最核心的原因是软件生态。工业场景里大量现成的代码库、算法库、Docker 镜像都是 x86 优先的。你用树莓派做原型没问题但到了产线上要对接 PLC、要跑厂商提供的 Windows 版 SDK、要用某些只有 x86 版的专业采集卡驱动ARM 板卡的劣势就暴露了。还有一点是内存和存储。Jetson 这类板卡内存偏小扩展存储也受限于 SD 卡或者板载 eMMC。而 UP Board 这类 x86 板卡支持标准 SO-DIMM 内存和 M.2/SATA 硬盘随便配都是 16GB 内存加 1TB 固态。有些视觉项目的模型和数据量动辄几十 GB 起步ARM 板卡在这个层面上真的不够用。2. AI Core X Modules一块 M.2 板卡如何把 AI 算力“模块化”2.1 从 Myriad X 这颗 VPU 说起AI Core X Modules 这个名字听起来有点玄乎拆开看就清楚了。它本质上是一块 M.2 接口的 AI 加速卡核心是 Intel Movidius Myriad X 视觉处理单元。Myriad X 是一颗专门为边缘视觉设计的 VPU内部有专用的神经网络计算引擎配合 16 个 SHAVE 向量处理核心整体 INT8 算力能做到 1 TOPS 左右但整颗芯片的功耗只有 1 到 2 瓦。这个数字和 GPU 比简直不值一提但要注意应用场景。边缘设备上跑的大多是轻量级分类网络、目标检测网络比如 MobileNet SSD、YOLOv4-tiny、PoseNet 这些。这些模型在 Myriad X 上跑单颗 VPU 实际吞吐量大约在几十 FPS 量级足够应付大量真实场景。而 1-2W 的功耗意味着不需要主动散热一个小小的散热片就够了这对工业设备内部狭小的空间来说很重要。我最早接触 Myriad X 还是插在 USB 口的 Neural Compute Stick 2 时代。那时它给我的印象就是一个“玩具”因为 U 盘形态散热太差连续推理一小时后性能就掉得厉害。AI Core X 改成 M.2 板卡形态之后散热条件大幅改善同时通过 PCIe 接口和主机通信带宽和延迟表现也提升了很多。这才是它能真正用于产品的形态。2.2 一个模块装几颗 VPU模块化设计解决了什么问题AI Core X 模块有不同配置最直观的区别就是板上集成了几颗 Myriad X VPU。常见的有单颗、双颗、四颗版本。多颗 VPU 之间通过板载的 PCIe Switch 扩展对主机来说它们呈现为多个 PCIe 设备但占用的物理接口只有一个 M.2 插槽。这种设计的聪明之处在于算力可裁剪。假设你做一款工业视觉检测设备前期算法还在验证阶段精度和帧率要求都不高那么插一个单 VPU 模块即可成本能省一大截。等到项目落地、客户要求同时检测多个工位你不需要重新设计主板只需要把 M.2 模块换成四 VPU 版本然后把散热片和外壳稍微加厚就完成了算力升级。我特别想强调的是这种模块化对产品化团队非常友好。很多创业公司做 AI 硬件前期最怕的就是硬件方案锁定。你选了一个 5W 的 SoC后期算力不够就得重新画板子周期至少三个月起。而 UP Board 加 AI Core X 的组合把计算平台和 AI 加速器解耦了前期的选型风险被大大降低。2.3 和 Jetson、Edge TPU 横向对比的选型坐标系我不止一次被问到“为什么不用 Jetson”。这里必须说清楚一个事实Jetson 和 UP Board 并非同一物种。Jetson 的核心是一颗带 GPU 的 SoC适合做融合了训推的复杂视觉任务但它的软件栈偏封闭很多工业外设驱动并不完善而且 GPU 在低功耗下的能效比优势只有在特定负载下才明显。UP Board 加 AI Core X 的组合CPU 和 VPU 是分离的你完全可以跑标准的 x86 发行版、装任意内核版本、用标准 PCIe 驱动。下面是几个主流边缘 AI 方案的对比维度我自己在选型时会照着这个表格过一遍方案算力形态典型功耗工具链最适合的场景UP Board AI Core Xx86 CPU Myriad X VPU15-30W整机OpenVINO工业视觉、多路视频分析、需跑复杂 x86 软件的边缘节点Jetson Nano / Xavier NXARM SoC GPU5-25WCUDA/TensorRT重度 CNN 推理、GPU 加速计算Coral Edge TPUARM SoC TPU2-5WTensorFlow Lite低功耗轻量分类、离线语音从这张表能看出来偏向“通用计算 一定 AI 加速”的场景UP Board 这套最合适偏向“极致功耗下跑神经网络”的场景Coral 性价比更高如果是做复杂的模型推理要上 Transformer 之类的大模型那还是老实选 Jetson 或者干脆用显卡。没有万能板子只有合适不合适的组合。3. 从规格表到现场真实场景里这块板子怎么用3.1 工业视觉质检算力不大但要求稳定工业质检是 AI Core X 模块最好的落地场景之一。典型需求是生产线上的相机拍下产品图片算法判断是否存在缺陷然后通过 GPIO 信号控制分拣机构。整个流程对算力的要求其实不高单张 500 万像素的图片推理一次MobileNet 级别的模型大概 20 到 50 毫秒就能完成但要求的是长期稳定运行不能动不动掉帧、死机。UP Board 加单颗 Myriad X 的组合在这个场景里表现很好。CPU 负责从相机拉流、做图像预处理、跑 PLC 通信协议VPU 专职推理两者并行不冲突。而且 x86 平台跑 PLC 通信库非常成熟常见的 Modbus、EtherCAT、S7 协议都有现成库可用。相比树莓派方案x86 平台的稳定性确实高了一个量级工业现场 7x24 小时运行很少出幺蛾子。3.2 移动机器人和 AGVx86 生态的天然优势AGV 和 AMR 这类移动机器人是另一个典型的应用场景。机器人的主控需要同时处理激光雷达数据、执行路径规划算法、和调度系统通信有的还要跑视觉避障。这些任务里路径规划和调度通信占了很大比重对 GPU 算力没有刚需但对 CPU 多线程能力和外设接口丰富度要求很高。Whiskey Lake 的四核八线程在这里是实打实的优势。ROS/ROS2 的节点调度很吃多核性能四核处理器跑起来明显比双核 Atom 从容。我见过一些团队把激光雷达的数据预处理放在 CPU 上同时用 Myriad X 做视觉的辅助避障整体资源占用控制得很好。更重要的是AGV 项目经常要对接客户现有的调度系统这些系统多半只提供 x86 的 SDKARM 方案往往直接被客户排除。3.3 视频流分析一个 VPU 能扛几路摄像头很多朋友关心的是“M.2 的 AI 模块到底能接几路摄像头”。我说一个粗略的估算思路大家可以根据自己的模型和帧率需求来套。假设你用一个 SSD-MobileNet 的目标检测模型输入分辨率 300x300在单颗 Myriad X 上实测大概能跑到 50 到 80 FPS。取保守的 50 FPS如果每一路摄像头按 15 FPS 的检测频率来算单路消耗 15 FPS那一颗 VPU 大约能处理 3 路摄像头。如果换用 YOLOv4-tiny实测在 20 到 30 FPS 左右一路摄像头按 10 FPS 算两路就比较极限了。这是算力维度。千万别忽略另一个瓶颈——视频解码。Whiskey Lake 的核显支持 H.265 硬解这个能力就是为多路视频准备的。如果你使用核显硬解多路高分辨率视频流的解码就不会拖累 CPU解码后的帧直接送 VPU 推理整个流水线基本能跑满。我见过不少人在 ARM 板卡上做多路视频分析CPU 直接被打满解码成了最大的瓶颈而这个瓶颈在 Whiskey Lake 平台上基本不存在。3.4 严格一点说VPU 落地的部署流程从开发到交付这套方案的部署流程大概是这样的在 PC 上用 OpenVINO 的 Model Optimizer 把训练好的模型转换成 IR 格式的中间表示文件然后把 IR 文件连同推理代码一同打包到 UP Board 上运行。整个过程和普通 x86 程序的部署几乎没有区别你也可以把整个环境打成 Docker 镜像非常方便。4. 开发者上手实操从装系统到跑通 OpenVINO 推理4.1 硬件准备与插槽选择的注意事项拿到板卡之后第一步是正确选择 M.2 插槽。UP Board 这类板卡通常会提供两三个 M.2 接口有的 B Key 走 SATA有的 M Key 走 PCIe。AI Core X 模块是 PCIe 设备必须插在走 PCIe 通道的 M.2 插槽上如果插到 SATA 的槽里系统无法识别。装好模块后在 BIOS 里确认 M.2 接口的工作模式被设置为 PCIe有些板卡默认是 Auto但保险起见手动指定一下。然后装好 Ubuntu 20.04 或 22.04进入系统后用 lspci 确认 VPU 是否被正确识别lspci | grep -i movidius正常情况下会看到类似Movidius Myriad X VPU这样的设备条目。如果看不到先检查插槽是否插紧再看 BIOS 里 PCIe 链路是否正常。这一步排除硬件问题之后再往软件层面排查。4.2 OpenVINO 工具链的安装与模型转换软件层面目前推荐直接通过 pip 安装 OpenVINO 的 Python 包这样最省事版本管理也清晰pip install openvino openvino-devopenvino-dev包含 Model Optimizer 等开发工具。把已经训练好的模型转成 IR 格式以 TensorFlow 模型为例mo --framework tensorflow --input_model your_model.pb --input_shape [1,300,300,3] --data_type FP16 --output_dir ./ir_model转换完成后ir_model目录下会有一个.xml文件和一个.bin文件这就是可以在 VPU 上运行的中间表示。注意这里我推荐使用 FP16 精度Myriad X 对 FP16 的支持是最好的INT8 需要额外的校准流程对于大部分边缘场景 FP16 的精度和性能已经非常平衡了。4.3 用 Python 跑通一次推理下面是一个最小可用的推理示例用 OpenVINO Python API 加载 IR 模型对一张图片做推理from openvino.runtime import Core core Core() # 加载模型 model core.read_model(modelir_model/your_model.xml) # 指定 Myriad X 设备 compiled_model core.compile_model(model, device_nameVPU) # 取输入输出张量的名字 input_layer compiled_model.input(0) output_layer compiled_model.output(0) # 假设 image 已经完成了预处理形状为 [1,300,300,3] result compiled_model([image])[output_layer]这里的device_name填VPU即可。如果你用的是新版 OpenVINO 2023 之后的版本设备名称在部分平台上改成了NPU需要按照实际识别到的设备名来填。推理结果和使用 CPU 跑完全一致只是模型被放到了 VPU 上执行。4.4 多颗 VPU 的负载分配如果你用的是双 VPU 或四 VPU 模块OpenVINO 会默认选择第一个可用的 VPU 设备。想要充分利用多颗 VPU需要手动做设备切分。最简单的做法是起多个推理线程每个线程分别指定不同的设备编号compiled_model_0 core.compile_model(model, device_nameVPU.0) compiled_model_1 core.compile_model(model, device_nameVPU.1)OpenVINO 的 HETERO 插件也支持异构执行比如把模型的前几层放在 CPU 跑后几层放在 VPU 跑但实际用下来多线程按设备切分的效果更好用、更好调试。4.5 板和驱动的坑这部分是重头戏。我把自己和周围朋友实际踩过的坑都列一下建议提前规避。第一个坑是内核版本太新导致驱动加载失败。Myriad X 的驱动在内核里已经包含但有些新内核改动了驱动接口老版本 OpenVINO 运行时可能无法匹配。我遇到过在 Ubuntu 22.04 的 HWE 内核上 OpenVINO 2022.1 无法识别 VPU 的情况解决办法是换用官方 LTS 内核或者升级 OpenVINO 到 2023 之后的版本。建议直接用最新 LTS 内核加最新版 OpenVINO兼容性最好。第二个坑是供电不足导致 VPU 掉线。单颗 Myriad X 满载功耗虽低但瞬间启动电流不小如果使用的是劣质电源或者 USB 供电的扩展坞很容易出现推理偶发失败、设备掉线的现象。这件事查起来特别头疼因为不是每次都发生。建议使用原装电源或者标称电流余量充足的适配器不要为了省几十块钱在电源上妥协。第三个坑是 M.2 模块的散热。我之前觉得 Myriad X 功耗这么低应该不用管散热结果连续满载推理两小时后推理时间从 20 毫秒一路恶化到 60 毫秒摸了下模块上的散热片烫得几乎不能碰。后来加了一个稍微大一点的铝制散热片加导热垫温度稳定在 70 度以内推理时间也恢复了稳定。所以就算功耗低散热设计也绝对不能省。5. 我的一些选型建议这套组合适合谁不适合谁5.1 适合你的项目的几个特征把一个项目打成适合这套方案的标签大概有这么几个特征项目需要跑 Linux 或 Windows 的完整环境需要安装各种 x86 专有软件包AI 推理算力需求在中低档位模型不超过几十 MB不需要跑大语言模型或大分辨率检测需要 7x24 稳定运行对散热和宽温有要求项目预算允许前期把硬件分摊到几千元级别但对后期运维成本敏感需要长生命周期供货而不是消费级主板的“卖完就换”。如果你的项目同时满足其中三四条UP Board 加 AI Core X 的组合几乎是最稳妥的选择。5.2 不要硬上的场景反过来我也见过不少硬上这套方案然后翻车的项目。一类是做超低功耗设备用电池供电、每天只工作几小时的场景Whiskey Lake 的功耗按 15W 算还是太大一颗 ARM 芯片可能 2W 就搞定了。另一类是跑大模型比如想在边缘跑 GPT 级别的模型这已经超过了 Myriad X 的能力范围直接换带大显存的 GPU 设备更实际。还有一类场景要特别说就是已经有成熟 ARM 软件栈并且不依赖 x86 生态的团队。如果你团队里全是 ARM 开发经验产品又能用树莓派或者 Jetson 满足需求没必要强行切到 x86。迁移成本有时候比硬件差价更贵这件事一定要想清楚。5.3 分享一个我自己的评估方法我做硬件选型有一个习惯会花半天时间把目标算法分别在 CPU 和 VPU 上跑一遍基准测试。先把模型在 CPU 上用 OpenVINO 跑记下 CPU 推理时间再在 Myriad X 上跑记下 VPU 推理时间。如果 VPU 的加速比不足三倍那说明这套方案的性价比不高不如直接升级 CPU 更快。如果加速比在五倍以上那 AI Core X 模块就是值得投入的。这个简单测试很多团队都会跳过但我强烈建议不要省。选型最怕的就是凭 PDF 参数表做判断真实跑一次比什么都直观。最后再分享一个小技巧在做产品化的时候尽量在结构设计里预留一个比当前需求高一档的散热空间。比如你现在只用单 VPU 模块但结构上按双 VPU 的散热规模来设计这样后期客户要求提算力你只需要换模块结构和电源都不用动。我因为这个设计理念在不止一个项目里省下了二次开模的费用这一点在硬件产品里是真正实实在在的成本。