Posts

今年 4 月 15 日前后，OX Security 披露了一起被称作「AI 供应链之母」的漏洞：MCP 的 STDIO 传输接口存在系统性远程命令执行缺陷。Cloud Security Alliance 的研究笔记估算，受影响实例约 20 万个，背后供应链包下载量超过 1.5 亿次，后续累计演进出 11 个 CVE。 为什么说它是设计缺陷而不是代码 bug？ 关键在于：这不是 Anthropic 官方 SDK 在某一行代码写错了，而是 STDIO 传输这个默认通道本身的设计选择——Python、TypeScript、Java、Rust 各语言官方 SDK 都把用户可控的配置一路传到 shell 执行。由于所有下游项目都信任参考实现，同一个缺陷被复制进了成千上万个 MCP server。Anthropic 后来也确认了这一行为。 换句话说，漏洞不是被「写出来」的，是被「设计出来」的，然后通过 SDK 默认值扩散到整个生态。 这个漏洞对企业实际意味着什么？ 任何能影响 MCP server 配置的人，都可能在宿主机上执行任意命令。这比传统 Web 漏洞更隐蔽，因为 MCP server 往往以开发者或自动化 Agent 的高权限后台身份运行。NIST 在其智能体安全材料里，已把 MCP、A2A、ACP 一并列为「不安全协议」。 面对 STDIO RCE 该怎么加固？ 不要把 MCP server 暴露在公网；用容器或沙箱隔离工具进程；升级到修复后的 SDK；对 server 配置做签名校验，拒绝来历不明的工具描述。把 MCP 当作一段会被模型自动调用的代码来审计，而不是当作无害插件。 这轮 STDIO RCE 给行业敲了什么警钟？ 这轮 STDIO RCE 给整个 Agent 行业敲了警钟：协议默认安全，必须从第一版就设计进去，而不是事后补 CVE。 ...

vLLM 团队 7 月 14 日发了与 TileRT 合作的博客，标题点出一个常被忽略的洞察：当 prefill 与 decode 分离之后，decode 侧其实是可以拔插的。 为什么 decode 侧值得单独做一个引擎？ prefill 是算力密集，堆矩阵乘优化就行；decode 是内存带宽密集，每吐一个 token 都要把整份权重从 HBM 读一遍。两类负载对引擎设计的要求完全不同。分离之后，prefill 池可以用一套优化，decode 池则可以换上为「低延迟流式输出」量身定做的引擎。 TileRT 就是这样一个面向延迟关键场景的专用 decode 后端。它把 decode 阶段的算子排布、访存模式重新组织，目标是把 token 间延迟压稳，而不是追求单批次最大吞吐。 可插拔 decode 带来什么架构启示？ 这件事的意义超出 vLLM 本身：它说明推理栈正在模块化。prefill、decode、路由、缓存各成一层，谁的实现更好就替换谁。对云厂商，这意味着可以针对自己的硬件做 decode 后端，而不必维护整套推理框架。 落地时该怎么选专用 decode 引擎？ 如果你的业务是对话式、对首 token 与流式延迟敏感，值得关注可插拔 decode 引擎；如果是批量离线处理，吞吐优先，专用 decode 带来的边际收益有限。 专用 decode 引擎是不是人人都该上？ 推理服务的「微服务化」已经开始。未来选推理栈，不再是选一个全家桶，而是像拼乐高一样选 prefill 池、decode 引擎、路由层各自最优的组合。 什么情况下反而不该追这个新引擎？ 可插拔 decode 引擎听上去很美，但它面向的是「延迟敏感、高并发流式」这一类特定负载。如果你的业务是离线批量生成、夜间跑批，吞吐与单位成本比毫秒级延迟更重要，那 decode 侧专用优化带来的收益有限，反而引入额外运维复杂度。判断标准很简单：打开你的线上 SLA，如果核心指标是「首 token 后多久出完一段」且用户在盯着屏幕等，那就值得上专用 decode；如果用户根本不看流式过程，提交后等结果就行，留在通用引擎上更划算。架构选择永远跟着负载走。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TileRT解码 ...

vLLM V1 功能表里，FP8 KV Cache 已经标为可用。它解决的是推理服务最头疼的问题：长上下文把 KV cache 撑爆 HBM，能同时服务的并发数被迫砍半。 FP8 KV 到底能省下多少显存？ KV cache 的大小约等于「层数 × 序列长度 × KV 头数 × 头维度 × 字节数」。BF16 下每个元素占 2 字节，压到 FP8 的 E4M3 格式后变成 1 字节，同等 HBM 能装下约两倍长的上下文或两倍并发。在 GB300 NVL72 这类靠 HBM 容量决定吞吐的机器上，这直接转化为每百万 token 的成本下降。 省显存的代价藏在哪里？ 权重量化大家已经很熟，KV 量化的特殊之处在于：KV cache 里存的是历史注意力信息，一旦量化误差在长序列里逐步累积，模型对遥远位置的注意力会漂移，出现「长上下文末尾忘事」。所以 FP8 KV 不是免费午餐——短上下文几乎无感，超长上下文要专门评测召回质量。 什么场景该开 FP8 KV、什么场景不该？ 上下文在 32K 以内、并发吃紧，大胆开 FP8 KV；上下文逼近 1M、且任务强依赖远距离检索，先拿你的真实请求集测一遍准确率，再决定是否回退 BF16。vLLM 里通过相关开关开启，灰度切流即可。 FP8 KV 在推理部署里排什么位置？ FP8 KV Cache 会和 prefix caching、PD 分离一起，成为 2026 年推理部署的标准三件套。容量换精度，是这笔账的本质。 ...

vLLM 团队 8 月 6 日发了一篇博客：在 Qwen3.5 上把总吞吐做到单 GPU 约 25K TPS。这个数字背后，是一次对「混合架构」的服务化攻坚。 全注意力加 GDN 为什么让服务化变难？ Qwen3.5 不是纯 Transformer，而是把全注意力层与 Gated Delta Network（GDN）层叠在一起。GDN 属于线性/SSM 一路的高效结构，状态表示与注意力的 KV cache 完全不同。这带来两个工程难题：怎么在 Blackwell GPU 上把 GDN 算快，以及怎么在 prefill 与 decode worker 之间正确搬运这种异构状态。 25K TPS/GPU 这个数字是怎么挤出来的？ vLLM 的做法分两路：在算力侧针对 Blackwell 对 GDN 算子做专门加速；在通信侧扩展 NIXL 分离服务路线，让注意力 KV 与 GDN 状态都能跨 worker 传递。博客特别提到，SSM 支持 P/D 分离是社区沿着 NIXL 路线推出来的——这说明开源推理栈对新架构的适配速度，已经快到能跟上新模型发布节奏。 这对要上 Qwen3.5 的部署者意味着什么？ 如果你要上 Qwen3.5 这类混合架构模型，别拿纯 Transformer 的经验直接套：prefix caching 的行为、P/D 分离的可用性、甚至默认参数都可能不同。上线前按官方部署提示逐项核对，尤其关注混合缓存开关。 混合架构给部署者提了什么醒？ 25K TPS/GPU 证明了混合架构既能省显存、又能在新硬件上跑出高吞吐。未来模型不会再是清一色注意力，推理栈必须学会同时伺候两种状态。 ...

在多副本推理集群里，最浪费的一件事是：同一个系统提示被十个副本各算一遍。vLLM 自带 prefix caching 能在单实例内复用 KV，但请求被 round-robin 随机打散后，缓存命中率随副本数上升反而下降。llm-d 要解决的就是这层跨副本的调度。 llm-d 怎么把路由从抽签变成查表？ llm-d 不满足于轮询，而是读取 vLLM 吐出的 KV-cache 事件，知道哪个副本上已经缓存了哪段前缀。新请求进来，路由层直接把它送到已经持有该前缀的那台副本，而不是重新算一遍。这把跨副本的缓存命中从碰运气变成了确定性查表。 分布式 KV 为什么要全局索引加分层卸载？ 光会路由还不够。llm-d 维护一个全局索引，记录每个 token 块住在哪个副本上。当显存吃紧，它还能把冷缓存分层卸载到 CPU 内存乃至本地 SSD，需要时再拉回来。这样 prefix 缓存不再是显存里的易失品，而变成一个可跨层管理的资源池。 开 prefix-aware 路由之前要注意什么？ 开 prefix-aware 路由的前提，是你的请求前缀真的有共享结构——固定系统提示、共享工具描述、长文档多轮问答。如果每次请求前缀都完全不同，路由再聪明也无的放矢。先统计你的缓存命中分布，再决定上不上 llm-d。 推理优化为什么从单实例走向集群调度？ 推理优化正在从「单实例内核调优」走向「集群级缓存调度」。llm-d 代表的方向是：把 KV 缓存当成一个分布式数据库来管，而不是每个实例自己的临时仓库。 这里有一个被忽视的前提你知道吗？ prefix-aware 路由要生效，前缀必须真的可缓存。如果你的系统提示里嵌了时间戳、用户名这类每次都变的字段，前缀哈希立刻失配，路由层再聪明也命不中。所以上 llm-d 之前，先做一件事：把系统提示里的动态内容全部挪到消息后半段，让公共前缀尽可能长。这一步往往不花一分钱，却能把缓存命中率拉高一截。再配合全局索引与分层卸载，你会发现集群总吞吐上去了，而新请求的平均等待反而下降。缓存这门生意，本质是把「重复计算」变成「一次计算到处复用」。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：llm-d路由

vLLM 文档里 Disaggregated Prefilling 仍标着 experimental，但已经是 2026 年大规模推理服务的主流方向之一。核心想法一句话：把 prefill 与 decode 拆到不同 GPU 池，分别优化。 prefill 与 decode 为什么是两种完全不同的瓶颈？ 一次请求进来，prefill 阶段要并行读完整段提示，是算力密集型，瓶颈在矩阵乘；decode 阶段逐个吐 token，是内存带宽密集型，瓶颈在把权重从 HBM 搬到计算单元。混在同一个 GPU 上跑，两者互相抢资源：一个长 prefill 会堵住正在 decode 的请求，让 token 间延迟（ITL）抖动。 拆成两池后，prefill 池专心吃算力，decode 池专心吃带宽，首 token 延迟（TTFT）与 token 间延迟（ITL）可以独立调优，甚至配不同的并行策略。 到底什么时候才值得做 P/D 分离？ 请求短、并发低的小服务，拆了反而多一次 KV 搬运的开销。当线上同时存在「大量长文档预填充」与「高并发流式输出」两类负载时，拆分的收益才压过搬运成本。vLLM 现在支持通过 connector 把 prefill 算好的 KV 块传到 decode 实例，靠 NIXL 这类高速通道做跨节点传输。 P/D 分离是不是抄大厂架构就行？ PD 分离不是银弹，而是一道容量规划题。先量出你线上 TTFT 与 ITL 哪个先触 SLA，再决定拆不拆、怎么配比两池 GPU。盲目抄大厂架构，常常是花钱买复杂度。 prefill 池与 decode 池该怎么配比？ 做容量规划时，先分别统计 TTFT 与 ITL 的线上达标率。如果 TTFT 先顶不住，说明瓶颈在 prefill 池，该加 prefill 侧 GPU；如果 ITL 抖动，说明 decode 池挤，该加 decode 侧。一个常见错误是按 1 比 1 平均分配两池，实际长上下文场景里 prefill 算力需求常常远大于 decode。建议从 prefill 多配起步，再根据监控回调。还要预留 KV 跨节点传输的带宽预算——NIXL 通道吃网络，别让它成为新瓶颈。拆分后务必做全链路压测，单看单侧性能没有意义。 ...

翻开 DeepSeek V4 公开技术文档，多数人直奔 MoE 与上下文长度，却容易漏掉一个不起眼的名词：流形约束超连接，简称 mHC。它改的是深度学习最基础的那根骨架——残差连接。 残差连接好好的，为什么需要加约束？ 从 ResNet 以来，残差连接让深层网络可以训练，但层与层之间的信息流是自由生长的：每一层的输出随意叠加回主干。在超大 MoE 模型里，这种自由度会放大信号方差，个别层的输出可能主导整条残差流，训练后期出现不稳定。 mHC 的做法是把每层的残差映射约束到双随机矩阵构成的流形上，也就是数学上的 Birkhoff 多面体。直观理解：它要求各层对主干的贡献「既公平又归一」，既不让某一层喧宾夺主，又保证信息在深层网络里均匀流动。 mHC 这类底层改动为什么没人谈却很重要？ 这类改动不像换 MoE 专家数那样有话题度，但它直接影响两件事：训练能不能稳定跑到极致规模，以及推理时输出会不会突然跑偏。对做大模型训练的团队，mHC 这类「把结构先验写进网络」的思路，比单纯堆参数更决定上限。 把 mHC 写进 model card 对社区意味着什么？ DeepSeek 把 mHC 写进公开 model card，等于把一个原本只在内部实验室流传的训练技巧摆上桌面。开源社区可以复现、消融、改进——这也是 V4 技术文档开放的真正价值：比权重更值钱的，是设计权重时的那些约束。 这件事对自己训练模型的人有什么启发？ 如果你在微调或预训练自己的模型，残差流的稳定性往往是被忽略的瓶颈。mHC 这类约束的思路可以借鉴：不必照搬双随机矩阵，但可以给各层输出加温和的归一化约束，避免某几层在训练后期主导梯度。观察手段也简单——画出各层残差贡献随训练步数的曲线，看是否出现个别层异常突出。如果出现，就说明你的网络在「押注少数层」，长期看会限制规模上限。这类底层改动平时看不见，一旦出问题就是训练崩在半路。把约束写进网络结构，比靠调学习曲线去救要可靠得多。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：mHC超连接

DeepSeek 更新日志给出的两个参考分放在一起读很有意思：GPQA Diamond 90.9，HLE 36.8。前者已经接近理科博士水平，后者却连四成都不到。这 54 分的落差，正是当前前沿模型能力边界最诚实的写照。 GPQA 与 HLE 这两个基准到底在考什么？ GPQA Diamond 是研究生级别的科学多选题，题目相对封闭、答案唯一，靠知识检索与逻辑推演就能拿下。HLE（Humanity’s Last Exam）则刻意收集那些即便专家也要查资料、有争议、信息高度不对称的难题，目的就是让模型「考不过」。90.9 与 36.8 的对比说明：在结构清晰的知识型任务上，模型已经很强；但在需要跨领域综合判断、容忍不确定性的开放难题上，它仍有巨大鸿沟。 90.9 与 36.8 的落差为什么重要？ 很多宣传只挑高分基准说事儿。只看 GPQA，会觉得 AGI 近在咫尺；加上 HLE，才发现模型在「不知道自己不知道」的地方依然脆弱。对企业采购，这意味着：把模型用在有标准答案的环节，可靠性可观；把它用在需要权衡的高风险决策上，仍需人类兜底。 面对榜单，正确的读法是什么？ 别只看单一最高分，把知识型基准与开放难题基准对照着看。前沿模型的真实水位，约等于两者之间的位置，而不是那个漂亮的 90.9。 这个落差怎么用在模型采购决策里？ 给企业做模型选型时，建议建立两张表：一张知识型基准（GPQA、MMLU 类），一张开放难题型基准（HLE 类）。把候选模型放上去对照，而不是只看厂商宣传的最高分。如果一个模型知识分很高、开放分很低，它适合做客服、摘要这类有标准答案的活；两张表都过得去，才敢让它碰需要权衡的决策。对普通用户，记住一个朴素原则：模型说得越自信，越要想想它是不是在一个「其实不确定」的问题上硬给了答案。36.8 这个分数，就是这份谦逊的量化依据。 说到底，榜单是用来照出边界的，不是用来制造幻觉的。把 90.9 与 36.8 并排贴在墙上，团队才不会在乐观与悲观之间反复横跳，而是老老实实知道自己站在哪、离下一道坎还有多远。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：HLE基准

DeepSeek 更新日志在描述 V4.1-Flash 时特意点出「具备原生多模态视觉理解能力」。这个措辞值得多停一秒：它意味着视觉不再是事后挂上去的插件，而是和语言主干一起训练、一起推理。 外挂 CLIP 的老路线到底有什么历史包袱？ 早期多模态做法是把一个预训练视觉编码器（类似 CLIP）抽出来，加一层投影，把图像特征塞进语言模型的词嵌入空间。这条路上手快，但有两个硬伤：视觉编码器与语言主干是两套训练目标，对齐靠薄薄一层投影；图像 token 与文本 token 在表示上始终有隔阂。 原生多模态到底在架构上改了什么？ 原生多模态让图像 patch 直接作为输入序列的一部分进入主干，与文本共享同一套注意力与专家路由。好处是视觉与语言在联合训练中互相校准，文档理解、图表推理这类「图文绑定」任务更自然。代价是训练流水线更复杂，视觉编码器的改动会直接波及语言能力，需要小心平衡。 原生多模态对应用层意味着什么？ 对开发者，原生多模态最直接的影响是「少一次模型切换」。过去要先调视觉模型再把结果喂给语言模型，现在一次调用同时拿到图文理解。在 OCR、截图排错、PDF 问答这类场景，链路变短、延迟变低、失败点变少。 怎么判断一个模型是真原生还是假原生？ 2026 年下半年，原生多模态会从旗舰下放到 Flash 档。判断一个模型是不是真原生，看它的技术文档如何描述视觉 token 与主干的融合方式——只说「支持图片输入」的，多半仍是外挂。 这条自检清单能帮你认出真原生吗？ 判断一家模型是不是原生多模态，可以问三个问题：技术文档是否说明视觉 token 与语言主干共享注意力；一次调用能否同时完成图文问答与推理，而非先识图再转文本；图表、截图这类含结构信息的输入，表现是否显著优于外挂模型。三个问题里中两个，才算真原生。对做文档智能、多模态 Agent 的团队，这直接决定了系统架构——原生模型让你能砍掉独立的视觉服务与结果中转，少一整层失败点和延迟。但也要留意，原生多模态对 OCR 这类纯文字任务未必更省，按场景搭配仍是常态。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：原生多模态

过去一年，行业学会了一件事：让模型在回答前多想一会儿，正确率就能涨。这就是 test-time compute scaling。但到 2026 年，这条曲线开始显出边际递减的形状。 多想一步，到底值多少钱？ 以 DeepSeek-V4.1-Flash 为例，Artificial Analysis 估它完成一项基准任务平均约 0.03 美元。如果把思维链拉长三倍，单任务成本可能逼近 0.1 美元甚至更高，而正确率的提升往往从「每多花一倍算力涨 10 分」衰减到「涨 2 分」。HLE 36.8 这个分数也在提醒：即便无限延长思考，最难的开放题仍不是「想久一点」就能解决的。 为什么思考越长，边际收益越递减？ 第一，可验证领域红利已被吃掉。数学、代码这类能机器验证的任务，长思维链带来的提升最明显，但早期低垂果实已摘完。 第二，错误会随步数累积。思考链越长，中间某一步走偏后自我纠正的概率越低，长度反而成了幻觉的温床。 第三，算力不是免费的。多花的每一秒都占用 GPU，在高并发场景里，等待首 token 的用户不会为你的「深度思考」买单。 不堆思考时长，那该怎么提正确率？ 不要无脑开最长思考预算。按任务分级：客观事实问答走最短；多步规划给中等预算；数学证明才开放长链路。并把「验证器」接进来——模型想完先自检，再决定是否继续想，比线性拉长更省。 test-time compute 走到 2026 年该怎么定位？ test-time compute 没有失效，但它从「越多越好」进入了「精准投放」阶段。2026 下半年的竞争，是看谁能用最少的思考步数拿到足够的正确率。 有没有一个粗算公式帮你找到性价比拐点？ 粗略估计，正确率随思考时长的提升类似一条对数曲线：前 50% 的算力贡献大部分增益，后 50% 只换来零头。工程上可以这样做灰度：对同一批请求，分别用短、中、长三档思考预算跑，画出正确率与成本的散点。你要找的是曲线斜率开始变平的那个拐点——在拐点之前加预算值得，过了拐点就该停。多数团队会发现自己长期在拐点右侧白烧钱。把预算从最长档降到拐点档，正确率几乎不掉，账单却能砍掉一大块。这才是 test-time compute 时代真正的省钱姿势。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：测试时计算