火爆全网的LLM在RT-ThreadOS中的应用探索

原创 RTThread物联网操作系统 2025-01-15 20:09

构建AI未来，Arm计算平台无处不在 如何增强电动汽车的实时控制能力？

2025年伊始，硅谷顶级风投A16z最近发表了一篇名为《2025 Big ldeas in Tech》的文章，通过对其50位合伙人进行了采访，得出了50个对科技趋势发展的判断，其中有22个方向与AI有关。

其中部分技术方向和更是与嵌入式AI紧密关联，其中包括:

1. 实时AI，应用开发的下一个重要方向；

2. AI将开始主导决策环节；

3. 端侧AI开始崛起；

4. AI将与所有的电子硬件融合；

这些方向清晰的表明了一个变化：即AI主导决策以及AI与电子硬件融合等技术的出现，必将导致嵌入式系统的应用和开发将会以一种全新的方式出现在所有开发者面前。

回想过去的一年，人工智能领域除了大模型，最火的词莫过于具身智能，这标志着AI正在从以思维价值为主导的人工智能转变为与物理世界交互为主导的人工智能体。此外，人工智能领域的标志企业Open AI在2024年末推出的o3模型，在数学、代码、软件工程等领域再一次取得了突破性的进展，其在代码领域的成绩已经跻身全球前200名。这意味着在不远的未来，以Chatgpt-o3为代表的新一代编程模型，将在众多的编程环境中取代当前人类的工作。在这样一个背景下，对于传统的嵌入式开发人员，我们也必须要与时俱进，深刻的认识到在大模型驱动嵌入式软件开发的新时代，软件任务逻辑和驱动分离的设计思想必将成为未来嵌入式系统开发的主流道路。

RT-Thread作为一款为人熟知的国产实时操作系统，在嵌入式领域一直是国产开源软件中旗帜性的存在。近年来，我们在嵌入式系统和AI结合的领域不断探索和尝试，希望能够找到一个切实符合嵌入式系统走的AI路线。借助2024年的开发者大会，RT-Thread AI针对LLM在RT-Thread OS中的应用探索，进行了详细讨论，希望能够给广大开发者以启发，下面是报告原文。

经过多年在嵌入式领域的深耕，RT-Thread OS在系统内核、组件以及软件包三个维度为广大开发者提供了数以千计的API，这些API在传统的嵌入式软件开发阶段有力的支持了应用开发过程，节约了大量的开发时间，缩短了开发周期，这也是RT-Thread OS一直长青的根本原因。但是进入到大模型驱动嵌入式软件开发时代，这些API又将会起到怎样的作用呢？我们继续向下看。

下面PPT左侧图片是经典的大模型应用场景，这个例子是将法语翻译为英语。那么我们也可以依次类比，如果我们想要RT-Thread OS听懂我们的人类的话，我们需要将人类的自然语言翻译成什么呢？很明显，在这个过程中，传统的API就变成了RT-Thread OS所认识的“词汇”了。如果我们能够将我们的自然语言翻译成一个个API，那么我们就可以通过对话的形式控制RT-Thread OS了。也就是说：对于RT-Thread OS来说，代码就是人和RT-Thread OS交流的语言，而API则是其中的“词汇”。也就是说如果LLM掌握了所有的RT-Thread API，那么也就可以搭建起人和RT-Thread OS沟通的桥梁。

基于这样的一个思想，我们可以想象，随着LLM在编程能力上不断超越人类代码能力，我们必须要掌握逻辑和驱动分离的程序设计思想。将逻辑部分交给LLM来实现，而仅提供软硬件结合的部分，即和真实世界结合的驱动部分。就像下面这张PPT中所显示的一样，对于传统的嵌入式软件开发。我们从需求分析、任务拆解到最后的软件驱动、软件逻辑全部都由开发者完成。这样整个程序按照程序员的设计固化在了硬件中，虽然程序可以准确执行，却丧失了软件的灵活性。如果我们将整个软件的逻辑部分全部交给LLM来在运行期完成，而仅仅提供控制硬件的驱动，那么整个软件的灵活性则会大大提高。但是如果想完成这样一个转变，一个重要的步骤就是需要让LLM知道，在现实的世界中，存在诸如rt_led_turnon这一类数以千计的RT-Thread API是真实存在的。

针对这一问题，RT-Thread AI团队是从以下两个方向入手来解决问题的。首先，我们整理了当前RT-Thread OS的大部分API，包括内核层、组件层以及软件包层面的，形成了非常庞大的知识库/训练集。然后我们针对当前开源LLM在嵌入式领域的应用，分析了开源模型的问题，其中内存占用和算力需求时制约嵌入式端应用LLM的最大瓶颈。我们发现，对于一般人类交流，一个话题大概仅需500个字左右，而一个正常人的语速也仅在150-200字每分钟，所以对于当前开源的大模型，其最大序列长度对于嵌入式都是十分浪费且不别要的。此外，我们也发现对于嵌入式场景，90%以上的嵌入式设备都是指令式的，即听从人类指挥完成相应任务，而不需要进行复杂而繁琐的对话。而不到10%的嵌入式设备才需要对话，而进对于这种设备，我们才需要较长的最大序列长度来保证上下文对话的连续性。

对于我们RT-Thread OS应用的绝大多数场景，我们更希望设计一种更适合嵌入式系统的LLM，即Embedded GPT，而这种GPT实际上更多（90%以上嵌入式场景）是指令式，而不是对话式的需求。我们在这一部分已经形成了两部分路线。一种是在开源模型基础上进行微调，同时通过RAG的方式来补足API的快速更新。但是这种方式存在模型推理幻觉、计算量内存占用过大等方面的缺陷。而在另一种路线，我们已经开发了一个新的更适合嵌入式系统的GPT，即Embedded GPT，这个系统参数规模约500M，max_position_embeddings为1024，该模型在综合的效果上，已经完全满足嵌入式系统需求中的绝大场景。我们擅长嵌入式API数据集的收集和整理，大模型公司在最前沿的模型架构和训练算力方面的有领先优势，我们非常期待在这个极其富有想象力的领域建立市场合作，创造共赢。

最后，我们基于软件任务逻辑和驱动分离的设计思想，在我们的语音小车上完成了几个从简单到复杂的指令控制，整个过程中，我们将小车控制的最基础API交给了大模型，让大模型知道在真实世界中，通过以下几个API就可以控制小车执行诸如“前进”、“后退”、“左转”、“右转”等指令。然后在运行期，我们通过对话的方式，指挥小车进行“顺时针旋转”、“开启雷达导航”等动作，最终实现小车控制的灵活性。这样的一种开发新范式，最终会从根本上改变嵌入式软件开发的模式，在减轻嵌入式软件开发工程师工作负担的同时，还极大的增加了软件控制的灵活性，将大模型的能力发挥到极致。