部署方式¶

部署方式应该由数据边界、时延、流量形态和团队运维能力决定。模型是否能启动只是第一步。

五种常见模式¶

模式	适合	优点	代价
托管模型 API	快速验证、流量不稳定、追求前沿能力	无 GPU 运维，弹性强	数据与供应商依赖，按 token 计费
本地桌面	学习、离线个人助手、小模型	简单、私密、低固定成本	并发和可靠性有限
单机单/多卡服务	部门应用、稳定负载、私有化	可控，调优空间大	驱动、容量、监控由团队负责
Kubernetes/集群	多模型、高并发、共享 GPU 池	调度、弹性、灰度和隔离	复杂度高，需要平台团队
混合路由	企业生产、隐私分级、成本优化	各取所长，可降级	路由、评测和审计更复杂

工具怎么选¶

llama.cpp¶

适合 CPU、Apple Silicon、NVIDIA/AMD/Intel 等多种硬件上的 GGUF 量化模型，本地体验和边缘部署门槛低。官方仓库支持 OpenAI 兼容服务、CPU+GPU 混合推理和多种整数位宽。

llama-server -hf ggml-org/Qwen3.5-0.8B-GGUF --port 8080

来源：llama.cpp 官方仓库。

vLLM¶

适合 NVIDIA/AMD 等服务器上的高吞吐服务，常用于连续批处理、PagedAttention、张量并行、量化和 OpenAI 兼容 API。新模型支持与参数名称变化快，部署前应锁定版本并读对应模型 recipe。

vllm serve Qwen/Qwen3.8-27B \
  --port 8000 \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

该命令来自 Qwen3.8 官方部署说明。实际运行前按 GPU 数和显存降低 tensor-parallel-size 与 max-model-len。

SGLang¶

适合高性能生成、结构化输出、Agent 和长前缀复用场景。与 vLLM 一样，应使用目标模型官方给出的 reasoning/tool parser。

sglang serve \
  --model-path Qwen/Qwen3.8-27B \
  --port 8000 \
  --tp-size 4 \
  --context-length 262144 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

Transformers¶

适合模型研究、快速验证和自定义 forward/generation。生产吞吐通常需要 vLLM、SGLang、TensorRT-LLM 或专用 serving 层。不要把 Notebook 中能生成结果等同于生产服务。

托管平台与 NIM¶

当团队更看重 SLA、企业支持、区域与快速上线，可使用云模型平台、托管端点或 NVIDIA NIM。先确认模型版本、数据留存、网络出口、扩缩容时延和价格，而不是只看“一键部署”。

容器化单机示例¶

以下结构比把模型直接跑在终端里更接近可移交系统：

services:
  model:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    ports:
      - "8000:8000"
    volumes:
      - ./models:/models:ro
    command:
      - --model=/models/model
      - --served-model-name=local-model
      - --max-model-len=8192
      - --gpu-memory-utilization=0.88
    restart: unless-stopped

生产中不要使用浮动 latest，应固定镜像 digest 或明确版本。模型目录只读，缓存、日志和配置使用独立卷。

健康检查的三层¶

进程存活：端口可连接。
模型就绪：模型加载完成，能响应最小请求。
业务可用：使用固定样本验证结构化输出、检索或工具链。

只做端口健康检查会让“进程活着但模型坏了”的实例继续接流量。

上线步骤¶

固定模型、容器、驱动和配置版本。
在单并发下验证质量与最长输入。
扫描并发，记录吞吐、TTFT、TPOT、显存和错误率。
设置队列上限、请求超时、最大输入与最大输出。
用 1% 到 5% 流量灰度，比较业务指标。
保持旧版本热备或可快速回滚。
达到门槛后逐级扩流，不一次全切。

典型部署错误¶

开放 0.0.0.0 端口但没有鉴权和防火墙。
为追求模型标称上下文把 KV Cache 配满，导致并发接近零。
多卡只关注总显存，忽略 PCIe/NVLink 通信和拓扑。
同时开启量化、推测解码、前缀缓存和编译，出错后无法归因。
自动重试没有总时限和幂等键，引发重试风暴或重复写入。
模型、Tokenizer、chat template 和 parser 版本不匹配。

三种可落地蓝图¶

蓝图 A：单团队私有服务¶

业务应用 -> 内网反向代理 -> 1 台推理服务器
                           -> 指标采集
                           -> 只读模型仓库

适合 5 到 30 个内部用户和稳定的小流量。重点是固定版本、限制并发、留出人工兜底。不要为了“以后扩容”提前引入 Kubernetes。

蓝图 B：共享 GPU 平台¶

多个应用 -> API Gateway -> 模型路由 -> 推理池 A
                                   -> 推理池 B
                        -> 配额 / 成本 / 审计

适合多个团队共用硬件。平台必须提供租户隔离、模型别名、配额、队列保护、成本归属和版本变更通知，否则共享只会把故障域放大。

蓝图 C：混合敏感度路由¶

请求 -> 数据分类器 -> 敏感：私有模型
                  -> 一般：托管 API
                  -> 高风险动作：人工审批

路由规则应是代码或可版本化配置，并把分类结果写入审计日志。不能依靠提示词要求模型自己判断数据是否可以出域。

生产参数基线¶

参数	起始策略	必须验证的风险
`max_model_len`	按 P95 输入加输出余量，不直接开满	KV Cache 挤压并发
GPU memory utilization	从 0.85 到 0.90 起测	碎片、峰值 OOM
最大并发	用压测找到 SLO 拐点	排队和超时放大
请求超时	略高于业务 P99，设置总时限	无限重试占满队列
最大输出	按任务上限设置	成本失控、长尾时延
重试	只重试可恢复错误，指数退避	重复写入、重试风暴
前缀缓存	稳定公共前缀才开启	缓存命中率虚高、隔离风险

不要照抄表中的值。参数基线的意义是让第一次试验有明确起点，每个改动都要关联性能结果和版本记录。

发布清单¶

[ ] 模型、Tokenizer、chat template、parser 版本一致
[ ] 镜像 digest、启动参数和环境变量已记录
[ ] 最小请求、长输入、结构化输出和工具调用均通过
[ ] 未授权请求、超配额请求和危险输入均被阻断
[ ] 容量达到预计峰值的 1.5 倍且仍符合 SLO
[ ] 上一版本可在目标恢复时间内重新接流量
[ ] 日志不包含密钥、完整敏感输入或思维链
[ ] 值班人实际执行过告警和回滚步骤

故障演练¶

至少做四次人工故障注入：杀掉一个推理实例、让上游返回 429、制造超长输入、让工具调用超时。观察网关是否限流或降级、请求是否幂等、告警是否到达正确负责人、恢复后是否积压重放。

上线判定：健康请求成功不代表系统可上线。只有错误路径产生预期状态码、可解释日志和受控降级，部署才具备生产含义。