边缘设备跑大模型，硬件先看内存还是 NPU：一套选型顺序

采购清单上写着“8 GB 内存、6 TOPS NPU”并不能回答设备助手能否离线完成一次长文档问答。前者没说明系统和模型分别能用多少内存后者没说明目标模型能否被这个 NPU 的运行时接收。**先固定模型、量化格式、上下文和同时在线的会话数再核算内存与后端最后才比较加速能力和整机功耗。**顺序反过来样机可能能展示一轮短对话却在真实文档、并发或热稳态下退出。这是一套采购前的筛选方法不是 RK3588、GPU 板卡或其他设备的性能排行。没有同一模型、同一输入和目标整机的测量记录就不能说哪块板的响应更快、更省电或更适合量产。先写下要运行的任务而不是先挑芯片“运行一个 7B 模型”仍然不是可验收的需求。技术负责人至少要把输入长度、期望输出长度、同时请求数、是否附带检索或语音模块以及断网时必须完成的动作写在同一页。两台都能加载权重的设备在长上下文和多会话下可能产生完全不同的内存压力。把这些条件留到采购之后后续测试只能证明选中的板卡哪里不合适却很难改变硬件边界。例如一台只接收几十字指令的设备控制面板与要读多页维修手册、保留对话历史的现场助手虽然都可能使用“本地 LLM”但前者的提示长度和峰值缓存较小后者还要为检索索引、文档片段和应用服务留空间。若产品还要同时显示视频或处理语音模型进程能启动并不代表整机任务能够并行完成。如果任务是设备手册问答还要把检索与文档更新纳入负载卡离线设备手册 RAG 的验证边界讨论的是这部分系统条件不能拿模型本身的内存预算替代。把可验收条件写成负载卡负载卡不需要先填想象中的 tokens/s。可以先固定模型名称及版本、量化文件、运行时及版本、最大输入与输出 token、并发上限和后台进程然后列出能接受的响应等待、断网功能和外壳温度约束。模型、量化和上下文有任一项改变就不能直接沿用上一轮的内存或速度结论。这张卡还要说明失败时怎么处理是提示用户缩短材料、切换较小模型、排队处理还是允许联网回退。没有降级路径的“硬件刚好够用”在文档越来越长或同时请求增加后很容易变成不可维护的承诺。内存预算要算运行时不是看模型文件能否存下模型文件放得进 eMMC只说明存储容量可能足够。推理期间权重需要以运行时支持的方式映射或装载注意力计算使用的 KV cache 会随着请求条件改变此外还有计算工作区、输入处理和操作系统占用。可以先把预算拆成五格权重驻留、KV cache、运行时工作区、应用与系统预留、并发或其他任务增量。采购前若只能给出模型文件大小却填不出其余几格内存容量还不能定板。​Hugging Face 的缓存说明​明确指出KV cache 在长上下文生成中可能占据显著内存缓存卸载与量化是在内存和延迟之间做取舍不能把它们当成免费扩容。llama.cpp的 server 配置也将上下文、并行槽位、KV cache 类型及其是否卸载、模型层卸载等列为独立参数。这些选项会改变实际的内存分布因此“同一个 GGUF 文件”也不足以保证两套运行配置具有相同峰值。量化先解决容量问题再验证质量和延迟降低权重精度通常能减少权重占用但并不自动缩小所有缓存、计算缓冲或操作系统开销。更重要的是目标模型能否使用某种量化格式取决于选定运行时和后端。若 4-bit 权重使模型得以装载却让目标任务的回答质量下降或者把瓶颈转到 CPU 与内存传输这个方案仍未通过产品验收。不要把“8 GB”当成固定安全线。相同容量下一块板的系统镜像、显示任务和 GPU/NPU 共享内存占用可能不同。正确做法是先在目标系统启动全部常驻服务记录可用内存再以负载卡跑冷启动、最长输入、连续请求及并发记录进程与整机峰值。如果峰值一直接近可用内存系统还需要为日志、升级、故障恢复和后续模型版本留余量。余量大小应由目标设备的实测和风险要求确定不能引用别人的板卡数字代替。后端兼容性排在 TOPS 前面TOPS 描述的是某类计算能力指标并不等于指定模型的端到端生成速度。模型算子、量化格式、驱动、内核与运行时之间必须有可执行的组合。以 Rockchip 为例其 RKLLM 官方说明​列出支持的平台和模型族同时说明需要先在 PC 端用 Toolkit 转换再由板端 Runtime、C API 和 NPU 驱动运行。读到“支持 RK3588”或“支持某模型族”最多能决定它值得进入验证清单不能直接推断任意版本权重可以复制到板上启动。通用运行时与厂商专用 NPU 路径也不能简单排成快慢榜。前者可能让同一个模型格式在更多设备上部署后者可能要求转换模型并冻结工具链、驱动和镜像版本。若团队没有维护该转换链与板级镜像的能力即使芯片标称加速能力可观后续每次换模型都可能成为一次兼容性项目。若产品确实要求特定 NPU则先取一份目标模型完成转换、板端启动和关键算子验证再谈采购数量。PyTorch ExecuTorch 的 LLM 文档同样把模型导出、部署和目标后端作为具体步骤“框架支持端侧 LLM”不是一张跨所有 SoC 的性能保证书。选硬件时应该要求供方交出目标模型、运行时、驱动和系统镜像的明确版本组合以及升级后谁负责重新验证。这比只给一个 NPU 指标更接近可交付的产品条件。若还没决定用哪条软件栈可先按​​​​​​​边缘大模型运行时的模型制品与后端选择缩小候选本文只处理硬件是否能承载选定路线的问题。带宽和持续散热决定“能跑”能否变成“可用”内存装得下、后端也能启动之后仍要看整机是否能持续服务。生成期间会反复访问权重与缓存模型越大、上下文越长、并发越多内存通道和数据移动越可能成为约束。NPU、GPU、CPU 与显示、摄像头或网络任务共享的资源不同单次空载演示不能推断设备在业务负载下的响应。此处不能从公开规格反算一个可信的用户体验数字必须在目标板上测。建议把短对话与长文档问答分开测再把单会话与上限并发分开测。记录首 token 等待、后续 token 间隔、进程与系统峰值内存、频率、温度和整机功率持续运行到热状态稳定后再看是否降频、延迟是否漂移。对需要全天在线的设备冷启动的一分钟演示只能说明功能路径通了不能证明持续负载合格。标称内存带宽只能帮助排除明显不合适的候选不能直接换算 token/s。若目标板能读取内存控制器计数器就在同一模型、上下文和并发设置下分别记录空载与显示、摄像等整机任务并行时的内存流量同时对照首 token 等待和后续 token 间隔。若没有可用计数器也可以固定输入和模型版本比较加入并行任务前后的延迟与频率但不要把这种差值写成精确的带宽利用率。容量够、后端也匹配却在并行任务下出现明显延迟漂移时再进一步排查内存通路和任务争用而不是直接断言 NPU 算力不足。供电和外壳也会改变结论。开放式开发板在桌面上散热正常不代表装进无风扇机壳、靠墙安装或被其他模块加热后仍能保持相同频率。若整机还承担视频显示、语音采集或网关通信测试时就让这些任务一起运行。只有这样模型所需的内存、带宽与热预算才与最终产品接近。下图强调验证的先后关系容量不够时不应继续争论 TOPS后端尚未跑通时也不能把标称算力当成采购依据。四条部署路线怎么逐步淘汰候选路线先核对的门槛通过后仍要承担的代价CPU 为主的通用 Linux 板目标量化格式能否运行内存与上下文峰值是否留有余量可能需要更小模型、较短上下文或更宽松的响应时间以实测判断带 GPU 的边缘板权重、KV cache 与其他应用能否在实际内存体系中共存功耗、散热、驱动和 GPU 内存分配需要整机验证厂商 NPU 板卡目标模型能否转换算子、量化、驱动与镜像版本是否匹配转换链和版本维护、模型迁移与板端调试不可省云端或混合方案断网、隐私、成本及响应时延是否允许联网网络依赖、数据治理与持续服务费用需要明确这个表不是性能结论而是淘汰顺序。若权重和运行时峰值无法放进目标内存先缩小模型或换硬件若专用后端不支持目标模型不要用更高 TOPS 试图弥补兼容问题若热稳态下响应无法接受再比较散热设计、模型量化、加速后端或混合部署。每次只更换一个关键条件才知道改善来自哪里。什么时候不值得坚持本地大模型如果设备只需要执行固定指令、检索少量结构化状态复杂生成模型可能比规则、传统分类器或云端能力更难维护。若模型必须频繁升级但设备的内存和驱动余量很小硬件一次性定板会把后续更新锁死。若业务允许联网、数据可以依法合规送出而目标体验在本地热稳态下始终达不到要求混合或云端架构应进入同一张评审表而不是被“必须本地”口号提前排除。离线仍是刚需时也不必把所有任务塞进同一个大模型。可以先限定设备端必须完成的意图识别、手册检索或简短问答把较复杂的问题留给明确的失败提示或可用时的云端回退。这样减少的是产品必须保证的负载而不是用不可靠的硬件估算掩盖问题。定板前该留下什么证据一份可信的选型记录不需要漂亮的 TOPS 排名但必须能让另一位工程师重跑模型与量化文件的版本、运行时和驱动版本、系统镜像、上下文与并发配置、常驻服务、供电和散热条件、测试输入以及峰值内存与热稳态下的响应记录。指标不必都好看但缺失项必须标注“尚未测”不能用官方支持矩阵填空。当前文章只依据公开资料给出筛选次序**先让具体工作负载有位置再确认内存、后端和整机持续条件。**真正的采购结论需要在目标板与目标机壳上用同一负载完成复核。若这一步还没做最稳妥的决定是保留两条可验证候选而不是提前宣布某个 NPU 或某个内存容量“足够”。