Optuna发布 4.0 重大更新：多目标TPESampler自动化超参数优化速率提升明显

发表于 2026-10-5 19:17:37

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

×

Optuna 是机器学习领域常用的超参数优化框架，自 2018 年首次发布以来已经成长为这个方向的标配工具之一。4.0 版本带来了一批实质性更新：官方功能共享平台 OptunaHub、面向生成式 AI 产物的 ArtifactStore、支持 NFS 的 JournalStorage、引入新 Terminator 算法，以及多目标 TPESampler 的大幅加速。本文按运维和算法工程师实际用得上的角度，把这些变更拆开讲。

一、Optuna 目前的体量

从社区里程碑看：

GitHub star 数超过 1 万
月下载量 300 万+
16,000+ 代码库在使用
论文引用 5,000+ 次
Kaggle 上的 code 使用 18,000+

这个量级说明它已经不是实验性项目，生产环境引入的成本风险相对较低。

二、OptunaHub：把算法共享出来

OptunaHub（hub.optuna.org）是官方的功能共享平台，4.0 正式发布。它解决的问题很实际：采样器、可视化算法这类东西，学术界和工程界各自造了很多轮子，散落在各个论文仓库里，用起来还得自己搬。Hub 的做法是让开发者注册并分享自己的算法，其他人直接调用。

对团队来说，价值在于内部定制的采样器可以放上去复用，不必每次新起一个 study 就从零搬代码。

三、ArtifactStore：管住训练过程产生的文件

生成式 AI 起来之后，优化过程中产出的不只是标量指标，还有文本、图像、音频、模型快照这些大文件。ArtifactStore 就是为这些设计的。

管理生成式 AI 输出的文本、图像、音频文件
管理深度学习模型的大型快照文件
这些文件通过 Optuna Dashboard 就能查看

4.0 稳定了文件上传 API，并新增了 artifact 下载 API；Dashboard 这边新增了对 JSONL 和 CSV 文件的支持。以前这类文件要么随手扔本地磁盘，要么自己搭个对象存储，现在能挂进优化流程里统一管理，回溯某次 trial 用了哪个模型权重方便很多。

四、JournalStorage：用日志文件做分布式

JournalStorage 是基于操作日志的新型存储后端，最大的好处是自定义存储后端实现起来简单。其中 JournalFileBackend 支持多种文件系统，包含 NFS，可以直接做跨节点的分布式优化。

这对没法搭传统数据库服务器的环境特别实用——很多公司内部既不给开 MySQL 权限，也不想为跑实验再部署一套数据库，共享一个 NFS 上的日志文件就够用了。

用法很直接：

import optuna
from optuna.storages import JournalStorage
from optuna.storages.journal import JournalFileBackend

def objective(trial: optuna.Trial) -> float:
    ...

storage = JournalStorage(JournalFileBackend("./journal.log"))
study = optuna.create_study(storage=storage)
study.optimize(objective)

五、新 Terminator 算法：别把优化跑过拟合

超参数调优有个肉眼很难发现的问题：搜索太多次之后，模型是在「背」验证集，而不是真的变好，这就是超参数过拟合。Terminator 就是为了在过拟合发生之前终止搜索，或者帮用户可视化出过拟合从哪一轮开始明显。

4.0 引入了预期最小模型遗憾（EMMR）算法来支撑更广泛的用例。实际意义是：在算力有上限的情况下，能更早收手，把资源留给真正还有提升空间的任务。

六、约束优化增强了

study.best_trial 和 study.best_trials 现在保证满足约束条件——以前可能返回一个其实不满足约束的"最优"trial，这点很坑。
TPESampler、NSGAIISampler 这类主流算法对约束优化的支持有改进。

如果你做调参时有「x 必须大于 y」「这个参数只能在某几个档位里选」这类硬约束，这次升级的体感会比较明显。

七、焦点：多目标 TPESampler 提速

多目标优化的必要性不用多说——翻译任务既要看质量又要看延迟，推理任务既要精度又要显存，这类权衡问题单目标优化是没法直接解的。

TPESampler（Tree-structured Pareto Estimation Sampler）是多目标场景里表现不错的采样器，相比默认的 NSGAIISampler 有几个优势：

样本效率更高，尤其在 1000–10000 次试验这个量级
能处理动态搜索空间
支持用户自定义类别距离

7.1 4.0 的性能提升

三目标优化场景下，200 次试验的运行时间提升约 300 倍
能高效处理数千次试验的多目标优化

提速来自三处算法层面的优化：WFG（加权超体积增益）计算、非支配排序、HSSP（超体积子集选择问题）。

7.2 它到底怎么工作的

TPE 的思路可以拆成三步：

把已经跑过的 trial 分成非支配解和支配解两组。
为每个参数分别基于这两组构建两套概率分布。
用这两套分布引导下一轮试验点的选择，倾向挑出更可能产生非支配解的参数取值。

这样做的好处是天然在探索（找新区域）和利用（在已知好区域深耕）之间做了平衡，不用额外调参数去配这两个权重。

7.3 一个最小示例

import optuna

def objective(trial):
    x = trial.suggest_float("x", -5, 5)
    y = trial.suggest_float("y", -5, 5)
    objective_1 = x**2 + y**2
    objective_2 = (x - 2)**2 + (y - 2)**2
    return objective_1, objective_2

sampler = optuna.samplers.TPESampler()
study = optuna.create_study(sampler=sampler, directions=["minimize", "minimize"])
study.optimize(objective, n_trials=100)

7.4 TPESampler 还是 NSGAIISampler

NSGAIISampler 是默认的多目标采样器，但在这些情况下 TPESampler 往往更合适：

大规模优化：1000–10000 次试验区间，TPESampler 通常更好
复杂搜索空间：有条件参数、动态搜索空间的问题，TPESampler 更灵活
高维参数空间：TPESampler 处理起来一般更有效

最终还是建议两种都跑一遍，在你自己的问题和算力条件下比一下再定，别照搬别人的结论。

八、升级前建议检查什么

如果项目里用了自建的存储后端，先确认 JournalStorage 覆盖得到——4.0 对这个做了简化，但老后端可能要改。
用到了 study.best_trial 的地方，留意约束满足行为的变化，行为变了但代码没改会静默产出不同结果。
依赖 optuna-dashboard 的话，确认 dashboard 版本和 4.0 兼容。
多目标且试验次数上 thousand 级的任务，值得专门测一下升级后的吞吐，提速幅度取决于目标数和试验规模。

整体看，4.0 里对生产最有用的是 JournalStorage + NFS 和 ArtifactStore 这两个组合起来做的「实验资产管理」，对调参效率最有用的是多目标 TPESampler 的提速。前者解决跑完没人管的问题，后者解决跑得太慢的问题。

qidao123.com企服评测-应用市场编辑提示