本文永久链接 – https://tonybai.com/2026/04/18/ollama-from-open-source-hero-to-community-enemy

大家好，我是Tony Bai。

两年前，在本地大模型的蛮荒时代，Ollama 曾如一道神光，照亮了无数普通开发者的探索之路。

凭借那句魔咒般的 ollama run llama3，它以一种近乎“降维打击”的优雅，将普通人与本地 AI 之间的天堑夷为平地。

一时间，Ollama 被盛赞为“本地 AI 的 Docker”、“开源精神的典范”，几乎成了无数技术布道者口中的“开源英雄”。

但就在几天前，一篇名为《本地大模型生态系统不再需要 Ollama》的文章，在技术社区 Hacker News 上，引发了一场“社区公审”。

文章详细罗列了 Ollama 在享受了社区的赞誉之后，犯下的种种“罪行”：从对核心依赖 llama.cpp 长达 400 多天的“选择性遗忘”，到试图用私有模型格式“绑架”用户，再到其背后若隐若现的“VC 商业化”套路……

一夜之间，Ollama 的形象从“屠龙少年”，变成了那条它曾经挑战的“恶龙”。

今天，我们就来深度复盘这场顶级社区的大讨论，看看这位曾经的“开源英雄”，究竟是如何一步步走向“社区公敌”的深渊的。

第一宗罪：对生身之父的“背叛”与“除名”

Ollama 之所以能如此快速地在各种平台上运行大模型，其背后最大的功臣，是一个名为 llama.cpp 的 C++ 开源库。llama.cpp 是真正负责模型推理的底层引擎。

Ollama 的 v0.0.1 版本，在其 README 中曾明确写道：“一个用 Go 编写的快速推理服务器，由 llama.cpp 驱动。”

Ollama 的本质，是一个基于 llama.cpp 构建的、优化了用户体验的“包装器（Wrapper）”。

然而，随着 Ollama 的声名鹊起，llama.cpp 的名字，却在其官网和宣传中，被刻意地、系统性地抹去了。

在 Hacker News 的帖子中，有用户愤怒地指出：

“这根本不是开源礼仪的问题。MIT 协议只有一个核心要求：包含版权声明。Ollama 没有做到。”

“社区注意到了。GitHub Issue #3185 在 2024 年初就被提出，要求 Ollama 遵守协议。这个 Issue 在 400 多天里，没有得到任何维护者的回应。”

直到社区忍无可忍，发起了 PR，Ollama 的联合创始人才最终在 README 的最底部，加上了一行极其微小的致谢：“llama.cpp 项目由 Georgi Gerganov 创建。”

这种对核心上游项目近乎“羞辱性”的冷处理，被社区视为一种赤裸裸的“背叛”，激怒了所有信奉开源精神的开发者。

第二宗罪：用“私有格式”构建“数据监狱”

比忘记致谢更让开发者无法容忍的，是 Ollama 为了“锁定用户”，而精心设计的私有化模型存储格式。

如果你用过 Ollama，你一定经历过这样的困惑：

你用 ollama pull 下来的模型文件，被存储在你的 Home 目录下，文件名是一串毫无意义的哈希值。你根本无法将这个 GGUF 文件，直接分享给其他工具（比如 LM Studio 或 Jan）使用。

Hacker News 的一位用户一针见血地指出了这个设计的“阴险”之处：

“我停止使用 Ollama 的原因就在于此。我能理解他们可能是为了做去重（Deduplication），但这使得我无法与其他工具共享同一个模型。每个工具都只能指向它自己的文件。无论他们的意图如何，这都在客观上，让你极难尝试其他工具。”

更糟糕的是，Ollama 会在下载模型时，对原始的 GGUF 文件进行一些“魔改”，并使用自己的一套私有配置。这导致了另一个灾难：性能下降。

有人在评论中分享道：“我最近开始使用 Jan，然后用 llama.cpp 和本地的 Ollama 跑同一个模型，llama.cpp 的速度明显更快。”

用更差的性能、更封闭的格式，换取所谓“简单”的用户体验。这背后，是典型的“建立围墙花园”的商业化思维。

第三宗罪：“VC 死亡陷阱”的经典复刻

Ollama 为什么要这么做？

一位用户在评论中扒出了 Ollama 创始团队的“前科”，让所有人恍然大悟。

“Ollama 是一家由 Y Combinator 支持的创业公司，其创始人之前构建了一个被 Docker 收购的 Docker GUI 工具。这个剧本太熟悉了：
1. 包装一个现有的开源项目，做一个用户友好的界面。
2. 建立用户基础，获得社区信任。
3. 融资，然后想办法商业化。
4. 最小化对上游的致谢，让产品看起来是自给自足的。
5. 创造锁定，用私有格式和哈希文件名，让用户无法迁移。
6. 推出闭源组件（GUI App）和云服务，开始收割。”

这套从 Docker 时代的 Kitematic 延续而来的“VC 死亡陷阱”，正在本地大模型领域被完美复刻。

社区的反击：大逃杀与“去 Ollama 化”

在这场社区的“公审”中，愤怒之余，开发者们也给出了大量极具建设性的“替代方案”。一场“去 Ollama 化”的大逃杀正在上演。

方案一：回归 llama.cpp 本身，王者归来

很多用户惊讶地发现，在他们唾弃 Ollama 的这段时间里，llama.cpp 自身已经进化成了一个极其强大的“完全体”。

它现在不仅自带了现代化的 Web UI（通过 llama-server），支持 OpenAI 兼容的 API，甚至还推出了“路由模式”，可以实现模型的“热插拔（Hot-swapping）”。

方案二：拥抱真正开放的“包装器”

社区推荐了大量同样易用，但秉持着真正开源精神的替代品，比如：

• LM Studio：自带强大的 GUI，底层使用 llama.cpp，暴露所有可调参数，支持任何 GGUF 模型，不搞“锁定”。
• Jan (jan.ai)：另一个开源的桌面应用，界面清爽，设计本地优先。
• llamafile：由 Mozilla 支持，可以将模型和 llama.cpp 本身打包成一个“单一可执行文件”，真正实现“一键启动”，且完全开放。

小结：当便利性遭遇开源精神

Ollama 的故事，是近年来开源商业化领域最值得深思的一个案例。

毫无疑问，Ollama 解决了本地大模型领域一个极其真实的痛点：极致的易用性（Ease of use）。它就像当年的 Docker，让无数普通人跨越了复杂的门槛。

但在追求极致 UX 的同时，它却似乎忘记了自己赖以生存的根基——那个由 Georgi Gerganov 等无数开源贡献者用爱发电构建起来的 llama.cpp 生态。

Hacker News 上的这场论战，并没有全盘否定 Ollama 的价值。但它向所有试图通过“包装开源”来构建商业帝国的创业者，提出了一个极其严肃的警告：

用户体验的简化，永远不能以牺牲“开放性”和对上游社区的“尊重”为代价。

你可以站在巨人的肩膀上，但你不能在站上去之后，假装那个巨人不存在。

作为开发者，我们享受着开源带来的巨大红利。但在选择工具时，除了便利性，我们或许也应该多一份清醒：去看看它的背后，是否隐藏着一个正在试图关上的“围墙花园”。

资料链接：

• https://news.ycombinator.com/item?id=47788385
• https://sleepingrobots.com/dreams/stop-using-ollama/

今日互动探讨：

你在使用 Ollama 时，是否也曾被它私有的模型管理方式所困扰？对于“包装开源”并进行商业化的模式，你是支持还是反对？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/04/17/the-origins-of-gpu-computing

大家好，我是Tony Bai。

在今天的人工智能时代，GPU 已成为数据中心的核心算力引擎，但它的崛起并非一夜之间的奇迹。ACM通讯文章《The Origins of GPU Computing》回溯了 GPU 计算的三十年发展史，揭示了从并行计算、图形系统到流处理等关键技术如何在政府资助的学术研究中逐步成熟，并最终汇聚成推动深度学习革命的基础设施。文章不仅梳理了技术脉络，也展示了学界与产业之间如何通过人才与思想的流动，共同塑造了现代 GPU 计算的格局。

本文是这篇文章的译文，供大家学习参考(格式有调整，更适合公众号阅读)。

政府资助的并行计算、流处理、实时着色语言和可编程图形处理单元（GPU）的学术研究直接推动了 GPU 计算的发展。GPU 被广泛应用于现代数据中心，并促成了当前的人工智能（AI）革命。生产 GPU 的英伟达（Nvidia）现已成为世界上最有价值的公司。这种计算变革及其产生的经济价值，得益于超过 30 年的政府资助研究。政府资助不仅有助于发展许多关键的技术创新，还培养了大量将这些技术带入行业的学生。

本文追溯了 GPU 计算的起源。我们首先描述了 GPU 计算所构建的技术（并行计算、并行图形系统、可编程着色器(shaders)和流处理）的发展，然后详细介绍了这些技术是如何转移到英伟达和其他公司，并最终应用于现代机器学习的。

赋能技术

GPU 计算建立在并行计算、并行图形系统和流处理的早期工作基础上。这些技术是通过超过 30 年的政府资助学术研究发展而来的。

并行计算

当你学习计算时，你了解到的是中央处理器（CPU）按顺序执行一系列指令。

实际上，芯片包含数十亿个并行切换并由导线连接的晶体管。开关和导线是物理计算机的基本构建块，它们同时运行。

此外，晶体管切换消耗的能量很少，而沿导线的通信消耗的能量要多得多。

通信需要功率来将信号从一点发送到另一点；功率随着距离的增加而增加，如果是在芯片之间进行信号传输，功率消耗将非常巨大。

虽然顺序计算机可能比并行计算机更容易理解，但顺序计算机必须通过同时切换的晶体管和同时传输信息的导线来实现。顺序计算机使用许多晶体管并行计算结果，然后仔细地以与顺序执行一致的方式组装这些结果。

创建这种执行是顺序的“幻觉”，在功率和性能上都是低效的。随着可用晶体管数量的增加，这种低效性也随之增加。在现代半导体技术中构建计算机的自然方式是设计并行计算机。GPU 比 CPU 更高效，因为它们是大规模并行计算机。

GPU 计算建立在并行计算的早期工作之上。与所有并行计算机一样，在 GPU 上运行的并行任务或线程必须相互同步和通信。

线程需要通信来使用由另一个线程产生的数据。同步是必要的，以在数据可用时发出信号，确保消耗的是正确的值。

并行计算、同步和通信的许多基础知识是由政府资助的学术研究开发的。由加州理工学院 Chuck Seitz 领导的 DARPA 资助的“宇宙立方”（Cosmic Cube）项目发展了并行计算的许多基础知识。在该项目上开发的硬件是英特尔 iPSC、Delta 和 Paragon 机器的蓝图，以及几台早期的能源部 ASCI 机器。“Cosmic-C”编程语言引入了异步消息传递和集合通信，后来以消息传递接口（MPI）的形式成为编程大型并行机器的标准。

麻省理工学院（MIT）的 DARPA 资助的 J-Machine 和 M-Machine 项目开发了用于通信和同步的低开销机制，以及现代互连网络的许多关键方面。这些机制使得并行性可以在非常细的粒度上被利用，最少只需 10 或 20 条指令即可作为一个可调度的工作单元。J-Machine 的许多特性被 Cray T3D 和 T3E 计算机直接采用。

并行计算有着超越这一特定历史分支的丰富历史。由于篇幅有限，我们无法进行完整的综述。Culler 等人的文章提供了一个很好的回顾。

GPU 计算与所有高性能计算一样，深受这一遗产的影响。它使用 MPI 进行节点间的通信，使用互连网络连接这些节点，并且在此研究过程中开发的许多通信和同步机制被用于协调并行计算。

并行图形系统

虽然不如传统的并行计算和超级计算机广为人知，但并行图形和成像计算机有着悠久的历史。

处理和生成图像需要巨大的计算量。例如，如果一台每秒处理一百万条指令的计算机（1MIPS）对百万像素图像的每个像素应用一次算术运算，计算机需要一秒钟来处理一张图像。

渲染电影和游戏中的 3D 虚拟世界比图像处理每像素需要的计算量大几个数量级。例如，为现代电影生成的图像每个像素需要大约十亿次浮点运算。因此，为了在实践中有用，图形和成像需要高性能的并行超级计算机。这些计算机在大规模数据集合上并行计算。

一个早期的 DARPA 资助研究项目是吉姆·克拉克（Jim Clark）在斯坦福大学领导的几何引擎（Geometry Engine）。

几何引擎促成了硅谷图形公司（Silicon Graphics）的成立，该公司率先开发了 3D 图形工作站。SGI 硬件架构和 OpenGL 软件库定义了现代 GPU 架构。

另一个值得注意的政府资助研究项目是亨利·福克斯（Henry Fuchs）及其合作者在北卡罗来纳大学领导的 Pixel Planes 系列高性能图形系统。事实上，Pixel Planes 5 是一台相当通用的单指令多数据（SIMD）计算机，它在 128 x 128 图像上运行并行计算。其他早期并行图形和图像计算机的例子包括 NASA 的大规模并行处理器（MPP）、Ikonas 图形系统和 Pixar 图像计算机。

早期 GPU 实现了类似于早期 SGI 工作站的固定功能图形流水线。当整个 OpenGL 图形流水线可以在单个芯片上实现时，英伟达引入了“GPU”一词。1999 年推出的英伟达 Geforce 256 由 1700 万个晶体管组成，是第一款商用 GPU。

在此之前，在皮克斯（Pixar）工作期间，Hanrahan 开发了 RenderMan，这是一个生成照片级逼真图像的系统。该系统彻底改变了电影行业，因为它能够生成可以与相机拍摄的实景无缝结合的图像。RenderMan 的一个关键组件是着色语言，它使用户能够扩展系统以模拟复杂的材质和光照。

虽然最初的 GPU 实现了固定功能流水线，但它们是由可编程组件构成的。不幸的是，这些处理单元因系统而异，因代而异。需要的是一种可移植的编程模型。由于 GPU 的主要应用是电脑游戏，因此将 RenderMan 着色语言适配到 GPU，以便游戏开发者可以创造新的光照和着色效果似乎是自然而然的。

在斯坦福大学的一个 DARPA 资助项目下，为当时的 GPU 设计并实现了一种实时着色语言（RTSL）。着色语言程序现在被称为着色器（shaders）。博士后学者 Bill Mark 领导了斯坦福 RTSL 的设计，后来加入了英伟达。他与另一位前斯坦福研究生 Kurt Akeley 一起增强了该技术，并创建了 Cg 着色语言。Cg 导致了微软 HLSL 和 OpenGL GLSL 的开发。

人们很快意识到，这些早期的着色语言足够灵活，可以实现科学计算中的许多算法。研究人员采用了诸如矩阵乘法、线性求解器、流体动力学求解器和分子动力学等算法在着色器上运行。这导致了 GPGPU（通用 GPU）计算运动的兴起。

流处理

DARPA 和 DOE 在斯坦福大学资助的关于 Imagine 流处理器和 Merrimac 流式超级计算机的工作发展了流处理，这是一种导致算术强度（计算与带宽之比）增加的并行计算形式。

如前所述，处理器消耗的大部分功率是在通信上。在芯片之间发送信号尤其耗电。芯片外通信也比芯片内通信慢得多。

流处理包含两个减少内存带宽需求的主要思想。

第一个是利用生产者-消费者局部性，使得一个阶段（生产者）将其结果转发给下一个阶段（消费者），而无需写入和读取内存。

第二个主要思想是将计算组织成称为内核（kernels）的函数。每个内核获取一个数据包，对该包执行函数，并输出另一个数据包。函数中的算术运算数量大于对内存的读写次数。这两种技术显著减少了内存访问次数，并提高了流处理架构的效率。

在流处理器中，计算被组织成产生和消耗数据流的内核。产生内核会将输出流写入流寄存器文件（SRF）。消费内核会从 SRF 读取输入，而数据无需写入或从内存中读取。通过适当的调度来匹配流的批处理大小与 SRF 的容量，这种组织使得应用程序能够维持非常高的算术强度（算术与内存带宽之比）。

一个设计和构建 Imagine 流处理器的 DARPA 资助项目于 1997 年在 MIT 启动，并于同年晚些时候转移到斯坦福大学。Imagine 是一台用于信号和图像处理工作负载的图形和媒体处理器。它由许多带有本地寄存器文件的并行算术单元、一个中央流寄存器文件和一个内存系统组成。内核从流寄存器文件读取流，通过本地寄存器文件传递中间结果，并将输出流写回流寄存器文件，供下一个内核读取。

Stream-C 编程语言被开发用于编程 Imagine。它扩展了 C 编程语言，增加了描述内核和流的构造。开发了众多的图形、信号处理和图像处理应用程序来调整和评估该架构。它在纹理映射光栅图形上的性能与当时的固定功能 GPU 相当。

在一次 DARPA 主要研究人员会议上，本文作者意识到这项技术可以应用于高性能计算，并构思了 Merrimac 项目。斯坦福 DOE ASCI 中心的计算机科学（CS）部分被重定向以追求这种高性能计算方法。该中心的年度报告提供了流处理发展史的详实记录。

Merrimac 架构被定义为将流处理适配到科学应用。与 Imagine 相比，主要变化是增加了科学计算所需的数据类型（如 FP64），将架构扩展到通过互连网络连接的多个节点以处理大规模问题，并增加了许多弹性特征，以支持在具有合理故障率的情况下进行大规模计算。

Stream-C 编程语言演变成了 Brook。Brook 背后的关键思想是将流编程的想法与更传统的数据并行计算合并。内核函数成为保持高算术强度的关键处理原语。

Brook 被适配以针对 2000 年代初的 GPU。这些 GPU 运行可编程顶点和片段着色器。着色器实现了内核，但指令数量有限且寄存器很少。常见的数据并行编程原语（如 map、reduce/scan、filter、gather 和 scatter）是通过在低级图形着色器之上构建虚拟数据并行计算机来实现的。这种抽象使得大量现有的并行算法可以在 GPU 上运行，并且早期着色器的局限性逐渐被消除。

早期利用内核执行高算术强度计算的一个很好的例子是稠密矩阵-矩阵乘法，它是现代神经网络算法的基础。在执行矩阵-矩阵乘法时，需要读取两个 n×n 矩阵并写入一个 n×n 矩阵。矩阵乘法需要 n³ 次乘加运算。因此，算术强度为 O(n)。这一事实众所周知，并导致了针对带有缓存的 CPU 进行矩阵乘法分块的有效方法。分块在 GPU 上运行时也非常有效。

斯坦福 ASCI 中心的数值科学家将几种科学代码移植到 Brook，以便在 Merrimac 模拟器上运行。这些代码包括计算流体动力学、磁流体动力学和 n 体模拟。n 体模拟是高效 GPU 应用的一个很好的例子。原子对之间的力由天体物理模拟中的引力定律给出，但非结合原子之间的相互作用由 Lennard-Jones 势（甚至更复杂的经验势）近似。这些函数需要许多算术运算。对于这些模拟，相邻原子存储在“邻居列表”中。分子动力学模拟立即成为 GPU 的主要应用。

GPU 和流处理器的一个关键特征是它们具有多种形式的硬件并行性。

每个 GPU 由许多核心组成。每个核心包含一个 SIMD 处理单元（通常为 32 宽）。

此外，每个核心都是多线程的。

回想一下，GPU 是为图形应用程序开发的，其性能取决于将纹理应用于三角形的效率。

纹理映射涉及计算三角形内每个像素片段的纹理坐标，然后使用这些坐标从图像中获取。这些纹理获取具有空间局部性，但时间局部性很小。空间局部性可以通过小型缓存来处理，但由于缺乏一致性，缓存无法处理时间局部性。

高效的纹理映射要求 GPU 隐藏这些纹理获取的延迟。早期 GPU 通过让片段请求纹理、挂起该片段的执行，并立即切换到处理另一个片段来实现这一点。这是多线程的简化版本，这意味着 GPU 需要有许多并行线程同时运行。任务总数是核心数乘以 SIMD 算术单元数（称为 warp）乘以线程数。Blackwell B200 GPU 拥有 384 个流多处理器（SMs）。每个 SM 有 64 个驻留 warp，每个 warp 有 32 个线程。因此，该 GPU 上有 786,432 个任务同时执行。

技术转移

流处理架构和编程系统通过人员流动从斯坦福转移到了英伟达。英伟达的一位架构师 John Nickolls 听说过流处理，并招募了 Bill Dally 在 2003 年为英伟达的 NV50 架构提供咨询。（NV50 于 2006 年作为 G80 发布）。流处理器的许多特性被合并到了该架构中。NV50 的“共享内存”发挥了 Imagine 和 Merrimac 中 SRF 的作用。

Ian Buck（Merrimac 项目的研究生和 Brook 的主要开发人员）于 2004 年加入英伟达。Ian 与 John Nickolls 合作将 Brook 演进为 CUDA。CUDA 合并了 Brook 和 Cg（一种图形着色语言）的最佳特性，并采纳了 Brook 程序员的反馈。关于该技术如何从斯坦福转移到英伟达的故事在一篇演示文稿中进行了描述。Mike Houston（该项目的另一位研究生）加入了 AMD，并直接使用 Brook 作为其 GPU 的编程语言。G80（NV50）和 CUDA 于 2006 年在超级计算大会上发布。

当 CUDA 于 2006 年发布时，很少有人了解并行编程，更不用说 GPU 流编程了。为了克服这一劳动力短缺，Wen-Mei Hwu 和 David Kirk 通过为教授讲授 CUDA 编程课程来推广 GPU 计算。参加这些课程的教师随后教授了成千上万的学生使用 CUDA 进行并行编程。从 Cosmic Cube、J-Machine 和 M-Machine 借来的并行计算技术既被应用于 GPU 内部（以协调多个 SM），也被应用于跨 GPU（构建多节点 GPU 系统以解决大型问题）。

赋能 AI

现代机器学习依赖于三个关键要素——海量数据集、具有许多层和权重的庞大模型，以及优化权重的计算能力。核心算法（深度神经网络、卷积网络、使用反向传播的训练和随机梯度下降）自 20 世纪 80 年代或更早以来就一直存在。大型标注数据集，例如 PASCAL 和 Imagenet，出现在 21 世纪初。最近的进展，例如将文本嵌入到向量空间中，使得自然语言深度学习成为可能。Transformers（“注意力就是你所需要的”）用带有历史记录的易于训练的神经网络取代了难以训练的循环神经网络。GPU 计算使得大规模数据集的网络训练在经济上变得可行。一旦展示了这种能力（Alexnet, GPT），AI 的能力就得到了迅速提升。AI 的快速采用为改进 GPU 计算系统提供了更大的动力。

英伟达的机器学习也得益于学术界与产业界的协同效应。2010 年，作者之一（Dally）与吴恩达（Andrew Ng）的一次早餐交谈促成了一个英伟达与斯坦福之间的联合项目，旨在 GPU 上构建深度神经网络。Bryan Catanzaro 领导了该项目的英伟达部分。在此项目中开发的软件成为了 CuDNN，它为英伟达 GPU 上的深度学习提供了一个现成的库——从而推动了深度学习的普及。

结论

GPU 计算背后的技术（已促成了现代机器学习）主要归功于 30 年的政府资助学术研究。

并行计算、并行图形系统和流处理的研究为 GPU 计算奠定了基础。在这些研究项目中培养的许多学生后来进入行业，转移了这些技术并利用其开发了创新产品。

从斯坦福流处理项目到 GPU 计算的转移非常直接，学术上的 Brook 语言演变为 CUDA，流处理器的功能被整合到 G80 GPU 中。

GPU 提供的高效、易于编程且性能极高的计算平台，通过计算着色器促成了当前的机器学习革命——提供了缺失的成分，以补充早已可用但一直缺乏计算能力的算法和数据。

资料链接：https://cacm.acm.org/federal-funding-of-academic-research/the-origins-of-gpu-computing/

关于作者

威廉·J·达利是美国加利福尼亚州圣克拉拉英伟达公司首席科学家兼高级副总裁，同时也是斯坦福大学电气工程与计算机科学的兼职教授。

帕特·汉拉汉是美国加利福尼亚州斯坦福大学电气工程与计算机科学的佳能荣休教授。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。