本地大模型部署硬件要求：别只看显存和参数量
搜“本地大模型部署硬件要求”时，最容易看到的是一张“多少 B 模型需要多少 GB 内存”的表。它可以做第一轮排除，却不能告诉你某个模型在某台设备上是否稳定。真正决定结果的是模型 artifact、量化、上下文、运行时、执行后端、输入模态和应用本身共同形成的工作集。
文件能放下，不等于内存能跑下
推理峰值内存至少包含模型权重、运行时缓冲、KV cache、输入张量、操作系统余量与内存分配行为。图片、音频、相机预览、数据库和 UI 还会继续占用进程资源，所以“模型文件只有多少 GB”不能直接等价为“多少 GB RAM 就能跑”。
应用还要考虑连续使用。同一个短 prompt 成功，只说明这一次工作集没有触发失败；上下文增长、多轮生成、连续拍照或长音频可能把峰值推到另一个位置。
参数量只能算权重下界
权重存储的粗略下界可以写成：
权重字节数 ≈ 参数量 × 每个权重的 bit 数 ÷ 8
这不是最终下载大小，也不是峰值内存。真实 artifact 可能包含元数据、tokenizer、混合精度权重和架构特有结构；运行时加载后还会产生额外分配。
因此，同样标成 INT4 的两个文件也不一定一样大，更不能只凭“4 bit”断言它们输出质量相同。
上下文会持续占内存
语言模型在生成时需要保存与上下文相关的中间状态。对话越长、RAG 塞入的材料越多、输出上限越大，这部分工作集越可能增长。产品若宣传支持长文档，就必须用最长承诺输入测试，而不是只跑一句问候语。
多模态任务还要加入图片与音频张量。OCR、看图问答和语音转录的内存轨迹，不能用纯文本测试代替。
运行时与后端会改变结果
LiteRT-LM、llama.cpp、ONNX Runtime 等运行时的模型格式、缓冲管理和硬件路径不同。即使模型家族相同，换运行时或换 artifact 也应重新测量。
手机有 NPU 不代表所有算子自动落到 NPU。发布时要记录实际执行路径；若后端不可用后回退 CPU，也要把回退后的体验作为独立结果。
用 Cove 的实际文件说明口径
Cove 当前固定的 Gemma 4 E2B LiteRT-LM artifact 在代码中记录的预期大小为 2,583,085,056 字节。这个数字适合该文件的下载和存储预检，不代表所有 Gemma 4 E2B 包都一样大，也不代表加载峰值就是这个数字。
好的硬件要求页应把三类数据分开：模型卡的参考规格、实际交付文件信息、真机测量结果。把它们压成一个“最低 4GB”之类的徽章，会让读者误以为结论比证据更确定。
真正可用的测试表
| 阶段 | 需要记录 |
|---|---|
| 启动基线 | App 未加载模型时的进程状态 |
| 模型加载 | artifact、运行时、后端、加载结果 |
| 代表任务 | 产品真实输入与输出上限 |
| 最大承诺 | 最长上下文或最大图片/音频输入 |
| 连续运行 | 多次任务后的峰值与失败 |
| 生命周期 | 后台、恢复、进程重建与释放 |
| 回退 | 首选后端不可用时的结果 |
Cove 仓库当前还没有完整真机 benchmark 数据集，因此本页只给方法，不发布机型兼容和性能结论。后续设备页必须从包含设备、芯片、系统、artifact、runtime、backend、输入、内存、温控与失败结果的原始记录生成。
选硬件时的判断顺序
- 先写清任务和最大输入。
- 确定运行时与 artifact。
- 用公式做第一轮不可能项排除。
- 在最低目标设备上测加载与代表任务。
- 再测最长上下文、多模态与连续使用。
- 记录失败和回退，不只保留成功结果。
- 用实测记录生成兼容表。
模型选择可继续看 Gemma 4 本地部署与 LiteRT-LM Android 教程。英文测量方法见 Cove On-Device AI RAM Requirements。
本文最后核验于 2026-09-16。文中没有给出未经真机验证的最低 RAM 或机型结论。
留言讨论
评论发布后会被人工复核，违规内容将被删除。
如果发表没有反应，可以前往联系我们告诉我们。