veRL 0.7架构升级：服务化强化学习框架解析

1. veRL 0.7版本架构演进全景

作为昇腾AI生态中的核心强化学习框架，veRL在0.7版本完成了从传统训练框架向服务化架构的关键转型。这次升级不是简单的功能迭代，而是从根本上重构了框架的运行时模型——将原本紧耦合的离线推理模式解耦为分布式服务化架构，同时统一了碎片化的训练后端实现。这些改动直接影响了框架的四个核心维度：

1. 执行模式：从同步SPMD到异步服务化
2. 资源管理：从静态分配到动态调度
3. 组件边界：从功能耦合到职责分离
4. 性能分析：从单进程到分布式profiling

这种架构转变使得veRL能够更好地支持Agentic RL场景，也为后续的多模态、多任务学习奠定了基础。下面这张对比表清晰地展示了v0.6到v0.7的核心变化：

2. 推理架构：从离线SPMD到服务化AgentLoop

2.1 AgentLoop服务化改造背景

传统强化学习框架的推理过程（即rollout阶段）通常采用同步数据并行（SPMD）模式，这种设计存在三个根本性缺陷：

1. 扩展性瓶颈：当需要集成LLM等重型模型时，同步执行的通信开销成为性能瓶颈
2. 灵活性不足：无法支持多轮对话（multi-turn）、工具调用等Agentic RL必需的特性
3. 资源利用率低：GPU/NPU在等待环境反馈或人工输入时处于空闲状态

veRL的解决方案是将rollout过程重构为服务化的AgentLoop模式，其核心设计目标包括：

• 支持用户自定义rollout逻辑的插件式扩展
• 提供标准化的推理请求API接口
• 实现请求级别的负载均衡

实际测试表明，在对话类任务中，服务化改造使NPU利用率从40%提升至75%，单卡支持的并发对话数增加3倍

2.2 服务化架构实现细节

2.2.1 核心组件交互关系

AgentLoop架构采用分层设计，各层之间通过Ray进行跨进程通信：

AgentLoopManager (控制面) ├── AgentLoopWorker1 (业务逻辑层) │ └── AsyncLLMServerManager (资源调度) ├── AgentLoopWorker2 │ └── AsyncLLMServerManager └── ...

关键组件职责：

• AgentLoopManager：批量请求的分片与调度，维护全局状态
• AgentLoopWorker：具体业务逻辑执行单元，每个worker对应一个Ray Actor
• AsyncLLMServerManager：管理底层HttpServer实例，实现负载均衡

2.2.2 通信协议优化

为减少跨进程通信开销，veRL设计了专用的序列化协议：

1. 使用Arrow格式压缩传输数据
2. 对张量数据启用Zero-Copy传输
3. 请求批处理（默认batch_size=32）

# 典型请求处理流程 async def generate_sequences(self, prompts): chunks = split_into_batches(prompts, self.batch_size) results = await asyncio.gather(*[ self.worker.generate.remote(chunk) for chunk in chunks ]) return merge_results(results)

2.3 性能优化实践

2.3.1 动态批处理策略

针对不同长度的prompt，采用动态批处理策略：

• 短文本：增大batch_size提高吞吐
• 长文本：减小batch_size保证低延迟

def calculate_batch_size(prompts): avg_len = sum(len(p) for p in prompts) / len(prompts) if avg_len < 50: return 64 elif avg_len < 200: return 32 else: return 16

2.3.2 内存优化技巧

在NPU环境下特别有效的内存管理方法：

1. 使用分页注意力(PagedAttention)减少KV缓存碎片
2. 对连续的小张量请求进行合并分配
3. 设置显存水位线自动触发GC

3. 训练架构：从多后端到统一Engine

3.1 统一训练架构的必要性

在v0.6版本中，veRL同时维护FSDP和Megatron两套训练实现，导致：

• 重复代码量超过60%
• 新功能需要多次实现
• profiling等基础设施难以统一

3.2 统一架构设计

3.2.1 分层抽象设计

TrainingTask (PPO/DPO等算法) └── BaseWorker (Actor/Critic等角色) └── BaseEngine (FSDP/Megatron等后端)

关键抽象层：

1. Engine抽象：封装分布式训练原语

   • 梯度聚合方式
   • 模型分片策略
   • 通信优化方法

2. Worker抽象：定义训练逻辑

   • 数据加载流程
   • 损失计算方式
   • 验证逻辑

3.2.2 典型训练流程

class PPOTrainer: def __init__(self, engine_type): self.engine = create_engine(engine_type) # 动态创建引擎 self.actor = ActorWorker(self.engine) self.critic = CriticWorker(self.engine) def train(self, data): with self.engine.step_context(): # 自动处理梯度同步 loss = self.actor.compute_loss(data) self.engine.backward(loss)

3.3 性能对比数据

统一架构后，在不同硬件配置下的性能表现：

4. 异步Profiling系统改造

4.1 改造前架构的局限性

原有profiling系统基于同步设计，存在三大痛点：

1. 跨进程采集失效：无法采集分离部署的推理服务数据
2. 控制链路冗长：需要从Trainer穿透多层调用到具体Worker
3. 配置依赖过重：装饰器必须依赖profiler实例参数

4.2 异步改造方案

4.2.1 推理侧profiling下沉

将profiling能力植入到HttpServer内部：

1. 每个HttpServer独立维护profiler实例
2. 通过Replica统一控制采集启停
3. 结果通过OSS/MinIO统一存储

class HttpServer: async def start_profiling(self, config): self.profiler = create_profiler(config) await self.profiler.start() async def stop_profiling(self): await self.profiler.stop() upload_results(self.profiler.output())

4.2.2 训练侧profiling上移

通过Engine抽象层统一管理：

1. 在BaseEngine中集成profiling控制
2. 各Worker自动继承profiling能力
3. 支持按训练阶段过滤采集

class BaseEngine: def __init__(self): self.profiler = DistProfiler() def step_context(self): @self.profiler.annotate("step") def _step(): pass return _step()

4.3 性能数据采集优化

4.3.1 数据量控制策略

针对NPU profiler的特殊优化：

1. 默认关闭memory profiling
2. 限制activity类型为关键算子
3. 设置10ms的采样间隔

# profiler_config.yaml npu_profiler: activities: - kernel - runtime options: sampling_interval: 10ms memory: false

4.3.2 跨进程时间同步

使用NTP协议同步各节点时钟，误差控制在±1ms内：

1. 主节点作为NTP server
2. 工作节点定期同步时钟
3. 采集数据时记录同步状态

5. 典型问题排查指南

5.1 推理延迟突增问题

现象：特定请求的延迟是平均值的10倍以上

排查步骤：

1. 检查HttpServer的负载均衡情况

   # 获取各Server负载 for server in manager.list_servers(): print(server.stats().queue_size)

2. 分析profiling数据定位慢请求
3. 检查是否有超长prompt未分片

解决方案：

• 调整动态批处理参数
• 增加prompt长度检查
• 扩容HttpServer实例

5.2 Profiling数据缺失问题

现象：部分节点的profiling结果为空

检查清单：

1. 确认NTP服务正常运行

   ntpstat

2. 检查profiler配置同步状态
3. 验证OSS存储权限

根治措施：

• 增加配置校验环节
• 实现profiling健康检查API
• 添加异常重试机制

6. 演进方向与实用建议

6.1 近期优化路线

1. 单卡多进程支持：解决NPU环境下多进程profiling冲突
2. 动态profiling控制：基于运行时指标自动调整采集粒度
3. 调度Timeline可视化：识别流水线中的气泡问题

6.2 架构设计启示

1. 服务化解耦：将rollout拆分为独立服务是支持Agentic RL的关键
2. 抽象分层：训练架构的统一显著降低了维护成本
3. 可观测性：异步profiling为分布式系统提供了新的调试手段

6.3 实践建议

对于计划升级到veRL 0.7的用户，建议：

1. 先在小规模环境验证服务化推理
2. 逐步迁移训练任务到统一架构
3. 利用异步profiling定位性能瓶颈

在NPU环境下的特别注意事项：

• 调整默认的profiling配置减少数据量
• 监控跨进程通信的内存使用
• 定期检查时间同步状态