高通8255/8295 DMS 部署实践：从算法到芯片的端到端优化

问题背景：车载 DMS 的边缘部署挑战

IMS 感知算法部署痛点：

痛点	具体表现
模型大小	TFLite/NCNN/QNN 三套格式，重复维护
实时性	多模型串行推理，帧率低
内存占用	频繁创建销毁对象，内存碎片
功耗	高负载运行影响整车能耗

目标： 在高通 8255/8295 上实现 DMS 全流程 15 FPS 以上实时运行。

---

高通平台技术架构

QNN 推理框架

┌─────────────────────────────────────────────────────────┐
│                    应用层                                │
├─────────────────────────────────────────────────────────┤
│  DMS Pipeline: Face → Landmark → Eye → Fatigue → Output │
├─────────────────────────────────────────────────────────┤
│                    QNN Runtime                          │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │ CPU后端 │ │ GPU后端 │ │ DSP后端 │ │ NPU后端 │       │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘       │
├─────────────────────────────────────────────────────────┤
│                 Snapdragon 8255/8295                    │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │ Kryo CPU│ │ Adreno  │ │ Hexagon │ │ HTP NPU │       │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘       │
└─────────────────────────────────────────────────────────┘

后端选择策略

模型类型	推荐后端	原因
人脸检测	NPU	并行计算密集
关键点定位	NPU	矩阵运算多
眼动追踪	DSP	时序处理强
疲劳判定	CPU	逻辑复杂，控制流多

---

部署优化实践

1. 模型量化优化

INT8 量化流程：

# QNN 量化配置示例
quant_config = {
    "input_tensor_width": 640,
    "input_tensor_height": 480,
    "custom_div_sub": {
        "mean_val": [123.675, 116.28, 103.53],
        "norm_val": [0.01712475, 0.017507, 0.01742919]
    },
    "resize_no_padding": True,
    "slimenn_cfg": {
        "bsnn_uint8_enable": True,
        "qnn_uint8_enable": False,
        "atcnn_uint8_enable": True
    }
}

量化效果对比：

模型	FP32大小	INT8大小	精度损失	加速比
Face Det	12MB	3.2MB	0.5%	3.8x
Landmark	8MB	2.1MB	0.8%	4.2x
Eye Track	5MB	1.3MB	1.2%	3.5x

2. 多模型流水线并行

优化前： 串行推理，总延迟 = Σ 模型延迟

优化后： 流水线并行

帧1: [Face Det] ──────────────→ [Landmark] ─────────→ [Eye]
帧2:           [Face Det] ──────────────→ [Landmark] ─────────→
帧3:                     [Face Det] ──────────────→ [Landmark]─→

效果： 吞吐量提升 2.5x

3. 内存池化

问题： 每帧创建临时缓冲区

// 优化前
void process_frame(Image* frame) {
    float* temp_buffer = new float[BUFFER_SIZE];  // 每帧分配
    // ... 处理 ...
    delete[] temp_buffer;  // 每帧释放
}

优化： 预分配环形缓冲区

// 优化后
class FrameProcessor {
    RingBuffer<float> buffer_pool_;  // 预分配
    
    void process_frame(Image* frame) {
        auto buffer = buffer_pool_.acquire();  // O(1)
        // ... 处理 ...
        buffer_pool_.release(buffer);  // O(1)
    }
};

效果： 内存分配开销降低 95%

---

性能基准

8255 平台

指标	优化前	优化后	提升
帧率	8 FPS	18 FPS	125%
内存占用	280MB	180MB	36%
CPU 占用	85%	45%	47%
功耗	3.2W	2.1W	34%

8295 平台

指标	优化前	优化后	提升
帧率	12 FPS	25 FPS	108%
内存占用	320MB	200MB	37%
CPU 占用	70%	35%	50%
功耗	4.5W	2.8W	38%

---

IMS 开发启示

优先级排序

优先级	优化项	预期收益	开发周期
P0	INT8 量化	4x 加速	1 周
P0	流水线并行	2.5x 吞吐	2 周
P1	内存池化	30% 内存	1 周
P1	后端调度优化	20% 功耗	2 周
P2	模型剪枝	15% 大小	4 周

---

我的判断

高通平台部署的核心是”量化优先”：

1. QNN 的 INT8 加速是最大红利，必须优先完成
2. 流水线并行投入产出比最高
3. 内存优化对长期稳定性至关重要

对 IMS 团队的建议：

• 建立统一模型转换流程：ONNX → QNN → INT8
• 后端选择要动态化，根据负载自动切换
• 内存池化要贯穿整个 Pipeline

---

本文基于实际部署经验整理，平台数据来自测试环境。