1. 别被“Infra”这个词唬住：它根本不是大模型专属黑话

“大模型Infra是什么？”——最近在技术群、招聘JD、甚至咖啡闲聊里，这句话出现频率高得反常。有人把它当成新晋玄学词汇，和“对齐”“涌现”“幻觉”并列；有人则直接划等号：“不就是搭GPU服务器吗？”；还有人翻遍文档，只看到一堆缩写：K8s、Ray、vLLM、Triton、DeepSpeed……越查越晕。我见过某高校实验室的导师，带着三个博士生折腾了四个月，把集群跑满95%利用率，结果发现推理延迟比单卡还高200ms——问题出在Infra设计的第一步就错了。这不是能力问题，是概念没掰清。

所谓“Infra”，本质是让大模型从“能跑起来”变成“能稳、快、省、可扩、可管”的整套支撑体系。它不等于硬件堆砌，也不等于运维脚本合集。你可以把它想象成一座超高层智能建筑：地基（算力调度）、承重结构（计算框架）、水电管网（数据与通信）、消防与电梯系统（可观测性与弹性）、物业中控室（编排与治理）——少哪一块，楼都盖不高，更别提住得舒服。而大模型的特殊性在于：它的“建材”（参数量动辄百亿千亿）、“施工工艺”（混合精度训练、动态批处理、KV Cache管理）和“住户需求”（毫秒级响应、千并发、多模态混跑）全都在挑战传统基建的极限。

关键词里虽然空着，但搜索热词已经暴露真实关切：大家真正想问的，从来不是定义，而是“我的业务卡在哪了？”“为什么别人能压到$0.03/token，我还在烧钱？”“模型上线三天就OOM，到底该调什么？”——这些才是Infra要解决的真问题。它不是PPT里的架构图，而是每天凌晨三点你盯着Prometheus面板时，那个决定要不要重启Pod的按钮；是当你把7B模型从HuggingFace拉下来，发现实际吞吐只有标称值1/3时，必须深挖的那三层缓存配置；是业务方说“明天要上线新功能”，你心里快速盘算“现有队列深度够不够扛住流量峰”的那一秒判断。

所以，这篇文章不讲教科书定义。我们直接拆解：一个真实场景下，Infra如何一步步从“能用”走向“好用”。你会看到，那些被奉为圭臬的开源工具，在具体任务里为何有时是神兵利器，有时却成了绊脚石；你会明白，为什么同样用vLLM，A团队QPS翻倍，B团队反而更卡；更重要的是，你能建立起一套自己的Infra决策树——下次面对新需求，不再盲目跟风选型，而是清楚知道：这里该用轻量级方案，那里必须上企业级治理，而中间那段灰色地带，恰恰是你技术价值的爆发点。

2. Infra的五根承重柱：缺一不可的硬性能力维度

很多人误以为Infra就是“把模型跑起来”，于是陷入两个极端：要么疯狂堆GPU，以为卡越多越强；要么死磕单机优化，觉得“我这台A100调得比谁都溜”。结果往往是：集群资源闲置率40%，线上服务P99延迟抖动超过500ms，模型更新要停服两小时。问题出在，他们只盯着其中一根柱子发力，却忽略了整座建筑需要五根承重柱协同受力。这五根柱子，是任何大模型Infra无法绕开的硬性能力维度，它们共同定义了“可用”与“好用”的分水岭。

2.1 算力调度：不是分配卡，而是分配“时间片”与“确定性”

调度的本质，是解决“谁在什么时候用多少算力”的博弈问题。传统YARN或Slurm调度器，按分钟级分配GPU，对大模型任务完全失效——一个7B模型的prefill阶段可能只需200ms，decode阶段却要持续数秒，中间还夹杂着KV Cache的显存搬运。如果调度器只认“整卡”，就会导致：小批量请求被迫独占整卡，显存浪费严重；大批量请求又因排队过长，首token延迟飙升。

真实案例：某公司用K8s+KubeFlow部署推理服务，初期所有Pod申请1张A100。监控显示GPU利用率长期低于30%，但用户投诉“点击发送后要等3秒才出字”。排查发现，调度器把每个请求都塞进独立Pod，而vLLM的dynamic batching机制在Pod间无法协同——相当于让10个厨师各自守着1个灶台，哪怕只炒1个蛋，也得占满整个厨房。解决方案不是换调度器，而是重构资源申请模型：将Pod改为申请“显存+计算单元”，由统一调度器（如Ray Serve或自研Scheduler）根据实时负载，动态将多个请求合并到同一GPU实例的vLLM引擎中。实测后，相同硬件下QPS提升3.2倍，P99延迟从2100ms降至680ms。

提示：调度决策的关键输入不是“模型大小”，而是“请求特征分布”。你需要采集真实流量中的输入长度、输出长度、batch size分布，用这些数据训练轻量级预测模型，才能让调度器预判“接下来100ms内，大概率会出现5个短输入+2个长输出的组合”，从而提前预留合适资源。

2.2 计算框架：框架不是越新越好，而是越“懂模型”越好

vLLM、TGI、Text Generation Inference、TensorRT-LLM……开源社区轮番上新，但选型逻辑绝非“Star数最多=最好用”。核心差异在于：框架对大模型计算范式的原生支持深度。以最典型的PagedAttention为例：传统Attention需要连续显存存放KV Cache，而vLLM将其离散化为“页”，像操作系统管理内存一样管理显存块。这直接带来两大收益：一是显存利用率提升2-3倍（尤其对长上下文），二是支持真正的continuous batching（请求可随时插入，无需等待batch填满）。

但代价是：vLLM目前仅支持Decoder-only架构（如Llama、Qwen），对Encoder-Decoder（如T5、BART）或MoE模型（如Mixtral）支持有限。某团队曾强行将T5模型接入vLLM，结果因KV Cache结构不匹配，decode阶段错误率高达17%。最终改用HuggingFace TGI，虽QPS低20%，但稳定性100%，且支持T5特有的encoder-decoder attention模式。

另一个关键点是量化支持。FP16是底线，INT4是刚需。但不同框架的INT4实现差异巨大：TensorRT-LLM的W4A16量化在A100上实测吞吐比vLLM高18%，但启动时间多47秒；而llama.cpp的Q4_K_M量化在Mac M2上跑7B模型仅需1.2GB内存，却无法利用CUDA加速。选择时必须明确：你的瓶颈是“冷启动速度”还是“稳态吞吐”？目标硬件是“数据中心A100”还是“边缘端Jetson Orin”？

2.3 数据与通信：90%的延迟黑洞藏在这里

当人们抱怨“模型太慢”，第一反应总是优化模型本身。但真实生产环境的数据链路分析显示：端到端延迟中，数据加载与跨节点通信占比常超60%。典型路径：用户请求→API网关→负载均衡→推理服务Pod→模型加载→Tokenizer→Embedding层→Attention计算→Logit输出→解码→返回。其中，“Tokenizer耗时”“Embedding层IO”“跨GPU通信带宽”三处最容易被忽视。

案例：某金融风控模型（13B参数）在单机8卡A100上测试，理论计算延迟应<500ms，实测却达1800ms。逐段打点发现：Tokenizer（基于HuggingFace Tokenizers C++库）单次调用耗时320ms，原因竟是每次请求都重新加载vocab.json和merges.txt文件。解决方案是将tokenizer预加载为共享内存对象，延迟降至23ms。更隐蔽的是Embedding层：原始实现用nn.Embedding，每次前向传播触发一次显存拷贝；改用FusedEmbedding（集成到vLLM中），直接在GPU显存内完成索引映射，节省110ms。

跨节点通信更是重灾区。AllReduce同步梯度时，若网络带宽不足，100G RoCE网络下，8卡同步一次梯度可能耗时80ms，而计算仅需40ms——通信成了瓶颈。此时Infra必须介入：采用梯度压缩（如1-bit Adam）、通信重叠（overlap computation with communication）、或改用Ring-AllReduce拓扑。某团队在256卡集群训练时，仅通过调整NCCL_SOCKET_TIMEOUT和NCCL_IB_DISABLE参数，就将通信延迟降低35%。

2.4 可观测性：没有指标的Infra，就像没有仪表盘的飞机

Infra的终极形态，不是“不出问题”，而是“问题发生时，30秒内定位根因”。这依赖一套完整的可观测性栈：Metrics（指标）、Logs（日志）、Traces（链路追踪）、Profiles（性能剖析）。但大模型场景下，传统方案常失灵。例如：Prometheus默认采集GPU利用率，但对vLLM而言，更关键的是vllm:gpu_cache_usage_ratio（KV Cache显存占用率）和vllm:request_waiting_time_seconds（请求排队时间）——这两个指标缺失，你就永远不知道是模型算得慢，还是请求堵在路上。

真实踩坑：某团队用Grafana看GPU利用率，显示稳定在85%，信心满满。结果线上突发大量timeout，排查2小时才发现：vllm:request_waiting_time_seconds中位数已飙升至12s，而GPU利用率仍“健康”——因为vLLM的scheduler正疯狂排队请求，计算单元却空转。根源是max_num_seqs（最大并发请求数）配置过低，而监控告警未覆盖此指标。

另一个陷阱是日志粒度。普通INFO日志只记录“请求开始/结束”，但大模型需要：Prefill耗时、Decode每token耗时、KV Cache命中率、显存碎片率。某团队自研的日志模块，为每个请求注入唯一trace_id，并在关键函数埋点（如_run_prefill、_run_decode），配合Jaeger做分布式追踪。当发现某类长文本请求延迟异常时，直接下钻到单次decode的127个token耗时曲线，发现第89个token突增500ms——最终定位为特定位置的RoPE旋转矩阵计算溢出。

2.5 编排与治理：让Infra从“能用”走向“可管可控”

当Infra规模扩大，人工运维必然崩溃。编排（Orchestration）解决“怎么部署”，治理（Governance）解决“谁来负责、怎么合规、如何审计”。二者结合，形成Infra的生命线。

编排层面，K8s是事实标准，但关键在Operator设计。裸K8s YAML部署vLLM，每次升级都要手动改ConfigMap；而vLLM Operator能自动处理：模型版本灰度发布（先切5%流量）、资源弹性伸缩（根据vllm:queue_length指标自动扩缩Pod）、故障自愈（检测到OOM自动重启并保留现场日志）。某公司用Operator后，模型迭代发布周期从3天缩短至45分钟。

治理层面，常被严重低估。典型问题包括：

• 模型血缘混乱：线上跑的模型版本，与Git仓库、模型注册中心、训练流水线记录不一致；
• 资源归属不清：某部门申请的GPU集群，被其他团队“借用”导致SLA不达标；
• 安全合规缺失：未对PII数据做脱敏，或模型输出未经过滤直接返回给前端。

解决方案是构建“Infra元数据中枢”：用数据库记录每个模型实例的model_id、version_hash、deployed_by、resource_quota、data_policy。某团队强制所有API调用携带x-model-id头，网关层校验其是否在中枢注册、是否符合当前数据策略。一次审计中，系统自动拦截了37个未注册的测试模型调用，避免了潜在合规风险。

3. 从零搭建Infra：一个可落地的七步实施路线图

很多团队卡在“第一步”：看着满屏工具不知从何下手。这里给出一条经过多个项目验证的七步路线图，它不追求一步到位，而是强调“每一步都产生可衡量的价值”，让你在推进中持续获得正反馈，避免陷入“投入半年不见效果”的困境。

3.1 步骤一：定义你的“最小可行Infra”（MVI）

跳过所有高大上的架构图，先问自己三个问题：

1. 当前最痛的瓶颈是什么？（是单卡跑不动？还是10个用户就超时？或是模型更新要停服？）
2. 未来三个月最关键的业务指标是什么？（是降低单token成本？还是将P99延迟压到800ms内？或是支持每日10次模型热更新？）
3. 团队当前最熟悉的技术栈是什么？（Python/Go？K8s经验？还是更擅长Shell脚本？）

基于答案，定义MVI。例如：

• 若痛点是“单卡7B模型QPS仅5，业务要求50”，MVI就是：在单台A100服务器上，用vLLM+FastAPI部署，实现QPS≥45，P99≤1200ms；
• 若痛点是“模型更新要停服”，MVI就是：用Docker+Traefik实现双实例蓝绿部署，更新时零停机；
• 若团队无K8s经验，MVI甚至可以是：用systemd管理vLLM进程，配合nginx做负载均衡——先跑通，再演进。

注意：MVI必须包含可验证的验收标准（如“用locust压测100并发，成功率100%，P99<1200ms”），而非模糊描述。这是防止范围蔓延的防火墙。

3.2 步骤二：构建“黄金路径”基准测试套件

不要一上来就压测线上环境。先建立本地可复现的基准测试（Benchmarking）套件，它将成为你所有优化的标尺。套件需覆盖三类典型请求：

• 短文本：输入50token，输出30token（模拟问答）；
• 长文本：输入512token，输出200token（模拟摘要）；
• 高并发：100个短文本请求同时发起（模拟API网关流量）。

使用标准化工具：

• vLLM自带benchmarks/benchmark_serving.py，支持指定模型、输入长度、输出长度；
• locust编写脚本，模拟真实用户行为（含思考时间、随机输入）；
• nvidia-smi dmon -s u实时采集GPU利用率、显存占用、功耗。

关键动作：运行三次，取中位数，记录初始基线。例如：vLLM默认配置下，7B模型短文本QPS=42，P99=980ms，GPU利用率72%。这个数字，是你后续所有优化的起点。

3.3 步骤三：聚焦“单点突破”：优先攻克最高杠杆率的瓶颈

分析基线数据，找出杠杆率最高的优化点。杠杆率=（优化后收益）/（投入工时）。常见高杠杆点：

• Tokenizer优化：如前述，预加载vocab可降300ms延迟，投入0.5人日；
• KV Cache配置：--block-size 32vs--block-size 16，对长文本吞吐影响可达40%，配置即生效；
• 量化选择：从FP16切到AWQ INT4，显存减半，QPS提升1.8倍，vLLM一行命令--quantization awq搞定。

某团队基线QPS=42，分析发现Prefill阶段占总耗时65%。他们没去改Attention内核，而是将--max-num-batched-tokens 2048（最大批处理token数）从默认256提升至2048，让vLLM能更激进地合并请求。结果QPS跃升至78，投入仅2小时。这就是杠杆思维：找到系统中最“松动”的螺丝，轻轻一拧，全局改善。

3.4 步骤四：引入轻量级可观测性，让决策有据可依

在MVI跑通后，立即接入基础可观测性。拒绝“等架构做完再加监控”的陷阱。最小可行方案：

• Metrics：用vLLM内置Prometheus Exporter（--enable-prometheus-exporter），暴露关键指标；
• Logs：用structlog替代print，为每条日志添加request_id、model_name、stage（prefill/decode）字段；
• Traces：用OpenTelemetry Python SDK，在FastAPI路由中添加@app.get("/generate")装饰器，自动记录HTTP耗时。

部署Grafana，创建第一个Dashboard：展示vllm:gpu_cache_usage_ratio（应<90%）、vllm:request_waiting_time_seconds（中位数应<100ms）、http_request_duration_seconds（P99应<1200ms）。当某个指标异常，你就能立刻下钻，而不是靠猜。

3.5 步骤五：实现自动化部署与回滚

手工ssh到服务器执行git pull && python serve.py的时代必须终结。MVI阶段可用最简方案：

• 编写deploy.sh脚本，封装docker build、docker stop、docker run；
• 在Git仓库根目录放Makefile，执行make deploy即可一键发布；
• 保存上一版Docker镜像ID，make rollback时docker run旧镜像。

进阶方案：用GitHub Actions，Push到main分支自动触发CI/CD流水线，构建镜像、推送到私有Registry、SSH到服务器拉取并重启。某团队实现后，模型迭代从“手动操作15分钟”变为“提交代码后3分钟自动上线”，且每次发布都有完整审计日志。

3.6 步骤六：建立模型与资源的“契约式管理”

当Infra服务多个团队，必须定义清晰的“服务契约”（SLA）。在MVI中，这体现为一份简单的service-contract.md：

## 模型服务契约（v1.0） - **服务范围**：仅支持HuggingFace格式的Decoder-only模型（Llama/Qwen系列） - **资源配额**：单实例最大申请8GB显存，CPU不限 - **SLA承诺**：P99延迟 ≤ 1200ms（输入≤512token，输出≤200token） - **变更通知**：模型版本更新提前24小时邮件通知 - **责任边界**：Infra团队负责底层运行时，业务团队负责模型权重与Tokenizer一致性

这份契约不是束缚，而是共识。它让Infra团队有底气拒绝“临时加个T5支持”的需求，也让业务方清楚自己的权责。某公司推行后，跨团队扯皮事件减少70%。

3.7 步骤七：启动“渐进式增强”：从MVI走向生产级

MVI验证成功后，按优先级逐步增强：

• 增强1（1周）：增加健康检查端点/health，返回GPU显存、vLLM队列长度、模型加载状态；
• 增强2（2周）：接入企业级日志系统（如ELK），设置关键词告警（如“OOM”、“CUDA out of memory”）；
• 增强3（3周）：实现模型版本灰度，用Nginx按Header或Cookie分流；
• 增强4（4周）：集成模型注册中心（如MLflow Model Registry），所有上线模型必须注册并标注stage=Production。

关键原则：每次增强只解决一个明确问题，且必须有可验证的收益。例如“增强2”上线后，告警平均响应时间从45分钟缩短至8分钟，这就是成功。

4. 工具链选型实战：vLLM、TGI、Triton-LLM的硬核对比

面对vLLM、TGI、TensorRT-LLM、llama.cpp等工具，选型不是比参数，而是比“谁最懂你的场景”。这里不做泛泛而谈，直接给出四组真实场景下的选型决策树，并附上关键配置与避坑指南。

4.1 场景一：创业公司快速上线AI客服，预算有限，需兼顾开发速度与成本

核心诉求：2周内上线7B模型客服，支持100并发，单token成本<$0.001，团队无CUDA专家。
选型结论：vLLM + FastAPI + Docker（非TGI或Triton）。

为什么不是TGI？
TGI虽成熟，但Docker镜像体积超3GB，启动时间>90秒，对需要频繁扩缩的云环境不友好；其REST API返回格式复杂（含generated_text、details嵌套），前端解析成本高。而vLLM的OpenAI兼容API（/v1/chat/completions）开箱即用，前端几乎不用改。

关键配置：

# 启动命令（重点参数） python -m vllm.entrypoints.api_server \ --model meta-llama/Llama-2-7b-chat-hf \ --tensor-parallel-size 1 \ # 单卡，不启TP --dtype half \ # FP16，平衡精度与速度 --max-num-batched-tokens 2048 \ # 激进合并请求 --block-size 32 \ # KV Cache页大小，长文本更优 --enable-chunked-prefill \ # 支持超长输入（>32k token） --port 8000

避坑指南：

• 切勿开启--enforce-eager：此参数禁用vLLM的图优化，QPS直降40%；
• Tokenizer必须预加载：在api_server.py中，于async def create_background_tasks()里初始化tokenizer，否则首请求延迟暴涨；
• Docker内存限制设为显存的1.2倍：docker run -m 24g（A100 20GB显存），避免OOM Killer误杀进程。

实测结果：单A100，7B模型QPS=82，P99=720ms，单token成本$0.00083（按AWS p4d实例小时价$3.79计）。

4.2 场景二：金融风控场景，模型需严格可复现，且必须支持INT4量化

核心诉求：部署13B风控模型，要求每次推理结果bit-wise一致（用于审计），INT4量化后显存占用≤10GB，P99延迟≤1500ms。
选型结论：TensorRT-LLM + Triton Inference Server（非vLLM）。

为什么不是vLLM？
vLLM的AWQ量化虽快，但其INT4 kernel在A100上存在微小数值误差（<1e-5），不满足金融级可复现要求；且其量化流程需先用awq库转换权重，再加载，步骤繁琐。TensorRT-LLM的--use_weight_only_quantization参数，可在构建引擎时直接生成INT4权重，且提供--enable_fp8选项确保全程FP8精度，bit-wise结果100%一致。

关键配置：

# 构建TRT-LLM引擎（关键！） trtllm-build \ --checkpoint_dir ./llama-13b-fp16 \ --output_dir ./trt_engine \ --use_weight_only_quantization \ --weight_only_precision int4 \ --max_batch_size 128 \ --max_input_len 512 \ --max_output_len 200 \ --gpt_attention_plugin float16 \ --paged_kv_cache # 启用Paged KV Cache

避坑指南：

• 必须用--paged_kv_cache：否则INT4引擎无法启用动态批处理，QPS腰斩；
• Triton配置config.pbtxt中，max_batch_size必须≤构建时的--max_batch_size，否则加载失败；
• 首次构建耗时极长（A100需2小时），建议在CI流水线中预构建，而非线上构建。

实测结果：13B模型INT4引擎，显存占用9.8GB，QPS=36，P99=1320ms，结果100%可复现。

4.3 场景三：边缘设备部署，硬件为Jetson Orin（32GB），需极致轻量

核心诉求：在Jetson Orin上运行7B模型，内存占用<8GB，支持流式输出，启动时间<10秒。
选型结论：llama.cpp + gguf量化（非任何GPU框架）。

为什么不是vLLM/TGI？
vLLM最低要求CUDA 11.8，Jetson Orin默认CUDA 11.4，编译极其困难；TGI依赖PyTorch，ARM64 wheel包稀少。llama.cpp纯C/C++实现，对CUDA无强依赖，且gguf格式支持CPU/GPU混合推理（GPU跑Attention，CPU跑MLP），完美适配Orin的异构架构。

关键配置：

# 量化模型（Q4_K_M，平衡速度与精度） ./quantize ./models/llama-2-7b.Q8_0.gguf ./models/llama-2-7b.Q4_K_M.gguf Q4_K_M # 启动（启用GPU加速） ./main -m ./models/llama-2-7b.Q4_K_M.gguf \ -ngl 40 \ # 将40层Offload到GPU（Orin GPU有1024 CUDA core） -c 2048 \ # context length -b 512 \ # batch size -p "Hello, how are you?" \ --stream

避坑指南：

• -ngl参数是关键：设为0则纯CPU，慢10倍；设为40（7B共32层，留余量）则GPU利用率85%；
• 必须用Q4_K_M或Q5_K_M量化：Q2_K精度损失过大，回答质量断崖下跌；
• -b 512不能设太大：Orin显存仅16GB，batch过大易OOM。

实测结果：Orin上7B模型QPS=3.2（流式），内存占用7.1GB，启动时间4.2秒。

4.4 场景四：科研实验室，需调试模型内部状态（如Attention权重、梯度）

核心诉求：训练/推理时，能实时获取某一层Attention的QKV矩阵、梯度值，用于算法研究。
选型结论：HuggingFace Transformers + PyTorch Profiler + 自定义Hook（非任何推理框架）。

为什么不是vLLM/Triton？
vLLM等框架为极致性能，将计算图高度融合，内部状态不可见；Triton更封闭。Transformers虽慢，但提供了完整的forward钩子（register_forward_hook）和梯度钩子（register_full_backward_hook），可精准捕获任意层输出。

关键代码：

from transformers import AutoModelForCausalLM import torch model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b") # 获取第10层Attention的QKV输出 def hook_fn(module, input, output): print(f"Layer 10 QKV shape: {output[0].shape}") # output[0] is attn_output torch.save(output[0], f"layer10_attn_{step}.pt") model.model.layers[10].self_attn.register_forward_hook(hook_fn) # 推理时自动触发hook outputs = model.generate(input_ids, max_new_tokens=10)

避坑指南：

• Hook会显著降低速度（约30%），仅用于调试，切勿上线；
• 梯度Hook需在loss.backward()后触发，注意retain_graph=True；
• 用torch.profiler.profile定位热点：with torch.profiler.profile(record_shapes=True) as prof:，避免盲目优化。

5. 那些没人明说的Infra真相：来自一线的12条血泪经验

Infra的世界没有银弹，只有无数个“当时要是知道就好了”的瞬间。这里分享12条在多个项目中反复验证的硬核经验，它们不会出现在官方文档里，却是决定成败的关键。

5.1 经验1：显存不是瓶颈，显存“碎片”才是

你可能遇到：nvidia-smi显示显存占用95%，但vLLM报错CUDA out of memory。真相是：显存被切成无数小块，最大的一块只有2GB，而vLLM需要连续4GB加载KV Cache。解决方案不是“清显存”，而是启用PagedAttention（vLLM默认开启）或设置--block-size 16，让显存管理像操作系统一样高效。某团队将--block-size从32调至16，相同硬件下支持的并发数提升2.3倍。

5.2 经验2：模型加载时间，往往比推理时间还长

vLLM加载7B模型需12秒，TGI需22秒。这期间服务不可用。必须预加载：在容器启动时，用curl http://localhost:8000/health轮询，直到返回{"healthy": true}再对外暴露服务。某团队在K8s中配置startupProbe，失败重试30次，避免流量涌入时服务雪崩。

5.3 经验3：Tokenize不是免费的，它是延迟大户

HuggingFace Tokenizer的encode函数，单次调用可能耗时200ms（尤其对长文本）。预编译tokenizer：用tokenizers库的save_pretrained保存为二进制，加载时用from_pretrained(..., local_files_only=True)，速度提升5倍。更激进方案：用Rust重写核心encode逻辑，再用PyO3封装。

5.4 经验4：KV Cache的“寿命”比你想的短得多

默认vLLM的KV Cache在请求结束后立即释放。但若用户连续提问（如聊天场景），缓存复用可降延迟40%。启用--enable-prefix-caching（vLLM 0.4.0+），它会为相同prefix的请求复用KV Cache。某客服系统启用后，多轮对话首token延迟从850ms降至320ms。

5.5 经验5：网络延迟在Infra中占比常被低估

跨AZ（可用区）部署时，API网关到推理服务的RTT可能达15ms，而模型推理仅需8ms。必须同AZ部署：K8s中用topology.kubernetes.io/zone标签，配合TopologySpreadConstraints，确保网关与推理Pod在同一物理机架。

5.6 经验6：日志级别设为WARNING，是Infra稳定的第一道防线

INFO日志会淹没关键错误。某团队将vLLM日志级别设为INFO，单日产生2TB日志，ES集群崩溃。强制所有组件日志级别为WARNING，错误用structlog打结构化ERROR日志，包含error_code、request_id、model_name，便于ELK聚合告警。

5.7 经验7：模型版本的“哈希值”，比Git Commit ID更可靠

git commit abc123可能对应不同权重文件（因.gitignore漏掉pycache）。用sha256sum model.safetensors生成权重哈希，作为模型唯一ID，注册到元数据中枢。某公司因此避免了一次“线上跑错模型版本”事故。

5.8 经验8：CPU核数，有时比GPU卡数更重要

vLLM的--worker-use-ray模式，每个Worker需1个CPU核处理请求调度。若8卡A100只配16核CPU，调度器会成为瓶颈。CPU:GPU配比至少为2:1（如8卡配16核以上），vLLM文档明确建议“32核 for 8xA100”。

5.9 经验9：Prometheus的scrape_interval不能设太小

默认15秒抓取，对vLLM高频指标（如request_waiting_time）会丢失峰值。设为5s，但需同步调高Prometheus内存（--storage.tsdb.retention.time=30d），避免OOM。

5.10 经验10：模型服务的“健康检查”，必须包含业务逻辑

/health返回200不代表服务健康。某团队的健康检查只查进程存活，结果线上服务因KV Cache泄漏，vllm:gpu_cache_usage_ratio达99.8%，但/health仍返回200。健康检查必须调用/generate接口，传入固定prompt，验证返回choices[0].text非空且耗时<1000ms。

5.11 经验11：Docker镜像的ENTRYPOINT，应指向可