推理服务的骨架，怎么才撑得住

选型会上大家比的是跑分。上线三个月后决定成败的，通常是模型外面那层东西。

一、发生了什么

MIT 科技评论 10 月 22 日发了一篇由 EXL 出品的文章，谈的是推理服务的骨架——围绕模型的那套工程系统，包括架构、显存管理、调度和优化决策。以下内容属于厂商口径。

文章的起点是一句判断：企业 AI 的竞争优势，越来越不取决于选了哪个模型，而取决于在模型周围搭了什么。

它给的理由是一条相互牵连的链子：服务架构影响显存占用，显存管理影响并发能力，并发能力决定批处理和调度的方式，调度又反过来决定 GPU 利用率和延迟。这些环节串起来之后，量化、投机解码、优化过的注意力机制这些技术才能兑现价值。反过来，链子上任何一环没理顺，钱花了，瓶颈还在。

文章举的例子是显存。推理时模型权重是固定的，但 KV 缓存会随并发请求数和上下文长度一起长。并发一高，即使算力还有空闲，可用的显存也可能会耗尽。这时候加卡，只是让一个效率不高的系统变得更贵。

方法上它只给了一条：先测量，再优化。找到当前最主要的那个约束，解掉，再测一次，看是不是又冒出了新的瓶颈。文章用了句挺刻薄的话——别把优化技术当卡牌收集，目标不是集齐，是找到能解掉最大瓶颈的那一张。

最后一个论点关于可替换性：今天最好的模型，明年大概率不是。骨架应该让换模型变成一次评测和配置的调整，而不是一次架构重做。

二、跟你有什么关系

技术负责人：预算该往哪投，取决于你的瓶颈在哪。如果瓶颈在显存，买更贵的卡没用；如果瓶颈在调度，换更强的模型也没用。

做应用层的团队：同一个基座模型，做客服和做文档批处理，需要的服务架构完全不同。前者要低延迟，后者可以过夜跑。用一个部署方案覆盖所有场景，一定有一边是浪费的。

采购和财务：报价单上的"每百万 token"是模型价，不是你的落地价。中间差着并发、缓存命中率、GPU 利用率三件事。

三、怎么判断

按这个顺序查，一步一测。

1. 先定工作负载，再谈模型。把请求分成两类：有人等着的（在线）和没人等的（离线）。这两类的容量规划、超时策略、降级方案都不一样，混在一张表里算，两边都不准。
2. 量出显存里的固定项和变动项。固定项是权重，变动项是随并发和上下文长度增长的缓存。算出你的卡在什么并发下会先耗尽显存，这个数字就是真实上限。
3. 再动优化技术。量化、投机解码这些不是默认打开的开关。先确认当前最大约束是显存、是算力、还是调度，再选对应的那一个，改完重新测。
4. 留一条换模型的路。把模型调用收在一层接口后面，评测集独立于模型。等新一代模型出来，你要做的是跑一遍评测、改一行配置。

四、三个别信的说法

更强的模型能解决性能问题。 模型能力解决的是答得对不对，服务架构解决的是答得快不快、贵不贵。这两件事经常反向：更聪明的模型往往更慢、更贵。

加卡就能提高并发。 只有当瓶颈是算力时才成立。如果瓶颈是显存里的缓存，加卡确实能加并发，但单位成本一点没降；如果瓶颈是调度策略，加卡的效果接近于零。

这是个中立的技术分析。 不是。文章由 EXL 出品，末尾指向它自己的工程手册系列，观点和它的服务方向一致。方法论可以借鉴，涉及"该买什么"的结论要另找依据。

五、一句话结论

模型决定上限，骨架决定你能不能拿到那个上限。

信息来源

• MIT 科技评论：怎么设计一套撑得住的推理服务，2026 年 10 月 22 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 23 日。