上周四 Meta 把 Muse Spark Open 的权重放出去了,8160 亿参数,免费下载。我顺手算了笔账:全精度检查点 1.5TB,官方给的落地方案是两台 M5 Ultra 的 Mac Studio,早期媒体估算那套配置三万八千美元。
免费的是权重,要付钱的是内存。
开放模型的门槛,已经从「许可证允不允许」换成了「它在你的硬件上站不站得住」。 这个变化没什么声响,但如果你的选型表上还只有「许可证」和「单价」两列,账一定算错。
Muse Spark Open 是混合专家架构:每层 256 个专家,每个 token 只路由 8 个,激活 420 亿。
很多人看到「激活 42B」就以为这是个 420 亿参数的模型。不是。激活参数决定的是单次前向的计算量,也就是算力和单价;总参数 8160 亿决定的是常驻内存,因为所有专家都得同时在内存里待着,路由只是决定这一次用谁。
这两列不能互换,也不能只看一个。
我在电力项目里做本地部署时踩过类似的坑。变电站的远程智能巡检系统必须跑在场内的服务器上,不能上云,这不是偏好,是合规和数据口径的要求。当时选模型,我先问的是「许可证能不能商用」「社区有没有人踩过坑」,等真正装上去才发现,卡住的不是这两条,是那台机器能不能把模型常驻起来、能撑几路并发。
现在我把它写成选型表的两列:激活参数(决定单价) 和 总参数(决定部署形态)。
同一周,阶跃把 Step 5 Preview 的权重也开了:600B 总参、27B 激活、100 万 token 上下文。它有一个数字比规格更有说服力:OpenRouter 的 token 用量榜上,它排到了周榜和日榜的全球第二。
这个排名我比厂商自己给的基准更信。基准说的是「厂商说它多强」,用量榜说的是「有多少人真的在烧钱调它」。
拿到权重是一回事,把权重跑起来是另一回事。
这条规律不止在硬件上成立。
上周翻发布记录时看到一条不起眼的内容:OpenCode 的 V2 合并了一个被用户称为「重大安全回归」的变更。问题出在配置层级,企业可以在 /etc/opencode 下发一份全局策略来约束所有项目里的 agent,这个变更之后,仓库级配置可以盖掉那份全局策略。
讨论只有十几分,争议也不大。但它戳中的位置很准。
我这些年做老系统渐进改造,最常遇到的不是「没有规范」,而是「三层规范同时在,谁也说不清哪个生效」。 全局配置、项目配置、环境变量、命令行参数,还有代码里硬写的那一行。每层都是好意加上的,加起来就是一团说不清的优先级。
agent 时代这件事变严重了。以前一份代码风格配置被覆盖,最坏是格式跑偏;现在被覆盖的可能是工具白名单、权限边界、审批门。而 agent 会主动 clone 仓库、主动读配置、主动按仓库里的约定执行,等于把策略的写权限开放给了任何它能触及的代码来源。
写好一份策略,只完成了「有」。它算不算数,取决于当它和另一份冲突时谁赢。
同一周 Codex 的做法可以对照着看:它的网络代理把鉴权挪到了 DNS 查询之前,并且堵住了凭据别名绕过检查钩子的路径。说白了,不是等请求发出去再判断该不该拦,而是在最便宜的那一步之前就拦住。
检查点往上游搬,是因为下游的检查点一直在被别名绕过去。
凡是能指向同一资源的第二个名字,都是一个绕开检查点的入口。
第一件,把你的模型选型表改成两列参数。 激活参数写一列,总参数写一列,再补一列「常驻内存」,没有公开数据的就标「待确认」。这一步不花预算,今天就能改。
第二件,画一张配置层级表。 把你所有 agent 工具的配置来源列出来:全局、组织、用户、仓库、会话、提示词里的指令。然后标出哪些键不允许被下层覆盖。这张表画完,你就知道自己现在到底有没有策略。
第三件,把链路上的「别名」找出来。 凭据别名、符号链接、模型别名、包别名、命令别名,任何能指向同一资源的第二名称都算。列出来,逐个确认它经过哪一层校验。