服务、网关与算力

服务为何困难，理论部分 第 31 章 与 第 32 章 已经讲过；落到实践里，它是一条由三个决定组成的请求路径。自托管端点只在负载值得时才划算，网关（gateway） 要放在前面管住密钥与成本，整套东西还必须落到能够承担的算力之上。这条路径自上而下穿过三个层：与之对话的网关、解码 token 的服务引擎，以及下方的 GPU。

自托管栈的三层

一个自托管推断栈是三层，外加一条贯穿其中的统一接口。图 82.2 展示了请求路径。

接口是整套设计的关键。到 2026 年，几乎每个引擎和网关都讲 OpenAI 的 HTTP 形态（/v1/chat/completions、/v1/completions、/v1/embeddings）。正是这一单一约定，让自托管模型可以换成托管模型、多个引擎前可以统一架一个网关，也让评测工具链（第 87 章）指向与生产相同的 URL。如今在它旁边又浮现出第二种形态：OpenAI 自己的主接口已换成有状态的 Responses API，vLLM 也在经典端点之外提供了 /v1/responses；但 Chat Completions 仍是各引擎与网关互操作的最小公分母。围绕它来构建，并让每一层都保持可替换。

第 1 层：服务引擎

服务引擎把一组权重变成一项服务：它把模型加载到加速器上，对请求做批处理，运行前向传播，管理键值缓存，并把 token 流式返回。大部分可控成本与大部分用户可感知延迟都在这里。同一组权重在两个引擎下、或在同一引擎的两套配置下，每秒 token 数与尾延迟可以相差一个数量级。

两个阶段驱动了每一个设计决策（第 31 章）。Prefill 并行处理整个提示词，是计算受限的。Decode 每次只产出一个 token，每一步都要重读缓存，是内存带宽受限的。关键特性都在回应二者之间的取舍，其中多数会在 第 32 章 与 第 33 章 中展开，这里先给出简版。连续批处理（continuous batching）每步加入与退出请求，是 2026 年的入门标配。PagedAttention 把缓存存为非连续的页，避免内存碎片。前缀缓存 / KV 复用把共享的前导前缀只算一次，是智能体与 RAG 的主导收益，并被 SGLang 的 RadixAttention 推广为基数树（一棵以 token 前缀为键的字典树）。量化（第 34 章）把权重压到更少的比特：FP8、FP4、经由 AWQ/GPTQ 的 INT4、GGUF K-quants。投机解码（第 33 章）先草拟廉价的 token，再用一遍验证它们。结构化输出是经 XGrammar 的语法约束解码，好让工具调用与抽取出的数据能被解析。prefill/decode 解耦把两个阶段放到各自独立的 worker 池上，是 2026 年数据中心的招牌模式。

玩家

下表是 2026 年年中的快照。许可证与「最适合」较为持久；基准注记来自第三方且与负载相关。

截至 2026 年年中，第三方基准报告 SGLang 在某些 H100 单模型测试上领先 vLLM（有一处引用约 29%），在前缀密集形态上收益更大，到 70B 规模差距收窄；LMDeploy 在吞吐上接近 SGLang，INT4 70B 的 TTFT 同级最佳；MLX 在某些 Apple Silicon 模型上比 llama.cpp 快 30 到 50%。这些来自厂商与博客基准，随模型、GPU、批形状与调优而变，且很快过时。在把任何一个当作决定因素之前，先在自己的负载上验证。

如何选引擎

这个决策主要是三个变量的函数：在哪里运行、流量长什么样，以及能投入多少性能工程。

• 选 vLLM，当想要 GPU 上一个稳妥、广受支持的默认、眼下就需要广泛的模型与特性、并且看重生态成熟度甚于最后那 20% 的性能时。对多数团队，这是更稳妥的起点。
• 选 SGLang，当流量前缀密集（智能体、RAG、多轮）或要服务大型 MoE 模型、并且想在这些形态上拿到顶级吞吐时。先在自己的流量上验证收益。
• 选 TensorRT-LLM，当全栈 NVIDIA、延迟与吞吐是一等成本、并且能在工具链上投入时（默认 PyTorch 后端相比旧构建流程降低了这一成本）。
• 选 LMDeploy，当量化的 w4a16 服务与 NVIDIA 机群上的低 TTFT 最为关键。
• 选 llama.cpp，当需要可移植性（CPU、经 Vulkan/ROCm 的 AMD、Metal）、边缘或本地部署与 GGUF 量化、且不需要数据中心级并发时。
• 选 Ollama 或 MLX，当目标是一台笔记本或少数内部用户；在 Apple Silicon 上专门选 MLX 拿最快单流。
• 上 Dynamo 或 llm-d，当已超出单节点、需要跨机群的 KV 感知路由、解耦与按 SLO 驱动的自动伸缩时。
• 2026 年不要从 TGI 起步；它已归档且仅维护。

稳妥默认（2026 年年中）： vLLM 架在 OpenAI 兼容端点之后，开启前缀缓存，配上合适的量化（Hopper/Blackwell 上用 FP8，或用 AWQ/GPTQ INT4 把更大的模型塞进更小的卡），并为任何工具调用或抽取路径配上 XGrammar 支持的结构化输出。它覆盖面最广，迁移风险也最低。对本地与开发，默认就转向 Linux/Windows 上的 Ollama 或 llama.cpp 以及 Mac 上的 MLX。它们是单节点、低并发的工具；不要把它们推进高流量路径。

一个最小的单节点 vLLM 启动：

vllm serve <model-id> \
  --enable-prefix-caching \
  --quantization fp8 \
  --guided-decoding-backend xgrammar
# 在 :8000 暴露一个 OpenAI 兼容服务器

标志名与结构化输出参数在 vLLM 各版本间会漂移；请查阅所用版本的文档。

第 2 层：网关

模型网关是一个控制平面，夹在应用代码和它要对话的众多模型供应商之间。往最简单里说，它是一个反向代理：讲一套 API，把请求扇出到 OpenAI、Anthropic、Google、Bedrock、Azure、自建的 vLLM，以及像 OpenRouter 这样的聚合器。但生产职责远不止代理转发。五件事不适合散落在应用代码各处，网关正是把它们集中起来的地方：

1. 统一 API。 一套请求 schema，于是把 gpt-5 换成 claude-opus-4 或一个自托管变体是改配置，而不是改代码。
2. 密钥托管。 供应商密钥留在服务器上。应用与智能体只持有短期的虚拟密钥，受限于模型白名单与预算，从不接触原始供应商凭据。
3. 成本追踪。 按密钥、按团队、按标签的花费，归因并可导出。这是团队采用网关被引用最多的单一理由。
4. 回退与路由。 重试、供应商故障切换、负载均衡、上下文窗口回退、按成本或延迟感知的模型选择。
5. 预算与策略。 硬性花费上限、速率限制、护栏（PII 脱敏、越狱过滤）与审计轨迹。

网关是服务层与其上一切之间的接缝。最新的网关把这一理念从单纯的 LLM 调用推到了智能体原生协议（用于工具的 MCP、用于智能体之间的 A2A），于是网关也成了工具与智能体流量的策略点，这一点直接接上了 第 85 章 的运行框架工作与 第 56 章 的授权模型。

玩家

若干厂商发布了夸张的开销数字（Bifrost「比 LiteLLM 快 50 倍」与「约 11µs」；Portkey「<1ms」；LiteLLM「1k RPS 下约 8ms P95」）。这些是条件不一致的厂商基准，未经独立验证。持久的要点是：编译型语言网关（Go/Rust：Bifrost、agentgateway、Helicone、Envoy）通常号称比 Python 的 LiteLLM 代理开销更低，但对多数负载，供应商与模型的延迟以数量级压过网关开销。在把开销当作决定因素之前，先在自己的流量上做基准。第 88 章 里一组受控基准点明了差距真正出现在哪：不是逐请求开销，而是吞吐，Python 代理在几百 RPS 处就饱和，而编译型网关穿过 1000 仍保持平直。

如何选网关

按顺序处理两个轴：托管对自托管，再是纯 LLM 对智能体原生。

• 选 OpenRouter，当身为独立开发者或小团队、想要最大目录、零基础设施、零合同时。
• 选 LiteLLM，当想要一个自托管、广泛兼容的网关、并有 DevOps 去运行时，尤其在 Python 栈、且流量中低、供应商覆盖比吞吐上限更要紧的场景。
• 选 Portkey（或若已在运行 Kong 则选 Kong），当治理、护栏与合规是硬要求而非锦上添花时。
• 选 agentgateway，当路线图偏智能体、需要把 LLM、MCP 与 A2A 流量纳入一个受治理的策略点时。
• 选 Envoy AI Gateway，当平台团队已身处 Envoy/Istio/Gateway API、想让 AI 控制平面留在同一套 CRD 中时。
• 用托管网关（OpenRouter、Cloudflare、Portkey 托管版），当想要零基础设施、并接受密钥与请求元数据经过第三方时。等密钥托管、审计或合规逼到头上，再转向自托管。

稳妥默认（2026 年年中）： 自托管一个性能良好的编译型网关，agentgateway（Rust，Apache-2.0，中立）或 Lux（Go，本书的示范案例），搭配一层可观测性做花费与请求分析。它提供带预算的虚拟密钥、花费追踪与回退，跑在自己的环境里，并在智能体负载下保持平直，而 Python 代理在那里会饱和（第 88 章）。LiteLLM 仍是一个合理之选，适合最广的供应商覆盖与中低流量，那里它的生态广度盖过吞吐上限。agentgateway 还把 LLM、工具与智能体流量纳入同一个策略点，这在路线图偏智能体后就要紧了。

一个最小的网关配置，把一个托管模型与一个自托管模型统一到一个名字之后，并加上回退。这里给的是形状，而非某一款产品的 schema：

# Each gateway has its own schema; this shows the shape, not a product's exact keys.
models:
  - alias: smart                 # 应用请求时用的名字
    target: anthropic/claude-opus-4
    api_key: ${ANTHROPIC_API_KEY}
  - alias: smart                 # 同一别名，负载均衡 / 回退目标
    target: openai/gpt-5
    api_key: ${OPENAI_API_KEY}
  - alias: local
    target: vllm/<model-id>      # 自建的 vLLM，OpenAI 兼容
    base_url: http://vllm-svc:8000/v1

routing:
  smart:
    strategy: fallback           # 若托管目标失败，用下一个
    fallback: [local]
    retries: 2
# 虚拟密钥、团队预算与花费上限在带外签发，
# 经由管理 API 或仪表板，而非此文件。

随后应用把一个标准 OpenAI 客户端指向该代理，请求模型 "smart"。网关解析别名，做负载均衡或故障切换，把花费记到虚拟密钥上，并发出追踪。上游的 "local" 解析到自建的第 1 层引擎，于是自托管与托管模型在一个名字之后变得可互换：

from openai import OpenAI
client = OpenAI(base_url="https://gateway.internal/v1", api_key="<virtual-key>")
resp = client.chat.completions.create(
    model="smart",
    messages=[{"role": "user", "content": "..."}],
)

每个网关都有自己的 schema，且在各版本间会漂移；确切的键请查阅其文档。

第 3 层：其下的算力

这套服务最终都会落到一块 GPU 上，需要有人去预置、调度、付费。两个问题居于中心，且大体正交：GPU 从哪里来（自建对租用轴）以及它们如何被调度。硬件本身是 第 62 章；编排基底是 第 65 章；成本算术是 第 76 章。这里我们做选择。

自托管对调用 API

在为 GPU 定容之前，先解决前置问题：到底要不要自托管？多数团队应当从托管 API 起步，仅当某个具体压力逼迫时才自托管。决策规则很直白：

• 调用托管 API（经网关），当流量是突发或低量、当想要前沿模型但不想运维它、当上线速度比每 token 成本更重要、当数据可以离开自己的环境时。对多数应用团队这是正确默认。
• 自托管，当下列至少一条绑定时：持续高利用率使每 token 经济性占主导（硬件被喂满）、数据驻留或合规要求权重与提示留在自己的环境里、需要某个 API 不提供的开放权重模型或微调、或需要 API 给不了的延迟与尾部行为控制。

网关让这件事可逆。因为两条路都讲同一种 OpenAI 形态的接口，可以从托管起步，把自托管路由作为又一个别名加进来，改配置就能迁移流量。为任一路径选模型是 第 81 章；整个栈的接线是 第 88 章。

GPU 从哪里来

一条谱系从无服务器 GPU 平台（推一个函数或一个模型，机器由它们管），经租用的 GPU 云与 neocloud，到超大规模云，再到在 colo 里自有硬件。决定性变量是持续利用率。

定价波动且聚合器之间不一致，因此锚定形态而非美元数字。截至 2026 年年中，标价锚把无服务器 H100 定在每小时 3 到 4 美元左右（Modal 约 3.95/hr，RunPod 约 2.89/hr），各层级 H100 按需价大约有 5 倍跨度。落地前请重新核实；这些每季度都在动。

经验法则：低于专用 GPU 持续利用率约 40 到 50% 时，无服务器更便宜，因为空闲时不付钱。高于此，neocloud 或超大规模云上的预留 GPU 小时价同时压过无服务器与按需。仅在持续极高利用率、摊销后的资本支出胜过多年租金时才自有硬件。仅为容错批处理用市场或 spot。当想保持可移植、跨云追逐最便宜可用容量并避免锁定时，在所有这些之上用 SkyPilot。

两个每小时价决定无服务器与预留成本线的交叉点；用本章的标价锚，盈亏平衡点落在所说的 40 到 50% 区间附近。

import numpy as np, matplotlib.pyplot as plt
serverless_rate = 3.95   # 美元/GPU-小时，仅在繁忙时付费（缩容到零）
reserved_rate   = 2.00   # 美元/GPU-小时，无论是否空闲都 7x24 计费
hours = 730              # 一个月
u = np.linspace(0, 1, 101)
serverless = u * hours * serverless_rate      # 成本随利用率变化
reserved   = np.full_like(u, hours * reserved_rate)  # 固定成本
breakeven = reserved_rate / serverless_rate   # 交叉点利用率
print(f"盈亏平衡利用率: {breakeven*100:.1f}%")
plt.plot(u*100, serverless, label="serverless（按量付费）")
plt.plot(u*100, reserved, label="预留（固定费用）")
plt.axvline(breakeven*100, ls="--", color="gray")
plt.xlabel("持续利用率（%）"); plt.ylabel("月成本（美元）")
plt.legend(); plt.title("GPU 成本：serverless vs 预留"); plt.show()

GPU 如何被调度

一旦掌控了一个资源池，就由一个控制平面决定放置。三个主导者及其分工：

• Slurm，当主导负载是大型多节点训练与批处理：启动、跑数小时、做检查点、退出的作业。gang 调度（一个作业的所有 worker 要么一起调度，要么都不调度）是原生且简单的。代价是没有原生的服务、入口或自动伸缩。
• Kubernetes，当要运行推断服务、混合负载或与 AI 并列的微服务、并想要自动伸缩、入口与服务网格生态时。加 Volcano 或 NVIDIA KAI Scheduler 做 gang 调度，加 Kueue 做多团队配额与准入，加 DRA 做细粒度 GPU/MIG 分配。
• Ray（在 KubeRay 上），当团队是 Python 原生、想在一个框架里同时做分布式训练、RL、数据与服务、跑在 K8s 之上时。

大团队常见的分工是训练用 Slurm、服务用 Kubernetes。2026 年的收敛是 Slurm-on-K8s 项目（SchedMD Slinky、CoreWeave SUNK、Nebius Soperator）在共享的 K8s 基础设施上保留 Slurm 的 gang 语义，缩小这道分工。势头朝着即便训练也统一到 Kubernetes（经由上述插件），因为如今主导 AI 算力开销的是推断而非训练，而服务恰好想要 Kubernetes 提供的那种弹性、缩容到零、延迟感知的调度。

稳妥默认（2026 年年中）： 对一个交付 AI 功能、混合突发推断与偶尔微调、没有专职基础设施团队的团队，从无服务器 GPU 或托管推断平台起步（Modal 拿通用无服务器 Python 工效，Baseten 拿带 SLA 的生产服务，Fireworks 或 Together 拿纯开放权重模型的 token 推断）。当利用率攀升、租金溢价开始主导账单时，再升级到用 Slurm 训练、Kubernetes 服务来调度的预留 neocloud 集群。

接线到一起

三层组合成一条请求路径，见 图 82.3，而正是 OpenAI 兼容接口让每一层都保持可替换。

这套接法之所以能在实践中成立，靠的是三个具体安排。第一，应用从不持有供应商密钥：它们持有网关签发的虚拟密钥，于是轮换凭据或给失控的智能体封顶是服务端操作，无需客户端重新部署。第二，一个 base URL、OpenAI 形态，同样服务应用代码、评测工具链与智能体运行时，于是切换模型或加回退只是改配置。第三，强制结构化输出靠的是引擎，而非提示词：当下游代码解析工具调用或抽取数据时，经 XGrammar 的引导解码才是可靠的那条路。

网关作为策略点

这些层最终通过网关接回本书主线。能力在于它能触达的范围：一套接口让每个模型，无论托管还是自托管，都变得可寻址，于是为每次调用挑最佳模型就成了一条路由规则。效率是引擎与算力层级的协同：连续批处理、前缀缓存与量化抬高每秒 token 数，而自建对租用与利用率的决策为每个 token 设下美元底线。信任仍然落在网关这个策略点上：密钥托管、花费上限、审计、PII 脱敏，以及把工具与智能体流量收进同一道受治理接缝的智能体原生协议，这正是本章交棒给 第 56 章，转入安全与授权的地方。

延伸阅读