来源：NVIDIA CEO 黄仁勋主题演讲 | GTC 2025

GTC2025信息脑图

• 片头
  • Token开拓了新边界：突出了token与物理世界的联系
• Geforce 5090显卡开场
  • GTC的渊源从Geforce开始：Geforce带来CUDA，CUDA促进AI，AI反过来促进计算机图形学
  • AI促进计算机图形学的范例：对每个像素预测15个像素，并保持时间稳定性
• AI的历史
  • 感知式AI：计算机视觉、语音识别
  • 生成式AI：在多模态之间转换
    • 除了文本、图像、视频，还包含氨基酸到蛋白质、特性到化学物质
    • 从检索式计算模型，转变为生成式计算模型。以前都是预先创建多个版本的内容。现在不再检索数据而是生成答案，根本上改变了计算方式
  • 自主智能AI：具备自主性（has agency）的AI
    • 能推理如何解决，并能采取行动。
  • 物理AI：能理解物理世界，如摩擦、惯性、因果
  • 对于Nvidia合作方的意义：每个阶段都开启了更多机遇，更大的图景诞生了更多的合作方
• 贯穿AI每个阶段的三个基本问题
  • 问题1：数据问题
    • 人类历史已经积累了数百问题空间，生成数百万个不同示例。如勾股定律、数独、益智游戏。这些会生成万亿个token
  • 问题2：训练问题
    • 无需人工干预，借助强化学习生成
  • 问题3：规模化问题
    • 投入的资源更多，AI越聪明。
    • 今年预估的资源比去年这时候预期的要多至少100倍
    • 为什么需要更多资源的逻辑
      • 过去：ChatGPT采取了“一击即中（One Shot）”的方式，所以回答问题很可能会出错，效果不佳
      • token数增加：现在不仅生成一个个token或单词，而是生成代表推理步骤的单词序列，生成token数大幅增加
      • 步骤增加：推理，可能会尝试多种方法后选择最佳方法，可能会用多种方法解决后做一致性检查，可能得出答案后将答案代回方程验证正确性。
      • 计算时效性要求不变，因此计算速度需要提高
  • 数据证明：四大云服务运营商的Blackwell和Hooper出货量对比
• AI工厂
  • 变化趋势：增长加速、软件的未来需要资本投入
  • 手工编码的通用计算到了尽头。计算机成为了软件token生成器，而非文件检索工具。
  • 将生成的token重构为音乐、文字、视频、研究成果、蛋白质
  • 软件栈：各行各业的900多个CUDA-X库，实现计算加速
    • 在CUDA上还有各行各业的AI库（物理学、生物学、光刻）来搭建AI框架，提供感知、学习、推理能力
    • 每个工厂需要两个“工厂”。例如一个工厂制造晶圆，另一个工厂制造晶圆所需的信息
    • 行业1举例：光刻
    • 行业2举例：无线网络通信（5G）
    • 行业3举例：基因测序分析
    • 行业4举例：计算机辅助工程（CAE）
• AI对于各行业
  • 云服务商（CSP）：GPU云，托管GPU
  • 边缘计算：6G无线网络 AI-RAN
    • 价值：通过上下文和先验知识，改善不同环境下的大规模MIMO（多输入多输出）。（原理类似前文的像素点预测）
  • 自动驾驶
    • 制造3种计算机：训练、仿真、自动驾驶
    • HALOS：汽车安全。对每一行代码安全评估。
    • Cosmos + Omniverse：AI创造AI，包括模型蒸馏、闭环训练（由Cosmos评分）、合成数据生成（Omniverse神经重建技术，将日志转为4D驾驶环境，并创建变体）
• 数据中心
  • 前提：未来每个数据中心都会受到电力限制
  • 向上扩展（Scale Up）
    • 在横向扩展（Scale Out）之前，先需要向上扩展（Scale Up）
      • 难点：无法使用类似Hadoop的方式复用现有服务器，电力成本会过高。
    • Blackwell的硬件设计
      • Blackwell源于Range。
      • 上一代Scale Up的极限：HGX。8个GPU，连接到NVLink 8交换机。然后通过PCI Express连接到CPU机架，最终形成AI超级计算机。
      • Range在HGX的基础上扩展了4倍，对接NVLink 32。Range证明方向正确，但规模过大。于是进行了重新设计。重构方式：解构了NVLink，放在机箱中心
    • 强大的计算能力是用于解决看似简单的终极问题：推理
      • 为什么推理是终极问题：工厂所依赖的推理的效率决定了工厂的盈亏。工厂生成的token越多，AI越能给出聪明的答案；但时间过长会贻误时机。
      • token数与响应时间依赖大量计算能力，所以就需要Blackwell
      • 数据证明：安排婚礼座位，传统LLM采用one shot，消耗了439个token，得到了错误的答案（白白浪费了token）；DeepSeek R1会尝试不同场景，返回检验答案，最终消耗了8559个token，得到争取到的答案。即20多倍的token数，150多倍的计算量
    • NVLink的价值：为什么推理需要NVLink：
      • DS R1运行时，需要将工作负载（数万亿个参数和模型）分布到整个GPU系统中。Blackwell的NVLink 72架构的优势在于每个GPU都可以执行推理所需的批处理和聚合。
      • 预填充阶段：推理模型需要进行思考、进行阅读网站和看视频以消化信息，这些信息消化和上下文处理非常依赖浮点运算。
      • 解码阶段：需要浮点运算更需要巨大带宽。数万亿个参数输入，每秒TB级的数据仅仅为了生成一个token。
    • Dynamo（直译为发电机）：AI工厂的操作系统
      • 需求：支持动态分配不同的GPU数量给预填充和解码，动态适应思考（更需要预填充）和聊天（更需要解码）等不同场景的需求
      • 为什么称之为操作系统：以前操作系统是协调应用程序运行。未来是协调Agents智能体
    • Blackwell对AI工厂的价值估算
      • Blackwell + Dynamo + NVL72 + FP4：在最大吞吐率和最高质量之间寻找平衡点。
      • Blackwell方案的ISO功耗是Hooper的25倍。对于一个数据中心，Blackwell的token生产效率是Hooper的40倍，每秒生成12,000,000,000个token
    • 未来规划：Blackwell Ultra、Vera Rubin（2026）、Rubin Ultra（2027）
  • 横向扩展（Scale Out）
    • 挑战：收发器会消耗大量能源，将电信号转换为光信号
      • 25万个GPU中的每一个都需要6个收发器，使每个GPU增加180瓦的能耗
    • 解决方案：共封装光学（CPO）
      • 基于微环谐振器调制器（MRM），解决如何扩展到数百万个GPU的问题
    • 最终方案：将硅光和光电一体化封装方案结合，不再需要收发器，光纤直接连入512端口交换机，节省数十兆瓦的能量。
    • 未来规划：下一代产品命名为Feynman
• 企业计算
  • AI与机器学习重塑了计算机技术栈：处理器、操作系统、应用程序、应用的运行方式、编排方式都不再相同
    • 范例：对数据将不再精确检索，而是阅读并尝试理解，直接给出答案
  • 未来的个人电脑：DGX Station工作站
    • 计算机三大支柱：计算、网络、存储
    • 重新设计存储：不再是基于检索的存储系统，而是基于语义。只需要与之交互。
• 机器人技术
  • 背景：全世界缺少5000万个工人
  • 三大基础问题同样适用
    • 数据问题：互联网规模的数据提供了常识和推理能力。基于Cosmos + Omniverse生成海量合成行动和控制数据。
      • Omniverse：物理AI操作系统
      • Cosmos：理解物理世界。用Omniverse调节Cosmos，用Cosmos生成无限数量的环境
    • 训练问题：
      • Newton：能训练触觉反馈、精细动作的物理引擎。将物理定律作为可验证奖励。
    • 规模化问题：
      • Nvidia Isaac Groot N1：人形机器人通才基础模型
        • 双系统架构，用于快思考和慢思考。
          • 慢思考用于感知和推理，规划行动
          • 快思考转化为精确而连续的动作
        • 泛化能力：操作常见物体、协同执行多步骤

感受

GTC2025演讲内容的逻辑性

老黄的演讲中的确不乏画饼的成分，以部分抵消DeepSeek对于Scaling Law的挑战。不过对于我们有价值的，还是他是如何从逻辑上说圆自洽。

• 为什么投资者还应该继续看好Nvidia：我们处于时代拐点
• 什么时代拐点：已经从生成式AI进入了自主能推理的AI，并向物理AI时代进发
• 自主推理AI与Nvidia有什么关系：推理产生更多的token，要求更高的计算速度
• 自主推理AI带来的革新：计算机将变成token生成器，token与物理世界关联
• 为什么token能与物理世界关联的基础：各行各业的CUDA-X
• Nvidia如何支撑产生更多的token：新技术Blackwell和CPO

reinvent computer

ARTS中的 Review英文技术文章点评 和 Share技术文章分享，先试点按照月为单位，每月发一篇汇总吧。每篇写一小段感想。
关于英文技术文章来源，从v2ex的推荐，找到了DevURLs – A neat developer news aggregator的文章聚合网站。但感觉这些文章大多很短，看得不太过瘾。所以在尝试了两周后，改为根据本周关注的技术点，用英文关键字Google，选择搜索结果中质量比较高的。

Review

eBPF for Cloud Computing - DZone

https://dzone.com/articles/ebpf-for-cloud-computing

eBPF这个术语看到过好几次，找了一篇入门介绍。主要是针对eBPF和K8S结合的场景，包括网络可观测性、安全、性能监控等用途。
eBPF的主要优势在于不用开发Linux内核模块，也能在内核执行。这点使其很适合K8S，用于包含Calico、Cilium在内的开源项目。

Improving language understanding by generative pre-training[J].

https://s3-us-west-2.amazonaws.com/openai-assets/research-covers/language-unsupervised/language_understanding_paper.pdf

在B站李沐视频和内网解读文章的辅助下，读了GPT-1的论文。除了论文本身的知识点外，有2个感受：

大数据的相关性特性

挺巧的是，最近从不同来源听到了这个理论两次。

第一次是ACE题库里的一道题：“美国海军军官莫里通过对前人航海日志的分析，绘制了新的航海日志图，表明了大风与洋流可能发生的地点，这体现了大数据分析理念中的：”
这道题的标准答案是：在分析方法上，更注重相关分析而不是因果分析。

第二次是听播客“纵横四海”，讲瑞幸数字化。瑞幸除了把甜度、浓稠度等饮料的指标做了数字化之外，也将其和销量的反馈结合起来。但在结合的时候，并不会试图推断出甜度与销量的因果关系，而是相信数据给出的指引。
播客里还举了几个典型的案例，比如沃尔玛发现飓风前人们喜欢屯蛋挞。至于为什么是蛋挞，而不是薯片，也不是可乐，从因果性没法给出很好的解释。
还有亚马逊的案例中书籍推荐之间的相关性，医疗保险方面买车与遵医嘱信用分的相关性。
这时候就要反人类的本能，放弃对因果性的追究，去全身心拥抱大数据。

从某个角度，LLM中对Few Shot有效性的解释，也可以从这个角度来理解。Few Shot本身并没有改变模型，但得到的结果就是更好了。即Few Shot与结果的有效性之间存在相关性。但当前的理论模型只能给出一些猜测，还无法完美证明。

个人对因果性与相关性的看法

对于这个现象，我的个人看法分为两点：

• 接受这个事实，从实用性角度先利用起来。
• 关注业界对于其背后原理的研究进展。

背景

在之前参与资产市场产品迭代的时候，就资产市场与研发平台的打通，研发团队就提出过使用IaC，实现“一键下行”。一键下行，指的是在下行复用组件资产的时候，将组件所依赖的资源也同时自动化开通，然后自动将组件部署在新开通的资源上。
举个例子：假设4A组件需要依赖RDS、Redis、OSS，就在后台配置的云资源环境自动申请RDS、Redis、OSS。站在研发的视角，隐藏了资源申请的复杂性，加速了复用流程，提升了研发体验。
在资产市场对外输出时，对接的云资源往往没有那么理想，必定是阿里云公共云资源。如果使用IaC，便于适配不同的云环境。

接下来即将开始的工作，可能也会涉及大量而频繁的云资源开通。最近在做Demo的时候，就深感开通和销毁云资源这个繁琐的事情有多浪费时间。
以程序员的偷懒本性，自然想到了使用IaC来提升效率。

概念和快速入门指引可以直接查阅参考资料，就不copy & paste了。只记录一些个人觉得实践时需要关注的点。
由于自家的关系，以下云资源默认为阿里公共云。

2. 工作中可能用到IaC的业务场景

IaC核心是版本控制和可重复，实现提效、降低误操作、一致性与合规安全。
适合IaC的业务场景是什么？企业上云、环境复制、环境重建、合规管控等。

3. 学习时的几个选型

3.1 Terraform vs. 阿里云ROS

1.保理的概念

保理，从本质上来说，就是应收账款的融资服务。
举个场景:某桂园向某混凝土公司A采购了2000吨水泥，应收账款100万。但由于账期原因，应收账款是按照季度结算。但公司A因为款项没有即时结清，产生了资金周转问题。于是公司A就将应收账款以折扣价转让给了保理商B。保理商B给供应公司A提供了融资，并通知某桂园回款后续不再打给公司A，而是打给保理商自己。季末某桂园将回款打给了保理商B。保理商B在融资和回款的差价里赚到了收益。
整个流程可以参见下图

在这个最基础的流程中，有三方：

• 卖方:某混凝公司A，也可以称为债权方、上游
• 买方:某桂园，也可以称为债务方、下游
• 保理商:分为商业机构进行的商业保理和银行保理

1.1 正向保理和反向保理

保理这个概念产生的时候，都是由拥有融资需要的卖方主动发起的。但卖方拿到融资却不供货转身跑路的情况，也不是不会发生。这种情况下，买方当然也不会为没有收到的货而白白付钱。保理为了尽量避坏账，会对卖方的资质和规模进行要求。
但现实中很常见的情况是：上游的卖方是中小企业，无法达成资质规模要求，尽调难度也很大；而下游买方是龙头企业，拥有较高的资信程度。为了在这种场景下也能让保理商放心融资，会由卖方（混凝土公司A）找买方（某桂园）做担保，由买方主动发起保理申请。买方为了保证上游供应链的稳定，出面找保理商做担保：公司A确实是我的上游供应商，我们有商务合作。如果你能信得过我的话（大企业的授信担保），就给公司A融资，然后在一定时间段后到我这里兑回款。保理商相信了A的资信，给公司A提供了融资。
在这里出现了一个核心企业的概念。核心企业是供应链中的概念,是供应链中的关键节点，资信程度较高（AA＋是基本门槛）。

在保理流程中，核心企业是保理的发起方。核心企业的类型也是区分正向保理和反向保理的关键判断因素。核心企业是卖家，就是正向保理；核心企业是买家，就是反向保理。这里的“正”和“反”指的是相关交易链的方向。

本文是极客时间《赵成的运维体系管理课》的读后体会之二 。

1.对故障的认识

ITIL的10个重要的IT管理关键模块之一就是故障管理。
故障永远只是表面现象，其背后技术和管理上的问题才是根因

即当技术和管理上的问题积累到一定程度后，就会以故障的形式爆发出来。所以不能仅将眼光限于故障本身和直接责任人。

• 管理者要先自我反省:员工只是执行者，管理者的责任永远大于执行者
• 强调用技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题
  • 短期可以辅以一些管理措施，比如靠宣传学习必要的Double Check/制定复杂操作的Checklist等。但是这些只能作为辅助手段，一定不能是常态
  • 随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升，所以最终必须将这些人为动作转化到技术平台中去

2.故障的定级

故障需要有标准化的流程来指导我们的处理过程。

这里有个关键组织:故障应急小组。这个组织有4个职责：

本文是极客时间《赵成的运维体系管理课》的读后体会之一。

运维配置管理实践中一些混乱现象

在公司的运维配置管理实践中，存在一些混乱的现象：

• 信息安全收到fastjson的安全问题报告，但报告中的服务器对应的系统却有错位
• 信息安全收到了报告，发现tomcat的某个版本出现了漏洞需要升级，但不知道到底影响到哪些系统，只能逐个请每个系统的负责人判断
• 部分服务器（特别是开发坏境服务器）已经基本可以确认不再被使用，但服务器资源没有回收，每月持续占用硬件预算
• 某系统上线后发现中漏配置了一个域名，导致部分用户打开首页报错
• redis缺少规划，多个系统公用一个redis集群的情况下，无法根据键（key）来区分每个系统占用了多少缓存。遇到内存不足的情况很难深入排查是哪个系统导致
• 生产消息队列中不少queue堆积着大量消息，但不知道是否还在用，不敢随意删除

这些情况很可能短期甚至长期内不会直接导致什么问题。可能就是让信息安全整理材料多费一点时间，开发排查多绕一点弯路，或多花一些硬件维持或扩容费用。但有些时候这些问题就是给未来出现的生产问题埋下隐患。
硬件的归属，服务器的使用情况，应用域名管理，软件版本，应用与中间件的关联等等，都属于广义上的配置管理。所以归根到底，是配置管理的混乱。

ITIL和配置管理CMDB

在ITIL（Information Technology Infrastrueture Library）中，有10个重要的IT管理关键模块。其中配置管理（CMDB）通常被认为是其他IT流程的基础。
CMDB（Configuration Managoment DataBase），配置管理数据库，是与IT系统所有组件相关的信息库。它包含IT基础架构配置项的详细信息。
在传统运维时代，CMDB的核心对象是资源，即网络和硬件设备。但在云计算和互联网运维时代，CMB的核心已经转变为了“应用”。随着微服务架构的推广，以应用为核心的注册中心、缓存、消息队列、数据库等都需要纳入配置管理的管理范畴。

以应用为核心的配置管理标准化可以包括：

疫情期间积累了一些远程办公条件下的项目管理经验，稍微整理一下。我司从企业文化到网络硬件，不太具备远程办公的基因，要补课的地方就额外多。

1. 按小团队划分并设定第一责任人

亚马逊CEO贝索斯提到过一个原则：如果两个披萨饼都喂不饱一个团队，那么这个团队可能就太大了。按照这个逻辑，我的团队可能只能容纳两个人。。。
玩笑开完了。但事实就是，对于一般人来说，能较好管理5~6个就已经是不错了。当团队人数超过这个规模，需要将团队拆分为6-10人的小团队规模，增加汇报层级，才能管得过来。
每个小团队可以包含前端、后端和测试，而数据库、UI等共享资源单独一个团队。

对每个小团队需要指定一个第一责任人（以下简称“责任人”）。这个责任人需要有以下的素质：

• 对小团队成员知根知底
• 快速响应的执行力和跟进能力
• 对任务目标有充分的理解

2. 通知走大群，信息收集走小群

2.1 通知

远程办公期间的通知事项会比较多。邮件通知方式不能确保所有人都会在第一时间查看邮件。
通过即时通信的群通知，可以确保绝大部分人都能第一时间看到并响应。
即时通信大群的注意点：

春节期间看完了极客时间的《说透中台》的课程，顺便也读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》一书。这篇从实际项目的角度来想象一下，如果让我来负责公司的中台，应该怎么做。
首先说下评价：这个课程符合我对ThoughtWorks的刻板印象：有点滥用理论术语，干货不多；问题题了不少，解决方案不落地。可能是都是给其他公司做的项目，有保密协议的缘故。能理解，但还是不推荐。阿里的那本中台书更加实在。

1. 中台概念整理

1.1 中台的目的

中台的目的就是企业能力复用。

1.2 中台的分类

中台主流分为两大类：业务中台/数据中台。业务中台产生数据，数据中台做数据的二次加工，并将结果再服务于业务中台。
也有“技术中台”的概念，可以理解为一些技术中间件的整合和封装，但我倾向于不将其认定为中台。
中台强调一个复用。如果根本没有系统从零开始建设，一上来就搞中台很容易会过度设计。

2. 中台的抓手

中台会面对所有业务线的需求。虽然中台有企业级的属性，但不代表建设中台的时候必须梳理企业的全业务线。中台的愿景是能力复用，那么最好有具体的新业务作为抓手。

上家公司虽然有这样那样的问题，但在能让我掌控的服务器资源自由度上，也不是随便在哪家公司就能有的。能随便申请个半打一打的4核8G的虚机来搞事情什么的。。。跳槽后就只有自己的Windows工作机了。Docker Desktop搞了半天也没法启用Kubernetes，这也是为什么之前的“Kubernetes实战”系列到7月就戛然而止的原因。
只靠Docker Desktop，平时开发的时候起个数据库或redis是足够用了，但像service mesh之类的就玩不了了。趁年前有空，搭了一套Minikube，把步骤顺便记录一下。原本想合并到之前kubeadm安装的那篇里，但可能会翻起来不方便，还是单独另开一篇吧。
后续“Kubernetes实战”系列都会基于minikube环境来搭建。

1. 软硬件条件

现在内存也不值钱了，插个16G足够玩了。
操作系统上，虽然Windows 10家庭版+VirtualBox/VMWare也可以，但从硬件利用率角度，还是用Windows 10企业版/专业版/教育版+Hyper-V比较好。
在控制面板->程序->启动或关闭Windows 功能 里面打开所有Hyper-V选项然后重启。
重启后运行systeminfo，看到如下内容，说明操作系统层面已经ok了：

1

Hyper-V 要求:     已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。

Docker Desktop是否安装不影响，但在安装Minikube的过程中最好不要启动。在安装过程中报过一个create: precreate: no External vswitch nor Default Switch found的报错，不确定是不是相关。
顺带提一句，如果装了Docker Desktop，可以在Settings->Daemon->Registry mirrors里填写：https://dockerhub.azk8s.cn、http://hub-mirror.c.163.com和https://docker.mirrors.ustc.edu.cn
另外感谢这篇docker/kubernetes国内源/镜像源解决方式 - xinkun的博客 | Xinkun Blog的整理，我也复制一下备忘：

2. 网络条件

以防万一请先关闭Windows防火墙。
因为你懂的那个原因，需要本地搞个SS的梯子。如果哪个步骤因为网络原因卡住了，可以切成代理再试一次。