Posts

九月底挂出、十月九日被技术社区重新翻出来讨论的 ID Balancing（arXiv 2609.39137），干的事听上去很跨界：它把两种主流的 MoE 负载均衡方法，统一成一个控制论里的 PID 框架。作者指出，DeepSeek 那套广为人知的「无辅助损失」负载均衡，本质上是一个固定步长的积分控制器；而 Kimi K3 用的分位数均衡，本质上是一个广义的比例控制器。在这个视角下，它们都是不完整的 PID，于是论文提出一个真正带积分和微分项的 ID 控制器，去稳定极稀疏 MoE 的训练。 MoE 训练为什么会「专家吃不饱、有的撑死」？ MoE 靠路由器把每个 token 分给几个专家，理想情况下每个专家被用到的频率差不多。但现实里路由器会「偏心」：少数几个专家越用越顺手，大部分专家常年冷门。冷门专家等于白训，模型有效容量被浪费；更糟的是训练会因此震荡、发散。传统解法是加一个辅助损失，强行惩罚不均衡——但这个损失的权重是个难调的超参，调重了模型被迫为了均衡而牺牲专业分工，调轻了又压不住。后来 DeepSeek 干脆去掉辅助损失，改成在路由器上加一个动态偏置，按历史负载微调；Kimi K3 则用分位数统计来校准路由分数。 PID 这个老框架，怎么就套到路由器头上了？ 控制论里，比例（P）控制器按当前误差大小回拉，积分（I）控制器对累积误差做修正，微分（D）控制器对误差变化率做预判。作者的洞察是：Kimi K3 的分位数均衡只看「当前负载离目标多远」并据此调整路由分数，正是比例项；DeepSeek 的无损失法按每步固定量累积修正，不随误差大小变化，正是一个没有比例、没有微分的积分项。两者都缺了一角。ID Balancing 于是保留积分项（随负载误差缩放），再补上一个微分项——只在负载误差的变化率足够大时才激活，用来在路由突然偏斜的瞬间提前刹车，而不是等偏完了再补。 这种「换个视角看老方法」，真能带来新收益吗？ 统一视角的价值，不只是好看。一旦把两种方法摆进同一个控制论坐标系，设计者就能像调工业控制器那样，系统性地考察积分饱和、微分噪声、稳定性裕度这些老问题。论文报告说这种组合在极稀疏 MoE 上训练更稳、不需要艰难调超参。它提醒的是：大模型里很多「新算法」其实是控制论、运筹学里成熟思想的转世，换个坐标系，老工程经验就能直接搬过来。对做 MoE 训练的团队，这种把调度问题翻译成控制问题的思路，比单个超参更值得收藏。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据多家科技媒体报道，十月六日前后 OpenAI 往 GitHub 上丢了一个仓库：722 篇由一个尚未发布的内部数学模型生成的手稿，被归成 372 个结果家族，整体以 Apache 2.0 协议公开。这被描述成迄今规模最大的一批「AI 生成、又经过整理」的数学成果语料。和前阵子那个「一万个智能体 88 小时攻克千禧难题」的叙事一脉相承，OpenAI 正在把自己模型的数学产量，以可下载、可引用、可复算的形式公开。 为什么要把 AI 写的论文开源出来？ 动机是双向的。对外，这是一份能力广告：它证明自家模型不只会写代码、聊天，还能在抽象数学和理论计算机科学上产出成体系的结果。对内，这是给形式化验证和后续训练备料——有了一大批经过结构化整理的手稿，研究者才能训练模型去读、去审、去补全证明。Apache 2.0 这个协议选得很聪明：宽松、可商用、不传染，等于把这批手稿当成公共基础设施往外撒，谁都能拿去做数据集、做评测、做工具。 「AI 生成 + 已验证」这个标签，到底可信到哪？ 需要泼的冷水也在这里。这批手稿是内部未发布模型的产物，外界拿不到那个模型，也拿不到完整的生成过程；所谓整理成 372 个家族，是 OpenAI 自己做的归集。媒体口径里反复强调「verified」，但具体哪些结论被 Lean 之类的证明助手逐行核验过、哪些只是「看起来对」，外部很难一眼分清。这就回到那个老问题：当一个机构同时握有生成模型、整理标准和验证权，它发布的「成果」到底是数学发现，还是一次精心编排的展示？开源的是文本，不是判断权。 对普通研究者，这批语料真正的用法是什么？ 别把它当答案库去抄。它真正的价值在于当反面教材和训练素材：看一个强模型会在哪些地方「编造」看似合理实则有洞的证明、它的错误长什么样、不同结果家族之间怎么互相引用。对做形式化验证、做定理检索、做数学 AI 评测的团队，这是一份难得的、规模够大的真实分布。但用之前务必带着批判——这不是教科书，是一个聪明但会一本正经胡说八道的学生的作业合集。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

在这一波 vLLM 安全披露里，还有一条被记作 PYSEC-2026-4198 的问题，盯的是 /score 和 /rerank 这两个端点的 late-interaction 打分。问题描述很拧巴：这两个端点在做 flash late-interaction 评分时，会从调用方可控的 X-Request-Id 请求头里，派生出每个 worker 的 query_key。一个并发请求只要复用了受害者的这个标识，就能把缓存里的查询 embedding 覆盖掉，结果是受害者的文档被拿去和攻击者的查询一起打分。 query_key 为什么要从请求头派生？ late-interaction 检索（ColBERT 那一类）要算「查询 token 向量」和「文档 token 向量」之间的最大相似度。一次打分请求里，查询这一侧的 token 向量算出来挺贵，工程上自然想缓存：同一个查询反复用，就别重复算了。于是服务端需要一个键来标识「这是谁的查询」。开发者图省事，直接拿请求方带来的 X-Request-Id 当这个键的来源——反正它本来就是用来追踪请求的。问题恰恰在于：X-Request-Id 是客户端完全可控的、服务端不做命名空间隔离的字符串。 撞一下这个头，怎么就改了别人的打分？ 既然键是客户端给的，攻击者只要猜中或复用受害者的那个 X-Request-Id，并发发一个请求，自己的查询向量就会按这个键写进缓存，覆盖掉受害者之前算好的那份。等受害者的下一个打分请求再来，它按自己的 id 去取缓存，取到的却是攻击者的查询向量——于是「受害者的文档 vs 攻击者的查询」被错误地配对打分。这等于在多租户检索服务里，把 A 的检索意图安到了 B 的文档上。官方描述里还提到共享的使用计数器也会因此把后续打分搞乱，连带可用性一起出问题。 修法为什么是「别拿请求头当身份」？ 这条漏洞的教训不是某个具体函数写错了，而是一个普遍的设计错误：把客户端自报的、用于日志追踪的字符串，当成了服务端的身份与缓存键。正确的做法是缓存键必须由服务端在内部生成、按租户/会话做命名空间隔离，客户端头只能作为日志辅助，绝不能参与状态路由。这和前面那条 cache_salt 泄漏是同一种病——缓存优化图方便时，随手把「谁是我」这件事外包给了不可信的请求方。对跑了 /score、/rerank 且开了缓存的团队，升到修复版本之外，还该自查：你的缓存键里，有没有混进任何用户可控的字符串。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月初 Cloudflare 生日周放出、随后被 InfoQ 在十月八日报道的 Clef，是它第一组开放权重的「决策模型」。和所有生成式模型反着来：Clef 不替你写一段话，它吃进一个状态（可以是文本、JSON、图片甚至视频）和一组类型化的问题 schema，然后对每个允许的选项返回一个概率。它有 27B 和 9B 两档，大的基于 Qwen3.8-27B 冻结后微调，小的 Clef-Flash 从 Qwen3.5-9B 加视觉编码器后训练，64K 上下文，Apache 2.0。Flash 档把一次类型化决策压到约 38.8 毫秒。 为什么要造一个「不生成文字」的大模型？ 生成式模型在 Agent 里的老毛病是：你问它选 A 还是 B，它给你写一段三百字分析，最后才说选 A。这段分析既贵、又慢、还可能跑偏。对一个每秒要做几百次「这条消息转发给谁、这个请求走哪个分支、这个工单分给谁」的系统，你根本不需要它写作，你只需要一个干净的概率分布。Clef 的设计就是把大模型那头的生成头，换成一个对预设选项打分的决策头：输出永远是结构化的、可比较的、能直接喂给规则引擎或博弈策略的。这是把大模型从「作家」改造成「裁判」。 冻结基座再后训练，和直接微调差在哪？ 官方做法是冻结 Qwen3.8-27B 的主体，只在上面接一个面向决策的后训练与强化学习平台。冻结基座意味着语言理解的底子不被破坏，新学的只是「在这个状态下，各选项的概率该怎么排」。这种做法的好处是稳定、可移植——同一套底层表征，换个决策任务只需重训上面那层头；坏处是它的天花板受限于基座对状态的理解，复杂到需要推理的决策，纯打分头未必够。Cloudflare 还配套放了一个 RL 微调平台，让你把自己的决策任务喂进去做适配。 它和「带约束的生成」有什么本质不同？ 表面上你也能让普通模型在几个选项里选一个，但那本质是「让它生成一个 token 再 constrain 住」，模型并没有被训练成「对选项概率建模」。Clef 走的是判别路线：输出空间直接就是选项集合，概率是被优化出来的目标，不是从文本概率里间接读的。这就是为什么它能把延迟压到几十毫秒——不做自回归逐 token 生成，一次前向直接给出全部选项的分布。对那些真正在边缘、在高频、在 Agent 循环里要反复做选择的环节，这是一条和生成式路线互补、而不是替代的赛道。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月七日到八日，做永续合约出身的 Architect Financial Technologies 上线了一个叫 Liquid Inference 的东西：一个 LLM 路由，但它不是按延迟或权重静态分流，而是对每一个请求跑一场实时拍卖。推理供应商实时出价，买方（调用方）设好性能、地域、数据合规规则等约束，最后按「满足规则的最低出价」成交。它把金融市场里那套订单簿和竞价，直接搬过来给推理定价。 静态路由和现场拍卖，差在哪？ 常见的 LLM 网关——无论是 OpenRouter 还是自建 proxy——分流逻辑大致是固定的：按模型标签、按健康检查、按预设权重轮询，出了问题再 fallback。它假设「哪个便宜、哪个快」是已知的、静态的。Liquid Inference 的赌注是这个假设错了：不同供应商在不同时刻、不同地域、不同负载下的真实成本和可用性一直在波动，静态权重永远追不上。于是它让供应商对每一个待派的请求报价，像交易所撮合订单一样，把这个请求实时分给当下最划算、又合规的那家。 一场拍卖要在毫秒级跑完，技术上怎么撑住？ 难点在延迟。普通拍卖是分钟级的，推理请求是毫秒级的，你不可能真的让几个供应商来回讨价还价。它的实现思路是：供应商持续在后台挂出对某类请求的报价（带性能、地域、数据处理规则等约束），买方请求进来时，引擎在这些「挂单」里做一轮匹配排序，挑出满足约束的最低价成交。本质上不是实时拉锯，而是把一个持续报价的订单簿拿来对单个请求做即时撮合。Architect 还拿它和 OpenRouter、Hugging Face 的托管做对比，把「每请求竞价」当成核心卖点。 这是降本神器，还是又一个金融化噱头？ 看好的一面：当推理供应商足够多、价格足够波动，这种市场化定价确实能把碎片化的闲置算力变现，买方也能压成本。存疑的一面：拍卖机制引入了新的复杂度——报价的真实性、供应商为了中标而牺牲质量的动机、以及合规约束在撮合里能不能真的被强制执行，都是问号。对开发者，眼下更实际的用法是把它当又一个带价格发现的网关，先在非关键链路上试，别一上来就把核心业务绑在一个金融化的路由上。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

在 vLLM 0.30.0 之前的另一处问题被编号为 CVE-2026-105752。它描述的场景非常具体：当请求通过 POST /v1/responses 提交一个 Harmony 工具续接（tool continuation）时，服务端要重建下一轮的引擎输入，却在重建过程里丢掉了 cache_salt 这个值。结果是，哪怕调用方本来开了缓存加盐，这条续接的前缀还是被塞进了全局的无盐缓存命名空间。在默认开启前缀缓存的部署上，一个已认证租户只要能重构出受害者的前缀，就能撞上这段缓存。 cache_salt 到底是个什么东西，为什么丢了就危险？ 前缀缓存是 vLLM 这类引擎省算力的核心手段：把一个请求里开头那段公共前缀的 KV 结果存下来，下一个请求前缀一样就直接复用。问题是缓存键是按前缀内容算的，如果大家都用同一段系统提示，那缓存键就一样——A 请求存进去的前缀表示，B 请求能直接读出来。cache_salt 就是给这个缓存键撒的一把盐：不同租户用不同盐，键就分开，互相读不到。它本质是个多租户隔离机制，靠的是「键里掺了只有你知道的随机串」。 续接为什么会把这把盐弄丢？ 罪魁在「重建」。Agent 多轮对话里，工具调用不是一次发完的，模型调一次工具、拿到结果、再接着生成，这中间服务端要把上一轮状态重新拼回引擎输入。拼的过程本来是个机械重组，开发者容易默认「前缀没变，缓存键自然沿用旧的」。但恰恰在这条 Harmony 续接路径上，重建逻辑没有把 cache_salt 这个元字段一起带过来，于是新的引擎输入落到了不加盐的默认命名空间里。一个本该隔离的会话前缀，就此和其他租户的前缀排在了同一个无盐池子里。 这条链能造成多大的实际后果？ 它不是远程代码执行，更像一条横向越界的信息泄漏：已认证的租户 A，只要能猜到或重构出租户 B 的请求前缀（比如一段公开的系统提示加固定的工具格式），就能命中 B 被无盐缓存的那一段，拿到它此前的 KV 缓存甚至触发缓存命中侧的行为差异。对多租户 API 厂商，这是把「逻辑隔离」从默认值里悄悄撤掉。修法也直接：0.30.0 要求续接重建时必须原样保留 cache_salt。这件事真正的教训是——缓存优化是性能生命线，但每一处「为了复用而做的键拼接」，都得单独审一遍隔离语义。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月八日前后的 GitHub 趋势榜上，一个叫 OpenHuman 的仓库冒到了 41.6k star、四千多 fork。它是一个用 Rust 写的智能体编排 harness，定位是本地优先（local-first）地把 AI 助手和各种模型组织起来跑在桌面上，协议选了 GPL-3.0，话题标签集中在 agent orchestration、LLM integration 和 desktop。在一大票 Python 写的 Agent 框架里，一个 Rust 本地优先的 harness 突然冲榜，本身就是个信号。 本地优先，到底和云端 Agent 框架差在哪？ 云端那套 LangGraph、AutoGen 的思路是把 Agent 当服务编排：状态存在后端、工具走 API、多用户共享一个运行时。OpenHuman 走的是另一条：你的会话、你的工具权限、你的模型密钥，默认都在你自己这台机器上，框架只是个把它们粘起来的壳。好处是隐私和可控——敏感的内部数据不必先离开本机才能被 Agent 处理；代价是它天然不适合做那种跨团队、多租户的集中式调度。它瞄准的是「我自己电脑上的那堆 AI 助手」，而不是「公司机房里的 Agent 舰队」。 为什么用 Rust 写 Agent harness，而不是 Python？ Python 生态对模型调用极其友好，但做桌面常驻、本地进程、文件系统深度集成时，Python 的内存占用、启动延迟和打包分发都让人头疼。Rust 写这类常驻后台的编排器，编译出来是单个二进制、内存可控、和系统原生集成更顺。对一个要常驻在桌面、随时接管剪贴板、文件、浏览器的 Agent，这层工程取舍很实在。当然，Rust 的代价是模型生态胶水层得自己写，和 PyTorch 那堆周边的衔接成本不低——这也是为什么它先吃 star、能不能真正用起来还要看后续迭代。 GPL-3.0 这个协议选择，释放了什么信号？ GPL-3.0 是 copyleft：谁要把它改进后闭源商用分发，就得开源。对比现在多数新 Agent 工具爱选的宽松协议，OpenHuman 选 GPL，等于摆明姿态——它要做的是一个「不能被大厂抄走当闭源服务」的本地底座。这对在意 AI 助手不被平台锁死的开发者是个拉拢。但也要提醒：GPL 的传染性意味着如果你想把它嵌进自己的闭源产品，会被协议要求整段开源，商用前务必看清。冲榜归冲榜，协议这关才是企业用户真正要过的。 ...

十月七日到八日，Scale AI labs 放出题为 Humanity’s Sixth Sense 的基准（arXiv 2610.08966，十月八日更新到 v2），专考「直觉式视觉推理」。结果扎眼：人类在这组任务上拿到约 93.1%，而目前最强的多模态模型 GPT-6-astra 只到约 53.6% 到 54%，个别口径下甚至跌到三成出头。也就是说，那些人眼扫一眼就懂的画面直觉，最前沿模型连及格线都摸不到。这不是又一个刷榜数字，而是把多模态模型一直藏在「看图说话很好」背后的短板，单独拎出来量了一遍。 直觉式视觉推理，到底测的是什么？ 它测的不是「图里有几只猫」这种可枚举的识别，而是那种人类靠经验一眼带过、却说不清规则的判断：这个物体该往哪倒、这个动作接下来会怎么演化、两张图之间那种微妙的因果与物理感。论文作者刻意把任务设计成小样本、人类凭常识即可作答的形态，再让人工按一致性标准打分。这类能力之所以叫「第六感」，是因为它几乎不来自显式标注，而是来自人在物理世界里摔过的无数次。模型没摔过，自然缺这一课。 为什么刷榜刷到顶的模型，在这却像换了个脑子？ 一个尴尬的解释是：模型擅长的是「把见过的图文对上号」，而不是「在脑子里跑一遍物理」。当题目落在训练分布的长尾——那种需要现场估计重心、动量、遮挡关系的画面——参数记忆帮不上忙，就得靠真正的世界模型去推演。而当前多数多模态模型的视觉侧更像一个巨大的检索器，把像素映射到语言空间，再让语言模型去编，编得头头是道，却没有一个在闭环里被物理约束训练过的模拟器。于是 benchmark 分越高，越可能只是「背题背得好」。 这个 54% 的差距，是模型不行还是基准太小？ 泼一盆冷水：任务集不大、评判又靠人，它能说明方向，却回答不了「模型迁移到真实世界能好多少」。基准的价值在于它把一个被 MMLU、MMMU 这类知识型测试掩盖住的缺陷，单独曝光了。对做产品的人，信号很直接：别相信多模态 demo 里那种一眼就懂的瞬间，那是精心挑过的；真要让模型操作机器人、读工业画面、判断现场状况，这道直觉坎还远没过。人在回路（human-in-the-loop）在这类场景里暂时撤不掉。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月七日，Perplexity 放出 pplx-embed-v2-late 一族多模态检索模型，分 0.6B 与 9B 两档，以 MIT 协议上了 Hugging Face。它打的不是「一个向量代表整页」那种稠密检索，而是 ColBERT 式的 late-interaction：查询和文档各自保留一串 token 级向量，检索时在 token 之间做最大相似度匹配。更关键的是它的分工——官方让 9B 那个重模型负责给语料建索引，0.6B 那个轻模型负责在线跑查询，小模型去查大模型建好的库。 为什么查询和索引用两个不同大小的模型？ 传统 embedding 服务为了对齐，查询侧和索引侧必须是同一个模型，结果就是边缘端也得扛一个大模型。Perplexity 这一族的赌注是：建索引是离线的、批量的、不怕贵，用 9B 把每页 PDF、每张图的细粒度语义压准；查询是在线的、每次请求都要扛延迟，用 0.6B 在边缘就能算。两端不必同构，只要共享同一套 token 相似度空间。这样一来，终端设备上跑一次查询的成本被压到极低，而召回质量仍由离线那个大家伙兜底。官方在 MADQA 上报告 92.4 的分数，Vidore v3 页面图这一栏做到 65.2，压过次优的 late-interaction 模型约 4.9 个百分点。 免 OCR 的 PDF 页图检索，省掉了哪道工序？ 做文档检索的老流程是：先 OCR 出文字、再切片、再向量化，OCR 错了后面全错。这一族模型直接把 PDF 页当图像喂进去，视觉编码器连同版式、图表、公式一起编码，文字只是其中一种信号。也就是说，一份扫描件、一张带复杂排版的财报、一个塞满图表的论文页，不需要先变成干净文本，就能被索引和召回。对那些版式即信息的文档，这一刀砍掉的不只是 OCR 这道工序，还有 OCR 错误向检索链路里传染的整条噪声。 小模型查大模型的库，代价和坑是什么？ 不对称不是免费的。查询侧的 0.6B 必须学会「用轻量模型的视角」去匹配重型索引里的 token，训练时要刻意对齐两端的表征空间，否则小模型吐出的向量分布和大模型索引对不上，召回就垮。late-interaction 本身还有存储代价：它存的是每文档一串 token 向量，而不是一个定长向量，索引体积远大于稠密方案。Perplexity 给的实践建议是查询与文档的 marker 位置要对齐，用 PyLate 的团队尤其要注意。对自建 RAG 的团队，真正值得抄的不是某个分数，而是这个「离线重、在线轻」的不对称思路。 ...

据 NVD 与多个漏洞追踪站披露，vLLM 在 0.30.0 之前存在一条被编号为 CVE-2026-105754 的多模态预处理缺陷。问题出在 /inference/v1/generate 这个端点：服务端信任了来自请求体的 kwargs_data 字段、features.mm_hashes 里的缓存标识，以及 features.mm_placeholders 里的占位区间，还允许在传输层直接选定多模态字段处理器，却没有把这些东西重新绑定到当前激活模型的渲染契约上。这一串信任默认，被合成一个可以跨请求污染共享状态的攻击面。 伪造一个网格几何，为什么能直接打死共享 EngineCore？ vLLM 的多模态后端要把一张图或一段视频切成若干 patch 网格，再交给视觉编码器算一次、缓存起来，后面文本 token 直接引用这个编码器缓存。问题在于，这个网格几何（grid geometry）和占位长度是由请求方说了算的。攻击者传一个类型错误、或者一个非正的占位长度，共享的 EngineCore 进程会直接崩溃。注意是「共享」二字：EngineCore 是整个服务端所有请求共用的那个推理核心，一个畸形请求打崩它，等于让所有在线用户一起吃 DoS。这不是把自己的容器搞挂，是把同台服务上别人的会话一起端掉。 知道受害者的内容哈希，能干什么更阴的事？ 更值得警惕的是缓存投毒这一段。多模态预处理为了省算力，会对输入内容算一个哈希，内容没变就直接复用上一次的编码器结果。一旦攻击者知道、或者能诱导出受害者的内容哈希，他就可以伪造一个相同哈希的条目写进缓存，让受害者下一次请求取回的是被污染过的编码器状态。官方描述里还提到，被丢弃的稀疏占位掩码会改变重放时的传输语义。换句话说，这不是简单的读文件，而是在多租户共享推理服务里，把别人缓存里的「视觉理解结果」换成自己想要的版本。对一个把 vLLM 当多租户网关、开了前缀与编码器缓存的部署来说，这条链的危害远超普通崩溃。 0.30.0 到底补了哪几刀？ 官方在 0.30.0 里把这些字段全部收回到服务端校验：网格几何与字段类型强制对齐激活模型的渲染契约，占位长度必须为正，缓存哈希与请求做绑定，多模态处理器不再由传输层任意指定。顺带一提，这不是孤例——同一波披露里还有 CVE-2026-105752、PYSEC-2026-4198 等若干条，都是 vLLM 在多模态与缓存边界上的信任问题。跑多租户、开了缓存、又把 0.30.0 之前版本挂在公网的团队，现在最该做的一件事就是升版本、并把 /inference 这一类内部端点收敛到内网。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论