想象你是一家连锁餐饮集团的行政总厨，任务是开发一道震惊全城的招牌菜。候选配料组合有十万种，而你只有一间后厨、一个灶台，每天试一道菜，试到退休也试不完。现在集团给你配了一间智能后厨：几十个灶台同时开火，几十位厨师同时试菜；一道汤炖了五分钟就发酸，品鉴官立刻撤掉它，把灶台让给下一道配方；某位厨师偶然发现了更好的调味手法，全店厨师马上学会；还有一位军师，根据所有试菜反馈，聪明地推荐下一道最值得尝试的配方。这套系统，就是 Ray Tune——分布式超参数调优框架。它把“试菜”从一个人的苦差事，变成几十个灶台的流水线；把调参时间从天级压缩到小时级。本文我们就用这座智能后厨作比喻，把 Ray Tune 的调度机制、ASHA 早停、PBT 种群训练、Optuna 集成一次讲透。

岗位关联

调参往往吃掉机器学习项目一半以上的时间。掌握 Ray Tune，等于学会用集群资源把“天级调参”压成“小时级调参”，这是进阶算法工程师的必备手艺。

目录
  1. 可视化演示
  2. 认识Ray Tune
  3. 分布式架构
  4. ASHA早停
  5. PBT种群
  6. 搜索算法
  7. 实战流程
  8. 收益对比
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

ASHA——异步早停 底部试验被淘汰释放资源 顶部试验继续训练 异步淘汰，快不等慢

认识Ray Tune

还记得那位想把十万种配料组合都试遍的行政总厨吗？他真正的瓶颈不是灶台不够，而是“指挥混乱”：哪个厨师做哪道菜、什么时候换人、分数记在谁的账上。Ray Tune 就是那张统筹全局的调度台。你只需告诉它“我要试哪些配方”，它自动把活分下去，把结果收回来。

传统调参是一层套一层的 for 循环：一组参数训练一个模型，跑完再看下一组，慢得像一个人在后厨一道菜一道菜地做。Ray Tune 把“训练 + 评估”打包成一个可复制的最小任务——试验（Trial）。每个 Trial 对应一组完整配方：学习率、批次大小、网络层数……它可以被分发给无数个灶台同时开火。

Ray Tune 的四个核心组件各有分工：Trial 是被调度的最小任务；Search Algorithm 是出配方的军师；Scheduler 是负责中途淘汰与晋升的裁判；底层的 Ray 集群是提供灶台的厨房。工作流程也很固定：定义目标函数 → 设定搜索空间 → 交给 Tuner → 并行试验 → 取回最优结果。

所以，Ray Tune 不发明新菜，它只把“试菜”变成一条流水线。面向用户的 API 只有寥寥几个类，复杂度和单个试验的解耦都替你处理好了——这正是它和“自己写多进程脚本”最大的区别。

min⁡λ∈ΛL(λ)\displaystyle \min_{\lambda \in \Lambda} \mathcal{L}(\lambda)
λ 是配方，Λ 是菜谱全集，L 是试菜得分——调参，就是在菜谱书里找出让得分最低的那一页。
  1. λ（配置向量）每一组超参数组合，好比一道菜的“盐、糖、火候”三元组。选什么值，直接决定模型长成什么样。
    λ=(lr,batch_size,layers,… )\lambda = (\text{lr}, \text{batch\_size}, \text{layers}, \dots)
  2. Λ（搜索空间）所有可能取值的集合，相当于菜谱书里所有待选配方的全集。空间设太大，厨师们试不完；设太小，又可能错过好味道。
    Λ=Λ1×Λ2×⋯×Λd\Lambda = \Lambda_1 \times \Lambda_2 \times \cdots \times \Lambda_d
  3. L（验证损失）模型在验证集上的表现评分，就是“试菜得分”。越低代表这道菜越接近招牌菜。
    L(λ)=验证集上的错误率\mathcal{L}(\lambda) = \text{验证集上的错误率}
  4. min（找最小）目标是把评分压到最低，也就是从上千道试做的菜里挑出最满意的那一道端给顾客。
    λ∗=arg⁡min⁡λ∈ΛL(λ)\lambda^* = \arg\min_{\lambda \in \Lambda} \mathcal{L}(\lambda)

分布式架构

一家餐厅的灶台有限，连锁品牌却可以在城市各处同时开火。Ray Tune 的分布式能力正是这种“开分店”的思路：底层由 Ray 集群提供资源池，把试验分发到一台或多台机器的 CPU/GPU 上。让你惊讶的是，代码写起来和单机几乎一模一样，跑起来却散布整个集群。

Ray 集群采用“无主调度”：每个节点既是计算者也是调度者。资源被抽象成可分配的单位，Tuner 把 N 个试验丢进一个任务池，节点抢到资源就领走一个试验开跑，跑完再领下一个。这就是并行试验的底层真相——没有谁在“排队等所有人”，只有谁空下来谁接活。

分布式带来的三大好处：弹性扩展（加几台机器只需改启动参数）、故障容错（节点挂了，试验自动迁移重跑）、资源利用（GPU 碎片被自动拼起来利用）。对使用者而言，多机并行几乎只是多写一个 resources={"gpu": 1}。

开分店的代价是店与店之间要通信、要协调，Ray Tune 的 overhead 也来源于此。但只要任务足够多、单次试验足够长，这个 overhead 就被摊得很薄，收益远大于成本。

Ttotal≈Ttrial×NK\displaystyle T_{total} \approx \frac{T_{trial} \times N}{K}
总时长 ≈ 单道菜时长 × 菜数 ÷ 灶台数。灶台越多，出菜越快，但总有个限度。
  1. T_trial（单个试验时长）跑完一个试验的时间，相当于一位厨师做一道菜需要半小时。它取决于模型复杂度和数据量。
    Ttrial=一次完整训练时间+验证时间T_{trial} = \text{一次完整训练时间} + \text{验证时间}
  2. N（试验总数）待测配方总数。若每个维度取 10 个候选、共有 3 个维度要搜，最粗糙的全搜索就是 1000 组。
    N=∣Λ1∣×∣Λ2∣×⋯×∣Λd∣N = |\Lambda_1| \times |\Lambda_2| \times \cdots \times |\Lambda_d|
  3. K（并行度）同时开火的灶台数量，等于集群所有可分配资源的函数。K 越大，摊到每道菜的时间越短，但通信与排队不可避免。
    K=∑node该节点可分配的 CPU/GPU 数K = \sum_{\text{node}} \text{该节点可分配的 CPU/GPU 数}

ASHA早停

主厨的经验之谈：一道汤炖了五分钟就发酸，就不用等两小时了。ASHA（Asynchronous Successive Halving Algorithm，异步连续减半算法）就是这位品鉴官。它把训练过程切成若干“档”（rung），每到一档就试一次菜，表现垫底的试验直接被撤下灶台，把资源让给后面排队的候选。

ASHA 的关键词是“异步”。传统连续减半（Successive Halving）要求同一批试验都跑完某一档，才统一比较、统一淘汰一半——像等所有客人吃完一道菜才上下一道，上一道菜早就凉了。ASHA 改成“谁先报分谁先被裁决”，试验之间无需同步等待，集群永远不闲着。

具体机制：每个试验按训练轮数（epoch）被分成多个 rung，每跨过一个 rung 就上报一次验证分数。到达检查点时，ASHA 用该档已完成试验分数的中位数当门槛，低于门槛的试验被早停（early stop）。活过多个 rung 的试验会获得成倍增长的预算，把资源集中到真正的希望之星上。

品鉴官的价值不是让每道菜做得更快，而是及时止损，把灶台和时间留给最可能成为招牌菜的配方。正因如此，同样的预算下 ASHA 能试出更多候选，调参的天花板被大幅抬高。

stop(i,r)  ⟺  si(r)<mr\displaystyle \text{stop}(i, r) \iff s_i^{(r)} < m_r
当某道菜在第 r 档的得分低于该档已完成菜品的中间水平时，品鉴官立刻撤菜，把灶台让出去。
  1. s_i^(r)（中期得分）第 i 个试验在第 r 档的验证得分，即这个配方的中期“试吃分”。
    si(r)=第 r 个检查点的验证指标s_i^{(r)} = \text{第 } r \text{ 个检查点的验证指标}
  2. m_r（中位数门槛）第 r 档所有已完成试验得分的中位数，相当于品鉴官手里的及格线。
    mr=median{sj(r):trial j 越过了档 r}m_r = \text{median}\{s_j^{(r)} : \text{trial } j \text{ 越过了档 } r\}
  3. stop(i, r)（早停判定）当试验分数跌到及格线下，ASHA 判定它“继续下去也翻不了盘”，立即终止并回收资源。
    早停后回收资源，转给下一候选配置\text{早停后回收资源，转给下一候选配置}

PBT种群

光淘汰还不够，行政总厨还有一张王牌：某位厨师无意中发现了更好的调味手法，就让全店厨师立刻学会。这就是 PBT（Population Based Training，种群训练）。它不像普通调参那样“各试各的”，而是让一组试验组成种群，边训练边互相学习。

PBT 的种群中，每个成员是一个带完整训练状态的试验——注意，不只是超参数，还包括训练到一半的模型权重。每训练一段，就进入“利用-探索”环节：利用（exploit）是把种群中表现最差的成员，直接替换成最优成员的超参数和权重；探索（explore）是替换后对超参数加一个随机扰动，避免所有成员变成一个模子。

这种“边训练边进化”的机制特别适合训练周期长的场景，比如强化学习或大规模语言模型训练：学习率、动量这类超参数会随训练自适应地漂移到合适的区间。由于参数继承是直接复制权重，新配置无需从头训练，资源浪费极小。

PBT 把调参从“大海捞针”变成“群体进化”——一个人做的好菜，全店立刻共享做法，再各自加点小创意。它和 ASHA 的“淘汰制”形成互补：一个去掉差的，一个传播好的。

wi←{wjf(wj)>f(wi)wi+σε其他情况\displaystyle w_i \leftarrow \begin{cases} w_j & f(w_j) > f(w_i) \\ w_i + \sigma\varepsilon & \text{其他情况} \end{cases}
同伴更强就整套抄作业，抄完再加一点自己的随机发挥——这就是 PBT 的利用与探索。
  1. f(w_i)（适应度）第 i 个种群成员的验证回报，相当于这位厨师目前这道菜的得分。
    f(wi)=验证集上的回报f(w_i) = \text{验证集上的回报}
  2. 利用（w_i ← w_j）若同伴 j 得分更高，把 j 的参数（菜谱加半成品）整套复制过来。
    wi:=wj(j 为当前最优成员)w_i := w_j \quad (j \text{ 为当前最优成员})
  3. 探索（w_i + σε）复制后再加一个高斯扰动，让配方微调出新花样。
    ε∼N(0,1),σ 为扰动尺度\varepsilon \sim \mathcal{N}(0, 1), \quad \sigma \text{ 为扰动尺度}

搜索算法

试菜如果全凭随机，再多灶台也浪费。真正聪明的总厨会请一位军师：根据之前所有菜的味道反馈，推断下一道菜最该往哪个方向调。Ray Tune 的 Search Algorithm 就是这位军师，它负责生成下一组候选超参数。

Ray Tune 内置多种搜索策略打配合：随机搜索（Random Search）最朴素，作为兜底永远有效；贝叶斯优化（Bayesian Optimization）用一个代理模型拟合“超参数→得分”的关系，优先探索最有希望的区域；最常用的是集成 Optuna，这个独立调参库的 TPE 算法用“好样本密度 / 差样本密度”之比来决定下一个采样点。

集成只是一行代码的事：search_alg = OptunaSearch(metric="loss", mode="min")。更重要的是，搜索算法与调度器可以自由组合——Optuna 负责出题，ASHA 负责淘汰，PBT 负责成员之间的互相学习，各司其职，互不干扰。

军师的职责是让每一轮实验都“问在点子上”。Optuna 负责聪明的头脑，Ray 集群负责强壮的双手，Ray Tune 则是把它们拼在一起的调度台。

xnext=arg⁡max⁡xl(x)g(x)\displaystyle x_{next} = \arg\max_{x} \frac{l(x)}{g(x)}
下一个采样点，选在“像好评菜”和“不像差评菜”比值最大的地方——TPE 的核心直觉。
  1. l(x) 与 g(x)TPE 把已有样本按分数分成“好”与“差”两组，分别估计密度。l 是好样本密度，g 是差样本密度——好比厨师记录过的“好评菜”和“差评菜”的分布。
    l(x)=P(x∣好样本组),g(x)=P(x∣差样本组)l(x) = P(x \mid \text{好样本组}), \quad g(x) = P(x \mid \text{差样本组})
  2. x_next（下一个采样点）下一个要试验的配置，就是让“看起来像好评菜”的概率远大于“像差评菜”的地方。
    xnext=arg⁡max⁡xl(x)g(x)x_{next} = \arg\max_{x} \frac{l(x)}{g(x)}
  3. 与随机搜索的区别随机搜索均匀撒网，无差别试菜；TPE 是“基于已有反馈的定向捕捞”。
    xrandom∼U(Λ)x_{random} \sim \mathcal{U}(\Lambda)

实战流程

纸上谈兵结束，回后厨动手。一次完整的 Ray Tune 调参，就像给连锁餐厅写一份标准作业流程（SOP）。第一步，写一个“试菜函数”：输入一组超参数，输出一个分数（验证指标）。

函数内部就是普通的机器学习代码：构建模型、读数据、按 config 里的超参数训练若干轮、在验证集上打分并上报。第二步，声明搜索空间：tune.loguniform(1e-4, 1e-1) 表示学习率按对数均匀采样，tune.choice([32, 64, 128]) 表示从列表里等概率选，tune.randint(10, 50) 表示整数均匀采样。

第三步组装 Tuner：传入 train 函数、搜索空间、试验数量 num_samples、调度器 scheduler（如 ASHAScheduler）和搜索算法 search_alg（如 OptunaSearch）。第四步 tuner.fit() 启动，跑完后用 get_best_result(metric="loss", mode="min") 取出最优配置。监控可以用 TensorBoard 或命令行进度条，随时看每个试验的得分曲线。

整套 SOP 的核心是“解耦”：训练函数是纯函数，Tune 只管调度。只要这个边界守住了，换机器、换调度器、换搜索算法都只是改三行配置的事——这正是 Ray Tune 实战中最值钱的工程习惯。

lr∼LogUniform(10−4,10−1)\displaystyle \text{lr} \sim \text{LogUniform}(10^{-4}, 10^{-1})
学习率按对数均匀采样：从 1e-4 到 1e-1，每一个数量级获得同等的尝试机会。
  1. LogUniform（对数均匀）在对数尺度上均匀采样。学习率这类跨越几个数量级的超参数，如果用普通均匀采样，小值区间的候选会少得可怜。就像盐要从“毫克”到“克”跨了三个数量级，必须按倍率均等分配尝试机会。
    log⁡10(lr)∼U(−4,−1)\log_{10}(\text{lr}) \sim \mathcal{U}(-4, -1)
  2. 搜索空间字典每个键是一个超参数名，值是采样分布，Ray Tune 每次从分布里抽一组完整配方。
    config={lr:LogUniform,batch:Choice([32,64,128])}\text{config} = \{\text{lr}: \text{LogUniform}, \text{batch}: \text{Choice}([32, 64, 128])\}
  3. num_samples（试验数）决定从搜索空间抽取多少组配方来试验，相当于给后厨批了几道菜。
    num_samples=N\text{num\_samples} = N

收益对比

最后，总厨要向老板交一份成本账：这套分布式后厨到底值不值？算账很简单——同样 100 组候选配方，每组试做 1 小时，串行要 100 小时，约 4 天；而 20 台机器并行 + ASHA 淘汰掉一半以上注定失败的配方，实际只需 2~3 小时。

时间压缩的公式拆开看有三个杠杆：并行度 K 把剩余试验分摊到多台机器；早停率 N_stop/N 把不合格的试验直接剔除；搜索算法让采样点更精准，同样的试验数能更快逼近最优。三者相乘，就是“天级→小时级”的秘密。

但分布式不是免费的午餐：试验调度、结果采集、机器间通信都会产生 overhead，加速比曲线随 K 增大而增速放缓。工程上因此要先小规模验证、再横向扩展；当 overhead 占比变高时，优化搜索算法往往比继续加机器更划算。

把这笔账算完，结论清晰：单独用并行、早停或搜索算法，都只是局部优化；Ray Tune 把三者编排成一条流水线，才是真正的收益放大器。老板听完，批准了这张采购单。

Speedup=TserialTtune=N×tavg(N−Nstop)×tavg/K+toverhead\displaystyle \text{Speedup} = \frac{T_{serial}}{T_{tune}} = \frac{N \times t_{avg}}{(N - N_{stop}) \times t_{avg} / K + t_{overhead}}
加速比 = 串行总时长 ÷ 分布式总时长。分母里，早停砍掉了一批菜，并行又摊薄了剩余时间。
  1. T_serial（串行总时长）不调分布式时，所有候选依次试验的总时间——100 道菜一道一道做。
    Tserial=N×tavgT_{serial} = N \times t_{avg}
  2. T_tune（分布式总时长）早停后幸存的试验数除以并行度，再加上调度与通信开销。
    Ttune=Nsurvive×tavgK+toverhead,Nsurvive=N−NstopT_{tune} = \frac{N_{survive} \times t_{avg}}{K} + t_{overhead}, \quad N_{survive} = N - N_{stop}
  3. Speedup（加速比）两者之比就是加速比。受 overhead 制约，K 越大收益增速越缓，所以“加到某个并行度后不如优化搜索算法”是常态。
    Speedup∼O(K) 但受 toverhead 制约\text{Speedup} \sim O(K) \text{ 但受 } t_{overhead} \text{ 制约}

AI 应用场景

图像分类的精度调优

阶段：模型训练前的超参数配置阶段

解决的问题：CV 工程师手工调学习率、数据增强策略时，单卡串行一轮要 8 小时，10 组配置要 3~4 天。Ray Tune 把 30 组配置分发到 8 张 GPU 上并行，再叠加 ASHA 在前几个 epoch 就淘汰差的，一天内完成——相当于把“一位厨师连续试菜”变成“八位厨师并行试菜，品鉴官随时撤菜”。

具体案例：某公司做细粒度商品识别，baseline 准确率 91.2%。搜索空间设为 lr 用 loguniform、增强强度用 choice、骨干网络冻结层数用 randint，num_samples=40，ASHA grace_period=3，Optuna 采样。7 小时拿到 93.1% 的配置。

推荐系统的动态调参

阶段：在线学习与模型迭代阶段

解决的问题：推荐排序模型线上数据漂移，固定学习率要么学不动要么震荡。PBT 让一个种群持续在线微调，成员的验证指标实时对比，差的定期复刻好的并加扰动——就像后厨每天晨会上分享新发现的调味技巧，全店立刻采用。

具体案例：新闻推荐 CTR 模型，一天两次 PBT 种群检查，学习率在 [1e-5, 1e-2] 内自适应漂移，CTR 相对提升 4.3%，全程无需人工干预。

AutoML 平台的调度底座

阶段：平台层的多团队资源共享

解决的问题：多个算法团队共用集群时，每人手动开脚本互相抢资源，GPU 碎片浪费严重。Ray Tune 作为平台调度底座，给每个任务配额，试验排队不挤占——就是连锁集团的总调度台统一分配各分店的灶台。

具体案例：某中台团队把 Tune 封装成 REST API，业务方提交搜索空间即可排队调参；集群利用率从 35% 提升到 78%。

Python 演示

python50 行
import numpy as npfrom ray import tunefrom ray.tune.schedulers import ASHASchedulerfrom ray.tune.search.optuna import OptunaSearch  def train_linear(config):    rng = np.random.default_rng(0)    n = 200    x = rng.standard_normal((n, 1))    y = 2.5 * x + 0.1 * rng.standard_normal((n, 1))    w = np.zeros((1, 1))    lr = config["lr"]    epochs = int(config["epochs"])    batch = int(config["batch_size"])    for epoch in range(epochs):        idx = rng.choice(n, batch, replace=False)        xb, yb = x[idx], y[idx]        grad = xb.T.dot(xb.dot(w) - yb) * 2.0 / batch        w = w - lr * grad        pred = x.dot(w)        loss = float(np.mean((pred - y) ** 2))        tune.report(loss=loss)    return {"loss": loss}  search_space = {    "lr": tune.loguniform(1e-3, 1e-1),    "batch_size": tune.choice([8, 16, 32]),    "epochs": tune.randint(10, 50),} scheduler = ASHAScheduler(max_t=50, grace_period=5)search_alg = OptunaSearch(metric="loss", mode="min") tuner = tune.Tuner(    train_linear,    param_space=search_space,    tune_config=tune.TuneConfig(        num_samples=40,        scheduler=scheduler,        search_alg=search_alg,    ),    run_config=tune.RunConfig(verbose=1),) results = tuner.fit()best = results.get_best_result(metric="loss", mode="min")print("best loss:", best.metrics["loss"])print("best config:", best.config)
目的：用 Ray Tune 对一个最小线性回归任务做分布式调参，演示 ASHA 早停 + Optuna 搜索 + Tuner 编排的完整流程。
  1. rng = np.random.default_rng(0)固定随机种子，让每次实验可复现。
  2. grad = xb.T.dot(xb.dot(w) - yb) * 2.0 / batch算出小批量上的梯度方向，学习率沿着它更新权重。
  3. tune.report(loss=loss)每个 epoch 上报中期分数，ASHA 靠它做早停。
  4. "lr": tune.loguniform(1e-3, 1e-1)对数均匀采样，跨数量级搜索时更公平。
  5. scheduler = ASHAScheduler(max_t=50, grace_period=5)品鉴官参数：上限 50 轮，前 5 轮不淘汰。
  6. search_alg = OptunaSearch(metric="loss", mode="min")请军师用 TPE 采样，优化目标是最小化 loss。
  7. num_samples=40总共做 40 道试验菜。
  8. results = tuner.fit()总调度台开火，Tune 自动分发全部试验。
  9. best = results.get_best_result(metric="loss", mode="min")端出全场得分最低（最优）的那道菜。

常见误区

误区只要把搜索空间定义好，Ray Tune 就会自动帮我改模型层数、激活函数，甚至把代码写好。我只管把数据传进去等结果。

正解Tune 只负责调度“你写的训练函数”，给它不同的 config。config 里的超参数要想生效，必须在 train 函数里手动读取并使用它们，比如 layers = config["layers"] 再用它搭网络。它像总厨的调度台：调度台只负责分灶台和记分数，怎么做菜还是每位厨师自己的事。

为何常见：很多人把 Tune 和神经架构搜索（NAS）混淆，加上“自动调参”的宣传，让人误以为连代码都能自动生成。

误区用了 ASHA 之后，每个试验的训练时间应该变短，因为“早停”不就是提前结束吗？

正解ASHA 不会缩短单个试验的时长，它是在中途终止劣质试验，让总预算花在更少的试验上。单个试验该跑多少 epoch 还是多少，甚至活下来的试验会获得更多预算。它更像品鉴官提前撤掉难吃的菜，而不是让每道菜熟得更快。

为何常见：“早停”两个字容易让人联想到“提前结束 = 更快”，实际上省的是整体吞吐，不是单点速度。

误区反正有分布式集群，把每个超参数的取值范围都拉大一点、维度多加几个，总能找到更优的配置。

正解空间越大，单位预算内的采样密度越低；ASHA 的中位线淘汰在半程更可能误杀“慢热”的好配置；搜索算法也要花更多样本才能聚焦。秘诀是先用小空间跑通流程，再逐步扩展——先开小灶验证口味，再放开菜单。

为何常见：想着“广撒网”有安全感，忽略了采样效率与早停机制对空间大小非常敏感。

误区我开 8 个终端各跑一组参数，也是并行调参，为什么非要引入 Ray Tune？

正解手工并行没有统一调度：谁先跑完无法自动感知、没有早停、没有采样策略、结果难以汇总，机器利用率也低。Ray Tune 的价值在于“调度”而不是“并行”：自动填坑、聪明淘汰、日志统一。它像后厨的总调度系统，而手工脚本只是把几个厨师塞进一个厨房各自为战。

为何常见：并行与分布式常常被混为一谈，看到“多进程”就以为等价于“集群调度”。

面试题

Q1. Ray Tune 中被调度和执行的最小任务单元是什么？

单选题 · easy

  • A.工作单元 Worker
  • B.调参试验 Trial← 正确答案
  • C.检查档位 Rung
  • D.集群机器 Node

答案：B。Trial 是 Ray Tune 中被调度和计数的单位，相当于“一张待试的配方卡”。Worker 是执行者，Rung 是 ASHA 的检查档，Node 是集群节点，都不是调参任务本身的最小单元。

Q2. 以下哪个是 ASHA 的核心思想？

单选题 · easy

  • A.全部训练完再比较平均
  • B.中期分数低就提前淘汰← 正确答案
  • C.随机更换超参数再训练
  • D.复制最优权重共享进度

答案：B。ASHA 的核心是“中期试菜，不行的撤桌”。全部训练完再比较是串行网格搜索的做法；随机换参是 PBT/随机搜索的思路；复制最优权重是 PBT 的做法。

Q3. 在 ASHA 中，一个试验到达检查档后，由它的分数与什么比较来决定是否停止？

单选题 · mid

  • A.与初始的分数比较
  • B.与历史最高分比较
  • C.与档位中位数比较← 正确答案
  • D.与集群平均分比较

答案：C。ASHA 用该档已完成试验分数的中位数作为淘汰线——好比品鉴官先看看这一桌菜的平均水平，明显低于平均线的撤掉。与初始分、历史最高分、集群利用率都无关。

Q4. 关于 PBT 的“利用-探索”机制，下列说法正确的是？

多选题 · mid

  • A.利用步骤复制最优权重参数← 正确答案
  • B.探索步骤加入随机小扰动← 正确答案
  • C.探索时从零开始重新训练
  • D.继承权重后无需从头训练← 正确答案

答案：ABD。PBT 的利用步骤是复刻最优成员的权重与超参数（A 对），探索步骤是加随机扰动避免同质化（B 对），继承权重后无需从头训练（D 对）。C 错在探索是在已继承状态上微调，不是从零开始。

Q5. 在 Ray Tune 中集成 Optuna，主要是为了获得什么能力？

单选题 · mid

  • A.更强的分布式通信能力
  • B.更聪明的候选采样策略← 正确答案
  • C.更快的单次模型训练
  • D.自动搭建网络结构搜索

答案：B。Optuna 的 TPE 用好坏样本密度之比推荐采样点，属于“采样策略”。它不负责分布式通信（那是 Ray 的活）、不加速单次训练、也不做架构搜索。

Q6. tune.loguniform(1e-4, 1e-1) 表示什么？

单选题 · easy

  • A.区间内线性均匀采样
  • B.对数尺度上均匀采样← 正确答案
  • C.只在区间端点处采样
  • D.以端点均值做高斯采样

答案：B。学习率常跨数量级取值（1e-4 到 1e-1 差了三个数量级），普通均匀采样会让小值区间几乎抽不到点。loguniform 表示对数尺度均匀，等价于 log lr 服从均匀分布。

Q7. 影响 Ray Tune 分布式调参加速比的因素有哪些？

多选题 · hard

  • A.并行执行的试验数量← 正确答案
  • B.集群调度的通信开销← 正确答案
  • C.早停淘汰劣质试验比例← 正确答案
  • D.验证集数据量的绝对大小

答案：ABC。加速比取决于并行度（A）、调度与通信 overhead（B）、早停淘汰比例（C）。验证集数据量只影响单次试验的绝对时长，不影响加速比本身。

Q8. ASHA 相比标准 Successive Halving 的关键改进是什么？

单选题 · mid

  • A.每次淘汰比例翻一倍多
  • B.异步评估无需同步等待← 正确答案
  • C.用贝叶斯代理模型选点
  • D.支持多个试验共享权重

答案：B。ASHA 与 Successive Halving 的核心区别在于异步：收到谁的报告就裁决谁，不用等一整批同时跑完。它不改变淘汰比例、不用代理模型、也不共享权重。

Q9. 下列关于 Ray Tune 各组件职责的说法正确的是？

多选题 · mid

  • A.调度器负责早停与资源分配← 正确答案
  • B.搜索算法负责生成候选配置← 正确答案
  • C.Tuner 负责编排整个调参流程← 正确答案
  • D.搜索算法和调度器互不兼容

答案：ABC。Tuner 是总调度台；Scheduler 管早停与资源分配；Search Algorithm 出候选配置；三者可以自由组合（例如 Optuna + ASHA），D 错在“互不兼容”。

Q10. PBT 中一个成员被替换为最优成员的配置后，若想保持种群多样性，下一步应该做什么？

单选题 · hard

  • A.对超参数做一次随机扰动← 正确答案
  • B.从初始权重重新开始训练
  • C.让该成员立刻退出淘汰
  • D.把批次大小固定为最大值

答案：A。替换成最优配置后，若大家一模一样就失去了探索空间，所以要加随机扰动（explore）。不需要从头训练（权重已被继承），也与此成员是否淘汰、批次大小无关。