大模型上线后遇到的第一个尴尬场景往往是：服务刚启动，用户发来第一条请求，结果等了半分钟模型才吐出第一个token。这种首次推理延迟过高的问题，通常被称为冷启动问题。它的本质是模型在第一次真正处理请求时，需要完成一系列初始化工作，包括权重从磁盘加载到显存、CUDA上下文建立、算子编译、KV缓存分配等。这些工作如果全部串行发生在用户请求期间，体验会非常糟糕。本文详细分析冷启动的耗时来源，并给出几种经过验证的加速方案。
冷启动到底慢在哪里：拆解耗时来源
要优化冷启动，第一步是搞清楚时间花在了哪里。大模型服务的冷启动通常由四个部分组成。第一是权重加载，一个7B的模型以FP16精度存储大约需要14GB磁盘空间，如果通过普通文件读取方式从磁盘载入内存再拷贝到显存，机械硬盘上可能需要数分钟，即使是NVMe SSD也需要十几秒。第二是框架初始化，包括PyTorch的CUDA上下文创建、nccl通信组建立、各层模块的实例化，这部分通常占用几秒到十几秒。第三是首次算子编译，如果使用了torch.compile或者TensorRT这类需要提前编译执行计划的引擎，第一次前向传播会触发图优化和kernel编译，耗时可能高达数十秒。第四是内存与缓存预分配，比如vLLM需要根据gpu_memory_utilization参数预先划分显存池用于KV缓存。
定位这些耗时的方法很简单，在加载和推理的关键节点打上计时日志，例如记录load_weights开始与结束时间、第一次forward的时间。也可以用py-spy或者nvidia-smi的轮询观察显存占用曲线，判断模型是否在缓慢加载。明确瓶颈之后再针对性优化，比如瓶颈在磁盘IO就去优化加载方式，瓶颈在编译就去开启预热，避免盲目堆方案。
权重加载优化：mmap与量化压缩双管齐下
权重加载是最常见的瓶颈，优化手段主要有两类。第一类是改进读取方式。PyTorch的torch.load默认会将整个文件读入内存，可以改用mmap模式，让操作系统按需将文件映射到内存页，配合mlock锁定热点页面，能显著减少加载时间。第二类是压缩权重体积，将FP16权重量化为INT8甚至INT4，文件体积直接减半或降到四分之一，加载时间随之线性下降，同时显存占用也大幅降低。以GPTQ或AWQ量化为例，7B模型量化到4bit后仅需约4GB显存，加载时间从十几秒缩短到几秒。
import torch
from transformers import AutoModelForCausalLM
# 使用mmap方式加载权重，减少整文件读取开销
model = AutoModelForCausalLM.from_pretrained(
"/data/models/qwen-7b",
torch_dtype=torch.float16,
low_cpu_mem_usage=True, # 避免在CPU上先复制一份完整权重
device_map="cuda:0",
)
# 进程启动后立即锁定内存页，防止被换出到swap
import ctypes
libc = ctypes.CDLL("libc.so.6", use_errno=True)
此外还有磁盘层面的优化：将模型文件放在本地NVMe SSD而不是网络挂载盘上；如果是容器环境，可以把模型打包进镜像层或挂载高速分布式缓存盘。对于多卡场景，建议让每张卡只读取自己负责的分片文件，避免全量读取后再切分，这一点tensor parallel部署时尤其重要。
模型常驻与进程复用：从根源上消除重复加载
很多冷启动问题的根源其实是架构设计问题。比如用Serverless函数承载大模型，每次缩容到零后再扩容都要完整走一遍加载流程。更合理的做法是让模型进程常驻：保持一个最小副本数的推理服务始终在线，配合健康检查防止被调度系统回收。如果必须使用弹性伸缩，可以设置scale to one而不是scale to zero，并开启预热池，让新实例在接收流量之前完成模型加载。
另一种常见模式是模型服务与业务进程分离。将模型加载到一个常驻的worker进程中，业务层通过gRPC或HTTP与其通信，这样业务代码无论怎么发版重启，模型进程都不需要重新加载。需要注意进程间显存不能共享，因此这种架构下建议单机只跑一个模型worker，多个业务实例共享同一个worker。下面是一个常驻预热服务的简单示例：
from fastapi import FastAPI
from vllm import AsyncLLMEngine, AsyncEngineArgs, SamplingParams
import uvicorn
app = FastAPI()
engine_args = AsyncEngineArgs(
model="/data/models/qwen-7b",
quantization="awq", # 使用4bit量化权重
gpu_memory_utilization=0.9, # 预分配90%显存作为KV缓存池
enforce_eager=False, # 关闭eager模式，允许CUDA Graph捕获
)
engine = AsyncLLMEngine.from_engine_args(engine_args)
@app.on_event("startup")
async def warmup():
# 服务启动阶段发送伪请求，触发kernel编译与图捕获
async for output in engine.generate("warmup", SamplingParams(max_tokens=1)):
pass
@app.post("/generate")
async def generate(prompt: str):
outputs = []
async for output in engine.generate(prompt, SamplingParams(max_tokens=256)):
outputs = output.outputs
return {"text": outputs[0].text}
uvicorn.run(app, host="0.0.0.0", port=8000)
推理框架预热机制：vLLM与TensorRT-LLM的实践
主流推理框架都针对冷启动提供了原生手段。vLLM方面，关键是开启CUDA Graph：在模型刚启动时框架会捕获一批不同batch size的执行图，之后推理直接重放图而不需要重新调度kernel，首次捕获虽然耗时，但可以通过启动时warmup完成。参数enforce_eager=False即启用该特性。同时合理设置max_num_seqs和max_model_len，避免KV缓存池预分配过大导致启动变慢。
TensorRT-LLM的思路是离线编译engine文件，把算子融合、精度选择的决策全部提前完成。线上服务只需要反序列化engine并绑定输入输出tensor，启动速度远快于即时编译。建议在CI流水线中加入engine构建步骤，产物按GPU型号归档，部署时直接拉取。无论使用哪个框架，都应该在就绪探针通过之前完成一次完整的伪推理，确保用户请求到来时所有初始化工作已经结束。可以在Kubernetes中配置readinessProbe指向一个轻量的warmup接口，只有伪推理成功后才将Pod加入Service后端。
最后补充几个工程细节：模型加载期间可以禁用不必要的tokenizer校验；多进程加载时注意设置CUDA_VISIBLE_DEVICES避免显存竞争；对延迟敏感的场景，还可以在服务前面加一层队列，冷启动期间将请求暂存，加载完成后统一放行。综合运用量化加载、常驻进程与启动预热，多数场景下首次推理延迟能从分钟级压缩到秒级，配合readiness探针可以做到对用户完全无感。