采购清单上写着“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 或某个内存容量“足够”。
