模型选型与约束匹配

「用哪个模型」这个问题，很少由「哪个最强」决定。真正决定答案的是延迟、隐私、成本、任务复杂度这四个约束里，哪一个先咬人。通常只有一个先咬人，而它一旦确定，候选集会立刻小掉一个数量级。

有一整类任务，大模型是形状不对，而不只是贵

Liquid AI 的 LFM2.5-Encoders 是两个 230M 与 350M 的开源编码器，支持 8,192 token 上下文，长上下文场景下在 CPU 上比 ModernBERT-base 快约 3.7 倍。它瞄准的是被生成式模型遮住的那一半生产负载：意图路由、策略检查、PII 识别、文本分类。

这些任务的共同点是输出是一个标签，不是一段话，而且整天在跑、大多跑在 CPU 上。对它们来说，旗舰模型不是贵一点，是形状不对——你为一个用不上的能力付了延迟、成本和运维复杂度。

参数量不是尺寸

Inkling 是约 1 万亿总参数、41B 激活参数的 MoE 模型。这两个数字都回答不了「我跑不跑得动」：真正决定的是显存，BF16 约 2TB，NVFP4 约 600GB。

所以看规模要同时看三个数：

1. 总参数——决定权重占多大。
2. 激活参数——决定每个 token 实际算多少。
3. 目标精度下的显存占用——决定你需要几张卡。

只报总参数的比较没有信息量。

承诺的日期不是可用的日期

Kimi K3 发布时是 2.8 万亿参数、承诺月内开放权重。在权重真正落地之前，它对一个自托管团队的价值是零。把「已宣布」和「已可用」记成两列，选型表才不会骗自己。

「选多大」之外，还有「选哪一层」

GitHub 在 Copilot 改成按 API 列表价计费之后，正面回答了「既然能直接调 API，为什么还要付 Copilot」：你要自己拥有哪一层——是模型调用本身，还是围绕它的编辑器、仓库、终端、组织策略与计费控制这一整套外壳。

模型选型和边界选型是同一个决定的两半。 先定你必须拥有哪一层，再去比价格；反过来做，比出来的价格没有意义。

交给谁

判断推理引擎对某个模型的支持到了哪一级、多久能真正跑起来，是「模型与推理引擎的支持路径」；目标是一台具体的机器，是「端侧模型部署与硬件适配」；要为很多人提供服务，是「推理服务容量规划」；而读一份发布公告并决定该不该换代，是「旗舰模型发布解读与换代判断」。