假设团队要在一台 Linux 网关上先跑通本地问答随后把同类能力放进 RK3588 设备和手机 App。一种看似直接的选法是四个运行时各跑一次按tokens/s排名最快的作为统一技术栈。这个顺序会漏掉更早的否决条件现有模型能否生成目标运行时可加载的制品加速后端是否支持指定芯片更新模型时谁负责重新转换、编译和随 App 或设备固件发布先按交付目标缩小路线再测速度。通用 Linux/CPU 或已支持的 GPU 上若团队持有可用 GGUF 并需要轻量本地服务llama.cpp是可先验证的起点明确要使用 Rockchip 支持芯片的 NPU则先核对 RKLLM 的模型转换、Runtime 和驱动组合已有 PyTorch 模型且移动 App 团队要管理端侧推理可评估 ExecuTorch 的导出与设备后端若愿意承担面向目标 GPU 的模型库编译和应用打包MLC LLM 是另一条路径。它们并非四个可互换的播放器也没有一个脱离硬件、模型与版本的全局性能名次。下文只依据各项目公开文档讨论可交付路径。尚未在目标设备上以锁定模型、量化、上下文和提示集完成可比测试因此不提供生成速度、首 token 延迟、峰值内存或功耗排名。官方后端清单也会变化最终可用性须以项目锁定版本和目标设备为准。第一刀不是比较速度而是确认你能交付什么文件四种方案的差别先体现在模型离开开发机后是什么。llama.cpp的常见部署入口是与其实现兼容的 GGUF 模型它提供 CLI 和服务入口并列出 CPU、Metal、CUDA、Vulkan 等不同后端。这个广度使它适合用来验证“同一类本地模型能否在多种通用机器上启动”但 README 的后端列表不是每块具体板卡都可用、每种算子都会落在加速器上的保证。RKLLM 的交付对象不同。Rockchip 文档把 PC 端 RKLLM-Toolkit 转换与量化、板端 RKLLM Runtime C/C 接口、RKNPU 驱动列成一条链模型被转换成 RKLLM 格式后再在受支持的芯片上运行。当前官方仓库列出 RK3588、RK3576、RK3562 和 RV1126B 系列具体模型与量化选项仍要核对对应 SDK 和固件版本。手里只有一个 GGUF 文件不能因为目标板也有 Linux 就认定它会经 RKLLM 使用 NPU。ExecuTorch 从 PyTorch 导出模型产出供端侧 Runtime 加载的.pte。它的 LLM 路径还涉及 tokenizer、生成循环、量化与目标后端.pte不是“所有手机和加速器通用的模型文件”。选定 XNNPACK、Vulkan、Core ML 或特定 NPU 后仍需检查导出、算子覆盖和目标设备运行结果。若应用本来就维护 PyTorch 模型与移动端原生代码这条链的优势在于模型导出和 App 集成职责比较清楚而不是自动获得某种速度。MLC LLM 则把权重转换、配置生成和面向目标设备的模型库编译放到交付链中其文档说明模型库可显式编译也可在某些 Python 路径下 JIT 编译。做 iOS/Android 产品时还要决定权重是否随包携带、何时下载、如何与库及 App 版本配套。它不是把任意 GGUF 或.pte改后缀就能运行的“统一格式”。编译与打包能力有价值但把这条构建链长期维持在 CI 中也是产品团队要承担的成本。先问的交付问题llama.cppRKLLMExecuTorchMLC LLM典型模型制品兼容 GGUF转换后的 RKLLM 模型按目标导出的.pte加上生成所需组件转换权重、配置与目标平台模型库应先核对的设备边界具体 CPU/GPU 后端和模型支持Rockchip 芯片、Toolkit/Runtime/驱动组合目标 App 平台、delegate 与算子覆盖目标编译后端、运行库及打包链最容易漏掉的维护工作GGUF/量化版本与服务配置模型转换和板端软件版本锁定导出回归、App API 与后端兼容每个目标的编译、库和权重分发这张表是筛掉不成立路线的起点不是性能评分表。同一模型家族名不代表四个制品的权重、量化、tokenizer、上下文配置或生成逻辑相同。若组织要求一份模型文件原样发到所有设备先确认这一要求是否合理多数情况下需要维护同一模型来源下的多个经验证制品并在发布记录中逐一标明来源与目标。把硬件要求和产品更新方式放到同一张选择单Linux 网关先验证功能再决定是否绑定 NPU考虑一台主要做现场设备手册问答的 Linux 网关。项目还没选定 NPU只知道网络可断、需要本地 API目标是先验证可用模型与检索链路。这时先用llama.cpp的受支持模型与本地服务做功能原型比较直接模型和问答流程可以先分开验收后续再测 CPU 或受支持 GPU 的资源占用。如果网关最终限定在 Rockchip 芯片且 NPU 加速成了硬需求就不能把原型“直接搬进 NPU”应另起 RKLLM 转换、驱动兼容与回答一致性验证。是否值得增加这套转换链要由目标设备上的收益和维护成本共同决定而非原型机的速度推断。移动 App 要把模型更新放进发布链再考虑一个需要把离线摘要嵌入 Android/iOS App 的团队。它已有 PyTorch 训练与评测流程要求模型和 App 版本一起灰度发布。此时 ExecuTorch 值得先做一条端到端最小链导出一个被支持的模型明确 tokenizer 和生成代码由谁维护在目标手机上验证 CPU 或指定 delegate。若团队更倾向于为多个 GPU 目标构建专用模型库并能维护 TVM/MLC 编译及打包基础设施则可并行评估 MLC LLM。两条路都涉及 App 大小、离线首次启动、权重更新和回滚仅看到“支持 Android/iOS”不能选定产品架构。这两个任务的“同一个模型”也可能不是同一测试对象。量化方式不同输出文本质量可能变化后端算子不覆盖时可能出现导出失败、回退到 CPU 或必须换模型结构。因而先把可用的模型候选和设备能力写成可检查的配对模型来源与版本 → 转换/导出版本 → 量化方式 → 目标后端 → 运行库/驱动 → tokenizer 与生成配置。只写“选 RKLLM”或“选 MLC”无法解释一次升级失败时到底该回退哪一层。如果产品要持续 OTA这张配对表还应进入发布工单。模型权重、运行时、驱动和应用接口未必能各自独立升级先在小范围设备重放固定问题集再扩大灰度。这个版本管理问题与边缘 AI 模型、固件和配置版本的拆分相通但本文关注的是选运行时之前必须承认的制品依赖不重复讨论 OTA 流程。如果网关场景还要回答设备手册问题离线设备手册 RAG 的版本、权限与引文边界仍需单独验收运行时选型不能替代应用层的证据控制。不要让一张tokens/s截图替你决定架构要比较两个候选先固定“相同”的含义相同目标设备、供电和散热条件相同模型来源、权重及可接受的量化差异相同 tokenizer、prompt、上下文长度、并发数和生成上限。然后分别记录冷启动、首 token 时间、持续输出、峰值内存、温度、功耗和回答质量。若格式转换导致算子或量化不同不能把结果当成完全同条件的运行时横比应把差异写进结论。此处列的是建议的验收设计不是已经取得的测试数据。性能测试之前还有三个更便宜的闸口。其一转换或导出能否稳定完成生成的制品能否在指定版本 Runtime 加载其二目标后端是否真的执行了预期计算有无无法接受的 CPU 回退其三失败后能否回到上一套模型、Runtime 与配置。三关有一关不成立哪怕演示视频很快也不适合作为量产路线。把业务体验也放进验收。现场问答需要的是在可接受等待时间内给出可追溯来源手机 App 需要的是可控的首次下载和无网可用性工业终端还可能要与摄像头、UI、网络任务争用内存。不同任务的瓶颈不一样平均解码速度不能代替首屏响应、内存峰值或长时间热稳定。没有目标设备与固定版本记录时可以提出这些测试项但不能声称哪条路线已胜出。什么时候不该沿用第一候选如果现成 GGUF 在 Linux 原型上跑通但产品合同明确要求特定 Rockchip NPUllama.cpp仍可能有价值却不应仅凭通用后端列表承诺该 NPU 路径。先用目标板确认可用 backend确需 Rockchip 官方链时再评估 RKLLM。反过来如果硬件尚未锁定、模型频繁更换且团队无力维护转换矩阵过早绑定 RKLLM 会把原本可替换的模型探索变成固件兼容项目。如果移动团队已有成熟 PyTorch 导出和原生应用流水线ExecuTorch 是可核验的候选但目标模型无法稳定导出、关键算子没有目标 delegate 覆盖时不应靠“移动端友好”标签继续投入。MLC LLM 面向多平台编译有吸引力但没有人维护 TVM/编译、模型库与权重包的版本关系时也不是低成本捷径。可考虑先用更简单的路径证明业务功能等目标设备、应用分发与模型更新频率固定后再引入复杂链路。因此一个可执行的选择不是“四选一”的口号而是一份短的责任清单目标设备是什么、能交付哪种模型制品、希望使用哪个后端、失败后回退到哪组版本、谁维护转换与应用集成。回答不了其中任何一项就先在一台目标机上完成最小验证并记录不能满足的条件。若目前只是想了解Ollama 本地 AI 的部署边界可以从上层应用入口读起这篇文章讨论的是入口之下的模型制品和设备运行责任。 
长河君 · 2026/10/24 2:21:42 · 阅读 1.2k 边缘大模型运行时怎么选：先看设备与模型制品，再看加速能力
假设团队要在一台 Linux 网关上先跑通本地问答随后把同类能力放进 RK3588 设备和手机 App。一种看似直接的选法是四个运行时各跑一次按tokens/s排名最快的作为统一技术栈。这个顺序会漏掉更早的否决条件现有模型能否生成目标运行时可加载的制品加速后端是否支持指定芯片更新模型时谁负责重新转换、编译和随 App 或设备固件发布先按交付目标缩小路线再测速度。通用 Linux/CPU 或已支持的 GPU 上若团队持有可用 GGUF 并需要轻量本地服务llama.cpp是可先验证的起点明确要使用 Rockchip 支持芯片的 NPU则先核对 RKLLM 的模型转换、Runtime 和驱动组合已有 PyTorch 模型且移动 App 团队要管理端侧推理可评估 ExecuTorch 的导出与设备后端若愿意承担面向目标 GPU 的模型库编译和应用打包MLC LLM 是另一条路径。它们并非四个可互换的播放器也没有一个脱离硬件、模型与版本的全局性能名次。下文只依据各项目公开文档讨论可交付路径。尚未在目标设备上以锁定模型、量化、上下文和提示集完成可比测试因此不提供生成速度、首 token 延迟、峰值内存或功耗排名。官方后端清单也会变化最终可用性须以项目锁定版本和目标设备为准。第一刀不是比较速度而是确认你能交付什么文件四种方案的差别先体现在模型离开开发机后是什么。llama.cpp的常见部署入口是与其实现兼容的 GGUF 模型它提供 CLI 和服务入口并列出 CPU、Metal、CUDA、Vulkan 等不同后端。这个广度使它适合用来验证“同一类本地模型能否在多种通用机器上启动”但 README 的后端列表不是每块具体板卡都可用、每种算子都会落在加速器上的保证。RKLLM 的交付对象不同。Rockchip 文档把 PC 端 RKLLM-Toolkit 转换与量化、板端 RKLLM Runtime C/C 接口、RKNPU 驱动列成一条链模型被转换成 RKLLM 格式后再在受支持的芯片上运行。当前官方仓库列出 RK3588、RK3576、RK3562 和 RV1126B 系列具体模型与量化选项仍要核对对应 SDK 和固件版本。手里只有一个 GGUF 文件不能因为目标板也有 Linux 就认定它会经 RKLLM 使用 NPU。ExecuTorch 从 PyTorch 导出模型产出供端侧 Runtime 加载的.pte。它的 LLM 路径还涉及 tokenizer、生成循环、量化与目标后端.pte不是“所有手机和加速器通用的模型文件”。选定 XNNPACK、Vulkan、Core ML 或特定 NPU 后仍需检查导出、算子覆盖和目标设备运行结果。若应用本来就维护 PyTorch 模型与移动端原生代码这条链的优势在于模型导出和 App 集成职责比较清楚而不是自动获得某种速度。MLC LLM 则把权重转换、配置生成和面向目标设备的模型库编译放到交付链中其文档说明模型库可显式编译也可在某些 Python 路径下 JIT 编译。做 iOS/Android 产品时还要决定权重是否随包携带、何时下载、如何与库及 App 版本配套。它不是把任意 GGUF 或.pte改后缀就能运行的“统一格式”。编译与打包能力有价值但把这条构建链长期维持在 CI 中也是产品团队要承担的成本。先问的交付问题llama.cppRKLLMExecuTorchMLC LLM典型模型制品兼容 GGUF转换后的 RKLLM 模型按目标导出的.pte加上生成所需组件转换权重、配置与目标平台模型库应先核对的设备边界具体 CPU/GPU 后端和模型支持Rockchip 芯片、Toolkit/Runtime/驱动组合目标 App 平台、delegate 与算子覆盖目标编译后端、运行库及打包链最容易漏掉的维护工作GGUF/量化版本与服务配置模型转换和板端软件版本锁定导出回归、App API 与后端兼容每个目标的编译、库和权重分发这张表是筛掉不成立路线的起点不是性能评分表。同一模型家族名不代表四个制品的权重、量化、tokenizer、上下文配置或生成逻辑相同。若组织要求一份模型文件原样发到所有设备先确认这一要求是否合理多数情况下需要维护同一模型来源下的多个经验证制品并在发布记录中逐一标明来源与目标。把硬件要求和产品更新方式放到同一张选择单Linux 网关先验证功能再决定是否绑定 NPU考虑一台主要做现场设备手册问答的 Linux 网关。项目还没选定 NPU只知道网络可断、需要本地 API目标是先验证可用模型与检索链路。这时先用llama.cpp的受支持模型与本地服务做功能原型比较直接模型和问答流程可以先分开验收后续再测 CPU 或受支持 GPU 的资源占用。如果网关最终限定在 Rockchip 芯片且 NPU 加速成了硬需求就不能把原型“直接搬进 NPU”应另起 RKLLM 转换、驱动兼容与回答一致性验证。是否值得增加这套转换链要由目标设备上的收益和维护成本共同决定而非原型机的速度推断。移动 App 要把模型更新放进发布链再考虑一个需要把离线摘要嵌入 Android/iOS App 的团队。它已有 PyTorch 训练与评测流程要求模型和 App 版本一起灰度发布。此时 ExecuTorch 值得先做一条端到端最小链导出一个被支持的模型明确 tokenizer 和生成代码由谁维护在目标手机上验证 CPU 或指定 delegate。若团队更倾向于为多个 GPU 目标构建专用模型库并能维护 TVM/MLC 编译及打包基础设施则可并行评估 MLC LLM。两条路都涉及 App 大小、离线首次启动、权重更新和回滚仅看到“支持 Android/iOS”不能选定产品架构。这两个任务的“同一个模型”也可能不是同一测试对象。量化方式不同输出文本质量可能变化后端算子不覆盖时可能出现导出失败、回退到 CPU 或必须换模型结构。因而先把可用的模型候选和设备能力写成可检查的配对模型来源与版本 → 转换/导出版本 → 量化方式 → 目标后端 → 运行库/驱动 → tokenizer 与生成配置。只写“选 RKLLM”或“选 MLC”无法解释一次升级失败时到底该回退哪一层。如果产品要持续 OTA这张配对表还应进入发布工单。模型权重、运行时、驱动和应用接口未必能各自独立升级先在小范围设备重放固定问题集再扩大灰度。这个版本管理问题与边缘 AI 模型、固件和配置版本的拆分相通但本文关注的是选运行时之前必须承认的制品依赖不重复讨论 OTA 流程。如果网关场景还要回答设备手册问题离线设备手册 RAG 的版本、权限与引文边界仍需单独验收运行时选型不能替代应用层的证据控制。不要让一张tokens/s截图替你决定架构要比较两个候选先固定“相同”的含义相同目标设备、供电和散热条件相同模型来源、权重及可接受的量化差异相同 tokenizer、prompt、上下文长度、并发数和生成上限。然后分别记录冷启动、首 token 时间、持续输出、峰值内存、温度、功耗和回答质量。若格式转换导致算子或量化不同不能把结果当成完全同条件的运行时横比应把差异写进结论。此处列的是建议的验收设计不是已经取得的测试数据。性能测试之前还有三个更便宜的闸口。其一转换或导出能否稳定完成生成的制品能否在指定版本 Runtime 加载其二目标后端是否真的执行了预期计算有无无法接受的 CPU 回退其三失败后能否回到上一套模型、Runtime 与配置。三关有一关不成立哪怕演示视频很快也不适合作为量产路线。把业务体验也放进验收。现场问答需要的是在可接受等待时间内给出可追溯来源手机 App 需要的是可控的首次下载和无网可用性工业终端还可能要与摄像头、UI、网络任务争用内存。不同任务的瓶颈不一样平均解码速度不能代替首屏响应、内存峰值或长时间热稳定。没有目标设备与固定版本记录时可以提出这些测试项但不能声称哪条路线已胜出。什么时候不该沿用第一候选如果现成 GGUF 在 Linux 原型上跑通但产品合同明确要求特定 Rockchip NPUllama.cpp仍可能有价值却不应仅凭通用后端列表承诺该 NPU 路径。先用目标板确认可用 backend确需 Rockchip 官方链时再评估 RKLLM。反过来如果硬件尚未锁定、模型频繁更换且团队无力维护转换矩阵过早绑定 RKLLM 会把原本可替换的模型探索变成固件兼容项目。如果移动团队已有成熟 PyTorch 导出和原生应用流水线ExecuTorch 是可核验的候选但目标模型无法稳定导出、关键算子没有目标 delegate 覆盖时不应靠“移动端友好”标签继续投入。MLC LLM 面向多平台编译有吸引力但没有人维护 TVM/编译、模型库与权重包的版本关系时也不是低成本捷径。可考虑先用更简单的路径证明业务功能等目标设备、应用分发与模型更新频率固定后再引入复杂链路。因此一个可执行的选择不是“四选一”的口号而是一份短的责任清单目标设备是什么、能交付哪种模型制品、希望使用哪个后端、失败后回退到哪组版本、谁维护转换与应用集成。回答不了其中任何一项就先在一台目标机上完成最小验证并记录不能满足的条件。若目前只是想了解Ollama 本地 AI 的部署边界可以从上层应用入口读起这篇文章讨论的是入口之下的模型制品和设备运行责任。