ray.rllib 入门实践-3： 配置参数列表

前言：

        上一个博客详细介绍了配置rllib算法的几种方式，并推荐了用 AlgorithmConfig 类去创建配置对象，然后再配置对象中，根据代码提示配置相关参数。AlgorithmConfig 中的可配置参数有很多， 使用时可以去对应的源码查看有哪些配置选项，

        本博客对配置选项做了一些梳理。并对其中最常用的一些成员变量以黄色高亮显示。

        本问主要来自源码解读。

环境配置：

        torch==2.5.1

        ray==2.10.0

        ray[rllib]==2.10.0

        ray[tune]==2.10.0

        ray[serve]==2.10.0

        numpy==1.23.0

        python==3.9.18

一、 AlgorithmConfig 子模块分组 

        RLlib 中有非常多的配置， 为了便于管理， 把所有配置划分为以下几组：

• training: 训练相关参数组
• environment: 环境相关参数组
• deep learning framework: 深度学习的相关框架选择， tf2 或者 torch
• rollout worker ： 部署工作选项
• evaluation : 评估相关超参数
• exploration: 探索选项
• options for training with offline data: 使用离线数据进行训练的选项
• options for training multiple agents ： 多智能体训练的相关设置
• reporting 报告选项
• options for saving and restoring checkpoints : 保存和回复检查点的选项
• debugging : debug 相关选项
• options for adding callbacks to algorithms, 添加算法回调的相关选项
• resources : 计算资源使用设置选项
• options for external features : 实验功能选项

二、 几个重要子模块的详细介绍

1. AlgorithmConfig.training() 

        AlgorithmConfig.training() 里面有许多可配置参数， 具体如下：

• gamma: float, markov 决策过程的折扣因子， 奖励值的折扣因子。
• lr : 学习率
• grad_clip : 是否使用梯度裁剪。 根据grad_clip_by的设置裁剪梯度。
• grad_clip_by ： 如果grad_clip不是None, 基于这个参数裁剪梯度。
• train_batch_size: 训练批量大小
• model: 传递到策略模型的参数。也可以通过成员变量的方式访问。
• optimizer: 传递给策略模型的参数。
• max_requests_in_fighter_per_sample_worker : 对每个采样进程的最大请求数。
• Returns:  返回更新的AlgorithmConfig对象。

2. AlgorithmConfig.environment()

        用于设置环境

• env: 环境说明符
• env_config: dict, 传递给env, 默认附加参数：num_rollout_workers, worker_index, vector_index, remote
• Observation_space : 观测空间
• action_space : 策略的动作空间
• env_task_fn : 一个可调用函数，将最后一个训练结果、基本环境和环境上下文作为参数， 返回一个新任务来设置环境。
• render_env : 是否渲染环境， 如果True, 尝试在本地工作线程或worker1上渲染环境。
• clip_rewards: 是否在policy的后处理期间， 裁剪奖励。
• normalize_actions: 是否把产生的动作归一化到动作空间范围内。
• clip_actions: 应该被弃用
• disable_env_checking: if true, 禁用环境预检查模块。
• is_atari : 用于显示指定环境是否为atrai环境。
• auto_wrap_old_gym_envs : 是否自动包装旧gym环境。
• Return : 返回更新的AlgorithmConfig对象。

3. AlgorithmConfig.framework()

• framework: {"torch", "tf2} 选择框架
• eager_tracing: 在 eager模式下启用跟踪， 提升性能，但稍微不利于调试。
• eager_max_retraces:
• tf_session_args: 默认情况下把tf设置为单进程操作。
• torch_compile_learner: 如果为True，则编译学习器上的TorchRLModule上的FORWARD_TRAIN方法。如果未指定，则默认为在学习者上编译前向训练。
• torch_compile_learner_what_to_compile – TorchCompileWhatToCompile 模式指定如果 torch_compile_learner 为 True 则在学习器端编译什么。有关其使用的详细信息和建议，请参阅 TorchCompileWhatToCompile。
• torch_compile_learner_dynamo_backend-torch 计算器模式使用的学习者。
• torch_compile_worker – 如果为 True，则编译工作人员上 TorchRLModule 的前向探索和推理方法。如果未指定，默认情况下不会在工作线程上编译前向方法，因为回溯可能会很昂贵。
• torch_compile_worker_dynamo_backend – 用于工作人员的 torch 计算器后端。
• torch_compile_worker_dynamo_mode – 用于工作人员的 torch 计算器模式。
• Returns - 返回此更新的 AlgorithmConfig 对象

4. AlgorithmConfig.rollouts()  

       用于指定rollout_worker

• env_runner_cls : 用于环境部署的envRunner类
• num_rollout_worker : 为并行采样创建的rollout-worker的数量， 为 0 则强制在本地工作线程，
• num_env_per_worker : 每个进程上运行环境的个数
• sample_collector : SampleCollector 类， 用于收集和检索环、 模型和采样数据。 重写 SampleCollector  基类可以实现自己的收集、缓冲、检索逻辑。
• sample_async : 使用后台线程进行采样， 通常不建议打开。
• enable_connections : 是否使用基于connector的环境运行器， 以便obs的所有的预处理和操作的后处理都在代理和操作连接器中完成。
• use_worker_filter_stats : 是否将filter的更新从中央filter(本地filter)推送到远程worker的filter.
• rollout_framework_length : 在推出期间将剧集分为多个步骤的片段。这种大小的轨迹是从 rollout 工作线程中收集的， 并组合成更大的一批 train_batch_size 来进行学习。例如，给定 rollout_fragment_length=100 和 train_batch_size=1000：1. RLlib 从 rollout 工作线程收集 10 个片段，每个片段有 100 个步骤。2. 这些片段被连接起来，我们执行一个 SGD 纪元。当每个工作人员使用多个环境时，片段大小将乘以 num_envs_per_worker。这是因为我们并行地从多个环境收集步骤。例如，如果 num_envs_per_worker=5，则部署工作人员将以 5*100 = 500 个步骤的块形式返回经验。这里的数据流可能因算法而异。例如，PPO 进一步将训练批次划分为多个小批次，以实现多轮 SGD。设置为“auto”以使 RLlib 计算精确的 rollout_fragment_length 以匹配给定的批量大小。
• batch_mode : 如何使用 EnvRunner 构建单独的批次。
• remote_worker_envs : 当设置一个进程中运行多个env时， 决定是否在远程进程中而不是同一进程中创建新的环境。
• remote_env_batch_wait_ms: 轮询环境时远程worker的等待超时时间。
• valid_worker_after_construction: 是否检查每个远程 worker 是否健康。
• preprocessor_pref : 是否使用rllib或deepmind的预处理器。
• compress_observations : 是否 LZ4 压缩在rollout期间收集的sampleBatches 中的各个观测值。
• enable_tf1_exec_eagerly – 显式告诉 rollout Worker 启用 TF eager 执行。例如，当框架是“torch”，但需要恢复 TF2 策略以进行评估或基于联盟的目的时，这非常有用。
• Sampler_perf_stats_ema_coef – 如果指定，性能统计数据以 EMA 为单位。这是新数据点对平均值的贡献程度的系数。默认值为“无”，它使用简单的全局平均值。 EMA更新规则为：updated = (1 - ema_coef) * old + ema_coef * new
• Returns - 此更新的 AlgorithmConfig 对象。

5. algorithmConfig.evaluation() 

• evaluation_interval: 在训练过程中，间隔多少个episode执行一次evaluation.
• evaluation_duration: 在训练过程中，间隔多长时间执行一次evaluation. 持续时间的单位可以时episode, 或 timesteps.
• evaluation_duration_unit: 配合 evaluation_duration使用， episode 或 timesteps.
• evaluation_num_workers: evaluation使用的worker数。 默认为0. evaluation会额外增加工作进程。
• evaluation_config: 将额外的参数传递给evaluation的创建者。
• evaluation_sample_timeout_s – ray.get 调用远程评估工作程序的sample() 方法的超时（以秒为单位）。 在此之后，用户将收到警告和有关如何解决问题的说明。这可以是为了确保剧集结束、增加超时或切换到 evaluation_duration_unit=timesteps。
• evaluation_parallel_to_training – 是否使用线程与 Algorithm.train() 调用并行运行评估。默认=假。例如。 evaluation_interval=2 -> 对于每个其他训练迭代，Algorithm.train() 和 Algorithm.evaluate()调用并行运行。注意：这是实验性的。可能的陷阱可能是评估循环开始时权重同步的竞争条件。
• evaluation_config – 典型用法是将额外的参数传递给评估环境创建者，并通过计算确定性操作来禁用探索。重要提示：策略梯度算法能够找到最佳策略，即使这是随机策略。 此处设置“explore=False”将导致评估工作人员不使用此最优策略！
• off_policy_estimation_methods – 指定如何评估当前策略以及任何可选配置参数。这仅在阅读离线体验时有效（“输入”不是“采样器”）。可用键： {ope_method_name: {“type”: ope_type, …}} 其中 ope_method_name 是用户定义的字符串，用于保存 OPE 结果，ope_type 可以是 OffPolicyEstimator 的任何子类，例如ray.rllib.offline.estimators.is::ImportanceSampling或您自己的自定义子类，或子类的完整类路径。您还可以添加其他配置参数以传递给字典中的 OffPolicyEstimator，例如{“qreg_dr”：{“类型”：DoublyRobust，“q_model_type”：“qreg”，“k”：5}}
• ope_split_batch_by_episode – 是否使用SampleBatch.split_by_episode()将输入批次分割为多个剧集以在估计ope指标之前。在bandits的情况下，你应该将此设置为False以提高ope评估速度。在bandits的情况下， 不分割剧集也是可以的，因为每个记录已经是一个时间步长了。默认值为True
• evaluation_num_workers – 用于评估的并行工作线程数。请注意，默认设置为零，这意味着评估将在算法进程中运行（仅当评估间隔不为 None 时）。如果增加此值，则会增加算法的 Ray 资源使用量，因为评估工作线程是与部署工作线程（用于对训练数据进行采样）分开创建的。
• custom_evaluation_function – 自定义评估方法。这必须是签名的函数（algo：算法，eval_workers：WorkerSet）->指标：dict。请参阅 Algorithm.evaluate() 方法以查看默认实现。该算法保证所有 eval 工作线程在调用此函数之前都具有最新的策略状态。
• always_attach_evaluation_results – 确保最新的可用评估结果始终附加到步骤结果字典中。 如果 Tune 或其他一些元控制器需要始终访问评估指标，这可能很有用。
• enable_async_evaluation – 如果为 True，则为评估工作人员使用 AsyncRequestsManager，并使用此管理器向评估工作人员发送sample() 请求。这样，算法对于长时间运行的事件和/或失败（和重新启动）的工作程序变得更加稳健。
• Returns - 此更新的 AlgorithmConfig 对象。

6. AlgorithmConfig.exploration()

        指定探索选项。

• explore: 默认探索行为。 设置为None 表示没有探索行为， 例如用于evaluation.
• explore_config : 指定 Exploration对象的配置。
• Returns: 返回此更新的 AlgorithmConfig 对象。

7. AlgorithmConfig.resources()

• num_gpus: 为这个算法分配多少GPU.
• num_cpus_per_worker: 为每个进程（worker）分配多少cpu
• num_gpus_per_worker: 为每个进程（worker）分配多少GPU,可以是小数
• num_cpus_for_local_worker: 为本地运行的进程分配多少cpu.
• num_learner_workers: 有多少个进程用于训练。
• num_cpus_per_learner_worker:为 每个用于训练的进程分配多少cpu.
• num_gpus_per_learner_worker: 为 每个用于训练的进程分配多少gpu.
• local_gpu_idx: 如果 num_gpus_per_learner_worker>0，并且'num_learner_workers'<2，则该GPU 索引将用于训练过程。这是CUDA 可用设备列表中的索引。
• custom_resources_per_worker: Optional[dict] = NotProvided,
• placement_strategy: Optional[str] = NotProvided,