学习ONNX交易 - 页 4

新评论
 

什么是 ONNX 运行时 (ORT)？



什么是 ONNX 运行时 (ORT)？

ONNX Runtime (ORT) 是一个优化和加速机器学习推理的库，允许用户在任何支持的机器学习库中训练他们的模型，导出为 ONNX 格式，并以他们的首选语言执行推理。演讲者强调了一个使用 PyTorch 和 ONNX Runtime 执行推理的示例，并指出用户可以访问 ONNXRuntime.ai 来探索他们首选设置所需的不同 API 和工具。

 

2020 年 ONNX 路线图讨论 #1 20200903



2020 年 ONNX 路线图讨论 #1 20200903

ONNX 路线图文件已向公众开放，是本视频的一个关键主题。讨论涵盖了在机器学习管道上扩展 ONNX，包括演进数据、预处理以及将 ONNX 扩展到 QFLO 等水平管道上。贡献者提出的建议包括支持数据框和采用新的运算符进行预处理。演讲者还讨论了采用 Python 数据 API 标准来扩展 ONNX 的支持并保证其他库之间的互操作性。此外，演讲者还讨论了将 ONNX 集成到 Kubernetes 和 Kubeflow 中以简化用户的 ML 开发。该小组计划继续评估该提案的影响，并欢迎通过路线图或指导委员会提供反馈。

  • 00:00:00 在本节中，演讲者讨论了已向公众投稿的 ONNX 路线图文件，并强调了这些投稿对于实施变更的重要性。发言人提到每周将举行六次路线图讨论，并计划在 10 月 14 日举行一次社区会议。讨论分为三个主要部分，第二部分侧重于在机器学习管道上扩展 ONNX。具体来说，讨论涵盖了数据演进和预处理，以及将 ONNX 扩展到像 QFLO 这样的水平管道上。演讲者还总结了贡献者提出的一些建议，例如支持数据帧和采用新的算子进行预处理。

  • 00:05:00 在本节中，讨论的重点是 ONNX 路线图和各种建议，例如支持音频频谱图处理和扩展数据布局支持。对话还涵盖了 ONNX 对 ML 管道的影响的提议扩展以及在 ONNX 中支持数据帧的潜在好处。参与者表达了他们的意见，一位成员分享了对 Python 数据 API 联盟为数组和数据框架互操作性构建数据 API 标准所做的努力的见解。该小组似乎同意扩大 ONNX 在这些领域的能力是一件好事，并且与更广泛的行业计划保持一致。

  • 00:10:00 在本节中，演讲者讨论了采用 Python 数据 API 标准作为扩展 ONNX 支持并保证同一标准的所有其他库之间的互操作性的一种方式。演讲者表示，采用该标准将使模型交换更容易，并且与更大的联盟协调时间表将更好地让用户使用 ONNX。他们还讨论了 ONNX 与传统数据结构（如数据框）之间的区别，以及其他图书馆采用相同标准的必要性。

  • 00:15:00 可以将 ONNX 集成到 Kuflow 管道中，使最终用户的 ML 开发更容易。 Chen 提到了管道的概念，其中所有组件协同工作以协调端到端的 ML 开发。 Kuflow 将模型和数据内容与基础架构相结合，为最终用户提供无缝体验。 Chen 正在探索如何将 ONNX 集成到该管道中以扩大其用途并使 ML 开发人员更轻松。

  • 00:20:00 在本节中，演讲者讨论了让使用 Kubernetes 和 Kubeflow 的用户更容易将 ONNX 用于其基础设施和环境的想法。目标是开发一个易于访问的 API，以从模型动物园中获取模型并使用 ONNX 创建端到端管道。演讲者展示了一个示例，其中他们使用 ONNX 来描述 Kubeflow 中机器学习过程的推理部分，并概述了开发 ONNX 组件以涵盖更多步骤（包括数据处理和分布式训练）的想法。这个想法是利用 Kubernetes 的强大功能，同时涵盖机器学习过程中的更多步骤。

  • 00:25:00 在本节中，演讲者讨论了扩展 QFlow 以拥有 ONNX 作业以启用分布式训练并添加数据处理和转换以进入模型训练部分。今天，ONNX 运行时本身支持从 PyTorch 训练转换器模型，但 ONNX 模型训练仍有进步空间。演讲者建议从模型动物园中的模型开始，看看数据需要如何为模型进行预处理和转换，但请注意，这不仅仅是在 ONNX 核心项目内部，需要更高级别的框架来定义组件像酷流一样。

  • 00:30:00 在本节中，参与者讨论了为 ONNX 路线图提出的提案，并建议将幻灯片链接到文档。该小组计划在随后的会议中继续评估该提案的影响，并希望在实施上有更多的收尾。他们还欢迎反馈并鼓励用户通过路线图或指导委员会提交。讨论以告别和参加未来会议的邀请结束。
 

2020 年 ONNX 路线图讨论 #2 20200909



2020 年 ONNX 路线图讨论 #2 20200909

在“ONNX 路线图讨论”视频中，演讲者讨论了与 ONNX 路线图相关的各种主题，包括形状推断、运算符定义、参考实现和 ONNX 规范。演讲者建议构建一个通用的形状推理基础设施以改进形状推理优化，减少原始运算符的数量，为每个运算符添加参考实现，以及更好定义的测试用例以确保 ONNX 的正确实现和测试。该小组计划继续在运营商 SIG 内部和 GitHub 讨论板上讨论添加新运营商的问题。

  • 00:00:00 在本节中，演讲者讨论了 ONNX 路线图并涵盖了一些建议的主题，特别是形状推断、偏移定义和 IR，所有这些都在路线图文档中之前提到过，并附有来自不同个人的评论。发言者询问昌明或巴肯是否可以解释他们的建议。 Buchan 讨论了他对形状干扰的反馈以及他过去遇到的问题。他建议构建一个通用的形状影响基础设施，只要 IR 发生变化就会重新编译形状，以确保形状推断优化齐头并进并同时改进优化。演讲者得出结论，这更多地适用于优化，而不是直接适用于形状推断。

  • 00:05:00 了解 ONNX 在形状推断和优化通道方面的当前功能。现有的基础设施已经支持基于已知输入值的形状推断，并可用于推断输出形状。更新模型检查器可能很容易取得成果，但其他更改可能需要更多讨论。该小组讨论这些更改是属于 ONNX 还是属于其他地方。他们还考虑了在连续循环中为每个运算符调用形状推理方法以获得预期结果的想法。最终，现有的基础设施已经允许优化通道和形状推断，但变化和改进可以增强这些能力。

  • 00:10:00 在本节中，演讲者讨论了运算符定义并建议减少原始运算符的数量，因为其他运算符可以与较低级别的运算符组合。他们还讨论了参考实现的主题以及基础设施评估一系列运算符的必要性。当前的参考实现在测试用例生成器中以 Python 实现的形式存在，但其组织方式并不便于评估一系列运算符。演讲者建议在 CI 中添加一些运行时，如 ONNX 运行时，以验证功能子图，可用于验证。

  • 00:15:00 在本节中，演讲者讨论了每个运算符的参考实现的必要性，以确保运行时不会偏离作者的预期。他们建议使用参考实现作为单元测试来验证与运行时的奇偶校验，也可以作为解释器模式来检查互操作性和验证。发言者指出，假设该函数由 ONNX 中存在的原始操作组成，则可以使用 ONNX 运行时来验证该函数。但是，在包含新原始操作的子图中对新操作符使用 ONNX 运行时是不可能的，因为没有其他运行时具有该实现。他们承认创建参考实现需要大量工作，但对每个操作来说都是强制性的。他们还强调了 ONNX 合规性的必要性，以确保运行时不会偏离作者的预期。

  • 00:20:00 在本节中，演讲者讨论了 ONNX 规范中参考实现的使用以及规范中清晰简洁的语言的重要性。虽然一些人提倡使用参考实现来消除规范英文文本中的歧义，但其他人则认为规范应该足够清晰，这样就不需要参考实现了。演讲者还讨论了严格合规性测试的重要性，以确保测试所有可能的极端情况。最终，共识似乎是虽然参考实现可能有用，但 ONNX 规范中不应要求它们。

  • 00:25:00 在本节中，讨论了在 ONNX 中实施操作员的要求，特别是关于参考实施和测试程序的需要。虽然有人认为运算符的参考实现对于生成测试数据是强制性的，但其他人不同意，认为提供 Python 函数来生成测试数据或提供固定数据集就足够了。但是，需要注意的是，拥有参考实现对于在运行时中实现运算符以正确测试其实现的人来说至关重要，尤其是对于具有许多不同属性的复杂运算符。讨论还阐明，虽然 ONNX 的参考运行时不是必需的，但每个运算符的参考实现是必需的。

  • 00:30:00 在视频的这一部分，演讲者讨论了拥有参考实施和更好定义的测试用例以确保正确实施和测试 ONNX 的重要性。他们指出，仅依靠生成的测试数据可能是不够的，并且提供简单的代码可以解决每个人的问题。谈话还谈到了对完整规范的需求以及运行时在未定义行为情况下确定要做什么的自由。一些发言者表示担心通过添加参考实现来增加那些提议运营商的负担。他们建议尽量减少工程工作量，并重新审视当前向系统添加操作的要求。

  • 00:35:00 在视频的这一部分，演讲者讨论了拥有完整且明确的 ONNX 规范的重要性以及执行规范的方法。他们同意 Python 中的参考实现将有助于确保在运行时中实现运算符的人员可以验证所有测试用例。然而，他们也承认实施规范并不简单，仍有一些问题需要解决。他们讨论了阐明如何使用规范的方法，并建议实践和反馈应该指导新运算符的提议，而不是提出一个运算符然后在运行时实现它。他们还指出，添加新操作的一个要求是它应该在一个众所周知的框架中实现。

  • 00:40:00 在 ONNX 路线图讨论的这一部分，该小组讨论了将新运营商添加到 ONNX 规范的过程。提案是更改添加新运算符的策略，这已经需要 Python 中的参考实现。他们的讨论围绕参考实现和合规性测试展开，他们计划在运营商 SIG 和 GitHub 讨论板上继续进行对话。该小组计划在下周举行的下次会议上继续讨论。
 

2020 ONNX 路线图讨论 #3 20200916



2020 ONNX 路线图讨论 #3 20200916

本视频中的讨论围绕与 ONNX 相关的各种主题展开，包括改进错误处理、添加预定义的元数据模式字段以表示模型的创建、量化物理优化的需要以及将 ONNX 模型从 Model Zoo 更新到的可能性最新版本。该团队计划根据这些主题的影响和成本确定这些主题的优先级，并在 1.8 版本发布后对其进行处理。此外，该小组考虑为 ONNX 工具集创建不同语言绑定的想法，特别是对 Java 感兴趣，以支持不同的平台，例如 Spark。演讲者还讨论了围绕 ONNX 运行时创建 Java 包装器的可能性。

  • 00:00:00 在本节中，演讲者建议与社区讨论三个主题：错误处理、增强模型动物园以及实施更多操作或运算符以进行量化。他们计划利用接下来的三个会议来讨论这些主题的成本和影响，并根据影响最大和成本最低的项目确定优先级。他们还解决了有关这些主题对 1.8 版的影响的问题，并解释说这些更改中的大部分将在 1.8 之后进行。一位社区成员建议改进错误处理，以便如果运行时遇到格式错误的 protobufs，它不会终止，而是返回错误代码或抛出异常，以确保更好的用户体验。

  • 00:05:00 在本节中，讨论的重点是改进 ONNX 中加载代码的错误处理，以防止崩溃并改进功能。该团队对代码进行了模糊测试，发现不受信任的模型有可能破坏整个过程，因此将其列为首要任务。 ONNX 运行时与 ONNX 检查器的检查过程不同，目前尚不清楚它们是否可以共享同一个检查器。此外，还提出了在审计期间更好地处理错误的话题，团队计划跟进这一建议。

  • 00:10:00 在本节中，演讲者讨论了他们名为 Trivial 的库，该库与 ONNX 生态系统交互并为 ONNX 模型提供服务。他们建议在 ONNX 中添加一个预定义的元数据模式字段，以表示创建模型时的时间戳、用于模型的训练算法以及用于生成模型的源库。他们建议为元数据字段定义标准键名称并键入它们。演讲者认为拥有元数据字段的模式对于图书馆和其他服务于 ONNX 模型的用户很有用。然后话题转移到需要扩展模型测试以覆盖 Model Zoo 中的所有模型，并提供高质量的好例子。

  • 00:15:00 在本节中，讨论围绕量化物理优化的需求以及扩展 ONNX 的模型动物园以包括量化模型展开。已经有几个请求将量化模型包含在模型动物园中，团队希望找到贡献者。他们提到了一个博客，其中来自 Hugging Face 的量化 ONNX 模型表现良好，但他们需要获得 Hugging Face 的许可才能发布它。也有人建议transformer库的顶层模型可以作为量化的例子，微软和太空都在做。此外，还有关于优化的讨论，一些人同意最好将优化留给运行时，因为它超出了 ONNX 规范的范围。

  • 00:20:00 在本节中，参与者讨论了使用版本转换器工具将 ONNX 模型从 Model Zoo 更新到最新版本的可能性。然而，他们注意到版本转换器并不是完全最新的，并且对于是否需要转换存在一些不确定性，因为 ONNX 支持所有以前的版本。该小组还考虑了 ONNX 工具集的不同语言绑定的想法，对 Java 特别感兴趣，以支持不同的平台，例如 Spark。添加 Java API 或绑定将有助于模型文件的加载和验证，以及将其他库转换为 ONNX 格式。

  • 00:25:00 在本节中，演讲者讨论了围绕 ONNX 运行时创建 Java 包装器的可能性，这将使基于 JVM 的机器学习项目（例如 Spark）变得更容易。尽管这是一项艰巨的任务，但使用 Java CPP 预设来自动生成存根可能是一个很好的起点。向后兼容性对于像 Spark 这样的大型项目至关重要，而针对 Java 8 需要大量工作。但是，如果社区有足够的兴趣和意愿做出贡献，探索可能是一件好事。
 

2020 年 ONNX 路线图讨论 #4 20200923



2020 年 ONNX 路线图讨论 #4 20200923

ONNX 路线图讨论的第四部分涵盖了数据框架支持、预处理、标准化、端到端机器学习管道和工具推荐等主题。数据框支持被评估为对经典机器学习模型很有价值，并且可以消除对预处理的需要。强调需要在 ONNX 模型中捕获预处理以提高性能，重点是标准化图像处理等高级类别。端到端管道被评为低优先级，但建议逐渐向管道中添加组件。讨论最后建议使用一种工具来帮助进一步讨论和分析议程项目。

  • 00:00:00 在本节中，演讲者讨论了 ONNX 路线图和社区建议的功能。到目前为止，他们已经涵盖了三个部分，包括 ML 管道和数据处理、操作定义或 IRS 以及核心机器人技术。路线图文档包括一个建议功能表，这些功能分为高、中和低优先级。但是，有些主题过于笼统，因此很难评估它们的重要性。演讲者计划在接下来的 30 分钟内讨论为什么其中一些功能被评为高分，并收集社区对哪些功能最重要的反馈。

  • 00:05:00 想知道如何确定 ONNX 路线图的优先级，视频的这一部分讨论了数据帧支持功能的重要性以及它如何解决平台内的其他问题。演讲者解释说，此功能对数据科学家很有价值，并且可能会消除对预处理功能的需求。他们还提到需要对路线图上的每个项目进行工程成本估算，以便有效地确定任务的优先级。欢迎提出建议，因为这是第一次以这种方式呈现路线图。

  • 00:10:00 在 ONNX 路线图讨论的这一部分，讨论了数据框架支持对机器学习模型的重要性。据信，数据框架支持主要针对经典机器学习模型，而不是 DNN 或其他模型。数据框不同于序列，因为它是张量的异构集合或具有可以具有不同类型的列的关系表。每个功能的重要性根据其将产生的影响进行评估，并将工程成本考虑在内。建议为每个框提供评论以突出显示功能重要性高或低的原因。

  • 00:15:00 在本节中，讨论了 ONNX 模型中预处理的重要性。对话强调需要在 ONNX 模型中捕获所有必要的步骤，而不是依赖外部库，尤其是在训练环境中，预处理会对性能产生重大影响。此外，预处理在推理方面可能很有用，特别是如果不是在基于 Python 的环境中。由于数据类型的异构性，讨论还涉及标准化预处理的挑战。尽管预处理是一个广泛而复杂的话题，但谈话的结论是，有必要考虑 ONNX 中缺失的运算符和类型以标准化预处理。

  • 00:20:00 在本节中，演讲者讨论了预处理的广泛范围，以及它如何不仅包括与视觉相关的处理，还包括音频数据。虽然预处理很重要，但发言者指出，可能没有必要支持所有数据类型，相反，对图像处理等高级类别进行标准化可能对开发人员更有利。然而，演讲者警告说，即使是看似简单的预处理任务，如图像大小调整，在库之间也可能存在细微的边缘情况差异，从而使标准化成为一项工程挑战。尽管如此，标准化预处理任务可能会有所帮助，演讲者建议收集常见的预处理步骤以供将来考虑。

  • 00:25:00 在本节中，演讲者讨论了在 ONNX 中包含端到端机器学习管道的优先级，一些人表示考虑到其他需要解决的项目，它的优先级较低。但是，他们认识到拥有端到端示例和说明如何应用 ONNX 的有用性，尤其是在将 ONNX Runtime 引入组合时。建议逐步将组件添加到管道中，重点放在训练部分，微调 ONNX，并最终将预处理添加到混合中。讨论结束时建议使用一种工具来促进对议程项目的进一步讨论和影响分析。

  • 00:30:00 在这一部分，演讲者感谢大家的加入，并告知听众他们将尝试在社交媒体和 ONNX 网站上发布讨论。
 

2020 年 ONNX 路线图讨论 #5 20201001



2020 年 ONNX 路线图讨论 #5 20201001

在 ONNX 路线图讨论期间，ONNX 团队讨论了社区成员建议并由包括指导委员会在内的不同人员评分的各种功能。虽然一些功能得到了一致同意，但其他功能却分裂了社区。该团队讨论了将 ONNX IR 更改为多个 IR 和集中式 IR 优化库的可能性。他们还讨论了在 ONNX 中集中优化库的想法，以及对 ops 实施标准接口和编码风格的要求。该团队还讨论了为 ONNX 模型提供简单运行时的可能性，以及在 ONNX 运行时不可用的情况下使用自定义 Python 操作。此外，该团队探索了预处理操作与数据框使用之间的关系，计划将他们的想法转化为未来工作的可操作建议。

  • 00:00:00 在本节中，ONNX 团队讨论了影响分析电子表格，该电子表格旨在收集不同人对项目重要事项的想法。他们列出了所有建议的不同功能，并从不同的人那里得到了分数，包括指导委员会和其他社区成员。他们注意到，有些功能似乎每个人都认为它非常重要或根本不重要，而其他功能则社区分裂。他们讨论了那些分裂的问题，以及他们同意的重要问题的后续步骤。他们还讨论了为什么被认为是高优先级设置标准，以及这如何取决于谁愿意花时间来实现一项功能。

  • 00:05:00 在 ONNX 路线图讨论的这一部分，参与者讨论了将 ONNX IR 更改为多个 IR 和集中式 IR 优化库的想法。由于优化和 IR 是不同的问题，因此关于这两个想法是否应该组合在一起存在一些争论。拥有多个 IR 的目标是简化和连接更简单的操作，同时优化库将改进核心 ONNX。关于 ONNX IR 的含义有进一步的讨论，需要澄清。参与者还讨论了这些潜在的变化如何影响他们在 ONNX 路线图上的当前分数。

  • 00:10:00 在本节中，团队讨论了在 ONNX 中集中优化库的可能性，但最终同意优化应该是运行时的一部分，并且与其他问题相比，它的优先级较低。他们还讨论了以特定方式实现 ops 的要求，具有标准的接口和编码风格，这已经是一项要求，但可能需要调整。他们建议，如果有人提出一种特定的风格，如果看起来可以接受，就可以接受。

  • 00:15:00 在本节中，演讲者讨论了为 ONNX 模型提供简单运行时的想法，这引起了人们对需要执行流和内部 IR 来处理模型的复杂性的担忧。但是，能够运行和评估 ONNX 模型以测试和建立正确性是有价值的，特别是在为操作员揭示单元测试中的任何差距方面。虽然实施一个简单的运行时需要付出多少努力和成本可能值得商榷，但 ONNX 运行时确实具有插入 Python 操作的能力，可用于此目的。

  • 00:20:00 在本节中，ONNX 路线图讨论的参与者讨论了在 ONNX 运行时不可用的特定情况下使用自定义 Python 操作的可能性。他们讨论了 Python 操作的局限性以及对标准接口以确保可行性的需求。此外，该小组还讨论了 ONNX 图形内部需要更多预处理功能的需求，以使模型更加独立和便携，特别是对于基于图像的预处理，如缩放和处理边界框。该小组指出，文本预处理，特别是标记化，是一个更复杂和更全面的问题，但他们可能能够抽象出一些常见的预处理场景。

  • 00:25:00 在本节中，参与者讨论预处理操作与数据帧使用之间的关系。虽然他们同意预处理和数据框是相关联的，但他们将它们视为需要不同类型工作的独立实体。预处理被视为跨数据帧的列按行工作的运算符，而数据帧提取本身将预处理运算符映射到列的行。该小组认为两者密切相关，并计划将他们的想法转化为未来工作的可操作建议。
 

2021 年ONNX 路线图讨论 #1 20210908


2021 年 ONNX 路线图讨论 #1 20210908

在 ONNX 路线图讨论期间，IBM Research 介绍了他们对新机器学习管道框架的提议，该框架将 Pandas Dataframe 上的典型数据预处理模式转换为 ONNX 格式。这个名为 Data Frame Pipeline 的框架在 GitHub 上是开源的，可以使用他们提供的 API 进行定义，该 API 在训练阶段在 Python 上运行。演讲者还讨论了使 ONNX 在 Python 以外的语言（如 Java、C# 和 C++）中可见的必要性，以及 ONNX 模型的导出和从其他语言发出的问题。此外，他们还讨论了 ONNX Python 和 C++ 转换器的当前功能，以及在编写 ONNX 模型时对范围界定、命名和修补功能的需求。

  • 00:00:00 在本节中，来自 IBM Research 的 Takuya 介绍了他们关于使用新的 ONNX 运算符的新机器学习管道框架的提案。该提案的动机是由于现有的管道框架无法表示数据预处理的典型模式。他们在 Python 上构建了一个名为 Data Frame Pipeline 的新管道框架原型，它将 Pandas Dataframe 上的典型数据预处理模式转换为 ONNX 格式。他们保护了三个新的 ONNX 运算符，包括一个日期运算符和两个简单运算符、字符串连接器和字符串拆分器。管道框架在 GitHub 上是开源的，可以使用他们提供的 API 进行定义，该 API 在训练阶段在 Python 上运行。该模型使用从数据框架管道输出的数据进行训练，他们的框架可以使用已经转换的 ONNX 机器学习模型。

  • 00:05:00 在本节中，演讲者讨论了 ONNX 格式以及如何将其与 Microsoft 提供的 ONNX 运行时一起使用。他们提到在他们的原型中，他们用 Python 实现了 11 个数据帧转换器，并将它们映射到 ONNX 运算符，其中大多数是简单的映射，但有些需要分析和转换，例如函数转换器。他们还讨论了生成具有带电体属性的 ONNX 运算符的方法，而不是在 ONNX 上执行聚合运算符。演讲者分享了初步实验结果，这些结果表明在 ONNX 上学习预处理时速度显着提高，分类编码的性能提高了 300 倍。他们还比较了预测的准确性并提及了他们的建议，为提出的运营商提出了问题和评论。

  • 00:10:00 在本节中，来自 Oracle 实验室的 Adam Pogba 建议 ONNX 应该在 Python 以外的语言中可见，因为当前功能全部包含在 Python 中，并且不清楚 C++ 是否是有效的绑定目标。 Pogba 解释说，模型检查器应该以其他语言显示，以便用户无需有效的 Python 环境即可与之交互。此外，Pogba 提到，由于解析问题，ONNX 运行时在使用模型时偶尔会出现段错误，模型检查器可用于验证并轻松修复此问题。

  • 00:15:00 在本节中，演讲者讨论了模型检查的核心功能以及跨其他语言公开它的用处。虽然他们希望在 Java 中使用它，但他们明白并不是每个人都会编写 Java API，因此对于大多数语言来说，C API 是一个更好的选择，可以轻松绑定。然而，需要有一个稳定且合适的目标供人们绑定，目前尚不清楚这些工具中的任何一个的 C++ API 是否被认为是合适的绑定目标。演讲者愿意参与这项工作，但除非社区有兴趣，否则不值得尝试激发巨大的努力。

  • 00:20:00 在本节中，演讲者讨论了 ONNX 模型的导出以及从 Python 以外的其他语言（例如 C# 和 Java）发出它们，特别关注 ML.NET 和 Trivial Library。演讲者敦促需要一个通用的 API，所有项目都可以使用它来生成 ONNX 模型，特别是考虑到目前存在的三种不同的实现没有共享代码，容易出现错误。通用 API 将确保只有一个地方可以更新和验证节点和图形，从而提供共享优势的机会，并使其他机器学习库更容易发布 ONNX 模型。演讲者承认，尽管这可能需要做很多工作，但共同努力可以使 ONNX 生态系统发展到 Python 之外。

  • 00:25:00 在本节中，演讲者讨论了 ONNX Python 和 C++ 转换器及其当前功能。他们注意到 ONNX 文档不够具体，这使得某些功能难以理解。但是，他们断言这些转换器中已经存在 ONNX 导出所需的许多功能，但需要以正确的方式向其他项目公开。此外，他们还讨论了在编写 ONNX 模型时对范围界定、命名和修补功能的需求。最后，他们建议转换器可以从链接到架构基础设施 sig 中受益，以便不同的人可以轻松使用它们。
 

2021 年 ONNX 路线图讨论 #2 20210917



2021 年 ONNX 路线图讨论 #2 20210917

在 ONNX 路线图讨论 #2 20210917 中，不同的演讲者讨论了 ONNX 需要改进的几个关键领域，包括量化和融合友好性、针对特定硬件平台优化内核以及向 ONNX 添加模型局部函数。其他主题包括对端到端管道支持的反馈、不同平台上的客户面临的挑战，以及转换 GRU 和 LSTM 图的问题。一些建议的解决方案包括为后端提供更多信息以执行预量化图、改进不同框架的互操作性，以及包括与原始图相关的命名空间以允许通用和优化的解决方案。此外，发言者还讨论了为更广泛采用而更好地部署包的必要性，以及开发更多转换器以支持多模式模型的潜力。

  • 00:00:00 在本节中，来自 Green Waves Technologies 的 Martin 讨论了 ONNX 需要改进的两个领域：量化和融合友好性。对于量化，Martin 建议为后端提供更多信息以执行预量化图，因为 ONNX 不可能遵循客户希望实现专门事物的所有不同方式。为了帮助实现这一点，Martin 建议向张量添加最小最大值、标准偏差和平均信息，以及额外的信息，如离群值统计、每个通道的通道信息和分布信息作为可能的附加信息。对于融合友好性，Martin 建议通过提供更好的导入/导出功能来提高不同框架的互操作性，这将使 ONNX 更容易识别在导入/导出不同图形时要使用的正确转换器。

  • 00:05:00 在本节中，演讲者讨论了组合运算符的当前函数使用情况，以及在运算符被分解时针对特定硬件平台优化内核的困难。建议将导出的函数分组到更高级别的容器（可能是函数）下，并将该容器映射到特定后端上的优化内核。 speaer 还建议包括与原始图相关的命名空间，以允许通用解决方案和优化解决方案。还提到了在最新的 ONNX 版本中添加了导入模型本地函数的功能。

  • 00:10:00 在本节中，演讲者讨论了向 ONNX 添加模型局部函数，这允许转换器操作员将函数体包含到模块原型中，作为 ONNX 标准中未定义的操作符的占位符。但是，发言者还指出，转换器最好以机器可读的方式标记和评论他们正在导出的内容。他们还谈到优化如何影响命名约定，并建议在 Slack 频道或额外会议中继续讨论该主题。介绍了下一个介绍，这是关于 ONNX 分析的。

  • 00:15:00 在本节中，讨论了关于端到端管道支持的反馈，ONNX 被视为非常适合轻量级部署到不需要大量生态系统要求的不同操作系统。演讲者表示希望使 ONNX 操作员跨 ONNX 和 ONNX ML 不仅可以执行模型，还可以执行数据准备阶段，包括涵盖其他类型的数据生产操作。他们声称，简化或通用的部署工件或模型可以增加价值，并能够通过专注于标准转换周围容易实现的成果来节省工作量和一致性。

  • 00:20:00 在本节中，演讲者讨论了客户在不同平台上面临的一些挑战，并指出了继续开发和扩展 ONNX 平台的潜在价值。他们谈到了孤岛问题以及简化包部署以更好地采用的必要性。对话还包括一位参与者的评论，他确认面临类似问题，并提出了合并 Linux 服务器 ONNX 或找到更好的方法来帮助用户将自定义代码转换为 ONNX 的选项。演讲者还谈到了多模式支持的主题，以及将模型集合表示为单个 ONNX 图的必要性。他们讨论了对更多转换器的潜在需求，并建议朝着正确的方向发展。

  • 00:25:00 在 ONNX 路线图讨论的这一部分，团队讨论了代理模型的代理示例，以展示客户在企业环境中用于非图像类型用例的事物类型。一位团队成员提到了一个欺诈检测模型的代理示例，该模型使用一些公开数据并且是一个相对简单的两层 LSTM 模型。该团队正在进一步调查此事，并试图获得更多代理模型的例子。他们还讨论了 GRU 和 LSTM 未正确转换的问题，并提到他们希望为所有情况添加支持。

  • 00:30:00 在本节中，演讲者讨论了将 GRU（门控循环单元）图转换为后端转换器可以读取的格式所面临的挑战。他们提到在某些情况下，TensorFlow 中已经发生故障，但将其转回 GRU 具有挑战性。他们建议使用 `--custom ops` 标志并制作一个适用于它的内核，然后再继续考虑使其成为一个函数或在语义方面保留它的想法。他们指出，最好的选择是明确表示用户是否希望它被分解，而使用自定义操作可能是唯一可靠地做到这一点的方法。

  • 00:35:00 在本节中，演讲者讨论是在 ONNX 和高级别上拥有完整的功能体还是只拥有 TF 基础更好。对于他们来说，TF 基础就足够了，因为 ONNX 可以用作整个链上的结果证明。但是，他们告诫不要让 ONNX 以 TensorFlow 为中心，因为 ONNX 应该能够来自不同的地方。他们还谈到了具有语义意义的命名子图的吸引力，几乎将其视为一个运算符，需要由各种不同的前端定义和生成。最后，他们同意进行更深入的演示，以继续与更多知识渊博的人进行讨论。
 

2021 年 ONNX 路线图讨论 #3 20210922



2021 年 ONNX 路线图讨论 #3 20210922

在 ONNX 路线图讨论期间，发言者解决了解决 ONNX 的偏移转换工具问题的需要，以改进 ONNX 对某些用例的最新优化堆栈的采用。演讲者建议更好地覆盖模型，以测试偏移量转换和解决当前在操作员或层测试中缺少的中间步骤。他们还讨论了元数据和联邦学习基础设施的重要性，包括需要在 ONNX 规范中包含用于迁移学习注释的元数据，以及联邦学习的概念以实现隐私、效率和计算资源的使用。发言者鼓励社区合作，并征求反馈意见以进一步讨论和实施这些想法。下一届会议定于 10 月 1 日举行。

  • 00:00:00 在本节中，英特尔的 Manoj 解决了 ONNX 模型偏移转换方面的差距，这些差距一直给许多客户带来问题。基本问题在于偏移量转换，因为许多客户在生产中部署模型后不会继续更新偏移量。客户在偏移转换方面面临多个问题，例如从 7 移动到 10 再到 13 进行量化，或者无法将旧偏移转换为新偏移以利用性能和良好的准确性。此外，单元测试或与每个运营商或层相关的所有测试都没有达到 ISV 满意的程度，因此，大多数客户仍处于 10 或 9 偏移量。

  • 00:05:00 在本节中，演讲者讨论了解决 ONNX 的偏移转换工具问题的必要性，因为它阻碍了采用具有最新优化堆栈的 ONNX 用于某些用例。正在集成 AI 并将其交付到他们的应用程序中的开发人员正在提供有关修复转换工具并确保它们无缝连接的需求的反馈。他们分享了他们面临的问题示例，例如缺少中间步骤和缺少适配器实现，这些问题阻碍了向量化性能模型的过渡。演讲者强调需要更好的覆盖范围和更多的模型进行测试，以确保更好地采用 ONNX。

  • 00:10:00 在视频的这一部分，演讲者讨论了从顶级创作者公司批准至少一个失败模型以进一步改进 ONNX 的必要性。讨论转向 fp16 转换的改进，这是移动和 Windows 等不同生态系统之间的差距之一，以及最近如何使用 Microsoft 转换器工具修复它。转换的责任尚不清楚，但讨论会转到下一个关于模型动物园的演示文稿，其中包含用于培训的语音运算符将有助于涵盖所有类别的模型。他们建议从 Transformer 或 NLP 训练样本开始，然后转向更多模型，以展示适用于 ONNX 的分布式训练基础设施和技术。

  • 00:15:00 在本节中，演讲者讨论了 ONNX 模型在训练中的作用，包括量化感知训练和混合精度使用的重要性。他们要求原始 fp32 模型更好地比较精度并展示使用 ONNX 模型进行训练的混合精度用法。他们优先考虑为变压器样本做出贡献，但请求社区帮助贡献其他受欢迎的类别。他们还讨论了未来的提议，以更好地反映模型中混合精度的使用作为元数据的一部分。最后，Gabe Stevens 展示了英特尔开始研究的部署配置。

  • 00:20:00 在本节中，演讲者讨论了分布式和联合学习的概念及其在隐私、延迟、效率和计算资源使用方面的优势。这个想法是将模型部署到一组设备上，其中一些设备有一个训练组，可以使用他们看到的数据来丰富模型。对 ONNX 的拟议修改将使其能够促进联合学习，使开发人员更有可能使用 ONNX。 API 的最小添加集包括一种查询零件以获取本地模型参数、更新这些参数并通知服务器模型如何更改以合并到包含来自模型的结果的新模型的方法设备。

  • 00:25:00 在视频的这一部分，演讲者讨论了在 ONNX 规范中包含元数据的想法，以允许迁移学习注释，并使使用在较大数据集上训练的模型训练较小的数据集变得更加容易。然而，此类系统的实施涉及多个需要留给实施者的设计决策。演讲者提出了三个项目，它们可以在不限制应用程序开发人员所需的灵活性的情况下促进此类系统的基本基础架构。他们还提到需要在一系列设备上部署模型版本的一致性，以及不强制只允许 ONNX 模型参与联邦学习系统的重要性。演讲者就规范设计者是否有兴趣关注此类学习配置以及他们是否愿意接受进一步讨论征求反馈意见。另一位发言者建议尝试使用 ONNX 运行时来做到这一点，因为它支持训练，并且已经为使用它进行联合学习构建了一些概念证明。

  • 00:30:00 在这一部分中，演讲者对为演讲付出的巨大努力表示感谢，并感谢社区提出的问题。演示文稿的目的是向相关 SIG 提出想法，以供进一步讨论和最终实施。最后一次会议将于 10 月 1 日举行，演讲者期待继续参与这些想法。
 

ONNX 社区虚拟聚会 – 2021 年 3 月



000 ONNX 20211021 ONNX SC 欢迎进度路线图发布

ONNX 研讨会以介绍开始，组织者强调了社区参与对 ONNX 生态系统发展的重要性。他们还提供了议程的概述，其中包括 ONNX 统计数据的更新、社区介绍以及 ONNX 指导委员会的路线图讨论。路线图提案旨在提高 ONNX 框架的支持、健壮性和可用性，包括预处理运算符、C API、联邦学习以及更好地集成数据处理和推理。还讨论了最近发布的 ONNX 规范 1.10 版，鼓励与会者提问并参与 ONNX Slack 频道以继续对话。

  • 00:00:00 在研讨会的这一部分，组织者提供了概述并欢迎所有与会者。他们提到了可用于 AI 的大量产品，并敦促与会者检查一下。研讨会的总体目标是获取 ONNX 及其流程、路线图和版本的最新更新，并向社区参与者学习如何使用 ONNX。他们鼓励与会者分享他们的反馈，更多地参与 ONNX 指导委员会、SIG 和工作组。他们提供了议程的概述，其中包括 ONNX 工作组的后勤工作、Wenming Yi 和 Alex 的状态介绍以及社区介绍。最后，他们展示了 ONNX 统计数据的令人振奋的更新，包括每月下载量增加近 400% 至 160 万次，表明生态系统正在健康发展。

  • 00:05:00 在本节中，演讲者讨论了 ONNX 生态系统的进步和发展，强调了社区中公司贡献的重要性。演讲者提到了来自 Amazon 的深度 Java 库项目，它为 Java 社区构建了良好的体验，并取得了长足的发展。 IBM、AMD 和 Sony 等多家商业公司正在为生态系统提供支持，并帮助 ONNX 成为行业标准。演讲者还谈到了社区治理和指导委员会的新成员，并邀请参与路线图讨论、Slack 频道、GitHub 上的问答以及对文档和博客的贡献。下一位演讲者接着介绍了路线图，这对于朝着正确的方向前进并将 ONNX 模型降低到 CPU 和加速器的电池至关重要。

  • 00:10:00 在本节中，演讲者讨论了 ONNX 指导委员会在夏季进行的路线图讨论。从不同成员收到的提案被分成四组，每组三个提案，每组提交给各自的 Sigs 批准和实施。提案范围包括预处理运算符、C API、模型检查、支持以其他语言发出模型、在张量中添加元数据信息、更好地集成数据处理和推理、定义联邦学习的概念、定义元数据处理属性以提高完整性数据、模型等。目标是为所有用户提供更好的 ONNX 框架支持、稳健性和可用性。

  • 00:15:00 在本节中，演讲者讨论了最近发布的 ONNX 规范 1.10 版，并感谢贡献者的辛勤工作。在 next.ai 网站上将有关于这一最新变化的进一步讨论和细节。演讲者邀请听众在聊天或 ONNX 通用 Slack 频道中发布任何问题以继续对话。
1234567891011...15
新评论
原因: