Neptune.ai
Neptune.ai 是面向 ML 团队的实验跟踪与模型元数据管理平台，提供实验对比、模型注册、监控看板与团队协作能力，支持主流 ML 框架。
Neptune.ai
核心参数与统计
Neptune.ai 定位为"为基座模型训练打造的最可扩展的实验跟踪器"（the most scalable experiment tracker built specifically for monitoring and debugging foundation model training），核心解决大模型训练场景下"实验指标散落在分布式节点、无法系统对比与复现"的问题。2025 年 12 月被 OpenAI 收购后，SaaS 服务将于 2026 年 3 月 5 日正式关停，当前仅对存量客户开放，不再接受新注册。
| 项目 | 公开信息 |
|---|---|
| 官方定位 | 最可扩展的实验跟踪器，专为基座模型训练监测与调试设计 |
| 部署方式 | 云端 SaaS（已关停）、自托管（私有云，已停止新部署） |
| 服务状态 | 2025-12-03 被 OpenAI 收购，2026-03-05 关停 |
| 支持框架 | PyTorch, TensorFlow, JAX, scikit-learn, XGBoost, LightGBM |
| 集成管道 | Airflow, Kubeflow, Prefect, MLflow, ZenML, Comet |
| 数据形态 | 指标、超参数、代码快照、模型权重、数据集版本、直方图、文件序列JSON |
| Python 客户端 | neptune-scale（日志记录）、neptune-query（数据查询） |
| Python 版本要求 | 3.10+ |
| 归属地 | 波兰（PL） |
| 支持平台 | Web, API |
| 支持语言 | 英文 |
与 MLflow / W&B 的定位差异：MLflow 是开源轻量实验跟踪，Weights & Biases 侧重交互式可视化与协作，Neptune 则在分布式训练的规模可扩展性、指标聚合与团队协作上更重，尤其适合训练千卡级基座模型的场景。OpenAI 收购 Neptune 的核心意图正是将其深度整合到自身的训练基础设施栈中，以获得对模型学习过程更细粒度的可见性。
产品生命周期状态：Neptune 已进入有序关停阶段。存量客户需在 2026 年 3 月 5 日前完成数据导出，官方提供了 Neptune Exporter 工具及面向 GoodSeed、W&B、Comet、Lightning AI、ZenML、Minfx.ai、Pluto 等多平台的迁移指南。
用户与市场认可
Neptune 的市场认可集中体现在其被 OpenAI 全资收购这一事件本身——这是实验跟踪赛道迄今为止最具标志性的退出案例，直接印证了其技术栈在大型模型训练场景下的工程价值。
被 OpenAI 收购：2025 年 12 月 3 日，OpenAI 官方宣布与 Neptune 签署最终收购协议。OpenAI 首席科学家 Jakub Pachocki 公开表示："Neptune 构建了一个快速、精确的系统，使研究人员能够分析复杂的训练工作流。我们计划与他们迭代，将他们的工具深度集成到我们的训练栈中，以扩展我们对模型学习过程的可见性。"这一公开背书直接说明了 Neptune 在千卡级分布式训练观测领域的技术壁垒。
社区与开源生态：Neptune 的日志客户端（neptune-scale）与查询客户端（neptune-query）均在 GitHub 上公开维护，在其活跃期积累了稳定的贡献者与集成生态。文档站显示其 App 版本号持续迭代至 3.20251215，SDK 发布频率在 2025 年下半年达到月均 2-3 个版本，反映了产品团队的工程投入密度。
客户结构：虽然具体客户名单与营收数据未公开，但从其功能定位（基座模型训练监测）和 OpenAI 的收购意图可以推断，其核心用户主要是从事大规模模型训练的研究机构、大型科技公司的 AI 实验室以及前沿 AGI 创业团队。产品设计中对分布式有境、千级实验并排对比、多进程并发日志的原生支持，进一步印证了这一客群画像。
成本优势
Neptune 的成本结构在其被收购前已形成"免费入门 + 团队订阅 + 企业私有化"的三层体系，但关停后已不再具有实际采购意义。
免费方案（历史）：Free 方案包含有限的项目数与成员数，适合个人实验跟踪入门，但存储量与并发日志通道受限。该方案已随服务关停而终止。
团队方案（历史）：Team 方案以席位 + 存储量计费，按年付有折扣；API 调用不额外计费。具体价格档位未在公开页面稳定呈现，以官方实时页面为准。
企业/私有化方案（历史）：Enterprise 方案提供自托管SSO、审计日志与定制存储配额。自托管客户在收购后由其客户经理单独对接协调迁移路径，Helm 仓库与容器镜像仓库已于 2026 年 3 月 8 日删除。
隐性成本（对历史用户的参考意义）：对实验跟踪平台而言，订阅费往往不是最大头，真正影响总成本的是三个维度：第一，存量实验数据的迁移成本——Neptune Exporter 可导出元数据，但模型权重文件、图表配置和看板布局的迁移仍需人工校验，文档中亦专门提供了"加速导出性能"的最佳实践指南；第二，团队学习成本——从 Neptune 迁移到替代平台（W&B、Comet、MLflow 等）需要调整日志 API 调用和查询脚本；第三，历史实验的可复现性——若代码快照与数据集版本完全依赖 Neptune 的元数据关联，关停后这些关联将一并失效。
Neptune.ai 的主要功能
Neptune 的能力围绕"将分布式训练的可观测性集中到一个平台"设计，公开能力可归纳为六个模块：
- 分布式实验跟踪：通过
neptune-scaleSDK 从多个独立进程中并发日志，支持超参数、指标、代码版本与硬件利用率的自动记录。Run对象支持创建、恢复、分支（fork）和继承，分支时可选择继承配置与预分支指标值。 - 大规模指标可视化：Web App 提供可自定义的图表组件，支持千级实验的面叠加、误差带（error band）高亮、离群点标识EMA 平滑、对数坐标轴以及对 NaN/Infinity 值的渲染。图表可切换浮动图例与底部吸附图例，支持截图模式。
- 并排对比与差异高亮：Side-by-side 视图以表格格式对比大量实验的配置、评分和其他值，对长字符串提供悬停完整展示，仅显示差异行以减少信息过载。
- 模型注册与元数据管理：集中管理模型版本、元数据与审批状态，与实验跟踪数据双向互联。支持在 Run 的属性命名空间下记录嵌套字典JSON 文件、文件序列、图片、音频和视频。
- 自定义仪表板与报告：拖拽式构建监控看板，支持动态分区（dynamic sections）和自定义代码组件（custom code widget），可直接在报告内嵌入可交互 Python 代码。报告发布后生成不可覆盖的版本化快照。
- 团队协作与权限治理：基于工作区和项目的两级 RBAC，支持角色只读/读写/管理员粒度。仪表板、图表和报告可通过持久链接实时共享，支持服务账号（service account）实现机器间共享凭证。
专家视点：Neptune 最独特的协同效应在于"分布式日志 + 元数据继承"——在千卡训练场景下，单个实验可能跨数十个进程，Neptune 允许从多个进程向同一个 Run 并发写指标，同时支持从父 Run 分支出新 Run 时继承配置与历史指标。这意味着研究者可以在一组基线实验的基础上迅速衍生变体实验，而无需重复记录公共参数。这种 "fork-and-inherit" 模式直接复用了代码工程中的分支思维，在减少重复日志数据量的同时保持了实验脉络的可追溯性。
Neptune.ai 的版本演进
Neptune 在产品生命周期内经历了从初创验证到被收购关停的完整阶段。以下按时间线梳理关键节点：
早期阶段：实验跟踪 v1.x（~2022–2024）
Neptune 最初以轻量实验跟踪工具切入市场，提供 Python SDK 和基础 Web 面板。此阶段的官方版本号体系不对外公开，产品迭代以功能发布为主。
规模化阶段：v3.x + 双 API 体系（2025）
2025 年是 Neptune 功能密度提升最显著的时期，SDK 发布频率达到月均 2–3 个版本：
- 2025-05：App 3.4.11，引入文件序列日志（log_files），支持系列直方图EMA 平滑算法、控制台日志从
system迁移至runtime命名空间。 - 2025-06：App 3.4.12，引入直方图序列、分支实验的前馈步骤支持；App 3.4.13，引入文件序列组件、浮动图例API Cheat Sheet。
- 2025-07：客户端 0.17.0 支持 GCS 文件上传；0.18.0 支持嵌套字典日志；App 3.4.14 增强图表平滑与浮点图例交互。
- 2025-08：App 3.5 引入首页（homepage）、实验性图表缩放功能、自定义误差带；客户端 0.21.0 重构 Run 构造函数；neptune-query 1.0+ 正式取代 Fetcher API。
- 2025-09 至 2025-10：App 3.20250908+ 引入 CVD 友好色板JSON 文件查看、动态看板分区、自定义代码组件；Query API 持续增强（fetch_metric_buckets、文件下载NaN/Inf 查询）。
- 2025-11：App 3.20251103.3 引入动态看板分区与自定义代码组件正式版。
关停阶段：收购与有序退出（2025-12 至 2026-03）
- 2025-12-03：OpenAI 宣布收购 Neptune，同日发布 Transition Hub 与 Neptune Exporter 数据导出工具。
- 2025-12 至 2026-02：连续发布面向 GoodSeed、W&B、Comet、Lightning AI、ZenML、Minfx.ai、Pluto 的迁移指南；App 和 SDK 仍持续发布维护版本（3.20251215.1、neptune-query 1.11.0）。
- 2026-03-05：Neptune SaaS 服务正式关停，所有残留数据删除且不可恢复。
- 2026-03-08：自托管客户 Helm 仓库与容器镜像仓库删除。
| 里程碑 | 日期 | 事件 |
|---|---|---|
| v1.0 发布 | ~2022-03 | 暂无官方精确日期 |
| v3.x 主线迭代 | 2025-05 至 2025-11 | 月均 2–3 个 SDK 版本，功能密集发布 |
| 被 OpenAI 收购 | 2025-12-03 | 公开签署最终收购协议 |
| SaaS 服务关停 | 2026-03-05 | 所有数据删除且不可恢复 |
| 仓库清理 | 2026-03-08 | Helm 仓库与容器镜像仓库删除 |
Neptune.ai 的技术优势
Neptune 的技术优势不在"功能最多"，而在于"为分布式大模型训练场景提供了其他实验跟踪工具难以替代的观测深度"。其核心机制可拆解为三点：
面向分布式训练的并发日志架构：Neptune 的日志客户端（neptune-scale）原生支持从多个独立进程同时向同一个 Run 写入指标。在千卡训练场景中，每个 GPU 节点可以独立调用 run.log_metrics()，由客户端异步批量合并后写入后端。这种架构的工程价值在于：研究者不需要手动聚合各节点的指标，也不需要部署独立的日志聚合中间件，Neptune 客户端天然承担了"分布式 metrics aggregator"的角色。对比之下，MLflow 的自动日志更适用于单机实验，Weights & Biases 的并发写行为在数千级进程时可能出现冲突或瓶颈。
"Fork-and-Inherit" 实验分支机制：Neptune 允许从现有 Run 分支（fork）出新的实验，子 Run 可选择继承父 Run 的配置和预分支历史指标。这一机制的深层价值不仅在于减少重复日志数据，更在于它天然建立了实验之间的"演化树"，研究者可以直观追溯"这个变体从哪个基线实验演化而来、参数做了哪些调整"。文档中披露了专门处理分支冲突的 NeptuneRunConflicting 错误——当分支时出现继承冲突，系统以降级为 warning 而非阻断流程，体现了对大规模实验容错性的考量。
查询 API 与正则筛选能力：neptune-query 提供了基于扩展正则表达式（extended regex）的实验筛选语法，支持 AND、NOT 和分组运算符，可以在数千个实验中快速定位符合条件的目标。fetch_experiments_table_global() 和 fetch_runs_table_global() 函数进一步支持跨项目、跨工作区的全局搜索。这一能力在实验数量膨胀到难以手工浏览的阶段尤为关键——它使得"程序化实验分析"（programmatic experiment analysis）成为可能，研究者可以编写分析脚本自动筛选出满足特定条件的历史实验进行聚合对比。
技术架构的代价：这套架构的隐性成本在于——客户端依赖异步批量上传，在网络不稳定或后端延迟时可能出现数据丢失（文档中专门提到"如果单个数据点日志失败，同步过程不会停止"）；此外，Python 要求"main guard"（if __name__ == "__main__"）的标准实践，在 Jupyter Notebook 等交互式有境中容易被忽视，导致进程创建异常。
如何使用 Neptune.ai
重要提示：Neptune 服务已于 2026 年 3 月 5 日关停，以下内容仅适用于关停前的存量用户参考。新用户无法注册或使用。
存量用户数据导出
对于需要在关停前完成数据迁移的存量客户，Neptune 提供了三层工具链：
- Neptune Exporter：官方导出的命令行工具，支持按项目、按时间范围或按实验名称筛选导出。导出内容包括指标序列、配置参数、代码快照、模型权重元数据及看板/报告配置。
- 迁移目标平台向导：文档站 Transition Hub 提供了面向 GoodSeed、W&B、Comet、Lightning AI、ZenML、Minfx.ai、Pluto 的逐步骤迁移指南，包括数据格式转换建议与 API 映射对照。
- 加速导出最佳实践：文档明确建议通过限制属性范围、排除不需要的命名空间、使用并行导出任务等方式提升导出性能，避免在关停前最后时刻集中操作。
集成方式（历史参考）
Neptune 的典型集成链路如下：
训练脚本 → neptune-scale SDK → Neptune SaaS/自托管后端 → Web App
↓
neptune-query SDK → 程序化分析Python 集成核心代码模式：
from neptune_scale import Run
run = Run(
experiment_name="experiment-001",
)
run.log_configs({
"parameters/learning_rate": 0.001,
"parameters/batch_size": 64,
})
run.log_metrics(
data={
"metrics/accuracy": acc,
"metrics/loss": loss,
},
step=1,
)
run.close()查询导出示例：
import neptune_query as nq
# 列出匹配正则的实验
nq.list_experiments(experiments=r"regex_pattern")
# 获取指定实验的配置与指标
nq.fetch_experiments_table(
project="workspace/project",
experiments=r"exp_name_regex",
attributes=r"config | loss",
)Neptune.ai 的产品定价
Neptune 的定价体系在收购后已失去实际参考意义。以下基于历史公开信息整理，供已采购用户了解过往费用结构：
C 端/个人（历史）：Free 方案包含有限的项目数与成员数，适用于个人实验跟踪入门。存储量与并发日志通道受限，关停后不可用。
开发者/团队（历史）：Team 方案按席位 + 存储量计费，按年付有折扣；API 调用不额外计费。关停后已不可用，存量用户按合同条款处理退款或服务终止。
企业/私有化（历史）：Enterprise 方案提供自托管SSO、审计日志与定制存储配额，需商务确认价格。自托管客户在收购后由客户经理协调迁移路径。
关停后的财务处理：根据 Transition Hub FAQ，关停期间（2025-12-03 至 2026-03-05）的账单与续费按合同条款处理，用户可下载历史发票和收据。SaaS 数据在关停后将被删除且不可恢复，用户在关停前需确保完成数据导出。
Neptune.ai 的应用场景
Neptune 的典型应用场景集中在需要大规模分布式训练观测的领域，以下为最具代表性的三类：
- 基座模型预训练监测：在千卡级分布式训练有境中，Neptune 充当"训练控制台"角色，聚合各节点的 loss、learning rate、梯度范数等实时指标，通过自定义仪表板监控训练稳定性。核验重点是：客户端在高并发下的日志写入成功率、看板渲染延迟，以及异常指标（NaN、梯度爆炸）的报警响应速度。
- 超参数搜索与实验对比：研究团队在大规模超参数网格搜索（grid search）或贝叶斯优化实验中，利用 Neptune 的 Side-by-side 视图和正则筛选能力，快速定位最优参数组合。核验重点是：筛选查询的响应时间、实验分支后的继承完整性，以及图表叠加时的渲染性能。
- 模型版本管理与审计追踪：在合规要求较高的场景（如医疗、金融 AI），Neptune 的模型注册表与自动代码快照构成了"实验→模型→部署"的可审计链路。核验重点是：模型审批状态流转的灵活性、代码快照与实验的关联完整性，以及 RBAC 权限隔离的细粒度。
适用人群
Neptune 在其生命周期中主要服务于三类角色：
- 大模型研究员：需要系统化记录与对比分布式训练实验，对指标聚合的规模（千级实验、百万级数据点）有刚性需求。Neptune 的并发日志架构和正则筛选能力直接对应此类需求。
- MLOps 工程团队：需要将实验跟踪纳入生产管道，将与 Airflow/Kubeflow 的集成深度作为关键评估维度。Neptune 的管道路由与中间指标监控能力使工程团队能在大规模训练中保持可观测性。
- AI 研究团队管理者：需要跨项目、跨成员的统一实验管理视图，看重权限治理、审计日志与报告分享能力。
不适配边界：Neptune 不适合以下场景——第一，单人快速实验或小型项目（Excel 或本地日志足够）；第二，希望实验跟踪完全开源、不依赖外部 SaaS 的团队（虽然提供自托管，但关停后已不可用）；第三，需要强合规数据驻留且有长期稳定服务保障的生产有境（服务关停不可逆）。对于这些场景，迁移到 W&B、MLflow 或 Comet 是更合适的选择。
总结与展望
Neptune.ai 的核心价值在于它证明了"为分布式大模型训练提供专用实验跟踪基础设施"这一需求的真实存在，并以被 OpenAI 收购的方式验证了其技术路线的工程壁垒。它不是功能最全的实验跟踪工具，但在并发日志架构Fork-and-Inherit 实验分支、正则筛选等维度上，为大规模训练场景提供了当时其他工具难以替代的观测深度。
当前限制与风险：Neptune 已进入终局——SaaS 服务全面关停、数据不可恢复、自托管仓库已清理。对于历史用户，最大风险是未能在关停前完成完整数据导出，导致实验记录、模型元数据与看板配置的永久丢失。即便完成了导出，从 Neptune 的元数据格式向替代平台（W&B、MLflow、Comet 等）的映射仍需要人工校验，特别是图表配置、看板布局和代码快照的关联关系可能无法完美迁移。
对行业的历史意义：OpenAI 收购 Neptune 的案例为实验跟踪赛道设定了"天花板"——当你的实验跟踪工具足够深入到大模型训练的核心工作流，它就有机会成为基础设施层的一部分而被战略收购。这一信号对 W&B、Comet、MLflow 等竞品同样具有参考价值。
对潜在采购者的启示：虽然 Neptune 已不可用，但其产品周期提供了两个决策参考：第一，对于需要大规模训练观测的团队，评估替代平台时应优先检查其并发日志架构的规模上限（能同时支持多少进程写入、数据聚合延迟多少秒）；第二，实验跟踪平台的数据迁移成本不可忽视，优先选择具有标准数据导出格式和活跃迁移生态的平台，避免被单一供应商锁定。
限制与不适配场景
该工具在以下场景中存在使用限制：
场景适配边界 需要高度行业专业知识的任务、对输出格式有严格规范的场景、需要零错误的自动化流程可能效果不达预期。AI 输出应作为初稿或辅助参考，最终结果需人工核验。
技术限制 上下文长度有限、复杂推理准确性可能不足、免费版有使用额度。建议在正式采用前通过试用验证核心场景的可用性。
版本信息
- Neptune 2026年6月更新 ：持续迭代的 SaaS 平台，暂无固定版本号。
- Neptune 1.0 正式发布 ：暂无官方精确日期。
用户评价