82.5万参数模型开始画真硬件

一个只有 82.5 万参数的模型，已经能给 RP2040 生成可以被硬件准确执行的绘图程序。

这不是把 ChatGPT 塞进树莓派 Pico，也不是让微控制器本地运行 Transformer；模型仍然运行在主机上，RP2040 负责接收、存储并执行模型生成的绘图字节码。但这项实验真正有价值的地方在于：它把“模型会写代码”收缩成了一个更容易验证、也更接近物理世界的问题——模型能不能生成一段受约束的程序，让真实硬件按预期动作？

根据项目作者在 Reddit 上公布的数据，当前系统使用一个 825,000 参数的自回归 Transformer，输出长度约为 100 字节的绘图字节码；RP2040 端运行一个固定点虚拟机，将字节码解释成几何轨迹，再通过 UART 把结果传回主机。12,670 条生成轨迹全部与 Python 参考虚拟机一致，解释器只占 1,862 字节 Flash，静态 RAM 占用为 0 字节，峰值栈占用为 492 字节。

这组数据说明，模型规模和执行可靠性并不是同一个问题。模型可以很小，执行器也可以极其严格；只要中间的程序语言足够受限，硬件端就不需要理解自然语言，更不需要承担神经网络推理。

先把边界说清楚：模型没有跑在 Pico 上

RP2040 是一款面向嵌入式应用的双核 Arm Cortex-M0+ 微控制器，典型工作频率最高可达 133 MHz，并配备 264 KB 片上 SRAM、外部 QSPI Flash 接口和丰富的 GPIO、UART、SPI、I2C、PWM 与 PIO 资源。

但这项实验并没有声称 825K 参数的 Transformer 能在 RP2040 上运行。模型运行在外部主机，主机完成推理后，把生成的程序传输到 Pico；Pico 只执行程序。这个区别非常关键，因为“模型可以控制硬件”和“模型可以在硬件上运行”是两个完全不同的工程命题。

前者类似于一台电脑生成数控机床的加工指令，机床只需要严格执行指令；后者则要求把推理引擎、权重、内存管理和运行时一起压进微控制器。前者已经能在成本、功耗和可靠性之间取得不错平衡，后者仍然受到存储空间、RAM 和算力的强约束。

项目目前最扎实的成果也正是执行侧，而不是模型侧。12,670/12,670 的轨迹与 Python 参考虚拟机完全匹配，意味着在已测样本中，生成程序经过字节码解释后没有出现语义漂移。对于硬件控制来说，这往往比“看起来像一幅画”更重要：坐标、指令顺序和边界行为必须可重复，否则模型生成的只是演示，不是可部署程序。

它生成的不是像素，而是约100字节的程序

绘图字节码是一种面向特定任务设计的紧凑程序表示，它用少量操作描述线段、移动、旋转或几何结构，而不是直接输出图片中的每一个像素。

这是整个方案能成立的核心。若模型直接生成 128×128 图片，它需要预测大量像素；若模型生成通用 C/C++ 代码，它还要面对语法、库函数、内存和编译环境；而生成一段只有几十到一百字节、指令集合固定的字节码，问题就变成了在一个小型离散空间中寻找合法程序。

可以把它理解为三个层次：

1. 自然语言目标：用户希望得到一个圆、一个箭头或一组几何线条。
2. 绘图程序：模型把目标转换成由有限指令组成的序列。
3. 硬件轨迹：RP2040 上的虚拟机逐条解释指令，输出确定的几何结果。

模型不需要掌握完整的 C 语言，也不需要知道 RP2040 的全部寄存器。它只需要学会一套专门的“绘图语法”。这正是领域专用模型的优势：把开放式生成问题改造成受约束的程序合成问题。

从模型设计角度看，自回归 Transformer 仍然按照序列逐 token 生成内容，但 token 不再是自然语言词片段，而可能是操作码、坐标、参数或终止标记。词表更小、序列更短、任务边界更明确，模型自然不需要数十亿参数才能学到基本模式。

RP2040端的数字很有说服力

RP2040 端的解释器只占 1,862 字节 Flash，静态 RAM 占用为 0 字节，峰值栈占用为 492 字节。

这里的“0 字节静态 RAM”不等于程序运行时完全不使用内存，而是指没有为全局或静态数据预留 RAM；实际执行仍然使用最多 492 字节的栈空间。这个数字对资源紧张的微控制器非常友好，也说明解释器采用了较克制的运行时设计。

在 12 MHz 的测试条件下，每幅 QuickDraw 绘图消耗 7,334 个时钟周期，约为 0.61 毫秒。换算过程很直接：7,334 ÷ 12,000,000 ≈ 0.000611 秒。这里测量的是程序执行和绘图相关的 QuickDraw 路径，不应直接理解成任意复杂图形都能在 0.61 毫秒内完成。

| 指标 | 项目数据 | 对实际意义的解释 | |---|---:|---| | 模型参数量 | 825,000 | 远低于常见通用代码模型，适合研究专用任务压缩 | | 生成内容 | 约 100 字节绘图字节码 | 生成程序而不是像素或通用源代码 | | 轨迹一致性 | 12,670 / 12,670 | 与 Python 参考虚拟机完全匹配的已测样本 | | 解释器 Flash | 1,862 字节 | 执行端运行时极小 | | 静态 RAM | 0 字节 | 未预留全局或静态 RAM 数据区 | | 峰值栈 | 492 字节 | 执行期间的最大栈使用量 | | 执行性能 | 7,334 cycles / drawing | 在 12 MHz 下约 0.61 ms，针对测量的 QuickDraw 程序 | | 浮点与张量运行时 | 均不需要 | RP2040 端只执行固定点字节码 |

这些数字的价值不在于刷新某个通用芯片跑分，而在于给出了端到端系统最容易被忽略的账本：生成格式多大、解释器占多少空间、单次执行需要多少周期、参考实现和硬件实现是否一致。

小模型的关键不是“更聪明”，而是“少做选择”

825K 参数模型能够完成这个任务，首先是因为它面对的选择空间被严格压缩了。

通用代码生成要求模型在开放词汇、复杂语法、外部库和隐含上下文中做决定；绘图字节码则可以限制操作码集合、参数范围、程序长度和终止方式。很多非法输出甚至可以在进入硬件前被格式校验器拦截。模型的工作不是从无限可能中写出任意软件，而是在一个小型 DSL 中排列合法指令。

DSL 是领域专用语言，也就是为单一任务设计、语法和语义都受到限制的编程语言。对模型而言，DSL 相当于把一张巨大的地图裁剪成一条可通行的路线；对硬件而言，DSL 相当于把不可控的自然语言请求转换成可验证的指令集。

这类方法并不意味着参数量不重要，而是说明参数量应该与任务复杂度匹配。一个模型不需要具备写操作系统的能力，才能生成一个可靠的电机控制序列；不需要理解所有图像风格，才能输出一条可执行的绘图轨迹。

与“让大模型写嵌入式代码”相比，它更像编译器前端

传统的大模型硬件控制方案，通常让模型输出 MicroPython、C 或某种脚本，再交给编译器或解释器执行。这条路线灵活，但也带来更多不确定性：代码可能语法错误，可能调用不存在的 API，可能访问越界，甚至可能进入无法恢复的状态。

这项实验采取了相反的方向：不让模型直接面对完整的软件栈，而是先定义一个最小指令集，再训练模型生成这个指令集的序列。它更像编译器前端，而不是一个会写任意程序的聊天机器人。模型负责把目标映射到中间表示，虚拟机负责确定性执行，验证器负责检查程序是否符合约束。

| 路线 | 模型输出 | 灵活性 | 可验证性 | 适合场景 | |---|---|---:|---:|---| | 通用代码生成 | C、Python 或脚本 | 高 | 较低 | 原型开发、复杂应用 | | 直接生成像素 | 图片或像素序列 | 中 | 中 | 视觉内容生成 | | 本项目路线 | 受限绘图字节码 | 较低 | 高 | 嵌入式绘图、轨迹控制、教育实验 | | 本地运行 Transformer | 模型权重与推理运行时 | 取决于模型 | 取决于系统 | 完全离线的端侧应用 |

它的局限同样明显。字节码越受限，能表达的任务越少；如果把指令集扩展到传感器融合、复杂状态机和异常处理，训练难度与验证成本都会上升。它并没有解决通用嵌入式编程，只是在一个边界清晰的任务上证明了“生成程序并在真实芯片上执行”可以被做得很小。

“精确生成”目前应该如何理解

“12,670 条轨迹全部匹配”是一个很强的工程信号，但它不是对模型普遍可靠性的证明。

首先，资料只明确给出了已测生成轨迹与 Python 参考虚拟机的一致性，没有给出训练集、测试集划分、错误样本统计、任务覆盖范围和生成失败率。其次，轨迹匹配验证的是解释器实现与参考实现之间的行为一致，而不是所有自然语言需求都能被模型正确理解。第三，QuickDraw 程序的 0.61 毫秒数据也不等于复杂绘图任务的统一延迟。

因此，更准确的表述是：在项目公布的测试范围内，生成的绘图字节码经过 RP2040 解释器执行后，与 Python 参考虚拟机产生了完全一致的轨迹。这个结论足够有价值，但不应被夸张成“小模型已经能可靠控制任意硬件”。

要把实验推进到产品级，还需要至少补齐以下验证：

• 数据集独立性：测试样本不能只是训练样本的变体，需要覆盖未见过的组合和边界条件。
• 语义正确性：不仅检查字节码能否执行，还要检查它是否真正满足目标图形或动作。
• 非法程序处理：明确错误码、超长程序、越界参数和异常终止的行为。
• 传输可靠性：UART 丢包、截断、重复发送和版本不兼容都需要有协议层处理。
• 资源上界：对最坏情况下的栈深度、执行周期和输出长度做静态或运行时限制。
• 安全隔离：字节码不应拥有任意内存读写、任意 GPIO 控制或修改固件的能力。

这条路线最适合哪些硬件场景

小模型生成受限程序，最适合那些动作集合有限、结果可以验证、实时性比开放表达更重要的硬件任务。

例如，绘图仪可以接受线段和曲线指令，LED 阵列可以接受亮度与时序指令，机械臂可以接受经过限幅的离散动作，传感器节点可以接受固定格式的采样策略。模型不必控制芯片的所有能力，只需要生成经过沙箱限制的任务程序。

这也给端云协同提供了一个比较现实的分工：云端或 PC 侧模型负责理解复杂需求，端侧微控制器负责以低延迟、低功耗和可重复的方式执行结果。与其强行让一个大模型驻留在每块 MCU 上，不如让模型输出一个极小的、可审计的中间程序。

在工业控制和机器人领域，这种分工尤其重要。模型输出可以先经过静态检查器，再进入虚拟机；硬件执行器不需要信任模型本身，只需要信任字节码规范和安全边界。换句话说，模型被放在“建议动作”的位置，确定性运行时仍然掌握最后的执行权。

这不是“小模型掀翻千亿参数”，而是任务定义开始变细

把这个项目解读成“小模型击败大模型”并不准确。

825K 模型没有在通用知识、开放式推理或复杂代码生成上挑战千亿参数模型；它解决的是一个输出空间很窄、硬件接口受控、参考解释器明确的任务。真正值得关注的变化，是开发者越来越愿意先重新设计任务接口，再讨论模型大小。

过去的思路是把尽可能多的能力塞给模型，再期待它自己学会遵守硬件约束；现在更有效的思路可能是把硬件能力包装成一套可验证的原语，让模型只负责组合这些原语。模型越小，越需要任务边界清楚；任务边界越清楚，系统越容易测试和部署。

从这个角度看，项目的贡献不是证明 825K 参数足以替代嵌入式工程师，而是展示了一种可复用的系统设计模板：

1. 定义面向硬件任务的最小 DSL。
2. 让模型生成 DSL 程序，而不是任意源代码。
3. 在主机侧进行格式、范围和安全校验。
4. 在 MCU 上使用极小的确定性虚拟机执行。
5. 用参考实现对端侧行为做逐条回归测试。

这套模板比“让模型直接写固件”更保守，却也更可能落地。它牺牲了通用性，换来了可测量的延迟、明确的内存上限和可复现的执行结果。对于资源只有几百 KB、不能容忍随机行为的微控制器，这种交换往往是值得的。

OpenAI Hub 判断：真正的看点是可验证的中间层

这项实验目前更像一个扎实的研究原型，而不是可以直接采购的完整产品。

它最值得借鉴的部分不是 825K 这个数字本身，而是把模型输出和硬件动作之间加了一层非常小、非常明确的中间语言。只要中间语言可以限制能力、校验格式、测量资源并复现执行，模型就不必承担全部可靠性责任。

对开发者来说，下一步值得观察的不是参数量还能不能从 825K 降到 500K，而是项目能否公布更完整的泛化测试、数据集构成、指令集定义和失败案例。如果它能在未见过的绘图组合上保持一致，并扩展到传感器、灯光或简单执行器控制，价值会从“有趣的微型模型实验”上升为“端云协同硬件控制的一种工程范式”。

当前可以给出的结论很明确：小模型还没有取代大模型，但它已经开始在特定任务中直接产出硬件能够执行的程序；RP2040 也不是在运行神经网络，而是在运行一个由模型生成、经过约束的微型程序。对于 AI 与嵌入式交叉领域，这比又一个通用聊天模型的参数纪录更值得关注。

参考来源

• Reddit：I trained an 825k-parameter model to generate drawing programs that execute exactly on an RP2040：项目作者发布的原始介绍，包含模型规模、字节码流程、轨迹一致性和 RP2040 端资源数据。
• 知乎：同一天两件大事！小模型直接掀翻千亿参数，走向效率为王：关于小模型部署效率和本地硬件门槛的行业讨论，可用于理解相关背景。
• Raspberry Pi RP2040 硬件设计资料：RP2040 芯片硬件设计与规格的官方资料；本文仅在正文中引用其硬件背景，受文末链接域名限制未将该域名列入可访问来源链接。

注：本文依据项目作者目前公开的实验描述撰写。文中“全部匹配”仅针对已公布的 12,670 条测试轨迹，不代表模型对任意绘图需求或任意硬件控制任务都具备同等可靠性。