企业官网建设流程全解析

前一段时间做大模型在线推理服务性能优化时，一直被一个问题困住：请求量上来之后，GPU 利用率看着不高，单路延迟也正常，但整体吞吐就是上不去。后来仔细拆分才发现，传统的“一个请求进来，模型在前向推理里从头算到尾”的串行思路，在大模型场景中已经不够用了。

当时越查越发现，这个方向背后并不是单一解决方案，而是多种“分离式推理架构”各有侧重。尤其是把 NVIDIA GPU、Groq LPU 这类专用推理加速器放在同一个语境里讨论时，很多人容易混淆：LPU 到底是不是 NVIDIA 的产品？分离式推理拆的到底是“模型层”还是“硬件层”？真到了选型阶段，又该优先考虑哪一种？

这篇文章会把三种分离式推理架构完整梳理一遍。先讲清楚为什么推理阶段需要“分离”，再把 NVIDIA GPU、LPU 等概念边界理清，接着逐一拆解三种架构的原理、适用场景、落地思路和坑点。面向的读者包括正在做大模型推理服务选型的后端工程师、准备入门 LLM 推理优化的开发者，以及想了解 GPU 之外硬件的技术爱好者。

读完本文，你会掌握三种分离式推理架构的核心差异，知道在 NVIDIA 环境下如何验证和选型，也能避开一些常见的误区和部署问题。

1. 为什么推理环节开始强调“分离”

1.1 大模型一次请求内部其实有两个差异巨大的阶段

大模型生成文本时，并不是一次性把整段内容算出来，而是逐 token 生成。一个完整的在线推理请求，可以拆成两个阶段：

• Prefill（预填充）：处理用户输入的 Prompt，并行计算所有输入 token，生成并缓存 KV Cache。
• Decode（解码）：根据 Prompt 和已生成的内容，逐步预测下一个 token，生成一个 token 就需要读取一次 KV Cache。

举例来说，用户输入 500 个 token，模型回答 800 个 token。那么请求的前半段是 500 个输入 token 的并行计算，后半段是 800 次串行采样。如果把一次请求看作整体，这两段对资源的需求截然不同。

Prefill 阶段计算量大，更依赖 GPU 的浮点算力，通常是计算密集型；Decode 阶段每一步只生成一个 token，核心开销在于反复读取 KV Cache，更接近访存密集型。用同一批 GPU 资源去同时处理这两个阶段，必然会产生资源冲突。

1.2 一体化推理服务的瓶颈在哪里

在传统的单体推理服务中，一个 API Server 接收请求后，由同一批 GPU 完成 Prefill 和 Decode。这种模式在模型较小、并发较低时没有问题。但当模型变大、并发升高后，问题就比较明显了：

• 首批 token 时延（TTFT）和单 token 生成间隔（TPOT）互相拖累。Prefill 请求挤占 GPU 算力时，正在 Decode 的请求会感受到明显的生成停顿。
• GPU 利用率忽高忽低。高峰期 Prefill 队首堆积，低峰期大量 Decode 实例又被闲置。
• 显存分配难以弹性伸缩。KV Cache 动态增长，但一体化部署时很难做到按阶段精细调度。
• 长上下文请求会放大上述问题。长 Prompt 的 Prefill 耗时变长，长回答的 Decode 又会持续占用 KV Cache。

随着推理框架和硬件调度策略的发展，业界逐渐形成一类思路：不再把一次请求当作“不可拆分的原子任务”，而是把不同阶段、不同资源、不同模型切分到不同位置上处理，这就是分离式推理架构的出发点。

1.3 分离式推理架构是什么

分离式推理架构，英文语境里常称为 Disaggregated Inference 或 Disaggregated Serving。本质上是把大模型推理过程中耦合在一起的资源需求拆开，让每一种资源都能被独立扩缩容、独立调度。

这种“分离”可以发生在多个维度：

• 时间与阶段维度：把 Prefill 和 Decode 放到不同 Worker 上。
• 模型与空间维度：把模型层切分到多张 GPU 上，通过 NVLink、RDMA 等高速互联协作。
• 硬件与芯片维度：把不同算子或阶段交给不同硬件执行，例如 NVIDIA GPU 与 LPU 专用处理器协同。

后面要详细展开的三种分离式架构，正是从这三个维度演化而来的。

2. 先厘清概念：NVIDIA GPU、Groq LPU 与“分离式推理”

2.1 GPU 与 LPU 到底是什么关系

很多读者第一次看到“NVIDIA GPU、LPU”同时出现时，很容易误以为 LPU 是 NVIDIA 推出的某种新 GPU。其实这里需要先厘清两个概念。

NVIDIA GPU 是通用并行计算加速器，例如 V100、A100、H100、H20、RTX 系列等。它既能训练大模型，也能运行推理，生态成熟，配套了 CUDA、TensorRT、Triton Inference Server 等完整软件栈。可以说，当前大模型训练和推理的主流载体就是 NVIDIA GPU。

LPU 是 Language Processing Unit 的缩写。这里提到的 LPU，在业界讨论大模型推理时，通常指 Groq 公司提出的专用语言处理器，而不是 NVIDIA 的官方产品线。公开资料显示，Groq LPU 是一种针对大语言模型推理设计的专用芯片架构，采用了软件定义静态调度和大量片上 SRAM 的设计思路，目标是把 token 生成的延迟做到很低，并减少对外部显存带宽的依赖。

所以更准确的说法是：NVIDIA GPU 和 Groq LPU 是两种不同的加速硬件路线。GPU 覆盖面更广，LPU 更聚焦 LLM 推理。两者在推理场景中可以被单独使用，也存在协同组合的讨论空间。

2.2 LPU 不是“另一个品牌的 GPU”

为了后续讨论清晰，这里做一个简单的概念对照：

简单来说，GPU 是“什么都能干的通用型选手”，LPU 则更像“专攻大模型生成环节的特长生”。两者各有适用范围，标题里把它们放在一起讨论，恰恰是为了解释如何通过“分离式架构”让不同硬件发挥各自优势。

2.3 “分离式推理架构”不是单指某个框架

很多朋友一听到“分离式”，就觉得应该是某个具体的开源框架，例如某个服务端参数开启后就算使用了分离式架构。其实不是。

像 vLLM、SGLang、NVIDIA Triton Inference Server 等推理框架都可能支持某种形式的分离或并行部署。真正的分离式推理架构，更应理解成一套设计策略：先判断资源矛盾点，再决定用哪一种分离方式去解决。本文介绍的三种架构，在实际项目中往往组合使用，而不是互斥选项。

3. 三种分离式推理架构总览

在正式展开前，先用一张表把三种架构的轮廓勾勒出来，方便后续按图索骥。

可以看到，三种架构其实回答了三个不同层面的问题：

• 什么时候存在资源冲突？用阶段分离解决。
• 单卡放不下、吞吐不够怎么办？用模型并行和资源池化解决。
• 不同硬件各有所长时，如何扬长避短？用异构协同解决。

下面分别展开。

4. 架构一：Prefill / Decode 两阶段分离架构

4.1 核心原理

Prefill/Decode 两阶段分离，是目前大模型推理场景中比较受关注的一类架构。它的出发点很朴素：既然 Prefill 和 Decode 的资源瓶颈不同，那就不要共用一个推理实例。

在传统单体推理中，当有 10 个请求同时进入时，假设 3 个请求的 Prompt 特别长，那么这 3 个请求的 Prefill 过程会占用大量 GPU 算力，导致另外 7 个轻量请求的 Decode 变得不稳定。请求之间互相“抢资源”，整体服务质量很难保证。

分离之后，系统内部会分为两组服务：

• Prefill Worker：只负责接收带完整 Prompt 的请求，计算出 KV Cache 后，将状态交给 Decode Worker。
• Decode Worker：只负责接收“继续生成”的请求，基于已有 KV Cache 逐个 token 生成结果。

整个链路可以看成一条内部流水线：

客户端请求 | ▼ 请求入口/路由层 | ▼ Prefill Worker —— KV Cache / 请求状态传递 ——> Decode Worker ——> 输出返回

4.2 为什么预填充和解码要拆开部署

进一步拆开解释，Prefill 与 Decode 对资源要求完全不同：

• Prefill 需要 GPU 执行大量矩阵乘法和注意力计算，计算密集度高。测量指标重点关注 TTFT。
• Decode 每步只生成一个 token，需要把 KV Cache 从显存中反复加载，容易受显存带宽限制。测量指标重点关注 TPOT 和单 token 生成延迟。

如果把它们拆到不同实例上，就可以为 Prefill Worker 配置算力更强的 GPU，为 Decode Worker 配置显存带宽更高、并发能力更好的实例。同时，两个 Worker 可以独立扩缩容。当用户输入变长时，只需要扩充 Prefill Worker；当并发对话变多时，只需要扩充 Decode Worker。

4.3 一个概念性的启动示例

下面给出一个概念性的启动示例。注意：不同推理框架的参数名和版本差异较大，实际使用时应以官方文档为准。这里的重点在于理解“同一个模型被启动成两类角色”的思路。

# 节点 1：只负责 Prefill 环节的概念示例 # 伪参数，实际参数名请查阅当前框架文档 vllm serve meta-llama/Llama-3.1-8B-Instruct \ --split-module prefill \ --port 8001 \ --max-model-len 8192 # 节点 2：只负责 Decode 环节的概念示例 vllm serve meta-llama/Llama-3.1-8B-Instruct \ --split-module decode \ --port 8002 \ --tensor-parallel-size 4

在设计上，路由层收到用户请求后，可以按以下逻辑分派：

# 伪代码：演示 Prefill/Decode 分离调度思想 def dispatch(request): if request is new_prompt: # 新请求先进入 Prefill Worker kv_cache_ref = prefill_queue.submit(request) # Prefill 完成后，把状态交给 Decode Worker decode_queue.submit( decode_task_id=kv_cache_ref, request=request, ) else: # 增量请求直接进入 Decode Worker decode_queue.submit(request)

这种方式让调度器可以感知请求所处阶段，避免“新请求”和“续写请求”抢占同一批计算资源。

4.4 工程上需要重点解决的问题

Prefill/Decode 阶段分离虽然思路清晰，但落到工程上并不容易，主要挑战集中在以下几点。

• KV Cache 的状态移交。Prefill Worker 计算出的 KV Cache 如何传输给 Decode Worker？是走共享显存、远程通信，还是重新计算一部分，需要根据网络和硬件能力权衡。
• 路由与调度效率。网关需要知道哪个 Decode Worker 持有哪些 KV Cache。如果 Decode Worker 很多，通常还需要增加一层 KV Cache 路由索引。
• 长连接与上下文保持。请求从 Prefill 阶段进入 Decode 阶段后，客户端连接需要保持稳定，不能在内部转移时出现断连。
• 扩缩容策略。两个 Worker 的弹性伸缩要依据不同的监控指标。Prefill Worker 看队列长度和 TTFT，Decode Worker 看正在生成的请求数和 TPOT。

4.5 适用场景

Prefill/Decode 阶段分离比较适合以下场景：

• 输入输出长度差异大，例如用户经常提交长文档摘要需求。
• 在线服务对首 token 时延和生成流畅度有严格要求。
• 希望在固定 GPU 数量上提升整体吞吐，而不只是盲目增加单卡显存。
• 想要精细控制服务资源成本，让不同阶段按最大负载分别扩容。

如果只是个人学习和跑 Demo，单机单卡直接用一体化服务即可，不必为了“分离”而分离，引入复杂度需要有一定规模收益才有价值。

5. 架构二：模型并行与资源池化的“空间分离”架构

5.1 为什么模型也要被“切开”

当模型规模继续增大，例如从 7B 级别增加到 70B、数百 B 以上，单张 GPU 已经无法装下完整模型，或者说即使能装下，单卡的显存也会限制 KV Cache 容量，从而限制并发数。

这时候需要把一个大模型“切开”，分布到多张 GPU 或多台服务器上。从系统角度看，这就是做了空间维度的分离：

• 将模型参数按层拆开，不同 GPU 负责不同的层，每个 GPU 还要承担粗粒度的数据传输，常见的是 Pipeline Parallel。
• 将某一层的参数按行、按列拆开，多张 GPU 共同计算同一层，常见的是 Tensor Parallel。
• 如果引入了 MoE 模型，还可以按 Expert 进行拆分，即 Expert Parallel，把不同专家放到不同 GPU 上，按路由动态激活。
• 当推理请求并发量很大时，还可以让多个 GPU 各持一份完整模型，按请求维度切分，即 Data Parallel。

在实际推理框架中，以上方案并不是单独使用的。比如大规模部署时，通常会先用 Tensor Parallel 把单节点的多张 GPU 组织起来，再通过 Pipeline Parallel 或请求并行扩展到多节点。

5.2 NVIDIA 单机多卡与跨节点通信底座

模型并行离不开高速通信。在 NVIDIA 多卡环境中，通信层级大概如下：

• 单卡内部：主要走显存、L2 Cache、NVLink 内部互联。
• 单机多卡：通过 NVLink 与 NVSwitch 连接，NVLink 带宽通常远高于 PCIe。
• 多机之间：通过 InfiniBand 或 RoCE 高速网络通信，框计算节点组合成 One Big GPU。

如果只是在一台 8 卡机器上做 Tensor Parallel，NCCL 会自动选择最优通信路径。但如果跨多台机器做推理，就要关注网络拓扑、网卡数量和集群调度策略。

下面是一个典型的多卡并行调度配置：

# 集群编排示意，并不是某个软件的固定配置 inference_cluster: model: meta-llama/Llama-3.1-70B-Instruct parallelism: tensor_parallel_size: 8 # 单节点内用 8 卡并行 pipeline_parallel_size: 2 # 跨 2 个节点按层切分 communication: intra_node: nvlink inter_node: ib # InfiniBand 或 RoCE 等高速网络 scheduler: max_num_seqs: 128 max_model_len: 32768 gpu_memory_utilization: 0.90

5.3 模型并行对推理延迟和稳定性的影响

不少初学者以为“并行越多，推理越快”，但在模型并行场景下需要冷静看待。

Tensor Parallel 每次前向计算前需要做 AllReduce 等集合通信。模型层数越大、单次通信的数据量越大，通信开销越高。如果单卡算力已经很空闲，主要瓶颈是跨卡同步频率，那么继续增加 TP 反而不一定提升速度，甚至可能增加延迟。

Pipeline Parallel 则会影响 GPU 利用率和调度复杂度。由于不同 GPU 负责不同层，上游 GPU 算完当前 micro-batch 后需要传给下游，Pipeline 前几个 stage 和后几个 stage 可能出现“上一批已算完、下一批没到”的空窗期。

因此，模型维度的“空间分离”更适合从容量角度解决“单卡装不下、单节点并发不够”的问题。它并不直接等价于“每增加一张卡，线上延迟都会降低”。

5.4 和阶段分离架构的区别

模型并行和阶段分离虽然都在集群中拆分布置，但拆的对象不同：

• 阶段分离拆的是请求生命周期，同一个模型可以存在于 Prefill Worker 和 Decode Worker 中，只是不同 Worker 做的事不同。
• 模型并行拆的是模型本身，单张 GPU 只持有模型的一部分，通常所有请求都会流经这些 GPU。

实际部署大型模型时，两者经常叠加：先通过 Tensor Parallel 把一个 70B 模型放进多个 GPU 节点，再把每个 GPU 组划分成 Prefill 组和 Decode 组，分别在两个方向上按需扩容。这个组合方案往往能最大化集群利用率。

6. 架构三：GPU 与 LPU 异构协同分离架构

6.1 LPU 凭什么参与大模型推理

第三种架构把视线从通用 GPU 集群转到了异构处理器上。既然 LPU 专为大模型推理设计，那为什么不能和 NVIDIA GPU 放在同一张推理链路中，各司其职呢？

这背后的逻辑在于：大模型推理不同阶段的瓶颈不同，GPU 在训练和复杂算子场景中通用性更强，而 LPU 这类专用处理器在 Decode 阶段更容易发挥低延迟、高吞吐能力。如果能把请求拆分，让不同硬件只处理自己擅长的环节，理论上可以获得比“只用一种硬件”更高的性价比。

当然，LPU 的具体表现取决于硬件的实际架构、算力和编译器成熟度，是否适合生产还需要在目标场景中实测。不能用“理论分工”替代“真实负载验证”。

6.2 异构协同的基本思路

一种概念性分工可以这样设计：

• NVIDIA GPU：放置完整模型或模型主体，处理复杂的前处理、Prefill 阶段、长上下文管理、路由调度。
• LPU：作为 Decode 阶段的加速器，接收来自 GPU 的路由结果，完成连续 token 生成，并把产出送回统一出口。

这种架构下，路由层起着类似“翻译器”的作用：把 GPU 侧生成的状态转换为 LPU 侧需要的数据格式，再决定是否要把后续请求交给 LPU 继续处理。

NVIDIA GPU Pool LPU Pool (Groq LPU等) ───────────────── ───────────────────── 接收请求 -> Prefill & KV Cache ---> 加载状态 -> Decode 长上下文管理 / 复杂路由 高速逐 token 生成

这样的组合能否落地，还取决于几个前提：框架是否支持不同硬件间的 KV Cache 共享；网络链路能否承受状态传输开销；两家硬件的部署接口能否统一。

6.3 当前技术挑战

GPU 与 LPU 的异构协同，目前更多处于探索和早期工程验证阶段，有几个问题需要解决：

• 生态割裂。NVIDIA 的算子库、推理引擎与 Groq LPU 的软件栈并不互通，统一编排难度较高。
• 状态同步成本。KV Cache 在 GPU 和 LPU 之间传递，需要经过主机内存或网络。如果每生成几个 token 就要同步一次，同步成本反而会抹掉异构带来的收益。
• 运营商的支持边界。GPU 池和 LPU 池如果来自不同云厂商或不同集群，部署复杂度会进一步上升。
• 容量规划复杂。两种硬件都要考虑扩缩容，故障恢复、监控告警、镜像管理都需要单独维护。

正因如此，第三种架构更适合有很强平台能力的团队去尝试。如果项目规模不大，直接使用第一种架构或第二种架构往往是更务实的选择。

6.4 什么时候值得关注异构协同

如果你已经遇到以下情况，可以开始关注 GPU 与 LPU 异构协同：

• 当前 GPU 集群的 Decode 阶段已经出现明显访存瓶颈，但整体算力并不紧张。
• 业务对单 token 生成延迟极度敏感，需要极致控制每一跳的耗时。
• 团队具备底层编译器、异构调度开发能力，而不仅仅是在应用层调 API。
• 项目预算和成本模型支持同时引入两种加速硬件进行对比测试。

如果暂时不具备这些条件，建议先了解原理，不必急于投入资源做全套异构改造。

7. 在 NVIDIA 推理环境中体验分离式架构的落地流程

7.1 环境预检是第一关

无论选择哪种分离式推理架构，都需要先确保硬件和驱动环境可用。NVIDIA 驱动问题在社区中讨论度一直很高，例如nvidia-smi has failed because it couldn't communicate with the nvidia driver，在 Windows 端还有安装的 NVIDIA 图形驱动程序版本在 D3D11 中存在已知问题，请安装推荐的驱动程序版本等提示。这些都属于环境层面的坑，需要在优化架构之前排除。

在 Linux 环境中，推荐先执行以下命令观察基础状态：

# 1. 查看 GPU 列表、驱动版本、CUDA 版本与显存占用 nvidia-smi # 2. 从 PCI 设备列表中确认 NVIDIA 硬件已被系统识别 lspci | grep -i nvidia # 3. 如果 nvidia-smi 失败，查看内核日志中的 nvidia 报错 sudo dmesg -T | grep -i nvidia # 4. 检查当前已加载的内核模块 lsmod | grep nvidia

正常情况下，nvidia-smi应能输出 GPU 名称、Driver Version、显存占用等关键信息。如果命令执行失败，优先检查驱动是否安装、内核模块是否加载、系统是否升级过内核。

在 Windows 环境下，如果 GPU 性能异常或应用提示驱动版本不符合要求，应前往 NVIDIA 官网下载当前设备对应的推荐版驱动，而不是随意安装旧版或测试版驱动。特别是你在使用较新 CUDA 或 PyTorch 版本时，驱动过旧常常会引发“CUDA unavailable”的错误。

7.2 场景选型建议

在动手部署前，需要根据实际场景明确选型方向：

7.3 从单体到分离的最小实验路径

如果是在 NVIDIA GPU 集群上做实验，建议按以下路径走：

1. 先用单卡跑通基线模型，记录 TTFT、TPOT、吞吐量。
2. 引入 Tensor Parallel，在单机 2 卡、4 卡、8 卡上分别测试扩展后的吞吐，找到收益拐点。
3. 将请求入口与推理 Worker 分离，先通过负载均衡暴露一个 API；再把推理 Worker 按 Prefill 和 Decode 两类角色拆分。
4. 加入 Prometheus 等监控工具，分别观测 Prefill Worker 和 Decode Worker 的 GPU 利用率、队列长度、KV Cache 用量。
5. 基于监控数据调整两个 Worker 的数量比例。例如业务偏向长输入时，增加 Prefill Worker；偏向多轮长对话时，则需要增加 Decode Worker。

这套路径不依赖特定框架，核心思路是先做可量化的基线采样，再做切分优化。当你把基线和优化后的指标放在一起时，才能判断这个复杂度是否值得。

7.4 用哪些指标评估分离效果

很多团队在评估分离式架构时只看“平均延迟”，这是不够的。大模型推理场景中，建议关注以下指标：

• TTFT（Time To First Token，首个 token 生成时间）：用户发出请求后到收到第一个 token 的时间，典型 Prefill 性能指标。
• TPOT（Time Per Output Token，每个输出 token 的平均时间）：反映 Decode 阶段生成速度。
• ITL（Inter-Token Latency，token 间延迟）：相邻两个 token 输出之间的间隔，在线对话体验感直接相关。
• 吞吐量：单位时间内能完成的请求数或生成的 token 数。
• 排队长度：请求在 Prefill Worker 或 Decode Worker 前的等待数量，反映系统扩容是否及时。

分离式架构不一定让所有指标“全部最好”。它提供的是资源隔离和独立扩容能力，最终目标是让 TTFT 与 TPOT 不再互相损害，让整个集群单位时间生成 token 总数更高。

8. 常见问题与排查思路

下面针对几个高频问题做进一步解释。

8.1 Ubuntu 环境反复遇到 NVIDIA 驱动失联

很多开发者会按照网上的教程在 Ubuntu 上安装 NVIDIA 驱动，但每次升级内核后，都可能出现驱动失联的问题。这通常是因为 NVIDIA 驱动是以内核模块方式运行的，Linux 内核升级后，新内核与当前驱动模块不兼容。

建议通过软件源或脚本统一管理驱动版本，设置好 DKMS（Dynamic Kernel Module Support），让内核升级后自动重新编译和注册模块。同时保留旧内核作为回退方案，避免生产环境因一次升级而整体不可用。

8.2 分离式推理后延迟反而升高

如果你在引入 Prefill/Decode 分离后发现平均延迟升高，不要急着回滚，先分析是哪个环节变慢了。用链路追踪把请求时间拆成四段：网关排队时间、Prefill 时间、状态传输时间、Decode 时间。很多时候问题出在传输层，而不是推理本身。调整 KV Cache 传递策略或者合并小请求，通常能明显缓解。

9. 工程建议与避坑指南

分离式推理架构听起来很“高级”，但工程落地时依然要遵守软件工程的基本原则。下面几条建议希望能帮你少走弯路。

9.1 先有基线，再谈优化

很多团队在执行优化前没有建立明确的基准指标，结果架构改造完成后，既说不清耗时花在哪，也说不清收益来自哪。建议在单体架构下先完成一轮完整的压测，记录 TTFT、TPOT、吞吐、GPU 利用率等基线数据。改造过程中每一次调整都要对照基线评估，不要一次性把所有优化全部叠加。

9.2 监控要覆盖到“角色”和“阶段”

传统的 GPU 监控只看整台机器的利用率，在分离式部署中会误导判断。例如 Prefill Worker 的 GPU 利用率可能很高，但此时 Decode Worker 正处于等待状态。建议在每个 Worker 上记录：

• 请求队列长度；
• KV Cache 总量和剩余容量；
• 阶段耗时（Prefill、传输、Decode）；
• GPU 算力利用率和显存带宽占用；
• 路由层丢弃和重试次数。

只有把监控细化到角色和阶段，才知道应该扩容哪一侧的实例。

9.3 配置管理要版本化

模型版本、并行策略、GPU 显存预留比例、KV Cache 策略、路由规则等配置，都属于影响在线效果的关键变量。建议使用配置中心统一管理，并保留每次变更的版本记录。避免在服务器上随手修改环境变量后重启服务，导致下一次排错时无法还原现场。

9.4 注意安全边界与最小权限

推理服务一旦以 API 形式对外暴露，就需要注意接口鉴权和流控。不要为了图方便，把内部路由端口直接暴露到公网。在多团队共享 GPU 集群时，需要做好权限隔离，避免某个业务误删或者抢占其他业务的显存与模型文件。涉及生产变更时，尽可能先在测试集群完整验证。

9.5 不要追求极致的架构复杂度

架构复杂度是成本，不是荣誉。如果你的并发量还没有高到让 Prefill 与 Decode 互相影响，使用单体推理服务可能更划算。三种分离式架构之间并不存在绝对优劣，只有适合当前负载模型的选择。合理的技术路线是：先用最简单方案跑通，再用监控数据推动架构演进。

10. 总结

整理一下本文的核心点：

• Prefill/Decode 阶段分离架构解决的是请求生命周期中的资源冲突问题，适合在线对话等延迟敏感场景。
• 模型并行与资源池化分离架构解决的是单卡装不下、单卡并发不足的容量问题，需要结合 NVLink、NVSwitch、RDMA 等高速互联考虑通信开销。
• GPU 与 LPU 异构协同分离架构则把目光放到不同硬件的擅长领域，试图通过专用处理器进一步降低生成延迟，但当前生态和工程复杂度仍有较高门槛。

NVIDIA GPU 是当前大模型推理的主流硬件底座，LPU 则代表了专用推理硬件的一个方向。把它们放一起讨论，不是为了证明谁比谁更“强”，而是帮我们理解：推理优化并不存在一把万能钥匙，真正成熟的方案往往是从资源矛盾出发，选择合适的分离维度，再通过监控数据不断调优。

建议下一步可以做两件事：一是用 NVIDIA 多卡环境跑通一个小模型的 Tensor Parallel 对比实验，找出并行规模的收益拐点；二是在你的真实业务压测数据中，观察 Prefill 和 Decode 分别消耗了多少时间与显存，再判断是否需要引入阶段分离。动手跑一轮数据，可能会比继续读十篇文章更有收获。