原文作者:B
原文来源:twitter
注:本文来自@bonnazhu推特,火星财经整理如下:
借着近期OpenAI 4o版本的发布,侃一下对AI+区块链的看法:
以OpenAI为首的生成式AI浪潮,靠一己之力,拉动了数据、存储、计算这三个板块的发展。从此之后,AI将成为它们未来十年甚至几十年最重要的客户,服务好AI,再由AI去服务各个下游行业客户和应用的链条正在逐步形成,AI成了最重要的中间层和发动机:
第一,AI带动了上游基建的需求:
1) 计算:包括芯片的设计与生产,云计算服务,数据中心,网络/电力基础设施等
这一环节偏重物理,AI的训练和结果输出需要消耗大量的算力、电力以及网络资源,而芯片的性能又是决定效率和能耗的关键,这就决定了像英伟达, AMD这样的芯片设计公司,台积电, 三星这样的晶圆代工厂,以及谷歌、微软,亚马逊等有云计算和数据中心业务的科技巨头注定捕获这一轮最大的价值。
但区块链并不是没有用武之地。目前算力垄断非常明显,高性能GPU一卡难求,或者需要付出很高的溢价才能在云计算厂商处获取相关服务,并且还可能由于地缘政治,芯片禁售等原因,导致算力在地理上的分布也呈现集中。这种失衡带来的需求外溢,使得去中心化计算成为这一轮AI浪潮中获取实际利益的区块链板块之一。这一板块的项目众多,新项目不断涌现,争夺会很激烈,如@akashnet_@rendernetwork@gensynai@NodeAIETH@exa_bits@ionet@fluence_project@gpunet@nosana_ai等等。
不过由于区块链网络本身的性能局限与机器学习高昂计算量的矛盾,使得复杂的深度学习必然要在链下进行,然后把结果传输到链上。如何验证算力提供方是否按照要求执行了训练任务是一个难点,并且计算需要调用数据和模型,存在潜在的隐私暴露问题。此时ZK(零知识证明)的威力就显现出来了。目前已经有不少项目在探索ZK为AI进行服务,例如 @bagel_network@gizatechxyz@ModulusLabs都旨在打造一个开发者可以部署AI模型,并可运用ZK对AI训练和推断过程进行校验的机器学习平台,即ZK machine learning,而@ezklxyz则是专注做服务AI的ZKP生成器和验证器,@Ingo_zk则是钻研ZKP生成硬件加速。
另外,生成式AI带来的能耗(包括计算产生的能耗以及散热带来的能耗)也是相当惊人。据说OpenAI训练GPT-6的时候,把微软的电网都搞崩了。随着之后各大巨头继续加码AI数据中心(其中OpenAI计划联合微软耗资1000亿美元打造名为Stargate星际之门的超级计算器),能耗只会几何级上涨。但是网络/电力这种基础的建设翻新周期很慢,且在例如美国这种国家,土地大多是私有的,拓展电网及相关的基础设施需要经过私人同意。如何让私人有动力参与到基础设施的拓展中,或是让私人减轻对电网的依赖和负担,这可能是未来 #DePin的一个重要议题。当然,除了电能,稳定的带宽也是AI需求的重要基础设施之一,大部分数据中心都会倾向于构建在ISP(网络业务提供商)近一些的地方,电力丰富的地方,网络带宽资源不一定丰富。如何利用#DePin解决这个错配问题,也是一个值得期待的方向。
2) 数据:包括数据采集、数据标注/处理、数据交易/授权。
尽管数据是AI的“食物”,然而大多数机器学习模型只能使用经过处理的结构化数据。目前,用于机器学习的数据来源非常广泛,且大部分是非结构化的和分散在各处的公开数据,因此需要花费大量时间和精力对这些数据进行搜集和处理。这其实是一个劳动密集的苦差事,却也是区块链和代币经济能够很好切入的环节,目前在做这个数据采集、处理分包业务的主要有 @getgrass_io@PublicAI_@AITProtocol这几家。
不过需要注意的是,随着新的机器学习模型架构的出现,对于结构化数据的依赖会有所改变。新的技术架构如自监督学习、GAN、VAE和预训练模型,可以直接利用非结构化数据进行深度学习,绕过数据处理和清洗环节,而这会对劳动密集型平台的需求带来一定冲击。
此外,可以公开抓取的数据只是这个世界数据的冰山一角,大量的数据其实掌握在私营机构或者个人用户手中,除了部分企业会有公开的API允许调用外,大部分数据仍旧没有被激活。如何让更多的数据持有者贡献/授权自己的数据,同时又能良好的保护隐私,是一个重点方向。曾经有不少做去中心化数据交易的平台,但因为苦于找不到有数据需求的甲方,经过几轮周期的大浪淘沙,基本都销声匿迹,只剩下少数如 @oceanprotocol熬到了AI的春天,而它们独特的Compute-to-data模式,让数据使用者可以直接在数据分享者的数据集上进行计算而不暴露数据,恰好解决了这个隐私痛点。
3) 存储:包括数据库(database),数据备份/存储系统(storage)
深度学习模型在训练和推断时用到的数据,大多是从数据库或者数据存储备份系统处调取的。可以把数据库和备份/存储系统理解成“冰箱”,不过数据库和备份/存储系统其实是不太一样的,前者侧重管理,需要支持频繁的读写,以及复杂查询(如SQL)和检索,后者侧重大规模、长期的备份和归档,需要保证隐私、安全和不可篡改。
Database和storage相辅相成,共同服务AI深度学习,一个典型的场景是:数据从database中提取,进行预处理和清洗,转换成适合模型训练的格式,处理后的数据可以存储在去中心化storage中,确保数据的安全。模型训练阶段,从去中心化storage中读取训练数据,进行模型训练,训练过程中生成的中间数据和模型参数可以存储在database中,便于快速访问和微调、更新。
这一板块是区块链的优势所在,@ArweaveEco@Filecoin@storj@Sia__Foundation都是这个赛道的,甚至@dfinity也可以归类进去,然而越来越觉得@ArweaveEco才是最适合服务AI的那个方案:其一次性支付永续存储的模式,加上生态系统中许多database项目作为补充,以及新发布的并行架构AO计算网络,完美适配深度学习中多线程任务的需求,这使得其能够很好地支持机器学习的部署。
第二,AI性能决定了下游应用的上限:
虽然AI已经或多或少在工业、农业领域(2B)有所应用,但这一轮我们看到的突破主要是基于大语言模型(LLM)的2C应用。我们可以把这些应用分成两大类:
第一类其实只是大语言模型的具象化,例如一些AIGC平台,它们根据用户指令生成用户想要的结果,但这一类应用的性能主要取决于使用的AI模型,而主要的LLM模型被巨头们垄断,因而应用间的差异性往往较小,护城河相对较窄;另一类则是利用AI模型来提升现有产品的功能和用户体验,例如增加了AI能力的搜索引擎、游戏等,包括@_kaitoai@ScopeProtocol@EchelonFND
除此之外,生成式AI浪潮还催热了一种新的应用生态—AI Agent,即智能机器人,其具备根据用户意图独立执行任务和做出决策的功能。AI Agent本质是在LLM的模型基础上,增加了更为复杂的执行和处理逻辑,使其能服务于不同的应用场景。实际上,这种Agent的雏形在加密货币领域已经存在,例如DeFi借贷协议的清算机器人(liquidation bot)和去中心化交易平台的套利机器人(arbitrage bot)。这些DeFi Bots虽然具备智能机器人的一些特点,但它们是纯链上的,不支持链下行为,且因为是基于智能合约,需要外部触发才能启动。
在没有AI的情况下,目前是通过一套外部的keeper网络来打通链下和链上的,例如价格预言机就是这样一个典型,以及 @thekeep3r也是一个例子。而AI Agent的出现,给了一种新的思路,即可以由智能机器人自行去完成,并实现自动化。链上AI Agent标的主要有:@autonolas@MorpheusAIs;而其他较为通用的AI Agent的标的有@chainml_@Fetch_ai;以及专注陪伴、人机交互的AI Agent有@myshell_ai@virtuals_io@The_Delysium,而这一类Agent的特点是拟人化,提供情绪价值,且具有被运用到各个游戏、元宇宙之中的想象空间。
第三,写在最后:
AI其实是一个融合叙事,它的出现,把原先各个孤立甚至当初找不到市场契合点的几个加密板块串联起来了。目前AI仍旧处于大基建投资时代,数据、存储、计算这一类上游板块是最直接的持续受益者,它们对AI发展更为敏感,确定性也更高。
但是对于这个行业的投资者来说,风险在于大部分的红利可能不在加密货币市场,目前币市的AI效应更多还是来自传统市场供需关系失衡带来的溢出效应,或者就是纯炒作。而下游应用由于性能天花板取决于AI模型,而AI模型仍处在不断迭代的过程中,且AI与产品的结合点还在探索,市场契合度还有待验证,这使得下游应用的未来变数还比较大,确定性不如上游板块那么高。
当然,还有像@bittensor_和@ritualnet这样的项目,我认为更应该称之为AI生态平台的项目。他们并不单纯专注于上游或下游的某一块业务,而是通过架构和经济机制设计,使上下游业务的各个提供者能够接入并部署到其平台或链上,实现所谓的人工智能协作。这些项目有着宏大的远景,但目前区块链AI上下游面临的需求捕获问题同样会反映到它们身上,且估值较高。不过,相比于押注某一个具体项目,押注这些平台的风险会相对小一些。
短期内,区块链能否继续从AI红利中获益,可能仍然取决于上游板块的供需关系失衡,尤其是供给不足状况的持续。但从中长期来看,区块链的可验证性、不可篡改性和代币激励等特性,确实能够为AI带来新的可能性,其中,零知识证明是一大利器,既能保护隐私,又能实现可信验证,完美解决了区块链在性能局限下服务AI深度学习高计算量需求的问题。