企业级 LLM 推理基础设施架构：从 Netflix 自研实践到推理系统设计原则

2026 年，越来越多的企业从"调用第三方 LLM API"转向"自建推理基础设施"。 Netflix 公开披露了其自研 LLM 推理服务（in-house LLM serving）的技术实践，成为这一趋势的标志性案例。这背后有四个驱动力：

一、成本控制：当调用量达到一定规模，第三方 API 的按 token 计费会非常昂贵。自建推理服务虽然前期投入大，但边际成本更低——尤其是在高吞吐、稳定负载的场景下。

二、数据主权与隐私：很多企业的核心数据（用户行为、内容、内部文档）不能出域。自建推理让数据留在内部，满足合规与隐私要求。这对 Netflix 这类内容公司尤为重要。

三、延迟与定制化：自建推理可以做深度优化（针对特定模型的量化、批处理策略），实现比通用 API 更低的延迟和更高的吞吐。

四、供应稳定性：依赖第三方 API 意味着受制于对方的限流、涨价、停服风险。自建推理把核心能力的控制权握在自己手里。

但要清醒：自建推理基础设施是一项重资产、高复杂度的工程，不是所有企业都适合。本文最后会给出自建 vs 托管的决策框架。先理解架构，再做决策。

一套企业级 LLM 推理基础设施，可以清晰地分为四层。 理解分层，是理解所有优化技术的基础。

第一层：硬件层（Hardware Layer）。包括 GPU/加速器、高速内存（HBM）、节点间互连（NVLink/InfiniBand）和存储。推理对内存带宽和容量极其敏感——大模型的权重必须常驻显存，KV Cache 也占用大量显存。硬件选型直接决定吞吐上限。

第二层：推理引擎层（Inference Engine Layer）。这是核心，负责把模型权重高效地变成 token 输出。代表引擎有 vLLM、TensorRT-LLM、SGLang 等。它们实现的关键技术包括：连续批处理（continuous batching）、PagedAttention（显存分页管理 KV Cache）、量化（FP8/INT8/INT4）等。

第三层：调度与服务层（Scheduling & Serving Layer）。负责请求路由、负载均衡、队列管理、优先级调度、自动扩缩容。企业级场景需要处理不同优先级、不同延迟要求的请求流。Netflix 这类公司的关键挑战就是如何在海量异构请求下保持服务质量（SLA）。

第四层：应用与接口层（Application Layer）。对外提供 API、流式输出、多轮对话管理、与业务系统集成。这一层关注的是开发者体验和与上层应用的对接。

分层的核心价值：每一层的优化相对独立。你可以升级硬件而不动引擎，可以换引擎而不动接口。这种解耦让推理系统可以持续演进。

连续批处理（Continuous Batching）是现代推理引擎提升吞吐的核心技术。 要理解它，先看传统的"静态批处理"有什么问题。

静态批处理的问题：传统做法是把一批请求凑在一起，等最长的那个生成完才处理下一批。但 LLM 生成长度差异巨大——有的请求生成 10 个 token，有的生成 1000 个。短请求被迫等长请求，GPU 大量时间在空转（padding 浪费）。

连续批处理的突破：不再等整批完成，而是逐 iteration（每生成一个 token）动态调度。某个请求生成完毕就立即移出，新请求随时插入。这样 GPU 几乎始终满载，吞吐大幅提升。

为什么这对企业级至关重要：企业场景的请求流是连续、异构、高并发的。静态批处理在这种场景下吞吐极低；连续批处理能把 GPU 利用率从 30%-50% 提升到 80% 以上。这是自建推理相对通用 API 的核心优势之一。

实现要点：连续批处理需要推理引擎支持动态的 KV Cache 管理（见下一章）和细粒度的请求调度。vLLM 的 PagedAttention、SGLang 的 RadixAttention 都是为了高效支撑连续批处理而设计的。

权衡：连续批处理提升吞吐，但可能略微增加单个请求的延迟（因为要频繁调度）。企业级系统需要根据 SLA 在吞吐和延迟之间调参。

KV Cache（键值缓存）是 LLM 推理性能与显存占用的核心矛盾所在。 理解它，就理解了推理优化的一半。

什么是 KV Cache：Transformer 自回归生成时，每生成一个新 token 都要"回看"之前所有 token。如果每次都重新计算所有历史 token 的 Key/Value，开销巨大。KV Cache 把已计算的 Key/Value 缓存下来，避免重复计算——用显存换计算。

问题在哪：KV Cache 的显存占用随序列长度 × 并发请求数 × 层数线性增长。在高并发、长上下文场景下，KV Cache 可能比模型权重还占显存，成为吞吐的硬瓶颈。传统做法为每个请求预分配最大长度的连续显存，造成大量碎片和浪费。

PagedAttention 的突破：vLLM 提出的 PagedAttention 借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的"页"，按需分配、非连续存储。这大幅减少了显存碎片，让同样显存能服务更多并发请求，吞吐提升数倍。

企业级的 KV Cache 优化方向：

• 前缀缓存（Prefix Caching）：很多请求共享相同的前缀（如系统提示词）。缓存这些公共前缀的 KV，避免重复计算。
• KV Cache 量化：用更低精度存储 KV Cache（如 FP8），减少显存占用，代价是轻微精度损失。
• 跨请求复用：在多轮对话场景，复用上一轮的 KV Cache，加速后续生成。

实践要点：显存是推理的命门。优化 KV Cache（分页、前缀缓存、量化）往往比升级硬件更能立竿见影地提升并发能力。

除了批处理和 KV Cache，还有两类技术对企业级推理至关重要：推测解码（Speculative Decoding）和量化（Quantization）。

推测解码——用并行换延迟：LLM 自回归生成本质是串行的（一次一个 token），难以并行。推测解码的思路是：用一个小模型（draft model）快速"猜"出多个 token，再用大模型一次性并行验证这些 token。被接受的 token 一次通过，被拒绝的从大模型重新生成。这样在不损失输出质量的前提下，把多个串行步骤变成一次并行验证，显著降低延迟。

为什么企业级需要它：对延迟敏感的实时场景（如对话、推荐），推测解码能在保持质量的同时把生成速度提升 2-3 倍。代价是需要维护一个额外的 draft model 和验证逻辑。

量化——用精度换成本：把模型权重和激活从 FP16/FP32 降到 FP8/INT8/INT4，可以大幅减少显存占用和带宽需求，提升吞吐、降低成本。2026 年 FP8 已成为推理量化的主流选择，在大多数任务上精度损失可接受。

量化的权衡：

• FP8：精度损失极小，显存减半，是当前生产环境的安全选择。
• INT4/更低：压缩更激进，成本更低，但精度损失风险增大，需要针对具体任务验证。

组合使用：连续批处理 + PagedAttention + 推测解码 + FP8 量化，构成了 2026 年企业级推理的"标配优化栈"。Netflix 等公司的自研实践，本质上就是这些技术的工程化整合。

企业级推理基础设施的容量规划，是把业务需求翻译成硬件配置的关键环节。 一个常见的错误是凭感觉买卡，结果要么浪费要么不够用。

容量规划的核心变量：

• 并发请求数（Concurrency）：峰值同时处理的请求数。
• 请求长度分布：输入 token 数和输出 token 数的分布（平均值、P99）。
• 延迟 SLA：首 token 延迟（TTFT）和每秒 token 数（TPS）的要求。
• 吞吐目标：每秒需要生成多少 token（总 TPS）。

估算的基本逻辑：

1. 显存预算：模型权重显存（参数量 × 每参数字节，FP8 约 1 字节/参数）+ KV Cache 显存（并发数 × 序列长度 × 每 token KV 大小）+ 激活与开销。这决定了单卡能支撑的并发上限。
2. 吞吐预算：目标总 TPS ÷ 单卡 TPS = 所需卡数。单卡 TPS 取决于模型大小、批处理效率和硬件。
3. 冗余与弹性：在峰值需求基础上预留 20%-40% 冗余，应对流量波动和故障转移。

实践建议：

• 先压测，再扩容：用真实流量分布做基准测试，测出单卡的实际 TPS 和并发上限，再推算总量。不要依赖厂商标称值。
• 关注 P99 而非平均：容量规划要为长尾请求（超长上下文）留余量，否则 P99 延迟会崩溃。
• 区分在线与离线：在线低延迟服务和离线批量任务可以分开规划、混合部署，提升整体利用率。

Netflix 类场景的启示：高并发、异构请求、严格 SLA 是企业级推理的典型挑战。容量规划不是一次性的，而是需要随流量增长持续迭代的工程实践。

自建推理基础设施不是越激进越好。是否自建，取决于规模、数据、能力和战略四个因素。 这一章给出一个可操作的决策框架。

适合自建的情形：

• 调用规模大：每月 token 消耗达到数亿甚至数十亿级，第三方 API 成本显著高于自建摊销成本。
• 数据敏感：核心数据不能出域，有强合规/隐私要求。
• 有工程能力：拥有能运维 GPU 集群、调优推理引擎的专业团队。
• 战略自主需求：不愿受制于第三方供应商的限流、涨价、停服风险。

适合托管（第三方 API/云服务）的情形：

• 调用规模小或波动大：自建利用率低，托管的按需付费更划算。
• 缺乏运维能力：没有专业团队，自建的隐性成本（人力、踩坑）极高。
• 快速验证阶段：产品还在 PMF（产品市场契合）探索期，不应过早投入重资产。
• 需要最前沿模型：自建往往跑开源模型，若业务依赖最强闭源模型，只能托管。

混合策略（多数大企业的现实选择）：

• 核心/敏感负载自建，峰值/弹性负载用托管补充。
• 稳定高频任务自建，长尾/低频任务托管。
• 用统一抽象层屏蔽底层差异，保持切换灵活性。

决策的核心问题：不是"自建好还是托管好"，而是"在我的规模、数据、能力和战略下，哪种组合的总拥有成本（TCO）最低、风险最可控"。

企业级推理基础设施正在从'集中式云端 GPU 集群'向'云-边-端协同'演化。 理解这个趋势，有助于做出面向未来的架构决策。

端侧推理的崛起：随着小模型能力增强和量化技术进步，越来越多推理可以在端侧（PC、手机、专用设备）完成。例如搭载大容量统一内存的桌面设备（如配备 AMD Ryzen AI Max+ 和 192GB 内存的工作站）已经能本地运行中等规模模型，为隐私敏感和低延迟场景提供了新选择。

云-边-端协同的价值：

• 隐私：敏感数据在端侧处理，不出设备。
• 延迟：端侧推理消除网络往返，实现毫秒级响应。
• 成本：把简单任务下沉到端侧，减少云端 GPU 压力。
• 可靠性：端侧推理不依赖网络，离线也可用。

异构计算的趋势：未来推理基础设施不会只有 GPU，而是 CPU、GPU、专用 ASIC、NPU 等多种算力的异构组合。不同任务跑在最合适的硬件上——这要求推理引擎和调度层具备异构感知能力。

语音/多模态推理的新需求：随着双工语音模型（如生产级语音交互模型）和多模态应用普及，推理基础设施需要支持流式、低延迟、多模态的推理负载，这对传统以文本为中心的推理栈提出了新挑战。

六个月后依然可读的原因：具体的产品和数字会更新，但本文讲解的分层架构、核心技术原理（连续批处理、KV Cache、推测解码、量化）、容量规划方法和自建决策框架，是 LLM 推理工程的底层知识，不会因单一产品发布而过时。掌握这些原理，你就能快速理解任何新的推理技术。

生产环境的稳定运行才是真正的挑战，搭建推理系统只是第一步。企业级推理基础设施需要一套完善的可观测性（Observability）与运维体系，这是保障 AI 服务持续可用的关键工程实践。

关键监控指标：推理服务的监控不同于传统 Web 服务，需要关注几个特有指标：首 token 延迟（TTFT） 反映用户感知的响应速度；每秒 token 数（TPS） 反映吞吐能力；GPU 利用率与显存占用 反映资源效率；KV Cache 命中率 反映前缀缓存的有效性；请求队列深度 反映系统是否接近过载。这些指标需要同时监控、联合分析——单看某一个都可能产生误判。

容量预警与自动扩缩容：生产系统需要设置容量水位线。当 GPU 利用率或队列深度超过阈值时，自动触发扩容；当负载下降时缩容以节省成本。但 GPU 实例的启动时间远长于 CPU 容器，因此扩缩容策略必须预测性而非纯响应式——基于历史流量模式提前扩容，而非等到过载才反应。

故障处理与优雅降级：GPU 故障是常态而非例外。企业级系统需要设计故障转移机制——当某张卡或某个节点故障时，请求能自动路由到健康实例。同时需要优雅降级策略：在极端负载下，优先保障高优先级请求的 SLA，对低优先级请求进行限流或降低生成长度，而非让所有请求一起崩溃。

模型版本管理与灰度发布：模型更新（如从 v1 升级到 v2，或更换量化策略）需要灰度发布——先在小比例流量上验证新版本的延迟、质量和稳定性，确认无问题后再全量切换。回滚机制必须随时可用。