最近,我做了一个开发者实验:尝试把 Qwen2.5-0.5B-Instruct 部署到 HPM6800EVK 上,让它在板端完成本地推理。
这里的“本地”不是把 MCU 当成串口终端,再去调用云端 API;也不是由 PC 代跑模型、板子只负责显示结果。模型权重、Tokenizer、推理框架、采样逻辑、交互流程都运行在 HPM6800EVK 开发板上。用户通过 UART 输入问题,MCU 在本地完成推理并流式输出回答。
这次视频演示的是两个方向:
第一个是本地聊天。
我将 Qwen2.5-0.5B-Instruct 移植到 HPM6800EVK 上运行。这个模型约 4.94 亿参数,经过混合量化后,模型文件约 414MB,Tokenizer 文件约 2.9MB。板端从 SD/TF 卡加载模型和词表,在 MCU 上完成前向推理,并通过 UART 提供交互式聊天体验。
在这个演示工程中,主要做了几件关键工作:
将模型推理流程用 C 实现并适配 MCU 运行环境;
将 Qwen2.5 的 Tokenizer 导出为板端可加载的二进制格式;
针对 HPM6880 的 RISC-V/Andes D45 内核使用 P 扩展 SIMD 指令优化矩阵计算;
对 KV cache、权重布局和运行时内存进行压缩与规划,让模型能够在板载 DDR 资源中运行;
保留 UART 流式输出,让用户能看到模型逐 token 生成结果。
在当前实验配置下,这个聊天 demo 可以演示中文问答、多轮对话和一些基础代码类问题。需要注意的是,整体生成速度并不快,更适合观察流式输出过程和验证链路,而不是追求即时响应。它验证的重点不是“MCU 要和 GPU 拼吞吐”,而是在特定硬件和模型配置下,观察小规模量化语言模型的完整推理链路能在 MCU 平台上做到什么。
第二个是代码生成。
聊天只是第一步。更进一步,我希望尝试让板端模型不仅能回答问题,还能把自然语言任务转成可执行代码。
在代码生成 demo 中,用户可以输入类似这样的任务:
求 10 的阶乘,并打印结果
板端大模型会生成 Python 代码,然后交给同一块 MCU 上嵌入的 MicroPython 运行时执行,最后把结果打印出来。
这部分的交互速度会更慢,更像是等待模型逐步生成一段可执行脚本,而不是云端代码助手那种即时响应体验。
也就是说,这条链路不是简单地“模型输出一段文本”,而是:
自然语言任务 → 本地大模型生成 Python → MicroPython 在板端执行 → 输出运行结果
为了让这条链路真正跑通,代码生成 demo 中需要增加几个工程模块:
针对代码生成任务设计 prompt,让模型尽量输出可执行 Python;
在 MCU 上集成 MicroPython 编译器、VM 和 GC 运行时;
增加math、random等常用能力的板端适配;
将 MicroPython 的open()和简化os模块桥接到板端文件系统接口;
支持代码运行失败后的错误反馈和重试,让模型有机会根据错误重新生成代码;
因此,视频里看到的文件读写也不是预置输出。模型生成的 Python 代码可以通过 MicroPython 直接访问 SD/TF 卡上的文件系统,例如创建文件、写入内容、读取文件、遍历目录等。
这里也需要强调:代码生成 demo 更适合简单、受控任务演示,例如计算、字符串处理和基础文件读写。它不能被理解为可以稳定完成复杂工程代码,也不能直接用于安全关键或实时控制逻辑。
这块板子是什么?
本次演示使用的是 HPM6800EVK 开发板。它搭载 HPM6800/HPM6880 系列高性能 RISC-V MCU,主频可达 600MHz,并配备大容量 DDR3L 外部存储、Quad SPI NOR Flash、eMMC、TF 卡等存储资源。开发板还提供 LCD、MIPI-DSI、MIPI-CSI、DVP 摄像头、千兆以太网、USB 2.0 OTG、音频、CAN、RGB LED 等丰富外设接口,适合用于图形显示、音视频处理、工业控制以及边缘 AI 等场景验证。
在这次 LLM demo 中,模型文件从 SD/TF 卡加载,模型权重、KV cache、运行时缓冲区等主要依赖板载 DDR 资源,推理和交互逻辑运行在 MCU 端,通过 UART 与用户交互。
为什么要在 MCU 上跑大模型?
从开发者视角看,我主要关注三个点。
首先,它让我能观察小规模量化语言模型在 MCU 平台上的运行边界。过去更多讨论的是服务器、PC、手机、边缘计算盒子,现在具备外部 DDR 的高性能 MCU 也可以进入本地模型推理的实验范围。
其次,它让我看到传统 MCU 工程可以接入一些语言模型相关模块,比如 Tokenizer、采样、脚本运行时和文件系统接口。
第三,代码生成这段比较有意思:模型先生成一段脚本,再由板端 MicroPython 执行。现在只适合简单任务,但这个链路本身值得继续试。
当然,这仍然是一个展示和方向探索 demo。它依赖特定硬件、板载 DDR 和量化后的模型配置,响应速度也比较慢。目前更适合用来观察“MCU 本地跑小模型”这条路能走到哪里,而不是作为产品应用来理解。
这也是我做这个 demo 最想表达的点:
这次 demo 至少说明:在这类硬件和模型配置下,MCU 本地跑小模型推理链路是可以做方向探索的。
下面这条视频,是从开发者视角做的一次实际演示。视频中展示了 HPM6800EVK 上的本地聊天、自然语言代码生成、MicroPython 板端执行,以及 SD/TF 卡文件读写。
后续我也会继续关注边缘 AI、本地小模型和 MCU 智能化方向的更多探索。
-
mcu
+关注
关注
147文章
19314浏览量
405702 -
uart
+关注
关注
22文章
1328浏览量
107306 -
开发者
+关注
关注
1文章
811浏览量
18132
发布评论请先 登录
在openEuler上基于vLLM Ascend部署Qwen3
2024年上海海思MCU开发者体验官招募,手机/MatePad大奖等你拿!
MCU代码自动生成功能,Gokit二次开发视频教学
STM32峰会:机智云MCU代码开发工具降低智能硬件开发成本
绝对干货!HarmonyOS开发者日资料全公开,鸿蒙开发者都在看
openEuler Summit开发者峰会:欧拉社区与开发者持续活跃 原创项目代码仓新增50%
号称全球最强开源模型 ——Qwen2.5 系列震撼来袭!PerfXCloud同步上线,快来体验!
阿里云开源Qwen2.5-Coder代码模型系列
Qwen大模型助力开发低成本AI推理方案
阿里巴巴Qwen大模型助力开发低成本DeepSeek替代方案
【开发者分享】开源硬核玩家集结:这些MCU板子泰酷了!
开发者分享 | 在 MCU 上探索 Qwen2.5 代码生成
评论