SGLang冷启动实测：T4上88%账单花在首个请求前

一台T4 GPU、一个轻量模型、一次冷启动，账单的88%在第一个用户拿到回答之前就已经烧掉了。这不是夸张的标题党，而是一份带着原始时间线的实测数据。

实验设置：模拟scale-to-zero计费

测试环境很克制：Colab上的单张T4，SGLang 0.5.21，跑Qwen2.5-0.5B-Instruct的fp16版本。作者的做法更值得注意——在启动服务器之前就开始计时，模拟scale-to-zero平台在worker创建时就开始计费的逻辑。

流程是这样的：启动服务，发送8个简短对话请求，然后进行60秒健康检查，最后停止。一次运行，完整记录。

这个设计的关键在于，它没有从"请求到达"开始算，而是从"资源被分配"开始算。这正是按需GPU平台的真实计费方式，也是很多开发者做成本估算时容易忽略的起点。

scale-to-zero（缩容至零） 是云原生和GPU按需平台的一种资源调度策略：当服务在一段时间内没有请求时，平台会把后端worker实例完全销毁，不再占用GPU；当新请求到来时，再重新拉起一个实例。它最大的好处是闲置时不产生费用，因此被大量Serverless推理平台采用。但代价是每次冷启动都要经历完整的进程初始化、模型加载、显存分配与图捕获流程，这段时间用户只能等待，而平台通常从实例开始创建的那一刻就开始计费。理解scale-to-zero的关键在于区分三种时间：平台计费时间、进程自我报告的就绪时间、以及用户实际拿到响应的时间。三者往往差距巨大，仅用中间那个“ready”来估算成本会严重低估真实账单。

时间线："ready"到底意味着什么

原始时间线是这篇文章最有价值的部分：

• 0秒：服务器启动，计费开始
• 约371秒：prefill CUDA graph捕获完成，耗时287.7秒
• 386.7秒：/health返回200，日志显示"ready to roll"
• 约563秒：第一个对话请求完成，耗时约176秒
• 约579秒：第二个请求完成（约16秒），其余六个在同一秒内完成
• 639.6秒：计费停止

之后在同一服务器上再发8个请求，每个只需0.08到0.22秒。

如果你在健康检查那个点切分账单，启动看起来占了60%（639.6秒中的386.7秒）。但第一个用户是在约563秒才拿到答案的——那是账单的88%已经花掉了。

"ready"不是等待的终点，而是等待的三分之二。

CUDA graph捕获为何成为隐藏成本

287.7秒的prefill CUDA graph捕获，是整个时间线里最大的一块。CUDA graph捕获的本质是把一系列GPU操作录制下来，后续可以快速重放，减少CPU调度开销。对推理服务来说这是性能优化，但在冷启动场景下，它变成了纯粹的预热成本。

这里有一个容易被误解的地方：日志里没有说明第一个请求那176秒具体花在了什么上，所以作者明确表示不做因果断言。这种克制是值得尊敬的——把观测和推测分开，是实测类内容的基本素养。

另一个细节更微妙：尾部每个健康检查在SGLang日志里都表现为GPU上的一次one-token prefill，但请求计数器不动。这意味着"GPU做了工作"和"请求被服务了"是两回事。健康检查本身在消耗算力，却不产生任何用户价值，也不体现在请求指标里。

CUDA graph 是NVIDIA在CUDA 10中引入的一种执行优化机制。正常情况下，GPU上的每个kernel启动、内存拷贝都由CPU逐一提交，在kernel数量多、单kernel耗时短的推理负载中，CPU提交开销会超过GPU实际计算时间，形成瓶颈。CUDA graph允许把一整串GPU操作（含依赖关系）预先录制为一张有向无环图，之后只需一次提交即可整体重放，大幅降低CPU调度开销与启动延迟。代价是录制阶段本身需要先把这套图跑通一遍甚至多遍，且对动态形状、动态控制流的支持有限。在长驻服务中，录制成本被摊薄到成千上万次推理里几乎可以忽略；但在scale-to-zero的冷启动场景中，录制只发生一次却要立刻投入使用，于是它从“性能优化”变成了实打实的“预热税”。尤其prefill阶段因为要处理变长输入，往往需要为多种序列长度分别捕获，录制时间会被进一步放大。

与vLLM的横向对比

作者给出了一个参照：同样这张卡上，vLLM 0.27.1在ready之后的8个请求总共只花了5.8秒。vLLM的启动开销约为171个计费秒中的165秒。

这个对比需要谨慎解读。两个框架的版本、优化策略、默认配置都不同，单次运行也不能代表所有场景。但它至少说明一件事：冷启动的构成在不同推理框架之间差异显著，ready之后的行为同样如此。

作者自己也强调，这只是单卡单次运行，更大的GPU或不同的模型可能完全不同。这句话不是免责声明，而是核心观点——测你自己的场景。

vLLM 是目前最主流的开源大模型推理引擎之一，以PagedAttention显存管理和高吞吐著称，与SGLang并列为两大高性能推理框架。两者在架构上都采用了分页KV缓存、连续批处理等思路，但默认配置、图捕获策略、调度器实现差异很大。vLLM在启动时通常只对解码阶段做CUDA graph捕获，且对捕获的batch size集合有更激进的裁剪策略，这使得它的冷启动图捕获阶段往往比SGLang短。同时vLLM的prefix caching、chunked prefill等默认开关也会影响首个请求的延迟表现。因此文中“同样一张T4、ready后8个请求vLLM只要5.8秒”的对比，反映的不仅仅是吞吐能力差异，更深层的是两个框架对“启动期该做多少预热工作”这一权衡的不同取舍——一个倾向于启动时多做准备、ready后更快，另一个倾向于尽快ready、把部分成本转移到首个请求上。

给scale-to-zero用户的三个时间点

基于这次实测，作者建议运行scale-to-zero服务时记录三个时间节点，而不是只记一个：

1. 计费开始到健康检查通过
2. 计费开始到第一个完成的请求
3. 最后一个请求之后的空闲尾部

然后按整个计费时长定价，而不是只算请求真正在跑的那部分。

这套方法的现实意义在于，很多团队用"请求处理时间"来估算GPU成本，却忽略了冷启动、预热和空闲尾部的开销。当服务频繁扩缩容时，这部分成本可能占据账单的大头。

作者把方法和使用的开源工具放在了GitHub上（github.com/qaisermehdi3-coder/qvunex），并公开征集其他卡型和服务器上的测量数据。这种开放态度，让单点实测有了变成社区基准的可能。