端侧推理并发时的资源边界在采用统一内存架构的端侧设备上部署推理服务时模型权重、运行时缓冲和 KV Cache 会竞争同一内存池。并发和上下文长度增长后内存压力可能触发 OOM 回收或杀进程具体行为取决于内核、cgroup 配置和进程的 OOM 评分。由于端侧设备的算力与内存资源相对有限建立基于操作系统安全的守护防线与背压控制机制是保障服务在高并发下稳定运行的前提。1. 统一内存架构下的内存增长陷阱端侧 AI 推理部署与云端集群部署存在架构差异。云端服务器的显存与系统物理内存通常独立分隔而多数端侧芯片采用 unified memory 架构计算核心与推理引擎共享同一块物理内存空间。当模型在执行长上下文推理任务时KV Cache 的尺寸随着生成 Token 的递增呈线性增长。在多并发请求场景下总体内存占用会呈现快速上扬趋势。# 查看端侧系统内存与 Cgroup v2 限制状态的典型命令行诊断 $ cat /sys/fs/cgroup/ai_inference/memory.current 7892314112 $ cat /sys/fs/cgroup/ai_inference/memory.max 8000000000 # 观察到进程因触及内存配额限制而被内核杀死 $ dmesg -T | grep -i oom [Fri Aug 29 14:20:05 2026] Out of memory: Kill process 9412 (onnx_runtime) score 950 or sacrifice child当内存占用触及物理配额上限时操作系统内核为保护自身运行会杀掉内存占用最高的进程。端侧部署的首要安全防线是针对物理内存建立明确的隔离边界。2. 容量估算模型与安全并发上限在部署端侧模型前需建立基于硬件约束的物理容量估算模型避免超出设备承载极限。端侧推理进程的总内存开销由三个部分叠加而成模型权重静态内存$M_{\text{weights}}$、运行时 Context 与 KV Cache 动态内存$M_{\text{kv}}$、以及操作系统与算力栈运行库保留内存$M_{\text{runtime}}$。$$\text{Total Memory} M_{\text{weights}} N_{\text{concurrent}} \times (\text{SeqLength} \times D_{\text{kv}}) M_{\text{runtime}}$$下面的数值仅用于说明估算方法不能直接作为部署参数。实际 KV Cache 大小还取决于模型层数、KV 头数、精度、批处理和推理引擎。假设静态权重占用 4.2 GB、单路 KV Cache 约占 256 MB8 GB 设备另留出 1.5 GB 给系统与运行时$$8.0 - 4.2 - 1.5 2.3 \text{ GB}$$按这组假设计算的理论并发上限为$$2.3 \text{ GB} / 0.256 \text{ GB} \approx 9$$实际部署还要给碎片、峰值缓冲和监控采样留余量并通过压测确定准入阈值而不是直接采用该计算结果。3. 背压门禁与过载请求拦截机制厘清容量上限后需在系统请求入口处引入防浪涌背压门禁Backpressure Gate。背压机制的原则在于在系统底层资源接近饱和前主动拒绝超载请求保障已有在线任务的稳定执行。#include iostream #include atomic #include chrono #include mutex class BackpressureGate { private: const size_t max_concurrency; const float memory_threshold_ratio; std::atomicsize_t active_requests{0}; public: BackpressureGate(size_t max_reqs, float mem_ratio) : max_concurrency(max_reqs), memory_threshold_ratio(mem_ratio) {} bool try_acquire(size_t current_system_mem_used_bytes, size_t total_mem_bytes) { // 1. 检查物理内存水位线 float current_ratio static_castfloat(current_system_mem_used_bytes) / total_mem_bytes; if (current_ratio memory_threshold_ratio) { std::cerr [Warning] 背压触发内存使用率达到 current_ratio * 100 %\n; return false; } // 2. 检查当前激活的并发数 size_t current active_requests.load(std::memory_order_relaxed); while (current max_concurrency) { if (active_requests.compare_exchange_weak(current, current 1, std::memory_order_acquire, std::memory_order_relaxed)) { return true; } } return false; // 超出并发上限实施背压拦截 } void release() { active_requests.fetch_sub(1, std::memory_order_release); } };上述示例展示了按内存水位和并发数拦截请求的思路。水位和并发上限应由压测确定HTTP 标准状态码通常使用429 Too Many Requests或503 Service Unavailable并按需要附带Retry-After不宜自定义为 539。4. 操作系统层面的 Cgroup v2 隔离除了应用层面的背压控制外最基础的底线防护应当依赖操作系统内核来实现。在 Linux 环境下可为端侧推理服务创建独立的 Cgroup v2 容器并设置memory.high与memory.max双层阈值# 创建推理专用的 cgroup 节点 sudo mkdir -p /sys/fs/cgroup/ai_engine # 配置平滑保护线High与硬上限Max # memory.high 会对 cgroup 内的内存分配施加回收与节流压力它不等同于 CPU 配额限制 echo 6500000000 | sudo tee /sys/fs/cgroup/ai_engine/memory.high echo 7200000000 | sudo tee /sys/fs/cgroup/ai_engine/memory.max # 设备访问权限应通过设备节点权限、容器运行时或 LSM 策略单独配置memory.high不是硬上限。超过它后内核会在分配路径施加回收与节流压力应用仍应监控memory.events主动缩短队列、取消可取消任务或降低并发。memory.max被触及后cgroup 内的任务仍可能发生 OOM。5. 守护线的工程闭环端侧 AI 推理部署不仅需要关注模型的运行成功率更需要建立系统可用性底线。容量估算给出起点入口背压限制排队增长cgroup 则缩小单个服务失控时的影响范围。上线前仍要在目标硬件、真实模型和目标上下文长度下压测并演练 OOM 与请求取消路径。