边缘推理多实例并发服务架构设计：模型共享内存池与请求级 Arena 隔离方案的工程实现

一、单实例推理的并发瓶颈——边缘网关上的请求排队与内存爆炸

在边缘 AI 网关场景中，设备需要同时处理多路视频流的推理请求。例如，一台搭载 RK3588 的边缘计算盒需要同时服务 4 路 1080P 安防摄像头的目标检测、1 路门禁的人脸识别以及本地 NVR 的实时推流分析。如果为每路请求创建一个独立的 TFLite/NCNN 模型实例，以 YOLOv5s 为例，单个实例约占用 28MB 模型权重 + 50MB 中间张量缓冲区，6 个实例将消耗近 500MB 内存——而 RK3588 的总可用内存通常只有 7.5GB（扣除 GPU 预占用后约 6GB）。

更棘手的是，多个推理实例并发运行时，CPU 缓存抖动（cache thrashing）导致推理延迟的 P99 从 45ms 恶化到 180ms。这是因为每个实例的模型权重在 L2 Cache 中相互驱逐，使得每次推理都需要从 DDR 重新加载权重数据。

解决这两个问题的钥匙是共享模型权重 + 请求级 Arena 隔离：将模型权重存放在所有实例共享的只读内存池中，每个请求仅分配独立的临时张量缓冲区（Arena），通过内存地址空间隔离消除实例间的数据竞争。

二、共享内存池与 Arena 隔离的底层架构

2.1 模型内存布局的三层划分

graph TD subgraph "只读共享区 (跨实例, 1 份)" A1[模型权重 .weights] --> A2[卷积核矩阵] A1 --> A3[BN 层均值/方差] A1 --> A4[全连接权重] end subgraph "Arena 隔离区 (每请求 1 份, 临时)" B1[输入张量 Buffer] --> B2[中间激活值 Buffer] B3[输出张量 Buffer] B1 --> B4[算子的 workspace 临时缓冲区] end subgraph "实例上下文区 (每实例 1 份, 持久)" C1[Op Resolver 函数表] --> C2[SubGraph 节点链表] C3[内存分配器句柄] end A1 -.->|只读指针, 共享映射| B2 C3 -.->|管理 Arena 分配/释放| B1

2.2 Arena 分配器的核心设计

Arena（内存竞技场）是一种 Bump Allocator：在预分配的大块内存中，通过移动指针实现极快的"分配"操作，且不记录任何 per-allocation 元数据。所有内存在请求处理完成后一次性释放（重置指针到起始位置），避免了传统 malloc/free 的内存碎片和 free 链表遍历开销。

sequenceDiagram participant Client as 推理客户端 participant Scheduler as 请求调度器 participant ArenaPool as Arena 对象池 participant Model as 共享模型实例 participant Memory as 物理内存 Client->>Scheduler: 提交推理请求 (图像数据) Scheduler->>ArenaPool: acquire_arena() ArenaPool->>Memory: 从预分配池中取 Arena (100MB) ArenaPool-->>Scheduler: Arena 句柄 Scheduler->>Model: run_inference(image, arena) Model->>ArenaPool: arena->alloc(50MB) // 分配输入+中间缓冲区 Note over Model: Bump 指针从 base 移动到 base+50MB Model->>Model: 执行推理 (复用共享权重) Note over Model: 仅访问 arena 中的临时张量 + 共享权重 Model->>ArenaPool: arena->reset() // 重置 bump 指针 Scheduler->>Client: 返回推理结果 Client->>Scheduler: 请求完成 Scheduler->>ArenaPool: release_arena() // 归还到对象池

三、生产级代码实现

3.1 Arena 内存分配器的实现

#include <stdint.h> #include <stddef.h> #include <stdalign.h> /* 对齐到 64 字节 (DDR burst 长度, 也是 Cache Line 大小) */ #define ARENA_ALIGNMENT 64 typedef struct { uint8_t *base; /* Arena 起始地址 */ uint8_t *current; /* 当前分配指针 (bump pointer) */ size_t capacity; /* Arena 总容量 (字节) */ size_t peak_usage; /* 本次请求的峰值用量 (诊断用) */ uint32_t magic; /* 魔数: 防止野指针写入 */ } memory_arena_t; #define ARENA_MAGIC 0x4152454E /* ASCII: "AREN" */ /* 从预分配的物理内存初始化 Arena */ int arena_init(memory_arena_t *arena, void *memory, size_t size) { if (!memory || size < 1024) { return -EINVAL; /* 最小 1KB, 防止空指针 */ } arena->base = (uint8_t *)memory; arena->current = arena->base; arena->capacity = size; arena->peak_usage = 0; arena->magic = ARENA_MAGIC; return 0; } /* Arena 分配: 移动 bump 指针, O(1) 时间复杂度 */ void *arena_alloc(memory_arena_t *arena, size_t size) { /* 安全检查: 魔数校验 */ if (arena->magic != ARENA_MAGIC) { return NULL; /* Arena 已被破坏 */ } /* 向上对齐到 ARENA_ALIGNMENT 的整数倍 */ size_t aligned_size = (size + ARENA_ALIGNMENT - 1) & ~(ARENA_ALIGNMENT - 1); /* 溢出检查 */ if (aligned_size < size) { return NULL; /* 整数溢出 */ } uint8_t *result = arena->current; ptrdiff_t remaining = (arena->base + arena->capacity) - arena->current; if (aligned_size > (size_t)remaining) { return NULL; /* Arena 空间不足 */ } arena->current += aligned_size; /* 更新峰值用量 */ size_t used = (size_t)(arena->current - arena->base); if (used > arena->peak_usage) { arena->peak_usage = used; } return result; } /* 重置 Arena: 仅将 bump 指针复位, O(1) */ void arena_reset(memory_arena_t *arena) { if (arena->magic == ARENA_MAGIC) { arena->current = arena->base; } }

3.2 多实例推理服务的请求调度层

#include <pthread.h> #include <semaphore.h> #define MAX_CONCURRENT_REQUESTS 8 #define ARENA_SIZE_MB 100 typedef struct { /* 请求描述符 */ void *input_data; size_t input_size; void *output_buffer; size_t output_capacity; /* 关联的 Arena */ memory_arena_t *arena; /* 同步原语: 调用者通过 semaphore 等待推理完成 */ sem_t completion_sem; int inference_status; /* 0 = 成功, <0 = 错误码 */ } inference_request_t; typedef struct { /* 共享模型权重: 所有实例只读共享 */ void *shared_weights; size_t weights_size; /* Arena 对象池: 预分配 MAX_CONCURRENT_REQUESTS 个 Arena */ memory_arena_t arena_pool[MAX_CONCURRENT_REQUESTS]; uint8_t *arena_memory[MAX_CONCURRENT_REQUESTS]; int arena_in_use[MAX_CONCURRENT_REQUESTS]; /* 0=空闲, 1=使用中 */ pthread_mutex_t arena_lock; /* 请求队列 */ inference_request_t *request_queue[MAX_CONCURRENT_REQUESTS]; int queue_head, queue_count; pthread_mutex_t queue_lock; pthread_cond_t queue_cond; pthread_t worker_thread; volatile int running; } inference_service_t; /* 初始化推理服务: 预分配 Arena 池 */ int inference_service_init(inference_service_t *svc, const char *model_path) { int ret; /* 加载模型权重到共享内存 */ svc->weights_size = get_model_size(model_path); svc->shared_weights = mmap(NULL, svc->weights_size, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (svc->shared_weights == MAP_FAILED) { return -ENOMEM; } ret = load_model_weights(model_path, svc->shared_weights); if (ret < 0) { munmap(svc->shared_weights, svc->weights_size); return ret; } /* 预分配 Arena 池 */ pthread_mutex_init(&svc->arena_lock, NULL); for (int i = 0; i < MAX_CONCURRENT_REQUESTS; i++) { svc->arena_memory[i] = aligned_alloc(4096, ARENA_SIZE_MB * 1024 * 1024); if (!svc->arena_memory[i]) { return -ENOMEM; /* 内存不足, 无法启动服务 */ } arena_init(&svc->arena_pool[i], svc->arena_memory[i], ARENA_SIZE_MB * 1024 * 1024); svc->arena_in_use[i] = 0; } return 0; } /* 获取一个空闲 Arena (阻塞等待直到有空闲) */ memory_arena_t *arena_acquire(inference_service_t *svc) { while (1) { pthread_mutex_lock(&svc->arena_lock); for (int i = 0; i < MAX_CONCURRENT_REQUESTS; i++) { if (!svc->arena_in_use[i]) { svc->arena_in_use[i] = 1; pthread_mutex_unlock(&svc->arena_lock); arena_reset(&svc->arena_pool[i]); /* 清零 bump 指针 */ return &svc->arena_pool[i]; } } pthread_mutex_unlock(&svc->arena_lock); /* 所有 Arena 都在使用中: 短暂休眠后重试 */ struct timespec ts = {.tv_sec = 0, .tv_nsec = 1000000}; /* 1ms */ nanosleep(&ts, NULL); } } /* 归还 Arena */ void arena_release(inference_service_t *svc, memory_arena_t *arena) { pthread_mutex_lock(&svc->arena_lock); for (int i = 0; i < MAX_CONCURRENT_REQUESTS; i++) { if (&svc->arena_pool[i] == arena) { svc->arena_in_use[i] = 0; break; } } pthread_mutex_unlock(&svc->arena_lock); }

四、边界分析与架构权衡

4.1 Arena 内存碎片 vs Bump Allocator 的限制

Bump Allocator 不产生外部碎片（因为从不 free 单个分配），但存在内部碎片：对齐到 64 字节可能浪费最多 63 字节/次分配。更关键的局限是：Arena 内的分配只能整体释放，不支持部分 free。如果中间某个张量在推理过程中需要动态扩展，Bump Allocator 无法原地扩展——只能分配新区域并拷贝。

4.2 模型权重的 Cache 亲和性

多个推理实例共享同一份权重数据，虽然节省了 DDR 带宽，但加重了 L2 Cache 的压力。在一颗 4 核 Cortex-A76 上，如果 4 个线程同时推理且遍历相同的卷积核，Cache 命中率反而上升；但如果每路请求使用不同模型，Cache 竞争将导致延迟抖动。解决方案是进程级模型亲和绑定，即把使用同一模型的请求路由到同一 CPU 核心。

4.3 Arena 大小与请求失败率的关系

ARENA_SIZE_MB 必须 ≥ 单次推理的最大临时内存需求。如果预估不足，arena_alloc返回 NULL 将导致推理失败。更安全的做法是在服务初始化时通过干跑（dry-run）模拟一次推理，记录 peak_usage，然后乘以 1.2 的安全系数作为 Arena 大小。

4.4 适用与禁用场景

适用：多路并发推理的边缘网关、需要内存严格隔离的多租户推理服务。
禁用：单路推理场景（Arena 隔离无收益）、模型需要动态 shape 推理且临时内存波动较大的场景。

五、总结

本文从边缘推理服务的内存瓶颈和 Cache 抖动问题出发，设计了基于共享内存池和请求级 Arena 隔离的多实例并发架构。

1. 共享模型权重消除了权重数据的多份拷贝：多个请求共享同一份只读权重映射，节省了 (N-1)×模型大小的物理内存。
2. Arena Bump Allocator 以 O(1) 时间完成单次分配和整体释放：避免了 malloc/free 的锁竞争和内存碎片，且 Arena 间的地址空间天然隔离，无数据竞争。
3. 预分配的 Arena 对象池提供了有界的并发度控制：MAX_CONCURRENT_REQUESTS 限制了同时进行的推理数，防止内存耗尽。
4. Cache 亲和性在多模型场景下需要额外的 CPU 绑定策略：同模型请求路由到同核，异模型请求分配不同核对 Cache 更友好。
5. 生产落地建议：通过 dry-run 获取 peak_usage 后乘以安全系数确定 Arena 大小，开启mlock锁定权重页面防止换出，使用perf stat -e cache-misses监控多实例场景下的缓存效率。