参数量不等于实力：DeepSeek 关停 V4 Pro 后，"每字到岗"才是真成本
9月14日中午12点，DeepSeek 的 V4 Pro 独立 API 服务正式下线，所有请求转由 9月10日刚上线的 V4.1 Flash 接手（DeepSeek API 更新日志）。这个切换动作本身不大，但背后释放的信号值得细看——它等于用真金白银把"参数量大就强"这个默认认知摆到了台面上，逼所有人重新审视。
先说清楚 B 到底是什么意思。
B 是参数量单位，1B 等于十亿个参数。很多人一看到"万亿参数"就觉得牛，但参数量描述的是模型"能装多少知识"的容量上限，不等于它实际装了多少。这就像一块地面积大，不代表里面已经住满了人。
粗略估算有个 20:1 法则：1B 参数大约需要 200 亿 token 的数据才能喂到接近饱和（Chinchilla 估算）。按这个比例，27B 模型对应约 5400 亿 token 的训练数据，折算下来大概是 2.4TB 英文文本，或者 270 万本中篇小说。所以问"27B 强不强"，如果不追问"喂了多少数据、喂了多久"，这个问题本身就没有答案。
反过来想：同一批数据，喂给大模型和小模型，谁表现更好？数据充足时，大模型确实有优势；但数据不够时，大模型就像一栋空房子，装不下更多东西，还多占了地方——两者差距会缩得很小。
为了把"数据不够"这件事具象化，我拿两块 3090 显卡训了一个 4000 万参数的稠密小模型（体积只有 Qwen 27B 的 1/675），做了一组对照实验：
组 A：2000 万字百科数据，只喂 1 遍，GPU 上跑了 8 分钟。模型蹦出来的词是"攻击、容易、现在的、象征、情人、十二月、书法"——每个词都完整，但连不成一句通顺的话。loss 值约 3.3。
组 B：33 万字数据，反复喂 88 遍。输出变成了"是你的新*，*。"——典型的复读死循环。loss 值约 0.08，比组 A 低了 40 倍。
注意看：loss 更低，模型反而更"傻"。loss 下降有时候只是"背得更熟了"，而不是"学到了新东西"。在一份小语料上反复训练，本质上就是在做这件事。
这组实验把"参数上限"和"数据存量"拆成了两个独立变量。27B 能装得满，靠的是 5400 亿 token 的粮食；40M 装不满，是 20 万字填不满。同一堵墙，两种撞法。
现在把三个主流模型放到一张表里看：
- V4 Pro：总参数 1.6 万亿，MoE 架构，每字实际到岗 490 亿参数，上下文 1M
- V4.1 Flash：总参数 5520 亿，非对称 MoE 架构，每字实际到岗 80 亿参数，上下文 1M
- Qwen3.8 27B：总参数 270 亿，稠密架构，每字实际到岗 270 亿（全员），上下文 262K
第一行是"总编制"，第二行是架构类型，第三行是"每个 token 实际调用了多少参数"。很多人只盯着第一行比大小，但真正决定成本和质量的是第三行。稠密模型是"全员到岗"，MoE 模型是"点名上岗"。Flash 只点到 80 亿人，却赢了到岗 490 亿的 Pro。
Qwen3.8 27B 在这个框架里的位置其实很清晰：稠密架构，270 亿参数全员到岗。LMArena 上 Image-to-WebDev 开源第一、总榜第七、Code Arena 第九；262K 上下文；Apache 2.0 协议全开源；双 3090 本地就能跑 q8 量化（LMArena 2026-08、Qwen 模型卡、本机实测）。
它的对手从来不是 1.6 万亿的 MoE 巨兽，而是"你愿意为每个 token 的质量付多少钱"这道选择题。本地跑 27B，每个 token 成本固定、可预期、数据不出门；走 Flash API，吃的是峰谷定价——缓存命中 0.02 元/M，未命中 1 元/M，差了 50 倍，还背着官方"吞吐受限"的注脚（DeepSeek API 定价页）。
说到底，B 是装知识的上限，不是知识本身。每个 token 实际调用了多少参数，才是你为每句回答真正付的钱。Flash 用 80 亿到岗打赢 490 亿到岗，靠的不是"小"，是"挑得准、喂得对"；Qwen 27B 用全员到场的 270 亿换固定成本，靠的是"不用挑、不出门"。
两条路径没有谁绝对赢，取决于你的付费方式。但"B 大就等于强"这个默认值，从 9 月 14 号起，不能再无条件地用了。
我下一步打算把这条链闭环：同一个 40M 模型，同一份数据分别喂 1 遍和 88 遍，看"上限"和"存量"的差距具体落在哪一行数据上。留言聊聊：你觉得"每字到岗人数"该不该成为选模型的第一标准？
页:
[1]