从单模型到LLM推理平台：vLLM、Triton与K8s部署实战指南

1. 从单模型到推理平台部署这件事到底在解决什么问题模型部署这个词听起来像是运维的活儿但真正做过的人都知道它其实是算法、工程、基础设施三拨人坐在一起吵架的过程。算法同学说我的模型精度掉了0.5个点工程同学说你的显存占用怎么又涨了运维同学说这台机器的GPU利用率只有15%你让我怎么跟老板交代。我做了几年模型服务从最早用Flask包一个PyTorch模型跑在单卡上到后来管几十张卡的推理集群踩过的坑基本能写一本小册子。这篇文章想聊的是把一个训练好的模型变成线上稳定服务再进一步变成能支撑多模型、多租户、弹性伸缩的LLM推理平台中间要跨过哪些坎。核心关键词就几个模型部署、LLM、vLLM、Triton、K8s。适合谁看如果你正在纠结“我训好的模型怎么给别人用”或者“公司要上大模型但不知道选什么推理框架”又或者“K8s集群跑起来了但GPU利用率上不去”那这篇应该能给你一些直接能抄的作业。先说清楚一个基本盘模型部署不是把模型文件扔到服务器上跑起来就完事了。它要解决的是四个问题——延迟、吞吐、成本、稳定性。这四个词互相打架你要低延迟就得牺牲批处理要吞吐就得攒batch要成本就得提高GPU利用率要稳定性就得做冗余和隔离。所谓“部署框架全景”本质上就是在这四个维度上找平衡点的工具箱。单模型服务和LLM推理平台看起来都是“把模型跑起来”但复杂度差了一个数量级。单模型服务你只需要关心一个模型的输入输出、一个进程的显存占用、一台机器的资源。到了LLM推理平台你要面对的是多个模型版本共存、不同模型对显存和算力的需求差异巨大、请求的输入长度从几十token到几十万token不等、还要做多租户隔离和计费。这不是加几台机器就能解决的问题架构上就得重新设计。我见过太多团队在单模型阶段用Flask加gunicorn跑得好好的一上LLM就崩了。原因很简单传统Web服务的并发模型和LLM推理的并发模型完全不是一回事。一个HTTP请求进来传统服务可能几十毫秒就返回了LLM推理可能要几秒甚至几十秒而且中间GPU一直在算。你用同步阻塞的方式去处理线程池瞬间就被打满后面的请求全部排队超时。所以从单模型到LLM平台第一个要换的就是推理引擎和并发模型。2. 推理引擎选型vLLM、Triton、Ollama到底怎么选2.1 先搞清楚每个工具的设计目标选推理引擎这件事最怕的就是“别人说好我就用”。我见过一个团队用Ollama做线上服务QPS一上来直接跪了然后问我为什么。我说Ollama的设计目标是让个人开发者在本地快速跑模型它的默认配置压根没考虑高并发场景。这不是Ollama不好是你用错了地方。先把几个主流选项的设计目标理清楚工具设计目标适用场景不适用场景Ollama本地快速体验和开发个人开发、原型验证、桌面端高并发线上服务vLLM高吞吐LLM推理线上LLM服务、批量推理非LLM模型、超低延迟单请求Triton通用模型服务框架多框架模型混合部署、企业级服务快速原型、个人项目LM Studio桌面端模型体验本地对话、模型评测任何服务端场景SGLang结构化LLM推理复杂prompt、多轮对话简单单轮推理这个表不是绝对的但能帮你快速排除明显不合适的选项。比如你要做的是线上API服务Ollama和LM Studio直接划掉它们就不是干这个的。2.2 vLLM为什么成了LLM推理的默认答案vLLM火起来核心就一个东西PagedAttention。这个技术说白了就是把操作系统的虚拟内存分页思想搬到了KV Cache管理上。传统做法是给每个请求预分配一大块连续显存来存KV Cache但你怎么知道这个请求会生成多长预分配多了浪费预分配少了不够用。PagedAttention把KV Cache切成固定大小的块用多少分配多少块之间不需要连续。这一下子把显存利用率从可能不到50%拉到了90%以上。我实测过一个场景同样一张A100 80G用HuggingFace Transformers直接推理并发到8左右就OOM了换vLLM同样模型并发能到30以上吞吐量差了将近4倍。这不是vLLM有什么魔法就是显存管理效率的差距。vLLM的另一个杀手锏是Continuous Batching。传统batching是等一批请求凑齐了一起送进GPU等最慢的那个生成完再处理下一批。Continuous Batching是每个iteration都重新组batch已经生成完的请求退出新来的请求补进来。GPU利用率直接从“脉冲式”变成了“持续满载”。部署vLLM的典型命令长这样python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --dtype auto \ --port 8000几个参数值得展开说。--tensor-parallel-size 2表示用两张卡做张量并行适合单卡放不下的模型。--gpu-memory-utilization 0.9是显存使用上限比例留0.1给CUDA上下文和临时buffer设太高容易OOM设太低浪费显存。--max-model-len是最大序列长度这个值直接影响KV Cache的块数量设太大显存不够设太小长请求会报错。注意--gpu-memory-utilization不是越高越好。我见过有人设0.98结果跑了一段时间后CUDA OOM因为碎片化和临时分配没留余量。0.85到0.92是比较稳的区间。2.3 Triton的定位和vLLM完全不同Triton不是推理引擎它是模型服务框架。它自己不实现推理计算而是把各种推理后端PyTorch、TensorRT、ONNX Runtime、vLLM等包装成统一的服务接口。你可以把它理解成一个“模型服务的操作系统”。Triton的核心价值在于多模型多框架统一管理。一个Triton实例可以同时跑一个PyTorch的图像分类模型、一个TensorRT的检测模型、一个vLLM的LLM推理后端。每个模型有自己的版本管理、动态批处理配置、实例组配置。对于企业级场景这种统一管理能力比单点性能更重要。Triton的模型仓库结构是这样的model_repository/ ├── image_classifier/ │ ├── config.pbtxt │ └── 1/ │ └── model.pt ├── llm_model/ │ ├── config.pbtxt │ └── 1/ │ └── model.py └── detection/ ├── config.pbtxt └── 1/ └── model.plan每个模型目录下的config.pbtxt定义了输入输出、批处理策略、实例数量等。这个配置文件是Triton的核心写好了性能翻倍写不好还不如直接跑。2.4 选型决策树我一般用这个决策树来选只做LLM推理追求高吞吐 → vLLM或SGLang需要同时服务多种类型模型CVNLPLLM → Triton vLLM后端本地开发快速验证 → Ollama或LM Studio需要极致低延迟单请求 → TensorRT或ONNX Runtime需要结构化输出和复杂prompt编排 → SGLang这个决策树不是死的但能帮你快速缩小范围。最怕的就是拿一个工具硬套所有场景最后哪个场景都不满意。3. 从单机到K8s部署架构的演进路径3.1 单机部署的天花板在哪里单机部署模型最直接的方式就是起一个进程加载模型暴露HTTP接口。简单场景下这完全够用但很快就会碰到天花板。第一个天花板是显存。一张A100 80G跑一个7B模型用FP16大概占14G加上KV Cache和中间激活实际能用到20G左右。剩下60G看起来很多但你要跑多个模型或者更大的模型就不够了。模型并行可以解决单模型放不下的问题但多模型共存还是得靠多机。第二个天花板是可用性。单机挂了服务就没了没有冗余。你可能说那我起两个进程但两个进程抢同一张卡一个OOM另一个也受影响。真正的冗余需要多机。第三个天花板是弹性。流量高峰来了想加机器单机架构下你得手动部署新实例、配置负载均衡、同步模型文件。流量下去了想缩容又得手动操作。K8s把这些变成了声明式的配置。3.2 K8s部署GPU服务的核心配置在K8s上跑GPU服务和跑普通Web服务有几个关键区别。首先是GPU资源调度你需要安装NVIDIA Device Plugin让K8s能识别和分配GPU。然后Pod的resources里要声明nvidia.com/gpu: 1。一个典型的vLLM Deployment配置apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen spec: replicas: 2 selector: matchLabels: app: vllm-qwen template: metadata: labels: app: vllm-qwen spec: containers: - name: vllm image: vllm/vllm-openai:v0.27.1 args: - --model - Qwen/Qwen2.5-7B-Instruct - --tensor-parallel-size - 1 - --gpu-memory-utilization - 0.9 resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8000 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 120 periodSeconds: 10这里有几个坑要注意。initialDelaySeconds: 120是因为模型加载需要时间7B模型大概要1到2分钟70B模型可能要5分钟以上。如果readinessProbe设太短Pod还没加载完就被判定为不健康会被反复重启。注意vLLM的镜像版本要和CUDA版本匹配。vllm/vllm-openai:v0.27.1默认用的是CUDA 12.1如果你的节点驱动版本较老可能需要换镜像或者升级驱动。我遇到过节点驱动是CUDA 11.8跑vLLM 0.27.1直接报错的情况。3.3 多模型共存和资源隔离LLM推理平台和单模型服务的核心区别之一就是多模型共存。不同团队要部署不同的模型有的用7B有的用72B有的要长上下文有的要低延迟。怎么在一套K8s集群里管好这些方案一是每个模型一个Deployment通过K8s的命名空间做隔离。优点是简单直接每个模型独立伸缩。缺点是资源利用率低每个Deployment都要预留GPU即使没流量也占着卡。方案二是共享推理后端用Triton或者vLLM的多模型能力在一个进程里加载多个模型。优点是资源利用率高缺点是隔离性差一个模型OOM可能影响其他模型。方案三是混合方案核心模型独立部署保证稳定性长尾模型共享后端提高利用率。这也是我目前比较推荐的方案。资源隔离方面K8s的requests和limits对GPU来说比较特殊。GPU不像CPU可以超卖requests和limits必须相等否则调度器会报错。这意味着你没法像CPU那样设置“请求0.5张卡限制1张卡”。要做GPU共享得用MIGMulti-Instance GPU或者时间片轮转方案但MIG只支持A100及以上时间片轮转对LLM推理的延迟影响很大。3.4 自动伸缩的坑K8s的HPAHorizontal Pod Autoscaler对LLM服务来说用起来没那么简单。普通Web服务可以用CPU利用率或者QPS来触发伸缩但LLM服务的瓶颈在GPU而GPU利用率这个指标本身就很微妙。GPU利用率高不一定代表需要扩容。比如一个请求正在生成很长的输出GPU利用率一直是100%但QPS可能只有1。这时候扩容没用因为瓶颈在单个请求的生成时间不在并发处理能力。我一般用排队请求数或者P99延迟作为伸缩指标。排队请求数超过阈值说明处理不过来需要扩容。P99延迟超过SLA说明用户体验下降也需要扩容。这两个指标比GPU利用率更能反映真实需求。但LLM服务的冷启动时间是个大问题。一个新Pod从创建到能处理请求7B模型要1到2分钟70B模型要5分钟以上。这意味着扩容决策要提前做不能等排队了再扩。我一般会设置一个预热池保持一定数量的空闲Pod随时能接管流量。4. 实操从零搭一个LLM推理服务4.1 环境准备和依赖检查假设你有一台带GPU的Linux机器想从零搭一个vLLM服务。第一步不是装vLLM是检查环境。# 检查GPU驱动 nvidia-smi # 检查CUDA版本 nvcc --version # 检查Python版本 python --versionnvidia-smi的输出里右上角的CUDA Version是驱动支持的最高CUDA版本不是你当前安装的CUDA版本。这个值要大于等于你要用的CUDA版本。比如vLLM 0.27.1需要CUDA 12.1你的驱动显示CUDA Version 12.2那就没问题。Python版本建议3.10到3.12。3.13有些依赖还没适配3.9有些新特性用不了。4.2 安装vLLM和模型下载安装vLLM最省事的方式是用官方Docker镜像但如果你想在宿主机上直接跑用pippip install vllm0.27.1这个命令会自动装PyTorch、CUDA runtime、transformers等依赖。但要注意pip装的PyTorch可能和你系统的CUDA版本不匹配。如果报错先去PyTorch官网找对应CUDA版本的安装命令。模型下载有两种方式。一种是让vLLM自动从HuggingFace下载第一次启动时会下载到~/.cache/huggingface。另一种是提前用huggingface-cli下载好指定本地路径。# 提前下载模型 huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./qwen2.5-7b提前下载的好处是启动快而且可以控制模型文件的位置。如果机器不能直连HuggingFace可以用镜像站或者手动下载。4.3 启动服务和参数调优启动vLLM服务python -m vllm.entrypoints.openai.api_server \ --model ./qwen2.5-7b \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 256 \ --dtype auto \ --port 8000--max-num-seqs 256是最大并发序列数这个值直接影响显存占用和吞吐。设太大KV Cache不够用设太小并发上不去。7B模型在A100 80G上256是个比较安全的起点。--dtype auto让vLLM自动选择精度。如果模型是FP16的就用FP16如果是BF16的就用BF16。BF16在A100及以上卡上性能更好因为Tensor Core对BF16的支持更完整。启动后测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 你好}], max_tokens: 100 }如果返回正常说明服务跑起来了。如果报错看日志里的CUDA error或者OOM一般是显存不够或者版本不匹配。4.4 压测和性能基线服务跑起来只是第一步你得知道它能扛多少并发。用vllm自带的benchmark工具python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --base-url http://localhost:8000 \ --model qwen2.5-7b \ --dataset-name sharegpt \ --num-prompts 1000 \ --request-rate 10这个命令会模拟每秒10个请求的负载跑1000个prompt输出吞吐量、延迟分布等指标。重点看两个数TTFTTime To First Token和TPOTTime Per Output Token。TTFT反映首字延迟TPOT反映生成速度。线上服务一般要求TTFT小于1秒TPOT小于50毫秒。我实测Qwen2.5-7B在A100上FP16精度并发32的情况下TTFT大概200毫秒TPOT大概20毫秒吞吐量大概1500 tokens/s。这个数据可以作为基线如果明显低于这个值说明配置有问题。5. 生产环境常见故障和排查思路5.1 OOM最常见也最头疼的问题OOM是LLM推理服务最常见的故障没有之一。表现是服务突然挂掉日志里出现CUDA out of memory。原因可能有几种第一种是显存预估不足。模型权重占一部分KV Cache占一部分中间激活占一部分CUDA上下文占一部分。很多人只算了模型权重忘了KV Cache。KV Cache的大小和max-model-len、max-num-seqs、num_layers、hidden_size都有关系。粗略估算公式是KV Cache 2 * num_layers * hidden_size * max_model_len * max_num_seqs * dtype_size以Qwen2.5-7B为例28层hidden_size 3584max_model_len 8192max_num_seqs 256FP162字节2 * 28 * 3584 * 8192 * 256 * 2 约 840GB这显然不对因为KV Cache是按需分配的不是一次性全分配。但这个公式能帮你理解各个参数的影响。实际使用中vLLM会根据gpu_memory_utilization动态管理KV Cache块。第二种是内存碎片。长时间运行后显存碎片化导致没有连续的大块显存可用。解决办法是定期重启服务或者用vLLM的--enable-prefix-caching减少重复分配。第三种是请求长度超限。一个请求的输入长度超过了max-model-lenvLLM会直接报错。如果没做好错误处理可能导致服务崩溃。解决办法是在网关层做输入长度检查超限的直接拒绝。5.2 服务无响应不一定是挂了有时候服务没挂但请求一直不返回。这种情况比OOM更难排查因为日志里可能什么错误都没有。常见原因是请求排队。vLLM的--max-num-seqs限制了同时处理的请求数超出的请求会在队列里等待。如果队列太长请求就会超时。解决办法是监控队列长度超过阈值就扩容或者限流。另一个原因是长请求阻塞。一个请求生成了很长的输出占着GPU不放后面的请求只能等。vLLM的Continuous Batching可以缓解这个问题但如果长请求太多还是会影响整体吞吐。解决办法是设置--max-tokens上限或者用优先级队列。还有一种情况是网络问题。K8s的Service或者Ingress配置有问题请求根本没到Pod。排查方法是看Pod的日志有没有收到请求如果没有就是网络层的问题。5.3 K8s相关的故障在K8s上跑GPU服务除了模型本身的问题还有K8s层面的问题。Pod一直Pending最常见的原因是GPU资源不足。kubectl describe pod看Events如果显示Insufficient nvidia.com/gpu就是集群里没有空闲GPU了。解决办法是加节点或者减少副本数。Pod反复重启看kubectl logs --previous看上次崩溃的日志。如果是OOM调大显存或者调小max-num-seqs。如果是readinessProbe失败调大initialDelaySeconds。服务发现失败K8s的Service通过Label Selector找到Pod如果Label不匹配Service就没有Endpoints。kubectl get endpoints检查一下如果是空的就是Label问题。节点GPU驱动异常有时候节点上的GPU驱动会挂掉nvidia-smi报错。这时候需要重启节点或者重新加载驱动。K8s的Device Plugin会检测到GPU不可用把节点标记为不健康。5.4 常见问题速查表现象可能原因排查方法解决办法CUDA OOM显存不足看日志确认OOM降低gpu-memory-utilization或max-num-seqs请求超时队列积压看队列长度指标扩容或限流Pod PendingGPU不足kubectl describe pod加节点或减副本Pod重启探针失败kubectl logs --previous调大initialDelaySeconds服务无响应网络问题看Pod是否收到请求检查Service和Ingress吞吐量低批处理配置不当看GPU利用率调大max-num-seqs首字延迟高模型加载慢看TTFT指标用更快的存储或预热6. 几个容易踩的坑和实操心得6.1 模型格式转换的坑HuggingFace上的模型格式五花八门有safetensors、bin、gguf等。vLLM主要支持safetensors和bingguf需要额外转换。如果你下载的是gguf格式得先转成safetensors。转换工具用llama.cpp的convert_hf_to_gguf.py反向转或者用transformers重新保存from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(./model-gguf) tokenizer AutoTokenizer.from_pretrained(./model-gguf) model.save_pretrained(./model-safetensors, safe_serializationTrue) tokenizer.save_pretrained(./model-safetensors)这个转换过程可能丢精度特别是量化模型。如果原模型是4bit量化的转成FP16再转回去精度可能进一步下降。所以尽量直接用原始格式别来回转。6.2 多卡并行的通信开销用--tensor-parallel-size做多卡并行时卡之间的通信开销不可忽略。NVLink的带宽比PCIe高一个数量级所以同一台机器内的多卡并行效果最好。跨机器的张量并行通信开销很大一般用流水线并行代替。我实测过2卡A100用NVLink做张量并行7B模型的吞吐量大概是单卡的1.8倍不是2倍因为通信有开销。如果是PCIe连接可能只有1.5倍。所以如果单卡能放下模型优先用单卡。6.3 长上下文的显存陷阱现在很多模型支持128K甚至更长的上下文但长上下文的显存消耗是指数级增长的。KV Cache的大小和序列长度成正比128K上下文的KV Cache可能是8K的16倍。一张80G的卡跑8K上下文可能能并发256个请求跑128K可能只能并发16个。解决办法是用滑动窗口注意力或者KV Cache量化。滑动窗口只保留最近N个token的KV适合长文档摘要这类场景。KV Cache量化把FP16的KV压成INT8显存减半但精度可能下降。6.4 监控指标的选择LLM服务的监控和普通Web服务不一样。普通Web服务看QPS、延迟、错误率就够了LLM服务还要看TTFT首字延迟影响用户体验TPOT每token生成时间影响总响应时间队列长度反映服务压力GPU利用率反映资源使用效率KV Cache使用率反映显存压力请求长度分布反映负载特征这些指标里我最关注的是队列长度和KV Cache使用率。队列长度持续大于0说明处理不过来KV Cache使用率接近100%说明显存快满了。这两个指标能提前预警比等OOM了再处理要好。6.5 版本升级的注意事项vLLM的版本迭代很快几乎每个月都有新版本。升级版本时要注意第一模型兼容性。新版本可能不支持旧版本的模型格式或者对某些模型的支持有变化。升级前先在测试环境验证。第二API兼容性。vLLM的OpenAI兼容API大部分是稳定的但有些参数可能变了。比如--max-num-seqs的默认值在不同版本可能不同。第三CUDA版本。新版本可能要求更高的CUDA版本如果你的驱动不支持就得先升级驱动。我一般会保留一个稳定版本新版本先在测试环境跑一周确认没问题再上生产。升级时用滚动更新先更新一个副本观察一段时间再更新其他副本。6.6 成本优化的几个思路LLM推理的成本主要在GPU上。一张A100按小时计费一个月下来不少钱。优化成本有几个思路提高GPU利用率。用Continuous Batching和PagedAttention把GPU利用率从30%提到70%相当于成本减半。混合精度。FP16比FP32快一倍BF16比FP16在A100上又快一些。如果精度允许用INT8量化还能再快一倍。模型蒸馏。用大模型蒸馏一个小模型7B的模型能达到70B模型80%的效果但推理成本只有十分之一。请求调度。把长请求和短请求分开处理短请求用低延迟配置长请求用高吞吐配置。这样能避免长请求阻塞短请求。自动伸缩。流量低谷时缩容高峰时扩容。但要注意冷启动时间别缩得太狠。7. 从单模型到平台架构演进的实际路径7.1 第一阶段单模型单机这是最简单的阶段一个模型跑在一台机器上直接暴露HTTP接口。适合内部工具、Demo、小流量场景。技术栈就是vLLM或者Triton加一个反向代理。这个阶段的关键是把服务跑稳。配置好显存参数做好健康检查加一个简单的监控。别想太多先跑起来。7.2 第二阶段多模型多机流量上来了一个模型不够用了或者要部署多个模型。这时候需要引入K8s做编排每个模型一个Deployment用Service做负载均衡。这个阶段的关键是资源管理。GPU是稀缺资源怎么分配给不同的模型是个问题。我一般用命名空间做隔离每个团队一个命名空间配额管理GPU资源。7.3 第三阶段推理平台到了这个阶段你需要的不只是跑模型还要做模型管理、版本管理、灰度发布、A/B测试、计费、审计。这时候Triton或者自研的推理平台就派上用场了。推理平台的核心能力包括模型仓库统一管理模型文件、版本、配置服务编排自动部署、伸缩、故障恢复流量管理灰度、A/B测试、限流、熔断可观测性指标、日志、链路追踪多租户隔离、配额、计费这个阶段没有标准答案每个公司的实现都不一样。但核心思路是一样的把模型部署这件事从“手工操作”变成“声明式管理”。7.4 我踩过的一个典型坑说一个我实际踩过的坑。有一次我们上线一个新模型配置里--max-model-len设了32768因为模型支持32K上下文。结果上线后频繁OOM。排查发现虽然大部分请求只有几百token但KV Cache是按最大长度预分配的32K的KV Cache把显存吃光了。解决办法是设置--max-model-len为实际需要的长度比如8192然后在网关层限制输入长度。如果确实需要长上下文用单独的实例跑别和短请求混在一起。这个坑的教训是模型支持的能力不等于你都要用。配置参数要根据实际场景来别直接抄模型卡上的最大值。7.5 另一个坑K8s的GPU调度K8s默认的GPU调度是整卡调度一个Pod要么占一张卡要么不占。这意味着你没法把一张卡分给两个Pod。对于小模型来说这很浪费。解决办法有几种。一是用MIG把A100切成多个小实例每个实例独立调度。但MIG只支持A100及以上而且配置比较麻烦。二是用时间片轮转多个Pod共享一张卡但延迟会受影响。三是用vGPU方案比如阿里云的cGPU或者腾讯云的qGPU但这些都是厂商绑定的。我目前的建议是如果模型小就合并到一个Pod里用vLLM的多模型能力跑。如果模型大就整卡调度别折腾共享。8. 一些零散但有用的经验8.1 模型加载加速模型加载慢是个痛点特别是大模型。几个加速方法用本地SSD。模型文件放在NVMe SSD上加载速度比网络存储快很多。70B模型从网络存储加载可能要10分钟从本地SSD加载只要2分钟。用内存文件系统。把模型文件放到/dev/shm加载速度更快但重启后丢失。预热。服务启动后先跑几个请求把KV Cache和CUDA kernel都预热好再接入流量。8.2 请求超时设置LLM请求的超时设置很讲究。设太短长请求会被截断设太长客户端会一直等。我一般设置分级超时连接超时5秒首字超时30秒总超时300秒首字超时30秒是因为模型加载后第一个请求可能比较慢之后就好了。总超时300秒是给长输出留余量一般请求不会超过这个时间。8.3 日志和追踪LLM服务的日志要记录请求ID、输入长度、输出长度、TTFT、TPOT、总耗时。这些数据能帮你分析性能瓶颈和用户行为。追踪方面OpenTelemetry是个好选择。它能把一个请求的完整链路串起来从网关到推理引擎到GPU每个环节的耗时都看得到。8.4 安全考虑模型服务的安全容易被忽视。几个基本点输入过滤防止prompt注入和恶意输入。特别是对外服务一定要做输入长度和内容检查。输出过滤防止模型输出敏感信息。可以用关键词过滤或者另一个模型做审核。访问控制API Key或者OAuth别裸奔。限流防止单个用户打满服务。按用户或者按IP限流。8.5 最后分享一个小技巧如果你在K8s上跑vLLM遇到Pod启动慢的问题可以试试Init Container预加载模型。用一个Init Container把模型从网络存储拷贝到本地SSD主容器直接从本地加载。这样Pod启动时间能缩短一半以上。initContainers: - name: model-loader image: busybox command: [cp, -r, /remote-model, /local-model] volumeMounts: - name: remote-storage mountPath: /remote-model - name: local-ssd mountPath: /local-model这个技巧对70B以上的大模型特别有用因为模型文件几十上百G从网络存储加载真的很慢。模型部署这件事说到底是在资源、性能、成本、稳定性之间找平衡。没有银弹只有适合当前场景的方案。从单模型到LLM推理平台每一步演进都是被实际问题推着走的。先把单模型跑稳再考虑多模型最后才是平台化。别一上来就搞大架构容易把自己绕进去。