双卡互联推理服务部署与性能调优实践

一、部署概述

本文讨论的部署对象是运行在双卡计算节点上的大语言模型推理服务。部署目标为：在两块计算卡通过高速互联链路连接的硬件条件下，完成推理引擎的安装、通信层配置、模型加载与服务发布，使服务在单发与多并发两种负载形态下均能稳定输出，并尽可能发挥卡间互联带来的吞吐与延迟收益。

适用读者包括：负责模型服务上线的开发者、进行推理性能调优的运维工程师、规划算力资源的技术负责人，以及需要在私有环境或云上环境部署推理服务的架构师。

部署前需要理解的基本背景：

• 推理服务属于长连接、流式返回的在线服务，对首Token延迟（TTFT）和每Token生成延迟（TPOT）敏感；
• 大模型参数通常超出单卡显存容量，需要多卡切分，切分后卡间通信效率直接决定整体性能；
• 卡间互联存在多种形态，带宽与延迟差异显著，部署前必须确认实际链路类型；
• 服务负载通常呈波峰波谷分布，部署方案需兼顾低并发延迟与高并发吞吐。

二、部署场景

双卡互联推理服务适用于以下典型场景：

1. 中等规模模型私有化部署：模型参数量超出单卡显存，但尚未达到需要多机多卡的规模，双卡切分是性价比最高的方案；
2. 低并发低延迟交互场景：面向内部工具、代码辅助、对话助手等场景，用户数量有限但对响应速度要求高；
3. 高并发批量生成场景：面向内容生成、数据标注、批量摘要等场景，吞吐量优先，允许一定程度的单请求延迟上升；
4. 成本敏感的算力复用场景：在已有双卡节点上通过互联改造或拓扑优化，提升既有硬件的利用率。

需要特别说明的是，卡间互联的收益并非在所有负载下都一致。部署前应明确业务的主要负载形态，再决定是否将互联优化作为重点投入方向。

三、架构与组件拆解

双卡推理服务的部署涉及以下关键模块：

层级	组件	作用
硬件层	计算卡 ×2、卡间互联链路、主机内存、本地存储	提供算力与显存，承载模型权重与中间状态
驱动层	计算卡驱动、通信库、运行时	使上层框架能够调用计算资源与互联链路
推理引擎层	模型加载器、张量并行调度、KV缓存管理、批处理调度器	完成模型切分、请求调度与流式输出
服务层	HTTP服务、流式接口、并发控制、健康检查	对外提供推理接口
观测层	日志、指标采集、链路追踪、告警	支撑验证与持续运维
网络层	负载均衡、访问控制、证书	保障服务可达与安全

其中，推理引擎层的张量并行配置与驱动层的通信库配置是本部署的核心，二者共同决定了卡间互联能否真正生效。

四、前置准备

4.1 硬件与拓扑确认

部署前必须完成以下确认：

• 确认两块计算卡的型号、显存容量、计算能力一致；
• 确认卡间互联的实际链路类型与理论带宽，区分高速专用互联与普通总线互联；
• 确认卡间互联是否经过改造或转接，转接方案可能带来带宽衰减或稳定性风险；
• 确认主机PCIe通道分配，避免两卡共享通道导致带宽争抢；
• 确认主机内存容量足以支撑模型权重加载与KV缓存换入换出。

4.2 基础环境准备

• 操作系统版本、内核版本满足驱动与推理引擎要求；
• 安装匹配版本的计算卡驱动与通信运行时；
• 安装推理引擎及其依赖，锁定版本号，避免环境漂移；
• 准备模型权重文件与分词器文件，校验完整性；
• 配置服务运行账号，遵循权限最小化原则。

4.3 资源规划

• 显存规划：模型权重按张量并行切分后分配至两卡，需为KV缓存预留足够显存，预留比例建议不低于总显存的20%；
• 并发规划：根据业务峰值QPS与单请求生成长度，估算所需的最大并发批大小；
• 存储规划：模型文件建议放置于本地高速存储，减少加载时间；
• 网络规划：服务端口、管理端口、监控端口需提前规划并纳入访问控制策略。

4.4 配置清单示例

# 推理服务通用配置示意（中立示例）
model:
  path: /data/models/<model-name>
  tokenizer: /data/models/<model-name>
  dtype: auto
  max_model_len: 8192
parallel:
  tensor_parallel_size: 2      # 双卡张量并行
  pipeline_parallel_size: 1
  enable_interconnect: true    # 启用卡间高速互联
cache:
  gpu_memory_utilization: 0.85
  block_size: 16
server:
  host: 0.0.0.0
  port: 8000
  max_concurrency: 4
  streaming: true
observability:
  log_level: info
  metrics_enabled: true

五、部署流程

步骤一：环境初始化

安装驱动与通信运行时，验证两卡均可被正常识别，并确认卡间互联链路处于可用状态。此步骤的关键是先验证硬件可见性，再验证通信可用性，避免驱动问题被误判为模型问题。

# 通用验证思路（示意，非具体产品命令）
# 1. 检查计算卡识别状态
<device-query-tool> --list
# 2. 检查卡间通信拓扑
<topology-query-tool> --show-matrix
# 3. 运行通信连通性自检
<comm-test-tool> --all-reduce --size 1G

若通信自检带宽明显低于链路理论值，应优先排查拓扑配置、转接方案与驱动版本，而非继续部署上层服务。

步骤二：模型部署与切分配置

将模型权重放置到规划路径，配置张量并行度为2，使模型权重与计算图切分到两块卡上。此步骤需注意：

• 切分方式需与模型结构兼容，部分层结构对切分有特殊要求；
• 加载过程中观察两卡显存占用是否均衡，明显不均衡说明切分配置有误；
• 首次加载完成后记录加载耗时，作为后续扩容与重启的基线。

步骤三：服务启动与参数设置

启动推理服务，重点设置以下参数：

• 最大并发数：需与显存容量、KV缓存块数量匹配，设置过高会导致请求排队甚至拒绝服务；
• 批处理策略：连续批处理可显著提升吞吐，但会增加单请求延迟，需按业务容忍度取舍；
• 显存利用率上限：过低浪费资源，过高容易在长序列请求下触发显存不足；
• 流式输出开关：交互式场景应开启，批量场景可按需关闭以简化客户端处理。

步骤四：开放访问与安全配置

• 通过负载均衡或反向代理暴露服务端口；
• 配置TLS证书，确保传输加密；
• 设置访问白名单或身份认证，禁止未授权调用；
• 对管理接口与推理接口做端口隔离。

步骤五：上线验证

见下节。

六、上线验证

部署完成后需从四个维度验证：

6.1 服务可达性验证

• 健康检查接口返回正常；
• 简单请求可返回完整响应；
• 流式接口可正常分块返回，无中断。

6.2 功能正确性验证

• 输入固定提示词，对比输出是否符合预期；
• 检查分词、截断、停止符处理是否正确；
• 验证超长输入与超长输出的边界行为。

6.3 性能指标验证

在单发与多并发两种负载下分别采集指标：

指标	含义	关注点
请求吞吐（req/s）	单位时间完成请求数	反映整体处理能力
输出Token吞吐（tok/s）	单位时间生成Token数	反映生成效率
平均TTFT	首Token平均延迟	反映交互响应速度
P99 TTFT	首Token尾部延迟	反映高负载下的稳定性
平均TPOT	每Token平均生成延迟	反映生成流畅度
P99 ITL	Token间延迟尾部值	反映流式输出抖动

验证要点：

• 单发场景：重点关注TTFT与TPOT，互联优化在此场景下收益有限，通常在个位数到十个百分点区间；
• 多并发场景：重点关注吞吐与P99尾部延迟，互联优化在此场景下收益更明显，吞吐提升可达十个百分点以上，尾部延迟改善幅度更大；
• 并发扩展性：从单发提升到4并发，吞吐通常可获得数倍增长，但每Token生成延迟会随之上升，需确认上升幅度在业务容忍范围内。

6.4 稳定性验证

• 持续压测不少于30分钟，观察显存占用、温度、错误率是否稳定；
• 模拟单卡异常，验证服务是否能正确降级或快速失败；
• 验证长时间运行后无内存泄漏与句柄泄漏。

七、常见问题与排查

现象	可能原因	排查方向
卡间通信带宽远低于预期	拓扑配置错误、转接衰减、驱动版本不匹配	检查拓扑矩阵、更换转接方案、对齐驱动版本
两卡显存占用不均衡	切分配置错误、模型结构不兼容	检查并行配置、核对模型层切分逻辑
高并发下TTFT急剧上升	批大小超出显存承载、调度策略不合理	降低最大并发、调整批处理窗口、增加KV缓存块
流式输出中断	超时设置过短、连接被中间层断开	延长超时、检查代理层缓冲配置
长序列请求失败	显存不足、最大长度设置超限	降低最大长度、提高显存利用率上限、启用量化
服务启动后无响应	端口未开放、进程未就绪、模型加载未完成	检查监听状态、日志、加载进度

八、运维与优化

8.1 监控告警

• 采集计算卡利用率、显存占用、温度、功耗；
• 采集服务侧QPS、TTFT、TPOT、错误率、排队长度；
• 对P99延迟、错误率、显存占用设置分级告警阈值；
• 保留请求级日志，便于问题回溯。

8.2 性能优化方向

• 批处理调优：在延迟容忍范围内提高批大小，是提升吞吐最直接的手段；
• KV缓存优化：合理设置缓存块大小与换出策略，减少显存碎片；
• 量化部署：在精度可接受的前提下采用低比特量化，降低显存占用，提升并发能力；
• 互联优化：确认互联链路真正生效，避免配置开启但实际走普通总线；
• 请求调度：对长短请求做区分调度，避免长请求阻塞短请求。

8.3 稳定性保障

• 配置健康检查与自动重启；
• 设置请求超时与重试上限，避免雪崩；
• 保留上一版本模型与服务配置，支持快速回滚；
• 定期演练单卡故障场景下的降级流程。

8.4 成本控制

• 按业务峰谷配置弹性扩缩容策略；
• 对闲置时段降低副本数或进入低功耗状态；
• 定期评估显存利用率，避免长期低负载运行；
• 对模型文件与日志设置生命周期策略，控制存储成本。

九、总结

双卡互联推理服务的部署，核心在于三件事：确认互联链路真实可用、配置合理的并行与并发参数、在真实负载下验证收益。

从实践规律看，卡间互联在单发场景下的收益相对有限，主要体现为小幅延迟改善；而在多并发高负载场景下，收益更为明显，表现为吞吐提升、首Token延迟下降与尾部延迟显著收窄。与此同时，并发本身才是吞吐提升的第一驱动力，从单发扩展到多并发可带来数倍吞吐增长，代价是单请求生成延迟上升，部署时需按业务形态做取舍。

建议部署完成后，先以单发验证功能正确性，再以多并发验证吞吐与尾部延迟，最后通过长时间压测确认稳定性，形成可复现的基线数据，为后续扩容、调参与故障排查提供依据。