端侧推理部署先保证设备原有任务不被拖垮把模型放到边缘设备上最先要保护的往往不是推理速度而是设备已经承担的工作。工业控制、采集、告警或通信进程通常有明确的时序要求。推理进程一旦在 CPU、内存或设备访问上失控用户感受到的就不是“回答慢一点”而是原有服务抖动、超时甚至重启。端侧部署没有统一的最优配置。模型大小、量化方式、设备架构、功耗限制、交互时延和主业务负载都会改变取舍。工程上更可靠的起点是先测清资源边界再以隔离和降级保护主业务而不是默认让推理引擎跑满机器。先建立设备上的真实负载基线不要只用空闲设备测模型首字时间。实际部署前应记录主进程在正常、繁忙和异常恢复时的 CPU、内存、磁盘与网络使用了解它能承受多少额外竞争。推理测试也应使用接近真实的输入长度和并发而不是只跑一个极短的提示。端侧模型的内存不只有权重。运行时还会分配上下文缓存、临时缓冲区、线程栈、加载器和设备驱动相关内存。量化能降低一部分占用但不能保证在所有框架和输入长度下都落在同一范围。应在目标设备上观察峰值并为系统与主业务预留余量。延迟同样要拆开看。加载模型、处理输入、生成首段输出和完成全部输出受到的瓶颈不完全相同。为了提升吞吐而合并批处理可能会拉长单个用户的等待为了缩短首段等待而增加线程又可能抢占实时进程。先决定这个设备真正看重哪个体验再调整参数。用 cgroup 限制资源但不要拍脑袋绑核Linux 的 cgroup 可以为推理服务设定 CPU、内存和进程数量等边界。这样即使模型请求异常增长也不会无限吞掉主机资源。具体限制应从基线和压测得出并通过监控观察是否频繁触发限制一开始就给出很紧的固定数值常会让推理抖动或造成难排查的 OOM。CPU 隔离与绑核需要谨慎。将主业务和推理任务分开调度有时能减少互相干扰但核数、调度策略、中断处理和驱动线程的分布都可能影响实际结果。不能只因设备有四个核心就假定划出一个核心给模型一定合适。应在目标内核与设备上验证并留意主业务的高优先级线程是否真的得到了保障。当资源不足时推理服务应有明确退路减少上下文、降低并发、改用更小的模型、只返回检索结果或暂时拒绝新的低优先级请求。降级比让进程持续交换内存、拖慢整台设备更可控。内存锁定和模型加载要遵守系统限制内存页被回收或频繁缺页确实可能造成延迟波动但并不意味着应对整个进程无限制调用内存锁定。锁定内存会减少内核可回收空间在内存本就紧张的设备上可能伤害其他服务。是否锁定、锁定多少、所需权限和失败后的行为都需要结合操作系统限制与设备容量评估。更实际的做法是控制模型与上下文的最大占用避免无界会话在启动时预热必要资源并观察是否影响主业务若内存锁定不可用允许服务以可接受的较低性能运行或直接不启用高负载模式。不要通过提升进程权限来绕开系统保护再把后果留给现场运维。模型文件、缓存目录和日志也应有明确位置与配额。端侧磁盘通常有限下载失败、版本残留和日志膨胀都可能让后续启动出问题。版本切换需要校验完整性并保留到已验证版本的回退路径。沙箱和硬件加速要一起测试推理进程若处理来自外部的输入或插件隔离是必要的。最小权限原则、受控文件系统、受限网络和系统调用过滤都能减少异常影响。不过安全规则不能只在开发机上“能启动”就算完成。推理框架可能需要访问特定设备、共享内存或驱动接口规则过宽会留下风险过窄又可能让硬件加速静默退回 CPU。应在目标设备上逐项确认所需权限并把设备访问范围收窄到实际使用的节点。不要以宽泛的 ioctl 或任意设备访问替代验证硬件驱动与内核版本不同允许的操作也可能不同。沙箱失败时应留下不含敏感内容的诊断信息便于区分是权限、驱动还是模型运行时问题。以主业务不退化作为上线门槛上线前至少做两类压测推理负载逐步升高时主进程的时序、错误和资源余量是否仍满足目标主进程处于忙碌状态时推理服务是否会按预期排队或降级。还要模拟模型加载失败、设备加速不可用、内存接近上限和进程重启检查系统能否回到一个安全状态。端侧推理的成功不只是跑出一段回答而是在有限硬件上与既有任务和平共处。资源边界明确、隔离规则经过实机验证、失败时能够收缩才适合把它放进需要长期运行的设备。