1. 从一次推理服务雪崩说起2026 年做大模型推理服务最让人头疼的不是模型效果而是流量曲线。白天业务高峰 QPS 冲到 800凌晨掉到 30如果 GPU 节点按峰值常驻账单会教你做人如果按均值配置高峰期请求排队直接超时。大模型推理弹性伸缩要解决的就是这件事让 GPU 集群的副本数跟着真实负载走同时保证调度链路不成为瓶颈。我这次落地的场景是自建 GPU 集群上的推理服务模型是 7B 和 13B 两个规格前端通过统一 API 通道接入后端用 Kubernetes 管理 GPU 节点池。核心诉求有三个第一所有模型调用走同一个 Key 和同一个入口避免每个服务单独维护鉴权第二扩缩容触发链路要可观测能看清是哪个指标触发的第三配置要能直接复制到自己的集群里跑通验证。这篇文章交付的就是这套工程骨架一份可复制的config.toml和settings.json一组扩缩容阈值参数以及从发请求到看到副本数变化的完整验证动作。适合已经在跑推理服务、想补齐弹性伸缩链路的工程师也适合刚开始接触 GPU 集群调度、想找一个可跟做起点的人。下面按接入、配置、验证、排障的顺序展开每一步都有具体命令和参数。2. TaoToken 统一 Key 接入推理服务的前置通道在讲 GPU 调度之前先把入口统一掉。自建推理服务最容易乱的地方是鉴权A 服务用一套 KeyB 服务用另一套扩缩容时新副本还要同步密钥。TaoToken 在这里的角色是统一 API 通道你只需要维护一份 Key所有推理服务通过同一个 base_url 接入扩容出来的新副本直接复用环境变量里的 Key不需要额外分发。具体操作上先在控制台创建 API Key然后把它写进推理服务的环境变量。注意 Key 只放在服务端环境变量或密钥管理里不要硬编码进镜像。接入地址用https://taotoken.net/api这个地址不带任何查询参数直接作为 OpenAI 兼容协议的 base_url 使用。如果你用的是 Claude Code 这类编码 Agent 做调试可以走 Coding Plan 通道它和推理服务的 Key 是分开管理的互不影响。调试阶段想快速验证模型连通性用模型对话页面直接发一条请求就行不用先搭服务。生产接入的 Key 管理在 API Keys 页面接入协议细节看接入文档。这里有个容易踩的坑扩缩容时新副本启动会并发拉取配置如果 Key 是通过启动脚本从远端拉的可能瞬间打满配置服务。建议把 Key 通过 Kubernetes Secret 挂载成环境变量副本启动时直接读本地不走网络。3. 推理服务配置骨架config.toml 与 settings.json配置分两层config.toml管推理服务本身的运行参数settings.json管调度和扩缩容策略。先看config.toml这是推理服务进程读取的配置重点是模型路径、并发上限和健康检查端口。# config.toml - 推理服务运行配置 [server] host 0.0.0.0 port 8080 # 单副本最大并发请求数超过则排队 max_concurrent_requests 64 # 请求队列上限超过直接返回 503避免雪崩 max_queue_size 128 # 单请求超时秒 request_timeout 120 [model] name qwen-7b-instruct path /models/qwen-7b-instruct # GPU 显存利用率上限留出余量给 KV Cache gpu_memory_utilization 0.85 # 最大上下文长度 max_model_len 8192 # 张量并行度单卡填 1 tensor_parallel_size 1 [api] # 统一通道地址不带查询参数 base_url https://taotoken.net/api # Key 从环境变量读取不写死在配置里 api_key_env TAOTOKEN_API_KEY # 健康检查路径供 K8s 探针使用 health_path /health metrics_path /metrics再看settings.json这是调度侧读取的扩缩容策略。核心是三个指标GPU 利用率、请求队列长度、P99 延迟。任何一个超过阈值就触发扩容全部低于阈值并持续一段时间就缩容。{ autoscaling: { min_replicas: 2, max_replicas: 20, scale_up: { gpu_utilization_threshold: 0.75, queue_length_threshold: 32, p99_latency_ms_threshold: 2000, cooldown_seconds: 60, step: 2 }, scale_down: { gpu_utilization_threshold: 0.30, queue_length_threshold: 4, p99_latency_ms_threshold: 800, stabilization_seconds: 300, step: 1 } }, scheduling: { gpu_type: a100-40g, node_pool: inference-pool, pod_anti_affinity: true, max_pods_per_node: 2 } }参数说明几个关键点。scale_up.step设为 2 而不是 1是因为大模型副本冷启动要加载权重一次扩 1 个跟不上流量爬升速度一次扩 2 个能更快压住队列。scale_down.stabilization_seconds设为 300 秒是防止流量抖动导致频繁缩容又扩容缩容比扩容更需要保守。pod_anti_affinity打开是为了避免同一模型的多个副本挤在同一张卡上单卡故障时不会全挂。4. 自动扩缩容触发链路与验证请求配置写好后触发链路是这样的推理服务暴露/metricsPrometheus 每 15 秒抓一次HPA 或自定义控制器读取指标对比settings.json里的阈值决定是否调整 Deployment 的副本数。整条链路要验证的是「指标上报 → 阈值判断 → 副本变化」三步都通。先验证指标上报。启动一个副本发几条请求然后拉取 metrics 端点# 启动推理服务本地验证用 export TAOTOKEN_API_KEY你的Key python -m inference_server --config config.toml # 另开终端发一条测试请求 curl -X POST http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-7b-instruct, messages: [{role: user, content: 你好}], max_tokens: 64 } # 查看指标确认 gpu_utilization 和 queue_length 有数值 curl -s http://localhost:8080/metrics | grep -E gpu_utilization|queue_length|p99_latency如果 metrics 里能看到inference_gpu_utilization 0.42这类数值说明上报链路通了。接下来验证扩缩容触发。用压测工具把并发打上去观察副本数变化# 用 hey 压测200 并发持续 120 秒 hey -z 120s -c 200 -m POST \ -H Content-Type: application/json \ -d {model:qwen-7b-instruct,messages:[{role:user,content:测试}],max_tokens:32} \ http://localhost:8080/v1/chat/completions # 另开终端每 10 秒看一次副本数 watch -n 10 kubectl get deployment inference-qwen7b -o jsonpath{.spec.replicas}预期结果是压测开始后 60 秒内副本数从 2 涨到 6 到 8压测停止后副本数在 5 分钟左右回落到 2。如果副本数不动先查 HPA 有没有读到指标再查阈值是不是设得太高。实测下来gpu_utilization_threshold设 0.75 比较稳设 0.9 会导致扩容滞后队列已经堆起来了才触发。验证成功后把settings.json里的min_replicas和max_replicas按你的节点池容量调整。节点池有多少张卡max_replicas就设成卡数除以单副本卡数别超卖。5. 本篇常见错排查报错一no available GPU node to schedule pod。这是节点池容量不够或者max_pods_per_node设太大导致调度器认为节点已满。先kubectl describe pod看 Events如果是Insufficient nvidia.com/gpu说明卡不够要么加节点要么把max_replicas调小。如果是NodeAffinity不匹配检查settings.json里的gpu_type和节点标签是否一致。报错二扩容后新副本一直CrashLoopBackOff。大概率是 Key 没挂载进去。新副本启动时读TAOTOKEN_API_KEY环境变量如果 Secret 没配好进程会直接退出。用kubectl exec进容器echo $TAOTOKEN_API_KEY确认空的话检查 Deployment 的envFrom有没有引用正确的 Secret。报错三缩容后请求超时率飙升。这是缩容太激进副本还没处理完在途请求就被杀掉。解决方法是给 Pod 加preStop钩子让进程先停止接收新请求处理完队列再退出lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 30] terminationGracePeriodSeconds: 60报错四metrics 里gpu_utilization一直是 0。检查推理服务有没有正确调用 GPU以及 metrics 采集有没有权限读 GPU 状态。如果是容器里跑确认nvidia-container-toolkit装好了nvidia-smi能在容器里执行。报错五扩缩容频繁抖动。流量在阈值附近来回穿越导致反复扩缩。把scale_up.cooldown_seconds和scale_down.stabilization_seconds都调大或者改用滑动窗口平均值而不是瞬时值来判断。抖动对 GPU 集群伤害很大每次扩缩都涉及权重加载和显存分配宁可反应慢一点。6. 接入与排障的下一步整套链路跑通后日常维护主要盯三件事Key 有没有过期、节点池容量够不够、扩缩容日志有没有异常模式。Key 管理在 API Keys 页面建议设个提醒到期前轮换。接入协议如果有更新看接入文档确认兼容性。调试阶段想快速验证某个模型能不能调通直接用模型对话发一条请求比搭服务快得多。如果你在用 Claude Code 做推理服务的代码开发Coding Plan 通道可以单独配和推理服务的 Key 隔离避免调试流量影响生产配额。最后留一个实用技巧把每次扩缩容的触发指标和副本数变化打到日志里格式化成一行 JSON方便后续做容量规划。跑上一周你就能看出业务的真实峰谷曲线比拍脑袋设阈值靠谱得多。