顺序反过来最容易踩坑
多数人是先看到某个模型很火，装完发现跑不动，再回头找小一号的版本。正确的顺序是先量清楚自己的显存，再决定模型规模和量化档位——因为这两件事共同决定了能不能跑。
- 先看显卡显存（不是内存），显存是硬约束
- 内存决定加载与缓存的余量，显存决定能不能驻留
- 如果没有独显，CPU 推理可行但速度会有明显落差，量化档位要更激进
- 统一内存架构的机器（如 Mac）显存与内存共享，可用空间相对宽松
量化档位怎么选
量化是用精度换空间与速度。经验上：能用更高的档位就别降，尤其是代码与推理类任务，降到低位之后质量下滑会比对话任务明显得多。先降模型规模，再考虑降量化档位，通常更划算。
- 先用推荐档位跑一遍，记录显存占用与速度
- 如果跑不动，优先换更小的模型规模
- 仍不行再降一档量化，重新测同一批任务的表现
- 质量掉得明显就退回去，改用云端或换硬件
推理框架的差别在哪
不同框架的取舍很清楚：面向个人一把梭的框架装完就能聊，图省事；面向服务的框架吞吐高、并发强，但要自己配环境。个人试用选前者，要对外提供服务选后者。
最后提醒一句：本地跑的价值在于数据不出机器和不受额度限制，代价是硬件成本与运维时间。如果你的使用频率不高，先用云端 API 通常是更理性的选择。
本地部署的成本不在装的那一小时，而在之后每次都要自己处理的问题。