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