技术/工具

据 JetBrains 官方博客十月八日文章，Mellum 2.1 正式发布。这是一个 12B 参数的开源模型，专门为软件工程场景中的路由、问答和子代理任务设计。跟主打全能的大模型不同，Mellum 2.1 的目标是低延迟、高吞吐、低成本——在生产环境里当编码 Agent 的调度层用。 训练方式很有特点：用强化学习在真实开发环境中训练，模型直接跟文件系统、终端和测试框架交互。这意味着它学到的不是教科书式的代码补全，而是 Agent 循环里那种读文件、改代码、跑测试、看报错、再改的完整工作流。Apache 2.0 协议，权重在 Hugging Face 公开。 上手门槛极低：Ollama 里两行命令就能跑起来。也可以直接在 JetBrains AI Assistant 里配置为自定义本地模型。适合做私有部署场景——代码不出内网，用 Mellum 做第一层路由和简单任务，复杂任务再升级到云端大模型。 JetBrains 做开源模型这件事，在 AI 行业里算是一个独特的存在。大多数公司开源模型是为了吸引开发者生态，然后靠云服务赚钱。JetBrains 的逻辑不一样——他们卖的是 IDE 订阅，开源模型是为了让用户在自己的 IDE 里获得更好的 AI 编程体验，不管用户用的是本地模型还是云端模型。 从实际部署角度看，Mellum 2.1 最适合的场景不是替代 GPT 做复杂编码，而是作为编码 Agent 的第一层路由。用户提交一个任务，Mellum 先判断这是简单改 bug 还是需要架构设计，简单任务自己处理，复杂任务升级到更大的模型。这种分层调用能显著降低 API 成本。 为什么 JetBrains 要自己做一个编码模型？ JetBrains 做模型的逻辑跟做 IDE 一样：他们比任何人都清楚开发者每天在编辑器里反复做哪些操作。与其依赖外部大模型来理解这些模式，不如自己训练一个专门优化过的小模型。Mellum 2.1 就是这个思路的产物。 本地跑需要什么配置？ 12B 参数量在编码模型里属于轻量级。配合 GGUF 量化，一张 16GB 显存的显卡就能跑。它不适合写复杂的架构设计，但做代码路由、简单 bug 修复、生成单元测试这些子任务，延迟和成本都比调 GPT-6 划算得多。 ...

据 MarkTechPost 十月九日报道，Conway Research 旗下的 OnDevice 助手项目发布了 Saluki 27B，一个基于 Qwen3.8-27B 的 2-bit GGUF 量化版本，文件体积仅 7.89GB，采用 Apache 2.0 协议开源。最反直觉的是，这个极度压缩的版本在工具调用基准上的表现居然超过了原始 Qwen3.8-27B。 原因在于 Saluki 不是简单的权重量化，而是在 2-bit 压缩的同时做了针对工具调用场景的后训练微调。它用了 NSA 稀疏注意力和 PRISM 蒸馏技术，把模型容量集中保留在函数调用的结构化输出能力上，牺牲了部分通用对话质量，但换来了在端侧设备上的可用延迟。 部署门槛很低：一张 8GB 显存的消费级显卡就能跑，或者用 16GB 统一内存的 Mac 通过 llama.cpp 加载。适合做本地路由模型——当用户请求是简单工具调用时走 Saluki，复杂推理才调云端大模型。 从本地部署的实际体验来看，2-bit 量化的模型在生成速度上确实有明显优势——因为权重体积小，从内存加载到计算单元的时间更短。在一台普通笔记本上跑，每秒生成的 token 数跟 4-bit 版本差不多，但内存占用小了将近一半。这对于内存紧张的轻薄本来说很关键。 不过要注意，官方公布的工具调用反超原版的数据，是在特定基准测试集上的结果。实际业务场景中的工具调用往往涉及更复杂的上下文和更多的工具选项，建议你在自己的任务集上跑一遍对比。如果只是简单的两三个工具调用，Saluki 可能确实够用；如果涉及长链路的多步工具编排，还是建议用更大的模型。 2-bit 量化为什么还能保住工具调用能力？ 2-bit 量化的传统认知是精度损失太大，模型基本不可用。但 Saluki 的案例说明：当你明确知道模型只需要做好工具调用这一件事时，可以针对性地压缩其他能力，把有限的位宽预算留给函数输出的结构化字段。这跟通用模型的全场景压缩思路完全不同。 本地部署要多少显存和内存？ 实际部署时建议跟原版 Qwen3.8-27B 的 4-bit 量化版本做同任务对比测试。虽然官方说工具调用反超原版，但在长上下文和复杂推理场景下，原版肯定还是更强。把 Saluki 用在它擅长的地方才是正解。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

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 通道吃网络，别让它成为新瓶颈。拆分后务必做全链路压测，单看单侧性能没有意义。 ...

很多人第一次量化本地模型，直接跑一个默认四 bit 的 GGUF，发现能用但总觉得「有点笨」——长上下文容易忘、数字容易错。问题常常不在 bit 数，而在量化时没有给模型一份重要性矩阵。本文记录 imatrix 量化的完整流程。 imatrix 到底在量化什么？ 模型里不同权重对输出的重要性差别巨大。普通量化一刀切，把关键权重也压了。importance matrix，简称 imatrix，记录了在代表性数据上每个权重的敏感度，量化时对敏感权重保留更高精度。同是四 bit，带 imatrix 的版本在困惑度和下游任务上往往明显更稳。 采集流程分哪三步？ 第一步，准备一份与下游任务相近的校准数据，几百到几千条真实文本，别用随机数据。第二步，用量化工具在这份数据上采集 importance matrix，输出一个矩阵文件。第三步，量化时把这个文件指进去，生成带 imatrix 的 GGUF。 回测该看哪些指标才靠谱？ 采集完要验证。跑一组你真实关心的任务：长文档问答、算术、结构化输出，对比默认量化与 imatrix 版的差异。困惑度下降不代表下游一定变好，但下游明显变好通常说明量化没把关键信息压坏。 最常见的误区是什么？ 校准数据分布很关键。拿通用网页文本去校准一个专门做客服的模型，imatrix 帮不上忙。校准集要贴近你真实会遇到的输入，哪怕只有几百条，也比拿网上随便下的通用语料强。 采集一份矩阵要花多少时间？ 采集 imatrix 不是点一下就完：要在一份有代表性的数据上跑前向传播，数据越多、越长，矩阵越准，但也越耗时。对个人用户，几百条数据、十几分钟到几十分钟通常够了，不必追求上万条。采出来的矩阵要和量化版本一起存档——换了量化配置，矩阵最好重新采，别拿一张老矩阵打遍天下。 imatrix 为什么算免费午餐？ 在消费级显卡上，imatrix 是不换硬件也能提升量化质量的免费午餐。多花几十分钟采集一份贴合业务的重要性矩阵，换来的是小模型在你自己场景里的稳定性——这比再往下压半 bit 划算得多。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：imatrix量化

你的业务把命运押在一家模型 API 上，迟早会遇到一次：它限流、它涨价、它抽风返回空。前面放一层网关，把多家供应商挂在同一个 OpenAI 兼容地址后面，是性价比极高的保险。Portkey 是这类网关里上手较快的一个。 模型网关到底解决什么问题？ 不是又一个聚合 API，而是三件事：故障自动兜底，主供应商超时就切备线；按规则路由，简单问题走便宜模型、复杂问题走强模型；以及统一可观测，所有请求的 token、延迟、错误集中在一处。上层代码只认一个 base URL。 最小配置该怎么搭？ 起一个 Portkey 实例，配置里登记多家供应商的密钥，定义一条策略：默认走主模型，连续失败两次或超过超时阈值就切到备用，备用再失败切第三家。设置重试次数与退避间隔。对上层应用，请求格式完全是 OpenAI 兼容的，改一个 base URL 就接上了。 多模型路由策略怎么定？ 别让所有请求都走最贵的模型。按任务复杂度分桶：分类、摘要、抽取这类结构化任务走便宜模型；创作、推理走强模型。网关支持按请求内容或元数据路由，这套分流本身就能把账单砍掉一截。 自动兜底有什么隐患？ 自动兜底会掩盖问题——主供应商明明在持续故障，被备线悄悄兜住，你可能几周都没发现。务必打开告警：当兜底触发次数超过阈值就通知，让你知道主链路出了状况，而不是被备线蒙在鼓里。 密钥和账单该怎么管？ 多家供应商的密钥统一收在网关节点，别散落在各个业务服务里，方便轮换和吊销。更实用的是账单视角：网关把所有请求归一后，你能清楚看到每个模型实际被调了多少次、花了多少。很多团队第一次看这张表才发现，一个没人维护的旧接口每天还在偷偷调用最贵的模型——关掉它就是纯利润。这种盲区，不用网关你永远看不见。 多供应商兜底值不值得现在上？ 多供应商兜底不是大企业专属，一个网关配置就能让你的智能体在某家模型抽风时不挂。把它当成基础设施保险，成本极低，关键时刻能保住一整个下午的在线服务。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Portkey网关

做过提示词工程的人都懂这种痛：上周还好好的回复，今天改了一段系统提示，某个边角场景突然开始胡来，而你根本不知道。解法不是更小心，而是把评测变成自动化测试。本文用 DeepEval 把 LLM 评测写进 pytest，接进 CI。 一条 DeepEval 用例长什么样？ DeepEval 把评测指标封装成断言：用一个样例，包含输入与期望输出，配上一个或多个指标，例如答案相关性、事实一致性、严格匹配。写起来和普通 pytest 几乎一样：定义样例列表，循环调用被测智能体，断言指标不低于阈值。逻辑上就是：对黄金集里的每条用例，跑一遍被测流程，再断言相关分数高于你设的红线。 黄金集该怎么一步步攒起来？ 别一开始就建几百条。先从线上真实工单里挑三五十条「最容易出错」的典型问题，人工标注期望行为。每次线上翻车，就把这个案例补进黄金集——它就会变成一条永远不许再犯的回归用例。黄金集是长出来的，不是设计出来的。 把评测接进 CI 有多大成本？ 评测要调模型，比普通单测慢且花钱。做法是：提交请求级别只跑子集做冒烟，合并到主干才跑全量。再给评测成本设个上限，避免半夜 CI 跑飞烧掉一大笔 API 费。 大模型评测分数该怎么正确看待？ DeepEval 这类「用大模型评大模型」的指标不是绝对真理，它更像一个报警器：分数掉了说明有变化，值不值得修要人判断。别把它当成精确的质量分，要把它当成「改动有没有让事情变坏」的护栏。 指标一开始该选几个才合适？ 一开始别把七八个指标全挂上，每加一个指标，评测成本和噪音都涨。先选两个最贴你业务的：答案相关性和事实一致性。跑稳了，再按需加。指标是手段不是目的，你要的是「改动没让事情变坏」这一条报警线，不是一张看着漂亮却没人看的仪表盘。 为什么提示词也需要回归测试？ 提示词和智能体代码和软件一样需要回归测试。把几十条黄金用例用 DeepEval 写进 pytest，你就拥有了一张安全网——下次再改提示词，心里有底，而不是靠玄学。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：DeepEval回归