## 一、开源模型信息太杂，先定三个筛子 每週都有一堆新模型冒出来，权重放出来就算"开源"。跟不过来的原因不是信息少，是没有筛选标准。 我给自己定了三个筛子：能跑起来、能力对口、许可证干净。 三个都过才值得花时间试。过不了两个的，先记个名字就行。 开源模型的信息量这几年涨得太快。一个新的榜单出来，一周就有二十个模型说自己第一。 我的做法是只留三个筛子，其余都当噪音：能不能跑、对不对口、许可干不干净。 三个筛子过完，一周通常只剩两三个值得下载的。这样反而跟得住。 ## 二、筛子一：我的机器能不能跑 先看参数量和量化支持。 七 B 级别的模型，消费级显卡量化后能跑；三十 B 以上就要看有没有人做过 GGUF 或者 AWQ 版本；七十 B 往上，多数人只能上云。 有个笨办法很有效：去模型主页找社区发布的量化文件，看下载量和更新时间。有活跃维护的，说明真有人在用。 能跑这一关，看三个数：显存占用、单次推理时长、以及量化后能不能用。 显存是最硬的限制。一个七十亿参数的模型，全精度要十几 G，量化到四位能压到四五 G。 还有一个容易忽略的点：上下文长度也会吃显存。你要跑长文，显存预算要按两倍算。 ## 三、筛子二：能力是不是我做的那件事 通用榜单参考价值有限。你要写代码就看代码补全的实际手感，要做客服就看中文指令跟随。 我的做法是准备十道自己的题，每题一句话需求，看它答得对不对。十分钟能跑完一轮，比看十个榜单快。 对不对口这件事，最容易被榜单带偏。榜单考的是通用能力，你干的是一件事。 比较实用的做法是：拿自己手上二十条真实输入，跑一遍候选模型，人工打分。二十条就够看出差别，不用等大评测。 评的时候不要只看答得对不对，还要看答错的类型。有的模型错得离谱，有的错得很像人——后者更容易修。 ## 四、筛子三：许可证有没有雷 这条最容易被跳过，后果也最重。 有的模型写着开源，但附加条款限制商用；有的要求派生模型同名发布；有的对用户量设了门槛。 真要用在商业项目里，许可证得逐条读，别只看 README 第一行那个 badge。 许可干不干净，看三样：能不能商用、要不要署名、以及衍生物怎么算。 第三样最容易出事。「模型产出的内容归谁」，很多许可证写得很模糊。 我的做法是：商用项目只用许可明确允许商用的模型，模糊的一律不用。这条线不值得冒风险。 ## 五、每週跟进的固定动作 - 周一看一次模型聚合站的更新列表，只扫标题； - 挑一到两个过筛子的，跑我那十道题； - 跑完记一行结论：能用、勉强、不能用； - 一个月回看一次这份记录。 这套动作每週花不到一小时，但半年下来能省掉大量试错。 跟进这件事，最怕的是每次从零开始。我建了一个表，四列：名字、日期、三个筛子的结论、一句话备注。 每周只做两件事：看有没有新版本，把结论更新到表里。超过两周没更新的，直接标记为搁置。 表看着土，但它能防止你把时间花在重复评估同一个模型上。这件事我踩过，浪费了差不多一个月。 补一句：别追新。 开源模型的迭代速度已经超过多数人的应用速度。你半年换一次，反而更稳。 追新的人往往在评测上花光时间，最后没做出一个能用的东西。 每週跟进的固定动作，我只有两个：看官方仓库的 release，看社区的问题列表。 release 告诉你能力变化，问题列表告诉你真实坑在哪。两个都看，十分钟。 看问题列表有个技巧：搜「OOM」和「slow」，两个词能覆盖八成抱怨。 ## 延伸参考 这一类的背景资料，万象系统之家的更新算是跟得比较紧的。 [万象系统之家](https://www.maxdo.tech/) 留一句：跟开源周报不是追新，是拿自己的题去验证。