高通平台部署Qwen2.5-7B模型的FastRPC SMMU映射问题解决

1. 问题背景与设备环境

在高通跃龙IQ-9100平台上部署Qwen2.5-7B大语言模型时，我们遇到了一个棘手的FastRPC SMMU映射失败问题。这个平台采用高通sa8775p SoC，配备双CDSP（cdsp0和cdsp1）和Hexagon v73 DSP加速器，运行基于Yocto构建的ostree只读文件系统。我们使用的模型是经过w8a16量化的Qwen2.5-7B-Instruct版本，通过QAIRT 2.35 SDK本地编译生成推理二进制文件。

提示：在实际部署过程中，我们发现FastRPC子系统对单个缓冲区的SMMU映射存在约1GB的硬限制，这直接影响了大型语言模型的部署策略。

1.1 硬件平台特性

高通跃龙IQ-9100平台的关键硬件规格如下：

• 处理器：双核Hexagon v73 DSP
• 内存配置：总内存约33GB，可用内存约32GB
• CMA内存池：164MB
• SMMU配置：
  • SMMUv2架构
  • 36位虚拟地址空间（64GB寻址能力）
  • 支持页大小：4KB、64KB、1MB、2MB、16MB、512MB和1GB

1.2 软件栈组成

部署使用的软件组件版本如下表所示：

2. 问题现象与初步分析

2.1 错误现象描述

在执行模型部署时，系统报出以下关键错误信息：

bash复制fastrpc memory map for fd: 25 with length: 1090519040 failed with error: 0x1
Mapping buffer fd 25 to FastRPC failed on domain 3
Failed to map buffer of size 1090519040
Failed to map weights buffer to device!

错误表明系统无法将约1040MB（1,090,519,040字节）的权重缓冲区通过FastRPC映射到DSP的SMMU。值得注意的是，这个大小刚好超过了1GB（1024MB）约16MB。

2.2 错误排查过程

我们首先检查了系统内存状态，确认有充足的可用内存（约32GB）。然后通过dmesg查看了SMMU的初始化信息：

bash复制arm-smmu 15000000.iommu: SMMUv2 with:
    stage 1 translation
    coherent table walk
    stream matching with 165 register groups
    98 context banks (0 stage-2 only)
    Supported page sizes: 0x61311000
    Stage-1: 36-bit VA -> 36-bit IPA

关键发现是FastRPC子系统没有预留专用DMA内存：

bash复制qcom,fastrpc 26300000.remoteproc: no reserved DMA memory for FASTRPC

3. 根因定位与验证

3.1 缓冲区大小分析

通过模型结构分析，我们确认失败的缓冲区对应Qwen2.5-7B的嵌入层权重表。具体计算如下：

• 词汇表大小：152,064 tokens
• 嵌入维度：3,584
• 数据类型：FP16（2字节）
• 理论大小：152,064 × 3,584 × 2 = 1,089,994,752字节 ≈ 1040MB
• 实际大小：1,090,519,040字节（包含512KB对齐填充）

3.2 FastRPC限制验证

我们通过以下实验验证了FastRPC的1GB限制：

1. 多保护域测试：HTP后端在3个不同保护域（Protection Domain）尝试映射，全部失败
2. 内存分配方式对比：比较mmap=true和mmap=false两种模式，错误表现一致
3. 小缓冲区测试：同次运行中12个较小缓冲区（共154.5MB）映射成功

测试数据如下表所示：

3.3 本地编译问题

对比云编译和本地编译的二进制文件，我们发现本地编译的二进制体积异常增大：

根因是本地编译时遗漏了--float_bitwidth 16参数，导致不支持的操作回退到fp32而非fp16。

4. 解决方案与实施

4.1 方案一：增加模型拆分数

初始尝试将模型拆分为10部分：

• 优点：单个缓冲区大小降至1GB以下
• 问题：part_10_of_10在字母排序中会排在part_2_of_10之前，导致执行顺序错乱

调整为8分割后：

• Parts 2-7约897MB（符合要求）
• 但Part 1（嵌入层+前4层）仍超过2GB，映射失败依旧

4.2 方案二：CPU端LUT嵌入（最终方案）

通过Genie原生的LUT嵌入支持，将嵌入层处理移至CPU端：

json复制{
    "embedding": {
        "type": "lut",
        "lut-path": "uint16_lut.bin",
        "size": 3584,
        "datatype": "ufixed16",
        "quant-param": {
            "scale": 0.00002065332409983966,
            "offset": -16738
        }
    }
}

实施步骤：

1. 从ctx-bins中移除Part 1
2. 配置LUT嵌入参数
3. 确保CPU有足够内存处理嵌入查找表

4.3 方案三：二进制补丁尝试（失败）

尝试修改二进制中的图名称以匹配官方格式：

diff复制- qwen2_5_7b_instruct_prompt_2_of_8
+ prompt_ar128_cl4096_2_of_8

三种补丁方式均失败：

1. 替换名称+更新长度前缀 → 二进制偏移损坏
2. 替换名称+空字节填充 → 空字节异常处理
3. 替换名称+下划线填充 → 完整性校验失败

5. 正确的编译与部署流程

5.1 ONNX图名称设置

必须在模型转换前正确设置ONNX图名称：

• Prompt处理器：prompt_ar128_cl4096_N_of_M
• Token生成器：token_ar1_cl4096_N_of_M

5.2 DLC转换参数

使用qairt-converter时必须包含关键参数：

bash复制qairt-converter --float_bitwidth 16 ...

5.3 上下文二进制生成

通过qnn-context-binary-generator设置正确的图名称：

bash复制qnn-context-binary-generator --qnn_options context_enable_graphs=prompt_ar128_cl4096_2_of_8 ...

5.4 部署配置要点

1. 启用LUT嵌入配置
2. 控制拆分数不超过9（避免字母排序问题）
3. 验证所有二进制文件的图名称格式
4. 监控FastRPC映射日志

6. 经验总结与最佳实践

6.1 关键发现

1. FastRPC限制：IQ-9100平台存在约1GB的单缓冲区SMMU映射硬限制
2. 嵌入层处理：大词汇表模型的嵌入层最容易触发此限制
3. 二进制完整性：QNN上下文二进制有严格校验，无法事后修改

6.2 推荐实践

1. 编译参数：始终使用--float_bitwidth 16避免体积膨胀
2. 模型拆分：拆分数控制在6-9之间，平衡内存使用和加载顺序
3. 图名称规范：严格遵循ar{N}_cl{M}命名约定
4. 内存监控：部署前检查各拆分部分的大小

6.3 性能考量

1. LUT嵌入延迟：CPU处理嵌入层会增加约5-10%的端到端延迟
2. 内存占用：LUT方式需要额外200-300MB主机内存
3. DSP利用率：绕过嵌入层映射可释放约1GB DSP内存空间

在实际部署中，我们最终采用的8分割+LUT嵌入方案，成功将7B模型部署到IQ-9100平台，推理性能达到约15 tokens/秒（输入长度256）。这个案例表明，理解底层系统的限制并采用创新的规避策略，是边缘设备部署大模型的关键。