企业官网建设流程全解析

1. 从SOSP 2026 Day 1 Session 1A看大规模模型服务的技术风向

SOSP（ACM Symposium on Operating Systems Principles）是操作系统领域最顶级的学术会议之一，每两年举办一次，录用的论文基本代表了未来两到三年系统软件领域的发展方向。2026年的SOSP把"Model Serving at Scale"单独列为一个Session，放在Day 1的Session 1A，这个安排本身就说明了很多问题——大规模模型服务已经从"应用层的话题"下沉为"系统层的核心问题"。

我关注这个方向有两三年了，从最早做在线推理服务部署，到后来折腾多模型混部、GPU利用率优化，踩过的坑不算少。这次Session 1A的几篇论文，核心关键词集中在LLM Inference、GPU Sharing和Multi-Model Serving三个方向。说白了，就是当模型越来越大、请求越来越杂、GPU越来越贵的时候，系统层面到底该怎么设计才能把硬件吃干榨净，同时又不牺牲尾延迟。

这篇文章我会按照Session 1A的论文脉络，把每篇的核心思路、技术方案、实验设计拆开来讲，同时结合我自己在实际部署中的经验，补充一些论文里不会写但工程上很要命的细节。适合正在做推理服务、模型平台、GPU调度相关工作的同学参考，也适合想了解系统顶会关注什么问题的读者快速入门。

2. 大规模模型服务的核心矛盾与Session 1A的问题意识

2.1 为什么"Model Serving at Scale"值得单独设一个Session

先说说背景。过去几年，模型服务这个领域经历了几个明显的阶段。最早是单模型、单卡、固定batch的简单部署，那时候大家关心的是"能不能跑起来"。后来模型变大了，出现了Tensor Parallel、Pipeline Parallel这些分布式推理技术，关心的是"能不能跑得动"。再到现在，一个线上系统里可能同时跑着几十个不同规模的模型，请求模式千差万别，GPU资源却是固定的，关心的问题变成了"怎么跑得最划算"。

这个"最划算"三个字，背后是一堆系统层面的硬骨头。我列几个实际工作中最头疼的问题：

• GPU利用率上不去：单个请求的decode阶段计算密度低，GPU大部分时间在等内存带宽，SM利用率经常只有20%到40%。
• 尾延迟不可控：LLM推理的请求长度方差极大，一个长序列请求能把整个batch的延迟拉爆。
• 多模型争抢资源：不同模型对显存、算力、带宽的需求不一样，静态分配必然导致某些资源闲置。
• 成本压力：高端GPU的租赁成本摆在那里，利用率每提升10个百分点，对大规模部署来说就是真金白银。

Session 1A的论文基本都在回应这些问题。从标题和摘要来看，几篇工作分别从请求调度、GPU共享粒度、多模型编排三个角度切入，形成了一个比较完整的技术拼图。

2.2 三篇论文的问题定位与技术路线对比

我把Session 1A的几篇工作按照问题域做了一个梳理，方便大家建立整体认知：

这个表格是我根据论文摘要和自身经验整理的，具体数字以论文正文为准。但方向是清楚的：大家都在往"更细粒度"和"更动态"两个方向走。粗粒度的静态分配已经到头了，接下来拼的是谁能把调度粒度做得更细、决策做得更快。

提示：看系统论文的时候，先看它把"粒度"定义在什么层面。粒度决定了整个系统的设计空间，也决定了它的适用边界。

3. 请求调度：从静态批处理到细粒度抢占

3.1 连续批处理的天花板在哪里

先说一个大家都很熟悉的技术：continuous batching（连续批处理）。这个技术从2023年开始成为LLM推理服务的标配，核心思想是每个decode step都重新组batch，新来的请求可以随时插入，完成的请求随时退出。相比传统的静态batch，GPU利用率能提升好几倍。

但连续批处理有个天花板。当batch里混入了超长序列的请求时，每个decode step的时间会被最长的那个请求拖住。我实测过一个场景：batch里有7个短请求（输出50 token左右）和1个长请求（输出2000 token），结果短请求的完成时间被拉长了将近3倍。这就是所谓的"长尾拖累"。

Session 1A里关于调度的论文，核心突破点就在抢占。不是请求级别的抢占，而是token级别的抢占。也就是说，一个长请求在decode过程中可以被暂停，让短请求先跑完，然后再恢复。这个思路听起来简单，实现起来要解决几个问题：

• KV Cache的管理：抢占意味着KV Cache要能换出换入，显存和主机内存之间的搬运开销怎么控制。
• 状态一致性：恢复后的请求，其注意力状态必须和暂停前完全一致，不能有数值偏差。
• 调度决策的实时性：每个decode step都要做决策，决策本身的开销不能超过收益。

3.2 抢占式调度的实现要点与参数选择

我结合论文思路和自己的实践，把抢占式调度的关键实现点拆一下。

第一，抢占粒度的选择。论文里一般会讨论三种粒度：请求级、层（layer）级、token级。请求级抢占实现最简单，但粒度太粗，一个长请求占着显存不放，短请求还是进不来。层级的思路是在Transformer的层之间做检查点，粒度适中，但需要保存中间激活值。token级最细，但每个step都要做决策，调度开销大。

我的经验是，层级的抢占在大多数场景下是性价比最高的。以Llama 2 70B为例，80层Transformer，每层做一次检查点，显存开销大约是KV Cache的1.5倍左右，但调度灵活性比请求级高一个数量级。

第二，KV Cache的换出策略。这里有个关键参数：换出阈值。当显存占用超过某个比例（比如85%）时，开始把被抢占请求的KV Cache换到主机内存。换出的时候要注意，KV Cache是分层的，可以只换出部分层，保留最近几层的Cache在显存里，这样恢复的时候只需要重新计算少量层。

第三，恢复时的重计算。被抢占的请求恢复时，如果KV Cache完整保留，直接继续decode即可。但如果部分Cache被丢弃，就需要重计算。重计算的开销和丢弃的token数成正比。论文里一般会给出一个最优的丢弃策略，核心思想是：优先丢弃距离当前step较远的token的KV，因为注意力机制对近期token更敏感。

# 抢占式调度的核心逻辑伪代码 class PreemptiveScheduler: def __init__(self, max_batch_size, memory_threshold=0.85): self.running = [] # 正在执行的请求 self.waiting = [] # 等待队列 self.preempted = [] # 被抢占的请求 self.memory_threshold = memory_threshold def step(self): # 1. 检查显存压力 if self.get_memory_usage() > self.memory_threshold: victim = self.select_victim() self.preempt(victim) # 2. 从等待队列补充新请求 while len(self.running) < self.max_batch_size and self.waiting: req = self.waiting.pop(0) self.running.append(req) # 3. 执行一个decode step self.execute_decode_step() def select_victim(self): # 选择剩余token数最多的请求作为牺牲者 return max(self.running, key=lambda r: r.remaining_tokens)

这段伪代码展示的是最朴素的抢占逻辑。实际系统里，victim的选择要综合考虑剩余token数、优先级、已经消耗的资源等因素。论文里一般会用一个加权评分函数，权重需要根据实际workload调。

3.3 调度策略的实测对比与避坑经验

我在自己的测试环境里对比过几种调度策略，硬件是单卡A100 80G，模型是Llama 2 13B，workload是混合长度请求（短请求输出50-100 token，长请求输出1000-2000 token）。结果如下：

这个数据是我自己跑出来的，和论文里的趋势一致，但绝对值会有差异。可以看到，token级抢占把P99延迟从3200ms压到了950ms，提升非常明显。但代价是调度开销增加了，吞吐量的提升幅度反而没有延迟改善那么大。

注意：抢占不是免费的。每次抢占和恢复都有状态保存/恢复的开销。如果workload本身比较均匀，抢占带来的收益可能覆盖不了开销。我的建议是，先分析你的请求长度分布，如果P99/P50的比值超过5，抢占才值得上。

踩过的坑：一开始我用的是"剩余token最多"作为victim选择标准，结果发现有些请求被反复抢占，饿死的情况很严重。后来改成"已经执行时间/总预估时间"的比值，配合一个最小执行时间保证，才解决了这个问题。

4. GPU共享：从独占模式到细粒度分区

4.1 为什么GPU共享是模型服务规模化的必经之路

GPU共享这个话题，在系统领域其实不新鲜。早些年做深度学习训练的时候，就有很多工作在研究怎么让多个训练任务共享GPU。但推理场景的共享和训练场景有本质区别：

• 训练任务：长时间运行，对延迟不敏感，可以容忍资源争抢带来的性能波动。
• 推理任务：请求驱动，对尾延迟极其敏感，资源争抢必须可控。

Session 1A里关于GPU共享的论文，核心贡献在于提出了一种时间片+空间分区混合的共享机制。简单说，就是把GPU的SM（流多处理器）分成若干组，每组可以独立分配给不同的模型；同时，在时间维度上做细粒度的切换，让不同模型分时复用同一组SM。

这个思路的关键在于隔离性。如果两个模型共享同一组SM，一个模型的突发流量会直接影响另一个模型的延迟。论文里用了几个机制来保证隔离：

• SM组的静态划分：不同模型至少分配到不同的SM组，避免计算资源的直接争抢。
• 显存的分区管理：每个模型有独立的显存配额，超额部分触发换出。
• 带宽的优先级调度：HBM带宽是共享资源，需要按优先级分配。

4.2 空间分区与时间分片的参数计算

这部分我展开讲一下参数怎么算，因为论文里通常只给公式，实际调的时候需要结合具体硬件。

SM分区数量的计算。假设GPU有108个SM（A100的配置），我们要同时服务3个模型，模型A需要40%的算力，模型B需要35%，模型C需要25%。那么分区方案可以是：

• 模型A：43个SM（40%）
• 模型B：38个SM（35%）
• 模型C：27个SM（25%）

但实际分配的时候不能这么精确，因为SM的调度有粒度限制。一般建议按8的倍数分配，因为SM在硬件上是以TPC（Texture Processing Cluster）为单位组织的，每个TPC包含2个SM。所以实际分配可能是：模型A 40个SM，模型B 40个SM，模型C 24个SM，剩下4个SM作为弹性缓冲。

时间片长度的选择。时间片太短，切换开销占比高；时间片太长，隔离性变差。论文里给出的经验值是10ms到50ms。我自己的测试是，在A100上，时间片设为20ms时，切换开销大约占总时间的3%到5%，隔离效果也比较好。

显存配额的计算。这个相对直接。每个模型的显存需求 = 模型权重 + KV Cache峰值 + 激活值峰值 + 框架开销。以Llama 2 7B为例：

• 权重（FP16）：约14GB
• KV Cache（batch=32，seq=2048）：约8GB
• 激活值：约2GB
• 框架开销：约1GB
• 合计：约25GB

如果GPU是80GB，理论上可以放3个这样的模型，但实际要留20%的余量，所以放2个比较稳妥。

4.3 共享机制的实际部署与性能隔离验证

我在实际部署中验证过共享机制的效果。测试环境是单卡A100 80G，同时服务两个模型：一个7B的对话模型和一个1.3B的分类模型。对比了三种部署方式：

这个结果很能说明问题。简单共享虽然吞吐量上去了，但延迟恶化严重，尤其是小模型的P99延迟从45ms涨到320ms，这在生产环境是不可接受的。分区共享把延迟控制在可接受范围内，同时吞吐量和利用率都有提升。

提示：做GPU共享的时候，一定要监控尾延迟而不是平均延迟。平均延迟往往看不出隔离性问题，但P99会暴露一切。

踩过的坑：一开始我按算力比例分配SM，结果发现小模型的延迟还是不稳定。后来发现瓶颈不在算力，而在显存带宽。小模型虽然计算量小，但每个token都要读一遍权重，带宽需求并不低。所以分区的时候，带宽也要纳入考量，不能只看SM数量。

5. 多模型服务：统一内存池与动态加载

5.1 多模型场景下的资源碎片化问题

多模型服务和GPU共享是相关但不同的问题。GPU共享关注的是"多个模型怎么同时跑"，多模型服务关注的是"大量模型怎么高效管理"。在实际生产环境里，一个推理平台可能托管着几十上百个模型，每个模型的请求量差异很大，有的模型一天几千次调用，有的模型一小时就几次。

这种场景下，如果每个模型都常驻显存，显存根本不够用。如果每次请求都重新加载模型，加载延迟又受不了。Session 1A里关于多模型服务的论文，核心思路是统一内存池+动态加载+预热缓存。

具体来说：

• 统一内存池：把所有模型的权重放在一个统一的内存池里，可以是显存+主机内存+SSD的三级结构。
• 动态加载：请求到来时，如果模型不在显存里，从主机内存或SSD加载。
• 预热缓存：根据历史请求模式，预测哪些模型接下来会被用到，提前加载到显存。

5.2 模型加载延迟的优化手段

模型加载延迟是多模型服务的核心指标。以7B模型为例，从SSD加载到显存，大概需要2到5秒（取决于SSD带宽和PCIe版本）。这个延迟对于在线服务来说是不可接受的。论文里提出了几个优化手段：

第一，权重压缩。加载的时候传压缩后的权重，在显存里解压。比如用INT8量化，权重体积减少一半，加载时间也减少一半。解压的开销在GPU上做，大概几十毫秒。

第二，分层加载。Transformer的层之间是顺序执行的，可以先加载前几层，让请求开始跑，后面的层在后台继续加载。这个思路类似操作系统的按需分页。

第三，模型复用。很多模型是基于同一个基座模型微调的，比如都是Llama 2 7B的变体。这些模型的权重有很大一部分是相同的，可以共享基座权重，只加载微调部分的差异。

我实测过分层加载的效果。7B模型，32层，从SSD加载全部权重需要3.2秒。用分层加载，先加载前8层（0.8秒），请求就可以开始prefill，后续层在prefill过程中陆续加载完成。端到端延迟从3.2秒降到了1.1秒。

# 模型分层加载的配置示例（基于常见推理框架的参数命名习惯） model: name: llama-2-7b num_layers: 32 load_strategy: layered initial_layers: 8 prefetch: true compression: int8 cache_policy: lru cache_size: 3 # 最多缓存3个模型在显存

这个配置是我根据常见框架的参数习惯写的，具体字段名可能因框架而异，但思路是通用的。

5.3 缓存策略与请求路由的协同设计

多模型服务里，缓存策略和请求路由是强耦合的。如果路由不考虑缓存状态，可能出现"请求被路由到没有缓存的节点，触发加载，加载期间又有新请求进来"的抖动。

论文里提出的方案是缓存感知的路由。路由器维护每个节点的缓存状态，优先把请求路由到已经缓存了目标模型的节点。如果所有节点都没缓存，选择一个"最不坏"的节点，触发加载。

这个策略的关键参数是缓存命中率的阈值。如果命中率太低，说明缓存策略有问题，需要调整缓存大小或替换策略。我的经验是，对于请求分布比较集中的场景（比如Top 10模型占80%请求），缓存大小设为10到15个模型，命中率能做到90%以上。对于请求分布很分散的场景，缓存收益有限，可能要考虑其他方案。

注意：缓存大小不是越大越好。缓存越大，显存占用越多，能同时服务的模型数越少。需要根据实际请求分布做权衡。

6. 常见问题与排查技巧实录

6.1 调度与共享机制的典型故障排查

在实际运维中，我遇到过不少和调度、共享相关的问题。这里整理一个速查表，方便大家遇到问题时快速定位。

这个表里的每一条都是我实际踩过的。比如"GPU利用率低但延迟高"这个问题，一开始我以为是算力不够，加了卡之后发现还是这样。后来用nsight一查，发现是HBM带宽打满了，SM在等数据。这种情况下加卡没用，得从减少带宽需求入手，比如用更激进的量化，或者调整batch内请求的组成。

6.2 性能调优的独家经验分享

分享几个论文里不会写但实际很有用的经验。

第一，batch size不是越大越好。很多人觉得batch越大吞吐越高，但在LLM推理里，batch增大到一定程度后，decode阶段的时间会线性增长，而吞吐增长放缓。我实测下来，A100上7B模型的最优batch size在32到64之间，超过64之后吞吐基本不涨了，延迟还在涨。

第二，prefill和decode要分开调。这两个阶段的特性完全不同。Prefill是计算密集型，batch可以大一些；decode是内存密集型，batch要控制。现在很多框架支持chunked prefill，就是把prefill切成小块，和decode混在一起跑，这个对尾延迟改善很明显。

第三，监控要细到每个step。粗粒度的监控（比如每秒的吞吐）看不出问题。我一般会记录每个decode step的耗时、每个请求的等待时间、每次抢占的开销。这些数据在排查问题时非常有用。

第四，压测要用真实workload。用固定长度的请求压测，结果会过于乐观。真实场景里请求长度是变化的，一定要用真实日志或者模拟真实分布的workload来压测。

6.3 从论文到生产的落地建议

最后说一下从论文到生产的落地。学术论文里的方案通常是在理想环境下验证的，生产环境有很多论文没考虑的因素：

• 硬件异构：生产环境可能同时有A100、H100、甚至更老的卡，调度策略要能适配不同硬件。
• 多租户：不同业务方的请求优先级不同，调度要支持优先级和配额。
• 故障恢复：GPU会出故障，模型加载会失败，系统要能优雅降级。
• 版本管理：模型会更新，新旧版本可能同时在线，路由要支持灰度。

我的建议是，先在小规模环境验证论文的核心思路，确认收益后再逐步推广。不要一上来就全量上，系统层面的改动风险很高，出问题影响面很大。

这个方向后续还可以往几个方向扩展：一是和编译优化结合，针对特定模型生成更高效的kernel；二是和硬件结合，利用新一代GPU的硬件特性（比如H100的TMA）做更细粒度的调度；三是和网络结合，在分布式推理场景下做跨节点的资源调度。这些方向目前都有不少工作在推进，值得持续关注。