ollama上的免费模型

你刚装好 Ollama，想省下 API 的钱，结果一搜模型列表几百个，名字还都差不多，不知道该拉哪个。这篇不评谁最强，只给一套可执行的筛选路径：先按你手上的显存划范围，再按任务类型定档位，最后核许可证和实际效果。预算有限的人按这个顺序走，基本不会白下一堆跑不动的模型。

你刚装好 Ollama，想省掉 API 那笔开销，结果一搜模型库几百个条目，名字还都长得很像，不知道该拉哪一个。这篇不评谁最强，也不给你一张现成的排名，只给一条可执行的筛选路径：先按你手上的显存划范围，再按任务类型定档位，最后核许可证和真实效果。

预算有限的个人开发者按这个顺序走，基本不会白下一堆跑不动的模型。反过来，如果你先看别人推荐、再回头发现机器带不动，那才是最浪费时间的走法。下面四步，每步都配了判断标准和验证动作。

第一步：用显存把候选范围砍掉一大半

很多人挑模型是从「哪个最好」开始的，但对你来说第一道门槛是「哪个跑得动」。先查清机器可用的显存或统一内存总量，再倒推参数量上限。显存不够的时候，模型照样能下载下来，但运行时会频繁把权重卸载到内存里来回搬，生成速度掉得非常难受，体验和不能用差不多。

要注意的是，量化档位对能不能跑的影响，往往比参数量本身还大。同一个模型的不同量化版本，占用空间和运行表现差得挺多，别只看名字里带不带 q4 这种标记，具体档位怎么取舍，可以到站内的量化选型内容核对当时的说明。

• 先量出可用显存或统一内存，再决定参数量上限，而不是反过来
• 同一模型的量化档位优先试中间档，跑不动再往下退
• 候选压到 2-3 个就够了，一次拉太多既占磁盘也难做对比
• 拉之前先看一眼模型页写的硬件需求，能省掉一次无效下载

第二步：按你要干的活分类，而不是按排行榜排名

排行榜反映的是通用测试集上的表现，不一定对应你每天真正要做的事。更靠谱的做法是先把需求写成一句话，比如「读中文文档并总结」「写 Python 脚本」「中英互译」「本地知识库问答」，然后按这个类型去找模型，而不是按名次去找。

知识库问答这类场景尤其容易被误判：回答质量很大程度取决于嵌入模型选得对不对、文档切片切得好不好，换对话模型之前先把这两块排一遍。

第三步：拉下来之后怎么验证它真的能用

拉到本地只是开始，真正要紧的是验证。建议你固定一组自己的真实问题，五到十条就够，覆盖你最常做的活，然后让每个候选模型跑同一组题，人工扫一眼输出，差别马上就出来了。这比看任何评测都贴近你的实际场景。

1. 准备测试集从自己平时的需求里挑 5-10 条，写成固定题目，覆盖总结、改写、代码等不同类型。
2. 逐个跑同一组题每个候选模型跑完全部题目，把输出存下来，别边跑边删，方便回头对比。
3. 记两个速度指标记录第一条输出多久出现、整体生成快不快；如果明显变慢，通常说明显存吃紧或缓存被挤掉了。
4. 固定条件下复查同一台机器、同样的题目再做一轮，确认不是偶发卡顿，再决定留哪个。

如果拉取阶段就很慢，先别急着换模型，排查一下是不是走了默认源。站内有讲拉取加速的内容，可以照着调一遍，很多时候慢的是网络不是模型。

第四步：免费不等于随便用，许可证和隐性成本要核一遍

「能免费下载」和「能拿来商用」是两件事，很多开源权重对商用范围、用户规模或署名有附加条件。如果你打算把它接进自己的产品或给客户用，动手之前先去模型页面把许可证原文看一遍，别等做完了才发现不能用。

许可证

决定你能不能商用、要不要署名，下载前就该看，不是上线前才看

隐性成本

本地跑不是零成本，电费、硬盘占用和你调试的时间都要算进去

分层策略

高频轻任务放本地小模型，偶尔的重任务按量调用，不必一个模型打天下

想把本地跑和按量调用哪个更划算算清楚，可以到站内的价格与模型资料库核对当时的数字，再结合你自己的使用频率估一遍。机器长时间满载的电费，有时候真不见得比按量调用便宜。