PyTorch是目前最受欢迎的深度学习框架之一，初始版本于2016年9月由Adam Paszke、Sam Gross、Soumith Chintala等人创建，并于2017年在GitHub上开源。因其简洁、易用、支持动态计算图且内存使用高效，PyTorch受到众多开发者的喜爱，并被广泛应用于支持科学研究以及ChatGPT等应用的开发。此外，PyTorch有一个活跃的大型开源社区，提供了丰富的教程、示例代码和问题解答，给予成员帮助和支持。
Soumith Chintala是Meta副总裁以及PyTorch的联合创始人。Soumith对PyTorch的发展过程和最终用户体验产生了重要影响，并主导塑造了PyTorch开源社区的运营理念。
在《进击的PyTorch，与它背后的开源领袖》一文中，Soumith分享了PyTorch的开源历程，以及他所信奉的开源之道。在本文中，Weights & Biase创始人Lukas Biewald与他讨论了PyTorch的内部运作机制、管理开源社区的方法，以及当前流行的其他机器学习库。
（以下内容经授权后由OneFlow编译发布，转载请联系授权。原文链接： www.youtube.com/watch?v=2wp...
来源 | Weights & Biases
OneFlow编译
翻译｜杨婷、宛子琳
1
PyTorch的发展历程
Lukas Biewald：PyTorch从Torch发展而来，能简单讲讲它的发展历程吗？
Soumith Chintala： 2012年左右，我开始参与Torch开源社区的工作。Torch是一个科学计算库，具备加速功能，使用Lua语言，这是一种常用于编写视频游戏和微型软件的语言。Torch与Lua非常适配，Torch的创始人在2005年至2009年间用Lua编写了两个Torch版本，由于支持神经网络研究，当时一些最优秀的研究实验室（包括DeepMind、Facebook AI Research（FAIR）、Twitter以及许多大学）都使用Torch。
随着科学领域的不断发展，人们开始需要新工具，旧工具逐渐过时，因此我们希望编写一个更符合当时（2015 年左右）人们实际需求的新工具。于是，我们决定重构Torch的新版本，因为人们已经普遍将Python作为主要的科学计算语言，因此，我们重新用Python设计了一个Torch的新版本，最终成就了PyTorch。
Lukas Biewald：还记得我们刚开始创建Weights and Biases时，TensorFlow的发展正势不可挡。当时你是否看到了TensorFlow的不足之处？是什么激励了你，让你决定开发一个与之相抗衡的系统？
Soumith Chintala： TensorFlow于2015年12月发布，当时市面上大约有15到20个深度学习框架，那时TensorFlow还未像现在这样占据主导地位。TensorFlow在混乱的竞争局面中登场，在发布时进行了全面营销。谷歌是当时最好的研究实验室，TensorFlow利用谷歌云预算进行了大规模营销，以一种其他深度学习框架意料之外的强势方式打入市场。
当时，每个新的深度学习框架都需要一个shell脚本来进行编译和安装，缺乏经过精心设计的工程，单元测试可能仅在HPR上运行。因此，TensorFlow具有极大优势，向深度学习框架领域展示出高质量的工程实践。
但TensorFlow缺少对开源激励机制的关注以及与开源社区的互动，包括回答低级提问、满足用户各种需求以及及时处理用户发送的PR等。
我们认为，与社区互动、向社区提供有效帮助并逐步建立社区的过程在 TensorFlow中有所欠缺。而与社区互动的方式非常契合Torch的理念，我们一直在延续并以更大的规模不断发展这一理念。
2
社区驱动的开源项目
Lukas Biewald：你好像在说PyTorch的成功与技术水平差异无关，更多的是社区建设和互动，就像有人指出，PyTorch的及时评估反馈是你们成功的主要原因？
Soumith Chintala： 我坚信，TensorFlow是一个在技术方面具有相当高成功率的代表性编程模型，Jax就是一个最直观的例子，这说明，技术方向并不是导致TensorFlow未能达到预期的原因。Jax在编程模型方面与TensorFlow非常类似，只需提前跟踪一个程序，然后在辅助运行时（runtime）运行它，人们使用Jax的体验非常好。
TensorFlow从TensorFlow 1.0升级到TensorFlow 2.0的过程中，放弃了符号执行模型，而这可能是PyTorch最大的优势之一。如果人们需要从符号执行模型过渡到Eager执行模型，那么相比刚刚诞生的Eager框架，人们多半会选择PyTorch，因为后者在这方面已经发展了好几年，相对成熟。
Lukas Biewald：你们在构建社区方面做得非常出色，在这方面是否有什么窍门？对于试图自己建立社区的人，你有什么建议？
Soumith Chintala： 首先，要给予那些工作出色，但并不熟悉的人更多信任，赋予他们更多权力。其次，我们需要认识到，尽管我们曾试图提醒，但很多人对PyTorch的发展方向并不完全了解。
Meta为其投入了大量资源，是其最大的贡献者之一。但PyTorch最初源于Torch社区，由一群热衷于Torch的神经网络爱好者组成。PyTorch论文的主要作者是Adam Paszke，我和他在网上相识，当时他正在撰写关于Torch的博文。我记得他发表了一两篇博文，详细介绍Torch的内部结构，我觉得很酷，于是我们展开了交流。
有天他通过在线聊天平台给我发消息，"我正在波兰找实习，但没有找到合适的机会。" 我回复，"我们在考虑启动Python Torch项目，我这里有一个实习名额，你可以来面试看看，如果合适，你可以负责我们之前设想的PyTorch项目。"当时，我们以及一些来自NVIDIA的Luca Antiga等组成了一个来自不同公司的在线团队，共同推进这个项目。于是，Adam Paszke加入了我们团队，我们和Sam Gross全职投入到了该项目，PyTorch就这样诞生了。
我认为，PyTorch的DNA中天然融入了社区赋权理念，我们从一开始就坚持这一点，并且许多人都参与了PyTorch的开发，虽然大家可能在现实中素未谋面，但经过多年的共事，已经成为了线上好友。
在社区建设中，这种信任和模糊感十分重要。显然，你需要对团队成员保持信任，但并非每个人都具备同等的能力，也并非每个人都会成绩斐然。我们这么做，并不是为了追求某种预期的最终目标，而是为了观察发展走向。
Lukas Biewald：我听说很多开源社区都面临一个问题：可能会出现不良氛围，或者在这种高度分散的状态下难以做出决策，你是否遇到过一些棘手的情况，比如某件事需要大家共同解决，但却无法达成一致？
Soumith Chintala： 当然。我认为，自己为PyTorch带来的最有价值的贡献之一就是塑造了其社区文化，并在社区中构建了有效的激励机制。
在构建社区时，激励机制至关重要。我也确实遇到过一些棘手情况。例如，在过去几年中，Torch社区最重要的贡献者之一对于使用Python方向持有异议。
想象一下，如果你有一位不断高效输出代码的人才，但他对于项目的方向存在不同看法，你该如何应对？你会妥协于他的愿景，还是努力说服他改变想法？很多时候，未来的方向充满了不确定性，很难预测，也没有一个确定的正确答案。你只能根据长远目标和方向做出选择，这同样适用于构建激励机制。
在我看来，很多社区最终走向衰败的原因是他们不敢清除不友善的成员。社区管理员必须采取积极行动，阻止这些人进入社区，但有时难免有漏网之鱼。然而，我们绝不能允许他们在社区内传播不良言论。你必须把社区成员视为家人，与其保持紧密联系，积极进行保护。如果有人行为不当，就应该果断地将他们排除在社区之外。
Lukas Biewald：从一个开源社区中排除某人，这意味着什么？
Soumith Chintala：首先应该大胆直言，让社区成员充分了解规范。第一步是确立明确的规范，告诉成员什么能做，什么不能做 。例如，在PyTorch开发早期，社区有一位平时表现良好的成员，他在随机频道上发布了一个带有性别歧视色彩的段子，我看到后立即与他进行了沟通，告诉他请不要再发布类似内容。通过这种方式，我们设定了社区基调，向社区成员明确了哪些行为是不被允许的。
在很多社区中，大家不太愿意成为那个强制执行规定的人，因为我们难以把握其中的微妙平衡，如果干涉过于频繁，可能会显得缺乏人情味。但我想强调的是，从一开始我们就强烈推崇一种激励方式，在与人交流时，不妨提出一些问题：如何打造社区？如何扩大社区规模？其中见效最快的方法之一是引入激励制度，为那些做出贡献的人提供金钱或礼物奖励。
我认为，当动机源于内在自驱力时，开源项目通常会运行得非常顺利。因此，我一直秉持着一个指导原则，至少在社区达到临界规模前要遵循：不要依赖外在动机来建立社区，因为一旦你取消了激励措施，那么社区将很难长久维持。 要弄清楚人们是否会自发参与，这才是最重要的，也是吸引人们参与社区的关键所在。
Lukas Biewald：你多次提及了激励的重要性，同时也指出了哪些激励方式并不适用。但我猜测你也有意识地采用了特定的激励方式，以催生你所期望的行为。
Soumith Chintala： 通常情况下，人们只会对特定类型的优质工作或辛勤付出给予认可，而在随后的时间里，继续关注和认可这些贡献才是真正重要的。
PyTorch社区的许多贡献者任职于各大公司，很多时候他们所在公司的激励机制并不足以充分认可他们的付出。有时，我会直接给某位贡献者的上司写推荐信，希望推动社区成员的晋升，甚至不限于我所在的公司，我会向他们所在公司的领导解释该贡献者所面临的挑战和他们的出色表现，以帮助他们得到应有的认可。
各种形式的认可都非常重要，这些认可能够激励人们坚持自己想做的事。同时，社区成员们也有自己的生活，他们会受到社交和外部因素的影响，因此，我们应该努力去支持和帮助他们。
Lukas Biewald：记得在PyTorch 0.3和0.4版本时，实际上是我首次将PyTorch与Weights & Biases进行整合。那时PyTorch似乎经历了大量的破坏性API变更，我一直在思考，回头来看，这究竟是不是一个明智的计划，它是否鼓励你们勇敢向前迈进，还是说一切仅仅是无心之举呢？
Soumith Chintala： 在我看来，这是一个相对的问题。人们常常把 PyTorch与Tensorflow和MXNet进行比较，他们会说，"我用 PyTorch 0.2编写的代码到今天仍然可以运行"等等。因此，我们一直认为PyTorch在处理破坏性变更（Breaking changes）方面表现出色，在项目内部，团队成员也充满激情，并且非常注意避免破坏用户的代码。
我们坚信，即使是用户代码中的错误也是我们的问题。一旦用户出现问题，我们将尽全力修复和解决。
Lukas Biewald：如果能够重构PyTorch，你是否会从根本上做出一些改变？
Soumith Chintala： 如果有机会从头开始，我会采用与2016年完全不同的构建方式。那时，我们觉得PyTorch并没有太大的问题。
但如果现在重构，我会大量使用Python，并且将很多内核部分用Triton编写，减少使用C++，同时做整数的boxing，以便更好地支持符号整数等特性，这样用户就不需要在每处都用张量来处理。
如今的做法会有所不同，因为硬件和编译器发生了很多变化，我们会更加紧凑、高效地编写代码。
3
开源成功的衡量指标
Lukas Biewald：在开发PyTorch时，你们如何衡量成功与否，或者说你们关注哪些具体指标？虽然你曾提到不关注无关紧要的指标，比如GitHub的star数或者性能基准测试，但你们是否会通过具体的指标来衡量成功？或者说你们是靠直觉，并没有具体标准？
Soumith Chintala： 我们认为，指标是帮助我们衡量成功的一种方式。在产品开发过程中，很多人会过早地制定指标，他们认为优化或测量指标能给他们提供一条客观且稳妥的成功之路，这在构建性能产品或明显可测量的产品时可能有效，但就PyTorch而言，我们的目标是为用户提供更好的体验，用户体验具有高度主观性，就我所知，目前还没有一种得到普遍认可且有效的用户体验衡量指标。
因此，在最初开发PyTorch的两到三年间，我们使用了一些信号来进行衡量，比如下载量和引用PyTorch的研究论文数量，但我们的产品迭代主要取决于收集到的用户反馈。我个人每天会阅读500条来自论坛和Twitter的信息，并尽量回复。我们会与客户直接互动，积极交流。我们有一个由六人组成的优秀团队，他们会与我们的高价值客户或者对PyTorch生态系统带来巨大价值的客户保持紧密联系。这个过程能够帮助我们不断迭代、改进产品，并确保我们朝着正确的方向行进。
对我来说，我们使用的指标更多是一种保证，检查我们是否还在正确轨道上，但实际上，我们并不以这些指标来指导开发周期，也并不用它来激励我们向成功迈进。
Lukas Biewald： 当你们规划发展路线时，如何选取用户意见呢？你们会采纳或忽略何种意见？
Soumith Chintala： 我们基本上会从各种渠道汇总反馈意见，包括论坛、Twitter、 Slack等直接进行重要互动。在规划期间，大约每六个月，我们会对所有反馈进行综合排序，按照反馈的关注度加权排序，然后进行决策。另外，我们会询问团队成员，了解他们的期望。我们拥有一支由PyTorch团队工程师组成的团队，会询问他们愿意投入精力去做哪些事。通常情况下，这种匹配效果还不错。
对于一些有趣但排名靠后的功能，我们可能会考虑开发这些功能；但对于需求量低且排名靠后的功能，我们就不会选择进行开发。所以，功能开发与否也有一部分取决于该功能是否新颖有趣，这会帮助我们自然地进行选择。这是我们处理大多数功能决策的一般方法。
另外，我们还有一部分深层策略，例如推出会显著改变产品的功能，比如现在需要推出Torch编译等功能。这些功能通常不会来自用户反馈。我们有一个自然的管理层次结构，其中有一些核心维护者，在讨论策略时，我们会根据行业变化趋势来决定如何以及何时进行调整。
4
符号执行模型 vs Eager 执行模型
Lukas Biewald：符号执行模型和Eager执行模型之间有哪些考虑因素呢？你如何看待这两种模型？
Soumith Chintala： 符号执行模型并非一个新的概念，实际上，我认为TensorFlow和PyTorch是Theano和Torch这两个前一代框架的自然升级版本。Theano类似于TensorFlow，PyTorch类似于Torch，它们分别代表符号执行模型和Eager执行模型。
一般来说，那些喜欢和关注符号执行模型的人相信编译能力以及从系统中提取更多性能的能力；而那些相信Eager执行模型的人则认为，虽然编译器总是声称能够带来性能提升，但从未真正实现。
因此，2016 年构建PyTorch时，我们和之前使用Torch的社区更加相信需要以通俗易懂的语义来运行程序的需求。就像我提出运行要求，程序就开始执行，而不需经过五层抽象。这种根本原则上的差异不仅仅存在于深度学习领域，在图形领域也存在同样的情况。
在 80 到 90 年代，图形领域有立即（immediate）执行模式和流水线（pipeline）执行模式，最终立即执行模式因其简易性而胜出。因此我认为，这是一个有关人们内在偏见的深刻的原则问题，即他们更倾向于选择其中一种模型。
Lukas Biewald：有趣的是，这其实取决于你正在做的事，编译器广泛应用于各个领域，且发挥了重大作用，所以，为什么深度学习会更倾向于即时（JIT）执行模型？
Soumith Chintala： 我认为，需要根据特定情况评估某个事物是否在给定的时间段内具有价值。2015年，编译执行模型并没有产出很大效益，其中有两个原因：一是，当时的机器学习编译器还不够成熟和复杂，人们需要进行更多的研究和工程相关工作，使得这些编译器能够实现有用的功能；二是，当时的加速器主要是NVIDIA的GPU，已经由即时执行模式进行了充分压榨利用。
现在，编译器的复杂和成熟度都有所提升，足以从编译模型中提取出更多性能，加速器也变得更加快速和庞大，除非对你的模型进行编译，否则无法充分利用GPU，因为与GPU的速度提升相比，神经网络的大小相对保持不变。在GPU上，计算能力的增长速度比内存宽带快得多，因此在计算宽带比（bandwidth ratio）的时候使用即时执行模式是可行的。但现在，你被迫进行编译，否则将受制于内存带宽，就需要在计算时尽量多的使用寄存器，否则将受限于将数据从寄存器传输到主内存的速度。
Lukas Biewald： 随着时间推移，会有更多人转向编译模式吗？
Soumith Chintala： 是的，这也是去年年底我们在PyTorch 2.0中投入并发布编译模式的原因。
我们预计，AI和深度学习领域会经历两个阶段。首先，人们会进行实验和迭代调试，不断修改和尝试各种方法。在这个阶段，Eager模式仍然占主导地位。第二阶段，人们可能会花两天、两周或两个月（根据具体情况而定）来运行大规模实验，这些大规模实验都将使用编译模式，这能带来 2 至 5 倍的性能提升。
Lukas Biewald：四五年前，使用PyTorch和TensorFlow时，我并没有利用修改模型的实时功能，但我发现PyTorch更易使用。在没有充分使用Eager模式提供的其他功能，且编译模式速度更快，在绝大多数常规任务中表现良好的情况下，为什么像我这种相对不太精通这方面的人会更偏向使用PyTorch？
Soumith Chintala： Eager模式和编译模式有所不同，TensorFlow 1使用的是符号编程，实际上你也可以写一个Eager模式的符号编程。相比PyTorch，你之所以觉得TensorFlow难用，是因为你进行的是符号编程。
这就像元编程，你不仅需要挖掘探索想法，还需要思考如何将这个想法嵌入到另一个复杂的符号系统中去。类似于你有一个想法，知道如何将这个想法付诸实践，但如果把你的想法写成一个数学方程，这就需要认真思考了，因为脑海中的想法和数学方程有着本质上的区别。数学符号本身是一个独立的系统，你需要思考"用这个数学表达式，还是用那个表达式来表达思想"，所以，很多人做数学运算并不像那些熟练掌握数学、写过证明的人那样快。
PyTorch可以使用Python，用户只需编写程序，无需做其他事。而 TensorFlow是一个符号编程系统，用户需要进行额外训练自己使用 TensorFlow，这是人们面临的主要挑战。Jax试图摆脱符号编程，直接使用NumPy。我们将尝试恢复符号编程，并让PyTorch使用 torch.compile，用户就无需考虑如何进行编译，只需在程序中调用 torch.compile。总之，符号编程是TensorFlow面临的主要问题。
Lukas Biewald：为什么你们需要这么长的时间来构建编译模式呢？如果你已经在运行这些任务时进行了编译，为什么还需要全新版本？
Soumith Chintala： 这是我们构建的第五版编译器，我们在其中投入了大量时间，致力于将其调试到最佳状态。目前我们面临的最大挑战是，如何仅调用torch.compile来完成所有任务，而无需给用户增加额外的认知负担。用户无需考虑程序是否兼容、是否需要调整代码、是否收到错误消息等。
为此，我们进行了大量研究和尝试，旨在实现对部分Python程序的无缝覆盖。当我们无法恢复程序并进行编译时，可以回退到Python上。在此基础上，我们还需要提高程序的运行速度。如果无法加速，用户可能会选择使用编译模式，但这实际上对用户没有实际意义。
对于这些编译器，尤其是前两版编译器，从2016年开始至2020年左右，人们已经掌握了获取程序后进行加速的方法。但现在我们面临的最大挑战是，如何正确且高效地获取程序，我们在2021年12月首次构建的 TorchDynamo取得了系统性突破，并在去年12月发布之前对其进行了为期一年的改进与优化。
Lukas Biewald：实际上，要执行梯度下降算法来计算任意代码的梯度是相当复杂的。我感觉可能存在某个数学定理，表明我们无法计算生成的任意代码梯度。那么，是否存在某些特殊情况，在这些情况下执行任意操作时，无法找到梯度？
Soumith Chintala： 在不连续的编程结构下无法计算梯度，例如计算某个最大值时，计算梯度可能变得困难。在这种情况下，只有通过最大值的路径才能计算梯度，而其他地方的梯度为零。这意味着，梯度是正确的，但不符合传统的连续梯度的概念，即并非一个平滑的函数。实际上，在边缘处可能不存在梯度。然而，通常情况下，因为大多数人在程序语言中尝试的内容在数学上是可微分的，尤其是在处理张量时，所以计算梯度是可行的。
5
底层硬件与上层库
Lukas Biewald：你们如何看待构建在PyTorch之上的库，比如 fast.ai或者Lightning？你们是否会尽量避免推出与其重复的功能并与它们合作？
Soumith Chintala： 我们的工作原则是尽量提高效率，减少工作量。我们坚信要为社区赋能，同时也想从社区中分一杯羹，因为我们还处于发展阶段，还很"饿"。与社区规模相比，我们团队的规模并不是很大，所以除非激励机制完全不一致，否则采取其他策略对团队自身是不明智的。
通常情况下，当我们考虑采取某个方向时，我们首先会确保社区中没有其他人对此感兴趣；如果社区中有人对此感兴趣，我们会观察一段时间，判断他们会成功还是失败。我们通常会选择社区不感兴趣但却有大量社区成员感兴趣的方向，这种社区和成员兴趣的不对称性对我们来说是最理想的发展方向。
因此，我们与fast.ai、Lightning以及社区中其他利益相关者密切合作，为他们提供赋能，挖掘他们的潜力。这样做对我们来说大有益处，他们做得越多，我们需要做的就越少。因为我们有成千上万个待处理问题，不可能将其全部完成。这就是我们对建立在 PyTorch之上的库的看法。
Lukas Biewald：你们是如何与Facebook AI Research (FAIR) 合作的？FAIR能得到什么好处？为什么他们会投资？除了开发 PyTorch，你们还做了哪些事？
Soumith Chintala： Meta之所以投资PyTorch并保持其开源，主要是因为PyTorch庞大的生态系统。通过使用与行业中其他人相同的工具，Meta能够更快地迭代自己的AI工作。例如，当有新的AI工作开发出来时，很大一部分是在PyTorch中运行的，因此，像Google这些企业内部的应用科学家需要将其转换为TensorFlow，并进行适当测试，这些大企业倾向于使用自己构建的工具，但是使用PyTorch这些与行业中其他人相同的工具有助于加速应用过程。
此外，PyTorch作为一个流行工具，使得Meta在开展新项目时能够从其他人的工作中受益，同时也能吸引一些人才。然而，人才招聘只是整体利益中的一小部分，最主要的还是PyTorch庞大生态系统所带来的好处。
Lukas Biewald： 从这个角度来看，成为标准对PyTorch来说肯定非常重要，除了你不断提到的构建最高质量、最有用的库之外，你们是否还做了其他措施，推动PyTorch成为增长最快的标准深度学习框架？
Soumith Chintala：一般来说，如果你试图成为标准，往往很难实现这个目标；但如果你致力于构建最优秀的产品，成为标准的可能性会更大。很明显，除非存在两个或多个意识形态有显著差异但都非常成功的项目，这样才会导致多个标准的并存。
老实说，我们努力做的唯一一件事就是构建最卓越的科学计算框架，当然我们也希望这可以帮助我们在其他方面取得成效，比如成为标准。然而，一开始我们并未将成为标准作为最初目标。
Lukas Biewald：芯片在其中扮演了什么角色？PyTorch是如何与硬件供应商相互协作？
Soumith Chintala： 我们将自己视为两类客户的供应商，一类是前端使用PyTorch的用户，他们通过PyTorch表达自己的数学思想以完成工作；另一类是后端客户，即服务器端和边缘端的硬件供应商客户，他们努力使自己的硬件在PyTorch的抽象层下良好运行。如果运行成功，他们将自动获得数百万客户的认可。
我们在现有平台上（例如NVIDIA GPU和CPU）的工作很大一部分是性能调优，例如，新GPU的性能特性发生了变化，因此我们必须更新内部代码和传递方式，以提高性能。而在新平台上（如AMD、Mac GPU或TPU等其他加速器）的工作主要是功能补全，因为PyTorch的API非常庞大，约有一千个API函数，再加上是否使用量化张量、常规张量以及其他各种分布式功能，这使得维护PyTorch的后端平稳需要投入大量工作。所以在与新供应商（TPU、AMD GPU和Apple等）合作时，我们经历了大量从零开始的工作。
6
新兴框架的竞争
Lukas Biewald：可以看出，你对一些新的框架如JAX、Tinygrad、GGML等非常感兴趣，你比较欣赏哪些方面的技术创新？
Soumith Chintala： JAX试图成为一个纯函数图整合框架，利用其纯函数特性使用户能够进行功能强大的函数转换，就像函数编程者使用 map 和 reduce 等函数式转换。JAX将这一功能开发到了极致，我认为它的理念可能是"函数式深度学习"。
JAX在验证和挖掘众多优秀想法方面十分出色，它推翻了很多不太实用的想法，这些经验有助于我们从多方面了解自身的发展方向。
GGML和Tinygrad稍有不同。GGML采用了全面垂直一体化方法，他们的思路是，如果我们只需要为LLaMA构建一个框架，它只有一个生命周期，那我们该如何将这个想法推向极致？
他们正在从事一些相当有趣的探索，例如研究量化在何种情况下有效，探究用户的偏好以及在Mac等设备上性能的基准等等。这些都是非常有用的信息，通过GGML能够快速验证这些想法，帮助我们更好地了解和指导自己的工作。
关于Tinygrad，正如Jihad所说，我们认同复杂指令集，然而，对于深度学习而言，简化指令集已经足够，因为不太需要涉及控制流和其他因素。虽然我们不完全认同这一观点，但这个方向值得探索，可能会取得令人惊喜的成果。或许他会构建一个出色的AMD后端，或者在未来的开发中我们会看到它的应用。因此，我非常欣赏开发者选择与我们不同的道路并积极探索。
总之，我对竞争保持着密切关注，尤其是良性竞争，这不仅对用户有益，对我们自身也十分有益，它激励我们不断进步。例如开发JAX时，我们积极参与其中，试图向他们提供有益建议，告诉他们该做什么，不该做什么。
JAX发布时，我们努力向用户宣扬其优点，树立其声誉，并用我们的个人账号转发相关内容等。我认为，JAX正在探索一种很有趣理念方向，我相信其间会涌现很多其他优秀想法，即便我们可能不会直接采用JAX模式，但它也将帮助我们形成自己的认知并获得启示。
Lukas Biewald：据我观察，特别是在最近一段时间内，Weights & Biases的发展呈现出一种趋势：从过去传统的机器学习研究者和机器学习工程师逐渐偏向软件开发，他们对机器学习有一定了解，但更专注于底层技术性框架，更注重底层实现。你是否在自己的项目中也观察到了这种趋势？
Soumith Chintala： 是的，我们目前观察到的一个流行趋势是，很多用户甚至并不知道他们在使用PyTorch，他们只知道自己正在使用被打包的Mac应用或者通过Hugging Face等提供的稳定扩展功能。因此，我们正在认真思考这一点，实际上，这也是我们目前正在解决的关键问题之一。
我认为这与以杠杆效应的角度来思考整件事有关。我们的客户主要分为两部分，一是硬件供应商，二是用户。关于硬件供应商，NVIDIA一直处于主导地位，虽然我们也尽力帮助其他供应商，但他们的市场份额相对较小。在用户方面，PyTorch则一直保持相对平衡，没有单一的主导用户群。然而，现在出现了一个新的用户群，他们的规模迅速扩大，甚至不直接使用我们的API。从战略角度来看，我不认为这会对我们的产品构成生存威胁，但从杠杆动态变化的角度来看，这对PyTorch至关重要。
如果一个前端应用要求我们更改API，但这与我们的理念不一致，我们却没有反向杠杆来回绝他们。因为正如我之前所说，PyTorch非常务实，致力于为用户服务，虽然也有一些基本的方法论原则，但在很大程度上它们都非常低级，除此之外，我们做决策时都以务实为导向。所以我主要担心你刚才谈到的这一方面，但目前我还没有解决方案可供分享。我们正在积极思考如何应对这个问题.
7
开源 vs 闭源
Lukas Biewald：对于开源模型和闭源模型，这是一个一直备受争议的话题。可以看到Stability.ai开源了许多模型，同时也有许多人转向了HuggingFace。然而，在进行语言模型提示工程时，大多数客户仍在使用GPT-4、Anthropic和 Cohere等模型。这种情况有可能改变吗？
Soumith Chintala： 显然，我对这种现象存在偏见，我将成年后的大部分时间用在了开源领域，甚至在我工作之前，也一直将开源视为兴趣所在。我从开源中获得了一种解放，一种透明度和一种赋权感。如果没有开源，当时我在印度与父亲共用一台性能较低的笔记本电脑时，可能不会像现在这样有能力完成一些任务，因为我们当时无法购买昂贵的软件。
开源和盗版二者间只有一个具有合法地位，这是事实。所以为什么还要开源呢？这是个常见问题，还有类似于"为什么要将自己的产品无偿分享出去？"或者"为什么不利用它来赚更多的钱？"等问题，这些问题都是可以理解的。开源确实能够带来收益，但如果不考虑知识产权，很明显，一些大模型可能会因为安全性和可靠性等问题而被认为不适合部署。
这是一个有关价值取向的争论，取决于你更看重什么。如果你认为赋予人们更多权力更加重要，比如让尼日利亚的孩子能够访问这个模型，并在当地按照自己的意愿进行创作，那么短期内可能会导致模型的垃圾信息激增。
如果你认为权衡开源的利弊更为重要，即使可能带来轻微的负面影响；或者坚信"开源会导致灾难，人工智能会造成人员伤亡"等观点，这确实取决于个人信仰。这并不是一个确定的结果，你无法准确估计事件发生的概率，所以人们会用他们认为正确的方式做决策。
我相信，当前这一代甚至下一代的AI模型不会对人类构成任何危险，并且开源利大于弊，因此我赞同开源。
我深信，社会具备强大的适应能力，这种能力是一个不断重复的过程。每当出现颠覆性变革时，总有一部分人认为社会即将崩溃，而另一部分人则坚信我们能够平稳度过。事实上，社会几乎总是能够非常出色地适应变化。无论是印刷术、工业革命还是互联网等技术变革，人们往往低估了社会适应新事物的能力。这就是我的观点，尽管这种观点可能在某些地方并不受欢迎。
8
机器人领域的探索
Lukas Biewald：关于机器学习，你认为哪些方面被低估了？
Soumith Chintala： 在当前机器学习受到高度关注的情况下，我们很难找到其被低估的领域。但我认为，人们应该投入更多的时间构建一种系统，将80年代的符号推理系统与我们今天所看到的端到端神经网络系统相结合。这种符号推理系统在90年代很受欢迎，在21世纪初也产出了大量成果。许多人在80年代和70年代末就因这些方向性系统研究获得了图灵奖。
Lukas Biewald：将机器学习应用于现实世界的最大挑战是什么？
Soumith Chintala： 人们总是高估了机器学习在解决问题时发挥的作用。虽然机器学习可能会解决问题中最具挑战性的部分，但往往只占整个问题的一小部分。人们经常会惊讶地发现，AI并不是一个简单的魔法工具，只需一挥手就能解决所有问题。
AI的大部分进展，无论是研究还是应用，都涉及构建损失函数，必须非常仔细，否则它就无法按照你期望的方式工作。损失函数，或者所谓的反馈循环在指导方向上扮演着重要角色，它的影响力相当大，效果常常让人吃惊，但它往往被严重低估。
Lukas Biewald：听说你正在开展家务机器人项目。
Soumith Chintala： 大约12年前，我开始涉足机器人领域，在此投入了几年的研究。然后在2019年和2020年左右重新开始关注机器人领域。这个决定源自一个非常简单的动机，我不喜欢做家务，因此我想将这些琐碎的任务自动化。但我逐渐认识到，实现家务活的自动化并不容易，这是一个值得深入研究的问题。
我的动机非常单纯。我认为，机器人在某种程度上拥有强大的力量：如果你也喜欢偷懒，可能也会得到很好的结果。我每周花半天的时间与纽约大学的Lerrel Pinto教授以及一群学生一起探索这一领域。机器人大致可以概括为：肌肉和骨骼（即构建硬件）、构建大脑和传感器（主要是构建智能）以及与人类交流。如果机器人拥有智能，就可以完成各类任务，但是，机器人是否能够与人类进行有效的交流呢？这是一个值得探讨的问题。
机器人学作为一门基础学科，关键问题在于能否制造出机器人，这其中涉及脑科学，即如何使机器推理和观察世界。我在这方面提供了一些帮助，主要是因为许多人都在从事这个领域的工作，特别是在深度学习和机器人学的交叉领域。此外，还有与人类互动的部分，我并不仅仅指学术角度上的人机交互（HCI、HRI）。
更多是从产品方面来看待这一问题，就像你第一次使用iPhone时，一切都是如此自然流畅，无需特意学习，类似于这种与机器人进行交流的方式，已经有很多人在这个领域进行深入研究和探索。
因此，我更专注于这方面的工作，致力于通过手势和动作的组合，迅速教导机器。我对这个领域非常感兴趣，机器人距离现实应用还有很长的路要走。
我预计，大约七年内，能够在家中实现某些人机交互流程的自动化，尽管这并不是一个能够适用于各类环境的通用解决方案。也许到那时候，会有更多的资本注入其中。我认为，这个领域将从依赖政府拨款支持的研究项目逐渐转变为一个能够实现更大规模应用的新兴产业。时间会揭示答案，这个过程会非常有趣。
欢迎 Star、试用 OneFlow 最新版本：