技术/工具

vLLM 官方博客 10 月 14 日挂出一篇硬核长文：Adaptive Verification Without a Confidence Head。标题翻译成大白话就是：过去投机解码想要自适应调节草稿长度，得靠草稿模型自带的置信头；现在 vLLM 用一个在线拟合的接受率估计器，把这个依赖去掉了。博客作者宣布，置信评分能力现在对所有草稿模型开放。 为什么「有没有置信头」这么重要？ 投机解码的提速来自「小模型先猜、大模型批量验」。但草稿模型不是每次都猜得准，猜得不准还硬塞长草稿，验证环节反而变成浪费。自适应验证要解决的就是动态决定每轮验多长。传统方案要求草稿模型输出每个 token 的置信概率，也就是置信头，可现实里大量开源草稿模型根本没训这个头，自适应一直用不起来。vLLM 的方案是直接从历史接受率数据里拟合一个线性估计器，slope 与 intercept 两个参数在线滚动更新，等于用统计方法补上了置信头的角色。 部署侧现在能直接吃到什么？ 按博客的说法，能力已内置进 vLLM 主分支，使用时不再需要为草稿模型单独准备带置信头的权重。对推理团队的实际意义是：选草稿模型时，唯一的约束回归到「猜得快、猜得准」，模型阵容不再被置信头支持度卡住。上线前建议做两组压测：一组固定草稿长度做基线，一组开自适应，对比 TTFT 与端到端吞吐；接受率估计器冷启动阶段会有短暂的拟合抖动，前几百个请求不要直接进生产流量。 加速技术卷到这一代，拼的已经不是单点速度，而是能不能让普通模型组合都吃到红利。对还在自建推理服务的团队，另一个实际收益是草稿模型选型自由度提高后，不必为了自适应能力去绑定少数几个带置信头的模型，模型组合可以纯粹按接受率和延迟实测来挑。博客里也坦承了局限：拟合估计器在分布突变的场景会短暂失准，冷启动和模型热切换后的几百个请求要按预热期处理。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

九月底挂出、近期在 serving 圈被讨论的 CascadeEP（arXiv 2609.33252），专治 MoE 在 prefill 阶段的一个隐蔽瓶颈：注意力副本之间的失衡。分布式 prefill 把一个大请求切给多个注意力副本并行算，问题是哪个副本恰好命中了一个热门前缀、谁就先算完，谁分到的内容长谁就拖后腿。传统做法是大家在一道全局屏障前等齐——快的副本干等慢的，算力白白空转。CascadeEP 的整套设计，就是拆掉这道屏障。 prefill 阶段的「注意力失衡」到底卡在哪？ prefill 是一次性吃进长上下文、把所有 KV 算出来的阶段，它是算力密集的，和 decode 阶段的访存密集完全两回事。在 MoE 上做 prefill，注意力那部分是并行切到多个副本的，可一旦某个副本的数据更长、或所在 GPU 更忙，它就成了拖全队的长尾。更麻烦的是，专家计算（EP）本来要等所有注意力副本把 token 都准备好才能开始，结果就是每个专家都得停下来，眼巴巴等最慢的那个注意力副本交卷。 三道门：异步 EP、streamFFN、机会式权重拉取，各管什么？ 第一道是异步专家并行：别等所有注意力副本就绪，哪份 token 到了就让专家先算哪份，专家计算在注意力还在跑时就启动。第二道是 streamFFN：对这些陆陆续续到齐的 token，做流式批处理，在「尽早开始」和「攒够一批再算 FFN 的效率」之间找平衡，而不是来一个算一个把 kernel 启动开销打爆。第三道叫机会式专家权重拉取（OEWF）：那张跑得更快的副本，干脆主动去拉别人还没开始算的专家权重、把别人的活也接过来干。三招合起来，就是让快的别闲着、慢的别硬扛，把全局等待时间压下去。 这种「不等齐」会不会让结果出错？ 异步执行最大的工程顾虑是正确性：token 顺序、专家路由、权重拉取，稍微乱一点结果就飘。CascadeEP 的赌注是在 prefill 这种「一次前向、无自回归依赖」的阶段，token 之间本来没有 decode 那种步步依赖，天然允许乱序完成再聚合。这也是为什么它盯着 prefill 做——decode 阶段因果链一环扣一环，就没这么好松绑。对把 prefill 单独拆出来、专门服务长上下文和高并发的团队，这类「拆掉全局屏障」的思路，正是榨干 GPU 利用率的下一个主战场。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月九日前后，API 平台 Opper 放出一个叫 JEVMAN 的基准：让六个专门做快速决策的模型去玩经典街机吃豆人，每个模型打一百局，按平均得分、决策速度和执行成本排名。参战名单里有 Jev 1.13、Kev、Cloudflare 的 Clef 和 Clef-Flash、GPT-6 Luna，还有一个叫 Laya 的小模型。据榜单，Jev 1.13 以约 2750 的均分拿了头名，压过 GPT-6 Luna。这个基准火的点在于：它终于把「做选择」这件 Agent 里最频繁的小事，变成了一个能打分、能开源复现的游戏。 为什么用吃豆人考「决策模型」？ 吃豆人是个绝佳的实时决策试验场。每到一个岔路口，游戏把迷宫、豆子、幽灵的位置作为一个 JSON 状态交给模型，模型只要对「往左、往右、往上、往下」四个方向各返回一个概率，游戏就据此移动。它没有生成长文本的空间，考的就是：在带不确定性的实时环境里，你能不能快速、持续地做出不差的选择。这正是 Agent 在高频循环里天天干的事——不需要写一篇分析，只需要每几十毫秒选对下一个动作。 2 秒超时和回退规则，考的是什么？ 基准里有个很实际的设计：任何一次回答如果超过 2 秒，就被一个简单的兜底规则取代，这一步记为「回退步」。这个设计直接对准了决策模型的真实约束——在实时游戏里，慢就是输。模型光会选对还不够，得选得快。排名用的是均分并带 95% 置信区间，误差区间内的模型视为打平。这就把「质量」和「延迟」放进了同一个权衡框架：一个模型得分高但每步都卡 1.9 秒，另一个得分略低但毫秒级响应，在真实系统里谁更有用，基准会让你看清楚。 这和普通 LLM 游戏 AI 有什么不一样？ 普通让大模型玩游戏，是让它逐帧读画面、写一段推理再决定动作，又慢又贵。JEVMAN 测的是专门的决策模型——就是前面说的那种不生成文字、直接对选项吐概率的模型。它们之所以能实时玩，正因为输出是结构化概率、一次前向就出全部选项分布，延迟压得极低。这个基准的意义在于给这一类新兴的「判别式 Agent 组件」提供了第一个公开擂台：以后谁出一个新决策模型，拉进来打一百局见分晓。代码开源，你也可以把自己的模型接上去。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月六日（八日前后在 PyTorch Foundation 首页头条位置），PyTorch 工程团队发了一篇 Building Spyre as a Native PyTorch Device，讲怎么把一家叫 Spyre 的芯片，从「外接一个自定义后端」升级成 PyTorch 里的原生设备。做法是通过 torch-spyre 这个桥接层，把 PyTorch 既有的 device、allocator、stream、compiler 四套抽象，分别接到 Spyre 的运行时和固件上。其中关键一步，是给 Spyre 分配了 PrivateUse1 这个保留的设备身份代号。 第三方芯片要跑 PyTorch，过去难在哪？ PyTorch 对 CUDA、CPU 是亲儿子待遇：张量分配、计算流、图编译、内存拷贝全是内部一等公民。一家新芯片厂商要接入，传统做法是写一堆自定义 op、在 eager 模式里手动调自家 kernel，张量在 CPU 和设备之间来回拷，既慢又要改一堆上层代码。开发者写个 model.to(device)，到了非 CUDA 芯片上往往到处报错。这种「二等公民」地位，是国产和小众芯片落地大模型时最痛的工程鸿沟之一。 PrivateUse1 到底是个什么身份？ PyTorch 内部留了一个叫 PrivateUse1 的设备枚举值，专门给非官方支持的硬件留口子。拿到它，意味着 Spyre 在 PyTorch 里有了和 cuda、cpu 平起平坐的身份：你可以直接写 device=spyre，张量通过 PyTorch 的分配器常驻在 Spyre 显存里，流（stream）提供了开发者熟悉的异步语义，编译器抽象把图编译接到 Spyre 的后端。换句话说，Spyre 不再是那个需要特殊胶水的外来者，而是 PyTorch 生态默认就认识的一类设备。这层身份一旦拿到，海量已有 PyTorch 代码不用大改就能在 Spyre 上跑。 「原生设备化」对国产算力落地意味着什么？ 这件事的信号比 Spyre 本身更大。过去国产芯片落地靠的是每家自己造一套推理框架、自己做算子库，生态割裂。现在 PyTorch 官方演示了一条标准化路径：只要把 device、allocator、stream、compiler 这四块抽象接好，新硬件就能借 PyTorch 的庞大用户群直接复用整个上层生态。对任何想切入大模型训练与推理的国产芯片，这篇博客几乎是一份接入手册。当然，身份拿到只是开始——算子覆盖度、图编译器的优化深度、和 Triton 之类 kernel 生态的兼容，才是后面要慢慢补的硬功夫。 ...

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

据 Simon Willison 博客，OpenAI 在最近的 DevDay 上发布了 Jev 风格的 Decisions API。跟普通聊天接口不同，Decisions API 专门处理结构化决策：给一个输入，模型返回是或否、多个选项中的一个、或者一个评分，每个选项附带概率。 Simon Willison 看到文档后，直接让 GPT-6 Astra 读了一遍 OpenAI 的新 API 文档，然后写了一个 llm-openai-decisions 插件。这个插件接入他已有的 llm-typesafe 插件体系，让终端用户可以直接用命令行调用 OpenAI 的决策端点。整个过程就是 AI 辅助写 AI 工具。 决策 API 的工程价值在于：你不需要在业务代码里写一堆解析逻辑来从自然语言输出中提取结构化结果。模型直接返回 schema 约束好的答案和置信度，下游系统拿到就能用。这比让模型输出 JSON 再做容错解析可靠得多。 Jev 风格的决策 API 代表了大模型应用化的一个重要方向：从通用聊天到专用判断。以前你想让 AI 做内容审核，得写一大堆提示词让模型输出 JSON，然后在业务代码里解析和容错。现在直接调决策接口，模型返回带概率的选项，下游系统直接用。 Simon Willison 用 GPT-6 Astra 自己读文档写插件这件事本身就很有象征意义——AI 辅助开发 AI 工具已经成为常态。这个插件从想法到发布只用了很短时间，放在以前是不可想象的。开发者的生产力正在被 AI 本身重塑。 决策 API 跟普通聊天补全有什么区别？ 典型应用场景包括：内容审核判定、用户意图分类、工单优先级评分、风险评估打分。这些场景的共同点是：输出空间有限、需要置信度、下游系统要自动处理。用普通聊天接口做这些事，你得写一堆 prompt 工程和 JSON 解析。 为什么说这是 AI 工程化的新方向？ 值得注意的是，Ollama 在九月底也宣布支持了 Jev 风格的决策模型——TypeSafe 的 Jev API 已经可以在本地跑。这意味着决策类工作流的本地部署路径也打通了，敏感数据不用出内网。 ...

据红帽官方博客，Red Hat AI 3.4 版本引入了搭载 ZenDNN 后端的 vLLM-CPU，专门为 AMD EPYC 处理器优化 LLM 推理性能。ZenDNN 提供经过调优的计算内核和原语，让 PyTorch 等框架在 AMD CPU 上高效运行。 ZenDNN 做的事情跟 Intel 的 oneDNN 类似：把矩阵乘法、注意力机制这些高频算子替换成针对 EPYC 微架构手工优化的汇编实现，充分利用 AVX-512 指令集和大内存带宽。对于 CPU 推理这种内存带宽受限的场景，内核优化带来的提升往往比算法改进更直接。 什么时候 CPU 推理比 GPU 划算？答案是：并发量不高、延迟要求不苛刻、但你已经有大批 EPYC 服务器在跑其他业务。把 LLM 推理作为附加负载跑在现有 CPU 集群上，边际成本接近零。红帽在 MLPerf v6.1 里的 CPU-only 提交证明了这条路的可行性。 AMD 在 CPU AI 推理这条路上投入了很多年。ZenDNN 就是他们针对这个场景打造的软件栈，跟 NVIDIA 在 GPU 上做的 CUDA 类似，只是战场从显卡转移到了服务器 CPU。随着企业级 AI 应用从云端 GPU 向边缘和存量 CPU 扩散，这个市场会越来越大。 从性价比角度看，用 EPYC CPU 跑小模型做推理，每路请求的成本确实比 GPU 低。但前提是你已经有这些 CPU 在跑其他业务——如果专门为了跑 LLM 去买 CPU 服务器，那就不如直接上 GPU 了。关键在于盘活存量资源。 ...

据 Red Hat 新兴技术团队十月六日博文，Red Hat AI Inference 3.5 的 CPU 部署指南完整公开。核心方案是：用 Podman 拉取红帽官方推理容器镜像，在纯 CPU 的 x86 服务器上启动 LLM 推理服务，然后通过标准 REST API 调用。 CPU 推理的定位很明确：开发测试、小规模部署、边缘场景。不要指望用 CPU 跑 70B 模型做高并发生产——那是 GPU 的活。但如果你是一个小团队，想在内网跑一个 7B 或 8B 模型做内部知识问答，CPU 方案能帮你省掉 GPU 采购和运维成本。 配套的 cpueval CLI 工具链可以自动化做性能基准：测吞吐量、测延迟、生成可复现的报告。红帽还开源了 vllm-cpu-perf-eval 框架，用 Ansible 和 GuideLLM 做标准化测试。在 MLPerf Inference v6.1 里，红帽跟 Intel 合作的 CPU-only 提交拿到了每核心 Llama-3.1-8B 最高吞吐量。 红帽推 CPU 推理方案的战略意图很清楚：企业已经买了大量 x86 服务器，现在 GPU 太贵、太缺，能在现有硬件上跑起来的 AI 应用就先跑起来。不需要一步到位上 GPU 集群，先在 CPU 上验证业务价值，等流量上来了再考虑硬件升级。 ...

据 Simon Willison 博客和 LLM 项目更新日志，llm 0.36 版本已发布。这个由 Datasette 作者维护的命令行 LLM 工具，现在原生支持 OpenAI 最新的 GPT-6 Sol 和 GPT-6 Luna 模型——直接在终端用 llm -m gpt-6-sol 就能调用。 llm 的定位是统一命令行接口：不管后端是 OpenAI、Anthropic 还是本地模型，都用同一套命令。它通过插件系统扩展模型支持，pip install llm-openai 之后配置 API key 就能用。除了基础对话，还支持结构化输出、schema 约束和管道集成。 0.36 版本的另一个重要改动是模型插件可以声明 supports_conversation = False。有些模型只接受单轮请求，不维护对话历史——之前用 llm 的多轮会话模式会报错。现在插件自己声明不支持会话，llm CLI 就自动切到单轮模式，不再强行拼接历史。 Simon Willison 维护的 llm 工具虽然界面简单，但在开发者社区里影响力很大。它的设计哲学是：命令行应该是最通用的接口。不管你用哪个模型，输入输出的格式都应该统一。这种统一性让脚本作者不用为每个模型写不同的调用代码。 0.36 版本加入的 supports_conversation 标志，看似是个小改动，实际上反映了模型生态的一个趋势：不是所有新模型都需要多轮对话能力。有些模型就是设计来做单次推理的，硬要给它加对话历史反而会降低效果。这个标志让工具层能够正确适配不同模型的特性。 另外值得一提的是，llm 工具的所有历史记录都存在本地的 SQLite 数据库里，你可以随时用命令行搜索和回看。这种本地化的数据存储方式，对于注重隐私和数据自主的开发者来说很有吸引力。 这个命令行工具解决了什么痛点？ llm 工具最大的优势是跟 Unix 管道生态完美集成。你可以用 cat data.json | llm -m gpt-6-sol –schema output_schema.json 直接处理数据，输出结构化 JSON。这种用法在脚本和自动化流水线里特别方便。 ...