UP Board换代Whiskey Lake：AI Core X模块如何重塑工业边缘计算

最早接触 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 的硬件解码。这点在你做视频流分析时极其重要——解码不占 CPU，CPU 可以全力跑前处理和调度逻辑，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 方案的对比维度，我自己在选型时会照着这个表格过一遍：

从这张表能看出来，偏向“通用计算 + 一定 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 移动机器人和 AGV：x86 生态的天然优势

AGV 和 AMR 这类移动机器人是另一个典型的应用场景。机器人的主控需要同时处理激光雷达数据、执行路径规划算法、和调度系统通信，有的还要跑视觉避障。这些任务里，路径规划和调度通信占了很大比重，对 GPU 算力没有刚需，但对 CPU 多线程能力和外设接口丰富度要求很高。

Whiskey Lake 的四核八线程在这里是实打实的优势。ROS/ROS2 的节点调度很吃多核性能，四核处理器跑起来明显比双核 Atom 从容。我见过一些团队把激光雷达的数据预处理放在 CPU 上，同时用 Myriad X 做视觉的辅助避障，整体资源占用控制得很好。更重要的是，AGV 项目经常要对接客户现有的调度系统，这些系统多半只提供 x86 的 SDK，ARM 方案往往直接被客户排除。

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-dev

openvino-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(model="ir_model/your_model.xml") # 指定 Myriad X 设备 compiled_model = core.compile_model(model, device_name="VPU") # 取输入输出张量的名字 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_name="VPU.0") compiled_model_1 = core.compile_model(model, device_name="VPU.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 的散热规模来设计，这样后期客户要求提算力，你只需要换模块，结构和电源都不用动。我因为这个设计理念，在不止一个项目里省下了二次开模的费用，这一点在硬件产品里是真正实实在在的成本。