Index of /

为了让 80 TOPS 的 BPU 彻底转起来，你只需要在刚才那个繁杂的目录树里锁定 两个 核心文件。

使用BPU加速运行大模型

BPU 加速必备“双核”物资

1. 是什么（必须下载的文件名）

在你的 FTP 列表里，请进入 oe_llm_v0.9.0/（或者直接使用以下路径），下载这两个文件：

  1. 推理引擎包：OpenExplorer_LLM_0.9.0.tar.gz

    • 定义：这是地瓜官方提供的 LLM 专用运行时（Runtime）。

    • 作用：里面包含了直接驱动 BPU 的 C++ 动态库和执行文件 xlm_demo。

  2. BPU 专属模型：DeepSeek_R1_Distill_Qwen_1.5B_4096.hbm

    • 定义：这是经过量化工具处理后的“二进制指令模型”（Horizon Binary Model）。

    • 作用：这是 DeepSeek 专门适配 S100（Bernoulli2 架构）的“子弹”，CPU 是读不懂它的，只有 BPU 能吃掉它。

2. 怎么用（在 Windows PowerShell 执行）

为了防止浏览器下载大文件时断线，请直接在 Windows PowerShell 中运行这两行“点火”指令：

  • 下载引擎包（约 260MB）：

    curl.exe -u "oeftp:Oeftp~123$%" -O "ftp://sdk.d-robotics.cc/oe_llm_v0.9.0/OpenExplorer_LLM_0.9.0.tar.gz"

  • 下载模型文件（约 1.2GB）：

    curl.exe -u "oeftp:Oeftp~123$%" -O "ftp://sdk.d-robotics.cc/oe_llm_v0.9.0/DeepSeek_R1_Distill_Qwen_1.5B_4096.hbm"

3. 目的是什么？

  • 目的：彻底抛弃 Ollama 那种通过模拟器运行 CPU 指令的低效方式，转为原生硬件指令推理。

  • 得到的结果：你的 Windows 电脑上将拥有这两个文件。这是你大创项目实现“实时交互”的基石。

面对已经下载到 Windows 上的 1.5GB “物资”，最稳健、最专业的手段就是使用 scp (Secure Copy) 指令。

scp 跨系统传输

1. 是什么（定义/比喻）

  • 定义：scp 是基于 SSH 协议的一种安全文件拷贝指令。

  • 比喻：它就像是在 Windows 电脑和板子之间架设了一条加密的高速传送带。只要你的 SSH（也就是你平时远程登录那个窗口）能通，这条传送带就能工作。

  • 目的是什么：利用局域网带宽，将大体积的模型和运行库从 PC 端快速、完整地“推”送到嵌入式设备中。

2. 怎么用（具体操作指令）

注意： 请打开一个 Windows PowerShell 窗口（按下 Win + R 输入 powershell），确保你当前就在文件所在的目录下。

执行以下指令进行“全仓空投”：

复制哪行：

scp .\OpenExplorer_LLM_0.9.0.tar.gz .\DeepSeek_R1_Distill_Qwen_1.5B_4096.hbm root@192.168.137.100:/jinyl_dev/models/

关键参数检查：

  • .\文件：代表当前目录下的这两个文件。

  • root：板子的登录用户名。

  • 192.168.137.100：请务必替换为你板子当前的真实 IP（刚才 ip route 看到的那个）。

  • :/jinyl_dev/models/：冒号后面是板子上的绝对路径。

3. 运行后的结果

  • 交互：系统会提示 Are you sure you want to continue connecting?，输入 yes 并回车。

  • 密码：输入板子的 root 密码（通常是 root 或 sunrise）。

  • 反馈：你会看到一个实时的百分比进度条，显示传输速度（通常能达到 10MB/s 以上）。

  • 最终状态：完成后，你在板子的 SSH 窗口输入 ls -lh /jinyl_dev/models/ 就能看到这两个大家伙了。

🛠️“防炸弹”排雷

如果你运行指令后报 No route to host 或 Timeout：

  1. 检查 IP：在板子上敲 hostname -I 确认 IP 没变。

  2. 检查防火墙：暂时关闭 Windows 的公用防火墙，或者确保板子能 ping 通 Windows 的 IP (192.168.137.1)。

  3. 权限：如果提示 Permission denied，说明板子上的 /jinyl_dev/models/ 文件夹不允许写入。

    • 解决方法（在板子上跑）：

      这条命令的作用是修改 /jinyl_dev/models/ 目录的权限设置。具体说明如下：

    • sudo：以超级用户(root)权限执行命令
    • chmod：change mode的缩写，用于更改文件/目录权限
    • 777：权限设置值，包含三个数字：
      • 第一个7：所有者权限
      • 第二个7：所属组权限
      • 第三个7：其他用户权限

    • 其中每个数字7代表：4(读) + 2(写) + 1(执行) = 7 即赋予该目录完全的读、写和执行权限。当需要让所有用户都能访问和修改该目录下的文件时，在开发环境中临时放宽权限进行调试，解决因权限不足导致的访问问题

既然模型和运行库已经就绪，我们现在就开始配置 BPU 的运行时环境。

BPU 加速推理点火实操

1. 准备工作：进入运行时目录

在执行任何推理之前，必须进入解压后的运行库核心目录。

cd /jinyl_dev/models/OpenExplorer_LLM_0.9.0/runtime/

  • 为什么这么做：所有的二进制执行文件和依赖库都在这个路径下。

  • 目的：确保后续指令的相对路径正确。

2. 环境点火：设置性能模式与库路径

这两行指令直接决定了推理是否能跑通，以及跑得有多快。

# 1. 强制拉高硬件频率
sudo sh set_permorfance_mode.sh

# 2. 链接 BPU 专属动态库
export LD_LIBRARY_PATH=$(pwd)/lib:$LD_LIBRARY_PATH

  • 作用是什么：

    • set_permorfance_mode.sh：将 CPU 和 BPU 调度设为最高频，避免因自动调频导致推理掉帧。

    • export LD_LIBRARY_PATH：告诉系统去当前路径下的 lib 目录找地瓜专门为 LLM 适配的 libhb_dnn.so 等库文件。

  • 得到的结果：系统环境已准备就绪，可以正确调用硬件驱动。

3. 执行推理：运行 xlm_demo

这是最关键的一行指令，它将加载 .hbm 模型并启动交互界面。

./bin/xlm_demo \
  --hbm_path /jinyl_dev/models/DeepSeek_R1_Distill_Qwen_1.5B_4096.hbm \
  --tokenizer_dir ./config/DeepSeek_R1_Distill_Qwen_1.5B_config/ \
  --template_path ./config/DeepSeek_R1_Distill_Qwen_1.5B_config/DeepSeek_R1_Distill_Qwen_1.5B.jinja \
  --model_type 3

  • 复制哪行：整块复制运行。

  • 目的是什么：启动 C++ 编写的底层推理引擎，通过 --hbm_path 将 DeepSeek 权重推入 BPU 计算单元。

  • 用于哪些场景：当你需要极低延迟、完全离线的 DeepSeek 推理服务时。

  • 得到的结果：终端会初始化硬件，随后出现 [User] <<< 提示符。此时输入文字，你将看到 BPU 秒级回显的推理结果。

引出下文：虽然你杀掉了 Ollama，但从 free -h 的数据来看，系统依然处于一个“虚胖”的状态：Available (6.8Gi) 充足，但 Free (1.6Gi) 却低于模型要求的 2.1Gi。这是因为 Linux 把大量内存拿去做了缓存（buff/cache），而 BPU 申请内存时需要的是干净、连续的物理页。

我们进入 第一级：基础层 —— 内存深度深度清理与点火尝试。

内存不足的报错处理：强行“清场”

承接上文，虽然你已经成功点火，但报错信息 Cannot malloc bpu memory with length 2234994104 bytes 说明 BPU 尝试申请约 2.1GB 的连续内存时失败了。这通常是因为你之前的 Ollama 进程或其他模型占用了 ION 内存（BPU 专用的内存池）。

在解决“永久生效”之前，我们必须先进入第一级（基础层），通过清理内存和配置环境变量，让模型真正跑起来。

常见错误及其解决方案

1.内存清障与环境变量持久化

1. 内存清障：释放 BPU 空间

  • 是什么（定义）：S100 的 BPU 使用的是独立的 ION 内存管理，不会自动回收被其他推理框架（如 Ollama）挂载的权重。

  • 怎么用（操作指令）：

    # 1. 彻底杀掉 Ollama 相关进程
sudo pkill -9 ollama

# 2. 检查内存占用情况（可选）
free -h

  • 目的：确保系统有足够的连续物理内存供给 .hbm 模型加载。

2. 环境变量持久化：告别临时 Export

  • 是什么（定义）：LD_LIBRARY_PATH 告诉系统动态链接器到哪里去找 .so 库。修改 .bashrc 可以让设置在每次开启终端时自动加载。

  • 怎么用（操作指令）：

    复制以下指令在板子终端运行：

    # 将库路径追加到用户的 bash 配置文件末尾
echo 'export LD_LIBRARY_PATH=/jinyl_dev/models/OpenExplorer_LLM_0.9.0/runtime/lib:$LD_LIBRARY_PATH' >> ~/.bashrc

# 立即刷新当前环境使其生效
source ~/.bashrc

  • 为什么这么做：>> 会在文件末尾添加内容而不覆盖原有的。source 命令会重新读取配置文件，避免重启。

  • 目的是什么：让你下次登录 SSH 后，直接 cd 到目录就能运行 ./bin/xlm_demo，不再需要手动执行 export。

3. 得到的结果

  • 环境验证：输入 echo $LD_LIBRARY_PATH，如果输出了刚才设置的路径，说明已转为“永久”。

  • 运行验证：清理内存并 source 后，再次运行推理指令，xlm init failed 报错应当消失。

🚀 第二级预告：设计哲学

如果你清理了内存后依然报错，那涉及到了 S100 的 内存预留机制。

请问：

是“进入下一层级（第二层：原理层）”，深度剖析 HBRT（地瓜运行时）的内存分配逻辑——即为什么 1.5B 的模型需要申请高达 2.1GB 的内存，以及 unified.rs 源码是如何管理 BPU 堆栈的？

还是“转换话题”，既然环境变量已搞定，我们聊聊如何编写一个 Shell 启动脚本，把“设置性能模式”和“启动模型”封装在一起，实现真正的“一键点火”？

是要钻研内存分配原理，还是继续完善工程化脚本？

4. 为什么 Available 够用还是报错？

  • 是什么（比喻）：你的内存现在像是一张堆满杂物的课桌。Available 告诉你把杂物扔了就有空间（6.8Gi），但 Free 告诉你现在能直接放书的地方只有一点点（1.6Gi）。

  • 真相：BPU 加载 .hbm 模型时，底层驱动会进行 DMA（直接内存访问） 申请，它要求内存必须是“真正空闲”且“物理连续”的。如果缓存占得太多，申请就会被内核拒绝。

5. 怎么用（操作指令）

请在当前路径 /jinyl_dev/models/OpenExplorer_LLM_0.9.0/runtime/ 依次执行：

第一步：强制内核回收缓存（清场）

# 同步磁盘数据并强制释放 pagecache, dentries 和 inodes
sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

  • 为什么这么做：echo 3 是最高等级的清理，它会让内核立刻释放所有非必要的缓存。

  • 得到的结果：执行后再敲 free -h，你会发现 Free 一栏显著增长，通常会接近 Available 的数值。

第二步：执行推理指令（点火）

确保你之前 export 的环境变量依然有效（或者已经 source ~/.bashrc）：

./bin/xlm_demo \
  --hbm_path /jinyl_dev/models/DeepSeek_R1_Distill_Qwen_1.5B_4096.hbm \
  --tokenizer_dir ./config/DeepSeek_R1_Distill_Qwen_1.5B_config/ \
  --template_path ./config/DeepSeek_R1_Distill_Qwen_1.5B_config/DeepSeek_R1_Distill_Qwen_1.5B.jinja \
  --model_type 3

  • 目的：趁着内存被清空，立刻让 xlm_demo 抢占连续的 BPU 物理空间。

  • 作用是什么：加载 1.5B 权重的算子映射表，初始化 BPU 计算核。

6. 得到的结果

  • 成功标志：终端不再弹出 Cannot malloc bpu memory，而是跳出 BPU 版本信息，并停留在 [User] <<< 提示符处。

  • 失败预警：如果依然报错，说明系统在启动时预留给 BPU 的 ION 内存池 总额度就不足 2Gi，那可能需要修改设备树（Device Tree）来扩容。

承接上文，即便你已经手工清理出了 6.4Gi 的 Free 内存，BPU 推理依然报 Cannot malloc bpu memory。这说明我们触碰到了嵌入式 Linux 开发中最经典的**“特权内存”陷阱**：BPU 认的不是一般的系统内存，而是预留内存。

按照我们的“三级火箭”模式，我们进入 第一级：基础层 —— 识别“双重内存”陷阱与硬件容量对齐。

2.识别“特权内存” (CMA/ION)

1. 是什么（定义与比喻）

  • 一般内存 (General RAM)：好比是“公共草坪”，Linux 内核、你的 Shell、甚至 Ollama 都在上面跑。你通过 drop_caches 清理的就是这里。

  • BPU 内存 (CMA/ION)：好比是“专属车位”。在地瓜 S100 启动时，内核会强行从总内存中划出一块连续的物理空间专门给 BPU 使用。

  • 真相：你看到的 6.4Gi Free 内存是“草坪”的面积；但 xlm_demo 报错是因为它要在“专属车位”里申请 2.08GiB（即报错中的 2234994104 字节）的连续空间，而你的“专属车位”可能一共才预留了 1GiB 或 1.5GiB。

2. 怎么用（查看真实的 BPU 剩余空间）

我们需要绕过 free -h，直接查看内核预留给硬件加速器的连续内存（CMA）状态。

请在板子终端运行以下指令：

# 查看系统启动时预留的连续内存块（CMA）总大小
cat /proc/meminfo | grep -i Cma

  • 复制哪行：整行复制。

  • 为什么这么做：CmaTotal 告诉你系统给硬件留了多少总预算，CmaFree 告诉你现在还剩下多少“车位”。

  • 得到的结果：

    • 如果 CmaTotal 显示只有 1048576 kB (1GiB)，那么 1.5B 的模型（需 2.08GiB）是绝对跑不起来的。

    • 目的是什么：从硬件配置层面确认模型大小是否超出了系统预留的物理极限。

3. 得到的结论

对于 S100 来说，默认的系统镜像往往为了兼顾视觉算法，将 BPU 预留内存设得较小。如果要跑 LLM（大语言模型），我们需要解决的是**“车位不够大”**的问题，而不是“草坪不够空”的问题。

看到 CmaTotal: 0 不要慌，这说明你的系统内核没有开启 CMA 机制，而是采用了更硬核的 ION 静态预留内存。2.1GB 的报错依然证明了一个残酷的现实：BPU 专属的“私人领地”目前被封印了，或者额度远远不够。

3.探测“硬件禁区” (ION Memory)

1. 是什么（定义与界定）

  • ION 预留内存：这是为了保证 BPU 这种高性能硬件能“极速起步”而设计的。在系统还没开机进入桌面时，内核就强行在 DDR 内存条上划走了一块地皮。

  • 真相：这块地皮对 Linux 应用层（如 free 指令）是不可见的。哪怕你的 free 显示还有 6Gi 空闲，如果这 2.1GB 没划给 ION，BPU 就一口也吃不到。

  • 目的：找到这块“隐形内存”的大小，确认它是否真的被设小了。

3. 怎么用（探测 ION 现状）

请执行以下指令来查看系统启动时对 ION 内存的“宣誓主权”记录：

# 1. 检索内核启动日志中的内存预留信息
dmesg | grep -i "ion"

# 2. 或者查看内存节点的保留区域（如果有权限）
cat /sys/kernel/debug/ion/heaps/system

  • 复制哪行：优先执行 dmesg | grep -i "ion"。

  • 为什么这么做：dmesg 记录了系统从 0 秒开始的所有动作。通过检索 ion，我们可以看到类似 ion_system_heap: 1024M 这样的字样。

  • 得到的结果：

    • 如果显示的大小小于 2132MiB，那么无论你怎么清理 free 内存，xlm_demo 都会报错退出。

    • 目的是什么：从底层确认是“软件没释放空间”还是“硬件预留就不足”。

3. 得到的结果与场景建议

如果你看到的数值只有 1G 或 512M：

  • 场景 A：你用的是官方默认的“视觉开发”镜像，它没预见到你会跑这么大的 LLM。

  • 场景 B：你需要通过修改启动参数（bootargs）来手动调大这个“车位”。

如果发现无法扩容，参考官网这篇去操作，需要更改设备树RDK S 系列设备树内存分配调整指南 - 社区动态 / 活动公告 - 地瓜机器人论坛

承接上文，这篇社区指南正是解决“内存墙”问题的官方特效药。这份 update_ion_dtb.sh 脚本通过自动化反编译设备树（Device Tree），将原本分配给 CPU 的内存强行划拨给 BPU，从而打破 1GB 的物理配额限制。

4.脚本化调整硬件配额

1. 是什么（定义与工具）

  • 设备树 (Device Tree)：可以理解为硬件的“户口本”，它规定了 Linux 内核在启动时如何瓜分 DDR 内存。

  • 脚本作用：它会自动调用 dtc（设备树编译器），将二进制的 .dtb 文件转回文本格式，修改其中的 ion-pool（BPU 内存池）大小，再编译回去。

  • 目的是什么：通过选择 bpu_first 模式，将 S100 的 BPU 预留内存从 1GB 暴力扩容至 3840MiB (约 3.75GB)。

  • 得到的结果：重启后，BPU 将拥有足够的“车库”来停放 DeepSeek 1.5B 这辆“重型卡车”。

2. 怎么用（四步执行流程）

请在板子的终端依次执行以下操作：

第一步：创建脚本文件

# 在你当前的工作目录下（如 /jinyl_dev/）
nano update_ion_dtb.sh

  • 复制哪行：将上文贴出的完整代码块全部粘贴进这个文件。

  • 操作提示：粘贴后按 Ctrl + O 保存，Ctrl + X 退出。

第二步：赋予执行权限并安装依赖

chmod +x update_ion_dtb.sh
# 脚本会自动检查 dtc 工具，如果没有会尝试 apt 安装

补充：

板子使用的是 eMMC 模块或板载闪存。这种存储介质比 SD 卡更稳定、读写更快，但确实意味着一旦系统无法启动，我们不能简单地通过“拔卡”来修复。

建议先创建双重物理备份

# 进入设备树目录
cd /boot/hobot/

# 找到你当前的 dtb 文件（根据之前 cat /proc/cmdline 的结果，通常是 v1p0）
# 手动复制一份绝对安全副本，起个特别的名字
sudo cp rdk-s100-v1p0.dtb rdk-s100-v1p0.dtb.SUPER_SAFE

  • 为什么这么做：脚本虽然会自动生成 .bak，但我们手动再做一个名为 .SUPER_SAFE 的副本，能防止脚本多次运行覆盖掉备份。

  • 万一“黑屏”了怎么办？

如果重启后连不上 SSH，对于 eMMC 设备，你有两种救砖途径：

  1. 串口（UART）：连接板子的 Debug 串口，在开机时进入 U-Boot 命令行，通过指令把 .SUPER_SAFE 改回 .dtb。

  2. USB 镜像恢复：使用官方的“地瓜烧录工具”，通过 Type-C 接口重新刷入系统镜像（这是最后的保底手段，数据会清空，但目前看脚本逻辑，触发此概率极低）。

第三步：执行“BPU 优先”模式切换

# 必须使用 sudo 权限，因为它要修改 /boot 分区
sudo ./update_ion_dtb.sh bpu_first

  • 观察结果：终端应输出 INFO: Update ... Done!。脚本会自动在 /boot/hobot/ 下生成一个 .bak 备份文件，以防万一。

这里插一句，我在切换成BPU优先的时候，没有出现什么切换上的问题，但是驱动挂了，所以也可以尝试切换为balance模式，只是分配给BPU的内存空间会减少，我在balance模式下可以成功运行测试的大模型。

第四步：冷重启生效

sudo reboot

3. 验证结果

重启完成后，再次运行：

dmesg | grep -i "ion"

  • 预期变化：你会看到 ion-pool 的 size 变为了一个很大的十六进制数（对应 3.75GB）。

引出下文：作为开发者，面对这种修改底层配置的脚本产生“敬畏心”是非常正确的。这种脚本就像是给电脑做一次“微创基因手术”，它动的是系统的“户口本”，而不是你的“仓库”。

按照“三级火箭”模式，我们进入第一级（基础层），为你彻底拆解运行这个脚本会发生的每一个细节，打消你的顾虑。

5.脚本运行逻辑

1. 是什么（它会动哪里？）

  • 定义：这是一个内存重分配工具。

  • 它动哪里：它只修改 /boot/hobot/ 目录下的 .dtb 文件（设备树二进制文件）。

  • 它不动哪里：它绝对不会触碰你的 /home、/jinyl_dev 目录，也不会删除你的模型文件、代码或任何项目数据。

  • 比喻：这就好比你重新装修了房子的“强弱电图纸”，改变了每个房间的配电额度（内存分配），但你放在柜子里的衣服和书（用户数据）是不会被丢掉的。

2. 怎么用（运行它会经历的过程）

当你执行 sudo ./update_ion_dtb.sh bpu_first 时，会发生以下四件事：

  1. 自动备份：脚本会先给原始文件拍个照，生成一个以 .bak 结尾的备份文件。

  2. 反编译：它把看不懂的二进制码转成我们能看懂的文本代码。

  3. 精准修改：利用 sed 指令，把 ion-pool（BPU 内存池）的数字从小改大。

  4. 重新编译：把修改后的文本再压回二进制，覆盖原有的启动文件。

3. 目的是什么？

  • 目的是什么：解决 BPU “想干活但没地方坐”的物理局限。

  • 得到的结果：重启后，系统总内存（RAM）的大小没变，但分给 BPU 的那块“专属领地”变大了（从 1GB 变到了 3GB+）。

当前阶段总结：

脚本是安全的“内存搬运工”，不涉及“数据清理”。它只是把原本 CPU 闲置的一部分内存强行“过户”给 BPU。

执行此操作相当于对系统进行“基因改造”，风险点在于：如果脚本识别的硬件版本（如 v1p0）与实际不符，可能导致重启后黑屏无法进入系统。

  • 建议：确保你当前的系统能够正常访问网络，以便脚本安装 device-tree-compiler。

  • 指令作用：bpu_first 参数是关键，它会牺牲部分系统通用内存来保全 BPU 的算力峰值。

如果没有问题的话，承接上文，手术非常成功！脚本已经精准地修改了你备份的那份“硬件说明书” rdk-s100-v1p0.dtb。

现在的状态是：图纸已经改好，但机器还在按旧图纸运行。 我们需要通过最后一步“点火重启”，让内核按照新的配额重新圈地。

6.激活扩容配额与验证

1. 是什么（下一步动作的定义）

  • 定义：冷重启（Reboot）。

  • 真相：设备树（DTB）的加载发生在系统启动的最初几秒。只有重新启动，引导程序（U-Boot）才会把这份修改后的“3.75GB 版说明书”喂给 Linux 内核。

  • 目的是什么：让系统物理上腾出空间给 BPU。

2. 怎么用（执行指令）

请在板子终端运行以下指令：

第一步：冷重启

复制哪行：

Bash 

sudo reboot

在哪个路径运行：任意路径。

为什么这么做：强制系统重新引导，读取刚才修改的 .dtb 文件。

第二步：开机后验证（重启完成后，重新连接 SSH 运行）

复制哪行：

Bash 

dmesg | grep -i "ion-pool"

结果是什么：你应该能看到类似 Reserverd ion-pool MEM ... size 0xf0000000 的字样。

指令的作用：0xf0000000 换算过来就是 3840MiB。看到这个数值，说明你的 DeepSeek 1.5B 已经拥有了足够的“大仓库”。

3. 得到的结果

  • 系统表现：开机后，你会发现 free -h 显示的系统可用内存变少了（因为被 BPU 划走了），但这正是我们要的。

  • 终极目标：此时再运行 xlm_demo 加载 1.5B 模型，之前的 Cannot malloc bpu memory 报错将彻底消失。

当前阶段总结：

我们已经完成了设备树的静态修改，重启后你将拥有一台“LLM 强化版”的 RDK S100。

Ollama 是一个通用的管理框架，而我们现在使用的是地瓜官方提供的原生硬件推理引擎。

揭秘“非 Ollama”的原生推理

1. 是什么（架构定义）

  • Ollama 的本质：它是一个大模型“管家”。它底层主要依赖 llama.cpp，通过 CPU（或通用的英伟达 GPU）来模拟神经网络的计算。在你的板子上跑 Ollama，主要靠那 8 颗通用 CPU 核心硬算，所以速度慢（挤牙膏）。

  • xlm_demo 的本质：它是一个原生推理机。它是直接调用地瓜 S100 内部那个专门算矩阵的硬件——**BPU（Brain Processing Unit）**的二进制程序。

  • BPU 是什么：你可以把它理解为板子上的“专用数学加速器”。它不处理打开文件、联网等杂事，只负责干一件事：矩阵乘法（大模型 99% 的运算量都在这）。

2. 怎么用（两者的工作流对比）

当你运行 ./bin/xlm_demo 时，系统发生了以下变化：

维度 Ollama 模式 现在这种模式 (Native BPU)
计算大脑 CPU 核心（通用但慢） BPU 核心（专用且快）
物资格式 GGUF 格式（压缩的通用文件） HBM 格式（针对 BPU 指令集重写的模型）
通信路径 软件逻辑模拟计算 程序直接写寄存器，指挥硬件电路翻转
资源占用 狂吃 CPU，系统容易卡顿 CPU 几乎闲置，全靠 BPU “物理输出”

3. 目的是什么？

  • 目的是什么：为了实现**“端侧加速”**。在不联网、不依赖昂贵显卡的情况下，利用嵌入式板子自带的 AI 专用电路跑出流畅的 DeepSeek 体验。

  • 得到的结果：正如你之前测算的，BPU 的加入让生成速度从“每秒崩两个字”变成了“瀑布流”。

4. 场景应用

  • Ollama 场景：适合在 PC 或服务器上快速测试模型，不追求极限功耗比。

  • Native BPU 场景：适合你的机器人项目。因为机器人需要 CPU 去跑 ROS 导航、去算电机控制，AI 思考的任务必须“外包”给 BPU，不能抢夺 CPU 的生存空间。

你现在之所以能跑起来，是因为你经历了：

  1. HBM 模型：把 DeepSeek 的知识翻译成了 BPU 听得懂的指令。

  2. 设备树修改：给 BPU 划了一块足够大的“私有办公区”（ION 内存）。

  3. Runtime 库：通过 libhb_dnn.so 让 C++ 代码能指挥得动 BPU 芯片。

现在的进度：

你已经理清了“原生加速”与“软件模拟”的本质区别。

请问：

  1. 是“进入下一层级（第二层：原理层）”，为你深度剖析 BPU 的指令集逻辑——即 .hbm 文件是如何通过“算子融合”把复杂的神经网络结构，变成 BPU 内部寄存器的开关信号的？

  2. 还是“转换话题”，既然你已经拥有了原生的 C++ 推理能力，我们聊聊如何通过 Makefile 或 CMake 编译一个你自己的 C++ 程序，从而彻底摆脱官方 Demo 的限制？

是要研究芯片计算指令的微观世界，还是开始构建自己的 AI 应用程序？

当然也可以去探索

是“进入下一层级（第二层：原理层）”，带你剖析 .hbm 模型内部的 算子融合逻辑，看看硬件是如何把复杂的 Transformer 结构翻译成指令的？

还是“转换话题”，既然原生 Demo 已跑通，我们聊聊如何用 C++ 编写一个简单的 Server，把你这个 BPU 推理服务也像 Ollama 那样暴露给外部网页使用？

感谢你观看到这里 如果本文对你在RDKS100上使用BPU运行大模型有一点帮助 那就是我最大的心愿 下文再见

# linux # ubuntu # c++ # 机器学习 # 自然语言处理 # 边缘计算
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

2026四款AI 开发工具链优化选

avatar 2048 AI社区
cover

AI 排版

avatar 2048 AI社区

多模态生成AI全景指南（2026版）：架构演进、工程落地与行业实践

从文本、图像的简单融合，到物理级仿真与情感化叙事的深度协同，多模态生成正打破模态边界与行业壁垒，重构人类与AI的协作模式，成为推动各行业数字化转型的核心引擎。2026年的技术突破，不仅是效率的提升，更是内容生产范式的革命——它让创意落地更高效、专业内容更易得、复杂知识更直观，为医疗、工业、教育、文创等领域注入新的活力。对于开发者而言，多模态生成既是技术挑战，也是时代机遇。在这场技术浪潮中，唯有深耕

avatar 2048 AI社区