觉:瞳专题PyTorch社区探秘

本期瞳君带大家看一看pytorch的社区到底是什么样的？

关于本系列文章的相关声明

创作声明

本系列的内容创作分为如下三个部分：

1. 个人阅读文档之后的理解
2. 对原文档的部分翻译
3. 无关紧要部分的AI辅助创作
4. 部分相关信息的引用及二次创作

本系列的图片来自于：

1. PPT图形制作
2. 幕布思维导图工具
3. AI绘画辅助创作
4. 网络（如侵权，请联系作者删除）

在此向人类艺术家与一切内容创作者，AI科学家与工程师，程序员团体致以最崇高的敬意。

费曼学习法声明

费曼学习法（Feynman Technique）是一种通过将所学知识用简单明了的语言解释给别人听来加深自己的理解和记忆的学习方法。这种方法最初由物理学家理查德·费曼（Richard Feynman）提出。

费曼学习法的基本思想是：将所学知识用自己的语言表达出来，以便理解、记忆和应用。

瞳君通过边学边创作的方式，将所学知识用简单明了的语言解释给大家，以加深自己的理解和记忆。由于个人理解的局限性，创作内容可能存在错误，欢迎各位专家批评指正。

实验&创作就是失败，失败就是学习，学习就是进步。

原创声明

本系列下的文章引用皆包含出处，未包含出处的皆为瞳君原创**@搞知识的觉之瞳**，遵循相应平台的相关协议进行分发。如需转载，请根据相关平台的内容规定进行转载。

It's free and you can always change your mind, enjoy your reading!

社区简述

如图，PyTorch社区长这个亚子，这里我们大概翻译一下，可以看出主要就这几样功能：

让我们先从讨论开始看：

讨论包含了discuss与slack，其中discuss模块直接跳转到了Forum模块，于是这个模块的讲解我们可以光明正大的摸到后面再提了:dog:

同时slack是一个“更高级的圈子”，需要通过邮件申请才可以进入，而discuss适用于初学者。 于是乎这个板块就...摸完了？

然后是文档及其翻译：

官方提供了中文，日语与韩语的文档翻译，由地方性的组织进行维护，在这里向维护中文文档的大佬们点赞！

于是乎这个板块就...又摸完了？

贡献者及其管理板块：

终于到了剩下两个有得讲的界面之一了！ 这里一共有四个板块

Maintainers介绍了目前维护整个PyTorch项目的大爹们，把每个板块的Leader写得清清楚楚（方便你提PR的时候摇人） ContributionGuide提到了整体的PR（做贡献流程）

Governance提到了PyTorch的治理体系，也就是人员分工

Contributors则是将贡献者引导至开发者论坛，然后在这里“紧跟新版本”。

那这样就又又又水完了（你打算就这样应付了事吗？？？）

细节部分的解析——Maintainers

从Maintainers我们可以知道什么呢？这里不是一堆人名吗？

不不不，可以知道的东西太多了

首先，PyTorch现在分为几个模块在维护？ 其次，维护者的原则是什么？

这样就足够我们整一个分划了。具体的人名？你需要提PR再去看就行了~

Maintainers的任务

1. 处理分配给该模块或库的高优先级问题，并进行修复。（PR大爹）
2. 审查和处理分配给该模块或库的高优先级拉取请求。（PR解决问题高级一点容易先合并）
3. 在 discuss.pytorch.org 和 dev-discuss.pytorch.org 上回答与该模块或库相关的问题。（别拉错人）
4. 维护公共用户和开发文档。（Docs大爹）
5. 定期举行会议，并分享会议纪要以及半年或季度性的路线图。（日常开会）

PyTorch的模块维护情况

相关的功能板块，可以通过这个快速了解当前某个模块的具体情况。

最后的板块：PyTorch设计艺术：

不懂开发艺术就来开发？？？（搞:poop:山是吧）（蟹升牌の人格修正拳）

代码开发本就是一种艺术创作，但是你不能保证你每次的艺术视野是一样的。更别提你还要与其他人打配合。

就和画师画两张图不会完全一致一样，代码也是这样的。

但是，代码之间是存在依赖的，不像画师画的图之间是相互独立的。

不同的艺术视野各玩各的，艺术就变成抽象了！

所以才需要一类规范，规范所有PyTorch开发者的艺术视野，使大家在开发PyTorch上具有一致认知，这是CI CD的重要前提。

这里将从个人的视角谈谈PyTorch的设计艺术：

基本原则可以概括为如下几条：

• 可用性大于性能。
• 简洁大于简单。
• Python优先.

可用性大于性能

• PyTorch 的主要目标是可用性
• 第二个目标是具有合理的性能

这是一个很简单的理解，如果无止境的追求性能，那么可用性的灵活程度就会被大大的限制，使得它和其他生态会不具有良好的兼容性。同样的，如果无止境的追求可用性，那么性能就不一定很好了。深度学习是一个非常广大的领域，因此如果这个框架刻意的去追求性能的话，它就不可避免地往狭隘的方向做深度的优化，一方面会让整体的表现更加抽象，学习的门槛更高。另一方面它和其他框架的兼容性就更差，生态就会更小。就很难继续发展广大。

我们可以举一个高考生和数学老师的例子，高考生在他考试的六门科目都具有一定程度的泛化性，我们这里可以不那么恰当的把它比较为好的可用性，而数学老师是针对数学一个领域方向的特化，因此其在数学领域的性能肯定比高考生要好，可能30分钟就能写完一张卷子，并且拿到很高的分数。但是让这位数学老师去做其他五科的卷子，就会显得捉襟见肘。这就是可用性跟性能的一个辩证关系。

简洁大于简单

• 显式优于隐式
• 简单胜于复杂
• **简单/显式（便于理解、调试）：**每个张量都与一个设备关联。用户明确指定张量设备移动。需要跨设备移动的操作会导致错误。
• **简单/隐式（易于使用）：**用户不必担心设备；系统计算出全局最佳的设备放置位置。

（代码搭建上的）简洁是什么意思？很简单，就是这个东西后面没有什么遮遮掩掩的，它是什么就是什么，底层的依赖非常明确和清晰。 （代码使用上的）简单是什么意思？同样很好理解，就是这个东西非常容易用，敲三行就可以跑出来了。

简洁相对简单 简单不一定简洁 道理也很简单，台上一分钟台下10年功，非常好看的表演背后往往是付出了大量的磨练和细节。简单的东西背后往往有着深刻且复杂的原理，所以你用起来很简单，但是设计者花了很多心思。 简洁的东西是相对简单的，因为它比较好弄懂(没有很多深刻且复杂的原理)，使用起来虽然不一定非常简单，但是发点功夫还是很好理解的。 另外简洁和简单相比，还有一个很重要的优点，就是简洁的东西一定很好拆解，简单(代码使用上)的东西不一定很好拆解

换句话来说就是简洁的东西深入学习门槛一定相对较低，简单的东西深入学习门槛不一定很低(表面简单，背后可能敲了几万行if逻辑)

因此选择了简洁而不是简单

Python 优先

这个原则始于Python First：

PyTorch 不是绑定到整体 C 框架的 Python。它旨在深度集成到 Python 中。您可以像使用NumPy、 SciPy、[scikit-learn](pytorch.org/docs/master… Python 库一样自然地使用它。您可以使用您最喜欢的库并使用Cython和 Numba等软件包，用 Python 本身编写新的神经网络层。我们的目标是在适当的情况下不重新发明轮子。

简单来说就是，在这么多前端中，我们更注意Python，而不是其他玩意儿。

因此你可以在背地里用c对各个模块进行优化，但是在用户使用这个模块的时候，他们必须看到的是 Python的操作方式。

似乎是一些方便加深理解的链接：

soumith.ch/posts/2021/…

pytorch.org/docs/master…

那总的社区就介绍到这里了，我是瞳君@搞知识的觉之瞳，我们下期再见~

这篇好文章是转载于：学新通技术网