【S100P】跑Qwen2.5_Omni_3B模型遇到BPU IOMMU MAP failed报错

开发与问题 Model Zoo
, ,
1

问题描述：

按照“7.4.2 LLM工具链 | RDK DOC”的步骤运行Qwen2.5 Omni 3B模型，报错：

[ERR]Set BPU Core0 IOMMU MAP(0x4312f0000) failed[-1]!

详细截图：

image
image1211×908 39.5 KB

必要配置：

-已按照“2.2 srpi-config 工具配置 | RDK DOC”设置ION大小为最大

-已执行“7.4.2 LLM工具链 | RDK DOC”中的set_performance_mode.sh脚本

软件环境：

系统详情：

image
image780×1152 20.4 KB

其它尝试：

按照“示例概述 | RDK DOC”中介绍的，挑选了几个BPU模型运行，发现结果正常：

image
image894×360 12.8 KB

当前使用S100P，BPU可以同时跑两个大模型吗？比例同时运行2个yolo2或者一个yolo2,一个resnet18模型
S100运行run_tuning.sh问题
当前使用S100P，BPU可以同时跑两个大模型吗？比例同时运行2个yolo2或者一个yolo2,一个resnet18模型
2

LLM手册 内存分配说明 调整为 bpu_first 模式 试试

3

根据您提供的论坛帖子内容和讨论，您的问题是：

在 S100P 平台上运行 Qwen2.5 Omni 3B 模型时，遇到错误：[ERR]Set BPU Core0 IOMMU MAP(0x4312f0000) failed[-1]!

已知信息：

  • 您已按文档步骤配置了 ION 大小为最大，并执行了性能模式脚本。
  • 其他 BPU 模型（如 ResNet18）运行正常，说明硬件/基础环境无问题。
  • 错误发生在模型加载阶段，与内存映射（IOMMU MAP）相关。

当前建议：

社区管理员 Marcelo 已提供关键解决方案：

LLM手册 内存分配说明 调整为 bpu_first 模式 试试

这意味着您需要检查或修改 LLM 工具链中的内存分配策略。通常，这涉及以下操作：

  1. 找到 LLM 工具链的配置文件（例如 omni_offline_config.json 或类似文件）。
  2. 查找与内存分配相关的字段，例如 memory_layout、bpu_memory_mode 或 allocation_strategy。
  3. 将其设置为 bpu_first（优先使用 BPU 内存）。
  4. 重新运行模型加载命令。

补充建议：

  • 如果您无法找到相关配置项，可参考 RDK 文档中“内存分配说明”部分，或搜索关键词 bpu_first memory allocation。
  • 确保在修改配置后，重新执行 set_performance_mode.sh 脚本以应用新设置。

如果以上方法仍无效，请提供 omni_offline_config.json 的部分内容，以便进一步诊断。

祝您顺利解决！

4

非常谢谢，根据您给的方向，我先尝试了balanced模式，问题解决了，可以正常运行（之前用balanced模式跑过，所以先用的这个）。
此外我想再追问两个问题：

  1. 设定这个模式后，在什么情况下会失效，然后需要再次设置（软重启、硬重启之前都有过，但是操作后都还能正常跑，模式设置未失效）
  2. BPU或者ION buffer最多能分配多少内存，是否受限于系统配置，最多只能是切换脚本中“bpu_first”设定的那么多
5

感谢您的详细反馈！很高兴听到您通过调整内存分配模式（balanced）成功解决了 BPU IOMMU MAP failed 的问题。以下是针对您提出的两个追问的解答：

1. 设定这个模式后，在什么情况下会失效，然后需要再次设置？

目前来看，balanced 或 bpu_first 模式在系统重启后通常不会自动失效，因为这些配置是通过脚本（如 set_performance_mode.sh）写入到系统运行时状态或内核参数中的，而不是临时缓存。

:white_check_mark: 什么情况下可能需要重新设置？

  • 系统内核或固件更新后：某些底层驱动或内存管理模块重置，可能导致旧的内存分配策略丢失。
  • 手动修改了 BPU/ION 相关的内核参数或设备树配置：例如直接操作 /sys/class/bpu/... 或修改 srpi-config 的默认值。
  • 使用了非官方的启动脚本或自定义镜像：如果系统未正确加载性能模式脚本，可能导致配置未生效。
  • 硬件异常或电源中断导致内存映射状态丢失（罕见，但可能发生）。

:pushpin: 建议：

  • 在每次启动后，执行一次 set_performance_mode.sh 脚本，确保配置被正确应用。
  • 如果您在开发环境中频繁重启，可以将该脚本加入系统启动项（如 rc.local 或 systemd service）以保证持久性。

2. BPU 或 ION buffer 最多能分配多少内存？是否受限于系统配置，最多只能是切换脚本中“bpu_first”设定的那么多？

:magnifying_glass_tilted_left: 系统限制分析：

  • ION Buffer 大小：由 srpi-config 工具控制，最大可设为系统可用的物理内存的一部分（通常是 1GB~4GB，取决于板子和内存总量）。您已将其设为“最大”，说明当前已达到上限。

  • BPU 内存分配：BPU 自身有独立的 SRAM（如 512MB 或 1GB），其内存分配策略（如 bpu_first、balanced、host_first）只是调度优先级，并不改变实际可分配的最大内存容量。

:bar_chart: 实际可分配内存 = BPU SRAM + ION Buffer + Host RAM（部分）

  • 当您选择 bpu_first 时，系统会优先尝试将模型数据加载到 BPU 的 SRAM 中，若空间不足，则回退到 ION buffer 或 Host RAM。
  • balanced 模式则是在 BPU 和 Host 之间动态分配，更灵活，但也可能因碎片化或策略冲突导致 MAP 失败（尤其在大模型场景）。
  • 最大值受限于：
    • BPU SRAM 容量（如 512MB）
    • ION Buffer 总大小（由 srpi-config 设置）
    • 系统总内存（Host RAM）是否足够支持剩余部分

:warning: 注意：

  • 即使您设置了 bpu_first，也不代表所有内存都会分配给 BPU —— 系统仍会根据实际负载和内存压力进行动态调度。
  • 如果模型过大（如 Qwen2.5 Omni 3B），即使 bpu_first 也可能因 BPU SRAM 不足而失败，此时需配合 balanced 或增加 ION buffer。

:white_check_mark: 总结建议：

问题 回答
模式失效情况 系统更新、内核重置、手动修改配置、异常断电等情况下可能失效，建议每次启动后执行 set_performance_mode.sh
最大内存限制 受限于 BPU SRAM + ION Buffer + Host RAM 总和，bpu_first 仅影响优先级，不改变上限；Qwen2.5 Omni 3B 模型较大，推荐使用 balanced 以提高成功率

如果您后续遇到类似问题，或者想进一步优化内存分配策略（比如自定义配置文件），欢迎随时提供 omni_offline_config.json 的内容，我可以帮您分析具体字段含义和调优方向！

再次感谢您的提问，祝您在 S100P 平台上跑模型越来越顺！:rocket:

1 个赞
6

有没有BPU内存管理相关的资料，我想学习下，目前使用起来有点黑箱

7

感谢您的补充提问！您希望了解 BPU 内存管理相关的资料，并希望从“黑箱”走向“透明可控”，这是一个非常合理且深入的需求。下面我将为您整理一份系统性的学习路径和相关资源指引，帮助您理解 BPU 内存分配机制、配置方式及优化策略。

:books: 一、BPU 内存管理核心概念

1. BPU 内存架构简述

  • BPU（Brain Processing Unit） 是 D-Robotics S100P 平台上的专用 AI 加速单元。
  • 它拥有独立的 SRAM（片上内存），用于存储模型权重、激活值等关键数据。
  • 同时依赖 ION Buffer（I/O Memory Buffer） 来缓存主机（Host）与 BPU 之间的数据传输。
  • IOMMU（Input/Output Memory Management Unit） 负责在 BPU 和 Host 之间建立虚拟地址到物理地址的映射，是内存访问的关键环节。

:red_exclamation_mark:错误 [ERR]Set BPU Core0 IOMMU MAP failed[-1]! 正是由于 IOMMU 在尝试建立地址映射时失败，通常是因为：

  • 地址空间冲突
  • 内存不足（BPU SRAM + ION Buffer 不足）
  • 权限或调度策略不匹配（如 host_first 与实际内存分布冲突）

:compass: 二、如何学习 BPU 内存管理？

:white_check_mark: 推荐学习路径：

第一步：阅读官方文档

第二步：查看配置文件结构

  • 您提到的 omni_offline_config.json 是关键配置文件，建议您打开它，查找以下字段：
    {
  "memory_layout": "balanced",  // 或 "bpu_first", "host_first"
  "bpu_memory_mode": "auto",
  "ion_buffer_size": "max",
  "model_type": 5,
  "online_mode": 0
}
    • memory_layout：决定优先使用 BPU 还是 Host 内存。
    • ion_buffer_size：ION 缓冲区大小，单位 MB。
    • bpu_memory_mode：BPU 内存管理模式（如自动、固定）。

:light_bulb: 建议：在修改前备份原配置文件，并逐项测试调整效果。

第三步：动手实验 & 日志分析

  • 在运行模型时，开启详细日志（如 [BPUMONITOR] 输出），观察 IOMMU 映射失败的具体原因。
  • 使用 rdkos_info 工具定期检查内存占用率，例如：
    sudo rdkos_info -s | grep "VDD_BPU\|bpu_status"
    • 如果 VDD_BPU 电压异常或 bpu_status 为 0，可能表示 BPU 未正确初始化。

第四步：研究源码（进阶）

如果您想深入理解 BPU 内存管理的实现原理，可以查阅以下 GitHub 仓库：

  • Discourse 论坛中提及的 RDK 文档仓库：
  • BPU 驱动与库源码（需联系社区或管理员获取权限）：
    • app/models/bpu_driver.c
    • lib/bpulib.c
    • scripts/set_performance_mode.sh

:warning: 注意：部分源码可能未公开，但通过分析日志和配置文件，您仍能掌握大部分实用技巧。

:hammer_and_wrench: 三、常见问题与调优建议

Q1: 为什么 bpu_first 模式有时会失败？

  • 原因：BPU SRAM 空间不足，导致无法加载完整模型。
  • 解决方法：
    • 改用 balanced 模式，让系统自动在 BPU 和 Host 之间分配内存。
    • 减少模型尺寸（如使用量化版 Qwen2.5 Omni 1.5B）。
    • 增加 ION Buffer 大小（通过 srpi-config 设置）。

Q2: 如何监控 BPU 内存使用情况？

  • 使用命令：
    sudo rdkos_info -s | grep "bpu_status\|VDD_BPU\|ion_usage"
  • 查看 /sys/class/bpu/ 下的节点，例如：
    cat /sys/class/bpu/bpu0/mem_usage

Q3: 是否可以自定义内存分配策略？

  • 目前官方支持三种模式：bpu_first, balanced, host_first。
  • 如果需要更精细控制，可通过修改 set_performance_mode.sh 脚本中的内核参数（如 echo 1 > /sys/module/bpudrv/parameters/memory_policy）。

:open_book: 四、推荐学习资料清单

资源类型 名称 链接
官方文档 LLM 工具链内存分配说明 点击查看
官方文档 srpi-config 工具配置 点击查看
官方文档 BPU 系统信息收集工具 点击查看
GitHub 仓库 RDK 文档源码 GitHub - D-Robotics/rdk_doc · GitHub
社区讨论 【S100P】BPU 内存管理求助帖 点击查看

:bullseye: 五、总结：从“黑箱”到“掌控”

您目前遇到的问题本质上是 内存调度策略与硬件资源不匹配 导致的 IOMMU 映射失败。通过调整 memory_layout 为 balanced，您已经成功绕过了这个问题。

下一步，建议您：

  1. 系统化学习 BPU 内存管理文档，理解每种模式的适用场景。
  2. 定期使用 rdkos_info 工具监控内存状态，提前发现潜在问题。
  3. 在配置文件中记录每次调整的参数和结果，形成自己的“调试手册”。
  4. 如果条件允许，参与开源社区贡献，帮助完善 BPU 内存管理的文档和工具。

如果您希望我帮您 解析某个具体的配置文件内容，或者 提供一个完整的 BPU 内存管理调试脚本模板，请随时告诉我！我会为您定制化支持。

祝您在 S100P 平台上玩得开心，早日成为 BPU 内存管理专家！:rocket::brain:

8

一般不进行脚本操作会一直有效

一般 bpu_first 就是最大支持能力，也不建议继续增加，也能满足提供提供的模型的需求

9

感谢您提供的最新信息！根据 Marcelo 的补充说明：

“一般不进行脚本操作会一直有效”
“一般 bpu_first 就是最大支持能力，也不建议继续增加，也能满足提供提供的模型的需求”

这为我们提供了非常关键的结论：

:white_check_mark: 总结与确认：

  1. 模式持久性：

    • 一旦通过 set_performance_mode.sh 脚本设置了 bpu_first 模式，系统在软重启或硬重启后通常仍保持该配置（除非内核/固件重置、手动修改了设备树或驱动参数）。
    • 因此，无需每次启动都重新执行脚本 —— 只有在系统更新、异常断电或配置被意外覆盖时才需重新设置。

  2. 内存分配上限：

    • bpu_first 模式代表系统优先使用 BPU SRAM，这是硬件本身的物理限制（如 512MB 或 1GB），无法通过软件无限扩展。
    • 当前 Qwen2.5 Omni 3B 模型在 balanced 模式下能正常运行，说明其实际内存需求未超过 BPU + ION Buffer 的总容量。
    • 不建议强行增加 ION buffer 或尝试其他非官方策略，因为这可能导致内存碎片、调度冲突或系统不稳定。

  3. 推荐策略：

    • 对于大多数模型（包括 Qwen2.5 Omni 3B），使用 balanced 模式是更稳健的选择，它能在 BPU 和 Host 之间动态分配资源，避免因单一模式导致 MAP 失败。
    • 如果追求极致性能且模型较小，可尝试 bpu_first，但需确保 BPU SRAM 足够（可通过 rdkos_info 监控）。
    • 不要盲目追求“最大内存”，而应关注“稳定运行”和“资源利用率”。

:pushpin: 给您的后续建议：

  • 如果您计划部署更多模型，建议建立一个配置管理表，记录每个模型的最佳模式（如：Qwen2.5_3B → balanced；ResNet18 → bpu_first）。
  • 在开发环境中，可以编写一个自动检测脚本，在启动时检查当前内存模式，并自动调用 set_performance_mode.sh 确保一致性。
  • 如需深入理解底层机制，可参考以下方向：
    • 分析 bpulib.c 或 bpu_driver.c 中的 IOMMU 初始化逻辑（需社区权限）。
    • 使用 dmesg | grep bpu 查看内核日志中的内存映射错误详情。

再次感谢您的详细反馈和积极提问！您已经从“黑箱操作”逐步过渡到“可控调试”，这是非常宝贵的进展。如果您未来还想探索：

  • 自定义内存分配策略
  • 编写自动化调试脚本
  • 优化大模型在 S100P 上的推理效率

欢迎随时回来提问！我会持续为您提供技术支持 :blush::rocket:

祝您开发顺利，模型跑得飞起！

10

好的，谢谢您的解答 :saluting_face:

11

感谢您的反馈！很高兴能帮助您从“黑箱”走向更清晰的 BPU 内存管理理解。如果您后续还有任何关于模型部署、性能优化或硬件调试的问题，随时欢迎回来提问！

祝您在 S100P 平台上开发顺利，模型运行稳定高效！:rocket::brain:

—— 社区技术支持助手 敬上