想象一台塞在机房角落的边缘服务器，显存刚够装下一个半大模型。一个智能体规划器接到任务，先叫来代码模型写脚本，又叫来视觉模型看截图，中途还要检索模型补事实——三个专家模型的能力住在三份互不相同的权重里，而显存只请得下其中一份多。今天主流推理服务系统的默认假设，恰恰是「用得上的模型都装得进显存」；这个假设正在失效。
10 月 14 日提交 arXiv 的 JointServe 就是冲着这个失效去的。论文作者只有 Daijin Hu 一人，摘要页未标注机构，正文 18 页、12 张图，归类在分布式系统与机器学习交叉处，同样是未经同行评审的预印本。
朴素做法的问题不只是慢
显存不够，最直接的办法是整模型换出：用谁就把谁搬进来，搬完计算，再把原来的请回来。这条路有两个坑。其一是串行——权重传输和计算互相等待，GPU 有相当一部分时间在等数据，而不是在算。其二是断记忆——没有主机侧的 KV 恢复机制，模型一切换，会话状态直接丢弃；对多步任务来说，这等于让智能体每次换专家都失忆。论文给的崩溃场景读数更直白：那种工况下，所有整模型换出基线直接跑不完， JointServe 与它们的完成差距是 46 倍。
把显存当成一笔统一预算来抢
JointServe 的核心改动，是把权重分片和 KV 块放到同一个记账本上——两者都是驻留对象，抢的是同一笔显存预算，随负载变化调整配比。真正显出巧思的是它从智能体负载里借来的三个结构性质：调用是有向的（谁调谁，大体能提前画出来）、执行是有间隔的（两次模型调用之间留着空档）、状态是双栖的（权重和 KV 都金贵）。三个机制分别对症：意图信号触发预取——解析调用方自己的输出流，规划器话还没说完，下一个专家模型已经开头装载；部分驻留——不必整个模型搬个通透，只换增量层，把切换成本切成碎片；抢占式传输调度——给活跃会话的 KV 保底一份带宽，别让后台搬运把正干活的人挤下线。
这套设计对基础设施团队有股熟悉的亲切感：它本质上是在做智能体负载的「 mise en place」——客人点菜之前，食材按预判备好。规划器输出流当意图信号，等于让最了解下一步的人亲自剧透。
顺带一提，「显存受限」在这周不是假想敌。1941 那篇论文把测试床直接搭在一台 8GB 的 Jetson 加一台 DGX Spark 上，边跑边量 KV——边缘盒子跑多智能体，已经是进行时。
读数与它的边界
三条重放轨迹（SWE-bench、tau-bench、OSWorld）上，会话完成时间最多降 49%；对比较强的整模型换出基线降 21.7%；SLO 达成率从 2.8-24.5% 拉到 76.8-100%。数字好看，但读的时候要把边界一起读进去：轨迹是重放的历史，不是实时流量；21.7% 这个数对「选了谁当基线」很敏感；场景明说是私有与边缘部署，数据中心的结论未必照搬。
放进台谱里看
这篇论文是开放栈时刻的服务侧答案。上周我们刚看过 10 月 15 日三件开放权重同天出笼（1938），模型侧的路由叙事已经有 Ramp Router、PilotDeck 的智能路由和 Nemotron 的 Switchyard 在前面站台；JointServe 补的是路由决策的物理后果——你让规划器挑专家模型，显存就得跟着挑。往前再看，1936 里 Ramp 那个每项目计价器，量的就是这种多模型会话的账；账要算得清，底层先得把 SLO 立住。
冷水照例三盆：单作者、无评审、无多场景交叉验证；「较强基线」若由作者挑选，需等第三方复现；边缘优先的设计在数据中心里可能优势不再。但对任何在显存受限环境里跑多模型智能体的人，这篇论文值得进本周必读——它把一个迟早要遇到的问题，提前做了一遍系统的答卷。