LiteRT-LM 与 llama.cpp 怎么选：先选运行时再下模型

LiteRT-LM 与 llama.cpp 都能成为端侧大模型运行时，但它们不是同一个模型文件的两个播放器。LiteRT-LM 使用自己的模型包和 API；llama.cpp 主要围绕 GGUF 与 C/C++ 运行时。应先确定运行时，再选择对应 artifact，而不是下载一个文件后到处寻找能打开它的库。

模型格式不同

LiteRT-LM 在 Google AI Edge 的公开仓库开发，使用自身模型包与 API。.litertlm 是运行时部署链的一部分，不能通过改名变成 GGUF。

llama.cpp 是开源 C/C++ 推理项目，主要模型格式是 GGUF。GGUF 生态包含自己的转换、量化与元数据约定。

同一个模型家族在两个生态里可能有不同量化、转换和 tokenizer 包装。对比时必须记录完整 artifact，而不是只写模型名。

硬件路径怎么比较

LiteRT 官方定位覆盖受支持平台的 CPU、GPU、NPU 路径。llama.cpp 则由自身运行时与编译后端决定执行方式。两边都不能根据宣传页直接推断某款手机会走哪条路径。

公平 POC 要使用等价任务、固定输出、明确后端证据，并保留失败与回退。若模型 artifact 本身不同，应称为“部署路径对比”，不要包装成纯运行时跑分。

Android 集成边界

无论选哪一个，都建议包在应用自己的 InferenceEngine 接口后面。业务层只认识加载、生成、取消和关闭，不直接持有运行时对象。这样才能独立测试 UI、替换模型、增加回退或评估第二运行时。

维度	LiteRT-LM	llama.cpp
主要格式	.litertlm 路径	GGUF
运行时	Google AI Edge 栈	C/C++ 项目
Android 接入	按官方 Android API 与包	自己维护 native/JNI 边界
跨平台	按 LiteRT-LM 支持范围	共享 llama.cpp/GGUF 生态
调试重点	artifact、API、delegate/后端	编译选项、JNI、后端与 GGUF

表格只描述工程边界，不代表谁更快。性能必须在目标设备实测。

Cove 为什么先走 LiteRT-LM

Cove 当前固定使用 Gemma 4 E2B 的 LiteRT-LM artifact，代码记录预期长度为 2,583,085,056 字节。这个选择适合验证 Google AI Edge 路径，但不能由此推导 llama.cpp 同模型表现。

选择清单

优先评估 LiteRT-LM，当目标模型有受支持部署包、产品以 Android/iOS 为主、团队希望验证 LiteRT 硬件路径。

优先评估 llama.cpp，当目标模型稳定提供 GGUF、团队能维护 native 集成、桌面与移动共享 GGUF 流程很重要。

同时评估两者，当 artifact 可得性或目标设备行为仍不确定。不要为了“不做选择”把两个运行时一起塞进首版，这会放大包体、测试组合和生命周期复杂度。

POC 验收

• 两边任务与输出限制一致。
• 记录完整 artifact 与量化。
• 记录运行时 revision 与构建参数。
• 确认真机执行后端。
• 测加载、代表任务、连续运行、取消和释放。
• 失败与回退进入结果。
• 用产品质量门槛而不是单一速度决定。

继续阅读 LiteRT-LM Android 教程和 本地大模型部署硬件要求。英文深度版见 Cove 运行时对比。

---

本文最后核验于 2026-09-16，不包含未经统一 artifact 和真机验证的性能排名。