2023-08-13
预告 AI 操作系统 os.ai

AI 操作系统这个概念已经有很多人提出过。传统的 AI 操作系统可能更多是基础架构(infra)方面,本质上是管硬件的;我们提出的 AI 操作系统是管大模型的。

今天,我注册了域名 os.ai,暂时放了一个 placeholder 网页,简单介绍我们正在构建的 AI 操作系统。

AI 操作系统是大语言模型和应用之间的桥梁。我们的专业团队致力于提供低成本的解决方案,构建高可预测性、高可控性的生成式 AI 基础架构,支持生成文本、图片、视频、3D 元宇宙、生成式助理(generative agents)。

为什么我们需要 AI 操作系统?目前的大模型在成本、可预测性、多模态、评估测试等方面存在很多挑战,我们相信不仅需要模型本身的改进,更关键的是与数据和系统紧密协同设计。

低成本

目前使用 GPT-4 阅读一篇论文需要 10 美元,用 Runway ML 生成一段 7.5 分钟的视频需要 95 美元。

我们作为 AI 基础架构的专家,通过自建最前沿的 GPU 组成的 AI 数据中心,以及协同优化模型、数据和底层硬件架构,提供低成本的生成式 AI 服务。

可预测性

  • 在模型层面上减少幻觉
  • 沙盒化
  • 系统/用户权限隔离(避免指令注入)
  • 事实性校验
  • 可靠地执行长流程任务
  • 集成行业私有数据集和数据库

多模态

低成本的文本、图片、3D 元宇宙、个性化生成式助理的创作管线,生成细节具有高度可控性。

  • 文本 → 图片/视频/3D 模型
  • 文本 + 图片 → 图片/视频/3D 模型
  • 文本 + 视频 → 视频/3D 模型
  • 文本/图片/视频 → 个性化生成式助理

模型评估

在开放环境中对大语言模型自动进行高吞吐量的评估、测试和选择。使能大语言模型市场,使能生成式助理构建的元宇宙。

目前 AI 操作系统还仅仅是个初步概念,其中很多技术仍然在研究中,欢迎关注 os.ai,让我们期待大模型 AI 操作系统的来临。

Read More

2023-08-07
如何用技术手段防止屏幕拍照、文件上传等泄密

(本文首发于 知乎

涉及机密信息的公司,一般会划分为低密区、中密区、高密区:

  • 低密区:对于图像流、视频流、信息流,具有一定的泄露检测和溯源能力;
  • 中密区:对于图像流、视频流、信息流,具有一定的事前泄露阻断和检测能力,具有很强的事后泄露溯源能力;
  • 高密区:对于图像流、视频流、信息流,具有很强的事前泄露阻断能力。

高密区是最简单的,物理隔离,门口放上安检仪,手机、U 盘等电子设备都不允许带进去。

中密区和低密区是比较困难的,因为里面的办公电脑能上外网,手机也能带进办公室。以下从泄露阻断、泄露检测和泄露溯源几个维度来讲怎么维护信息安全。泄露阻断是指让数据泄漏不出去,泄露检测是在数据泄露可能发生的时候能够发现并上报,泄露溯源是指数据已经泄露的时候能够追查到是谁泄露出去的。

Read More

2023-08-05
AI 集群该用 RoCEv2 还是 Infiniband

(本文首发于 知乎

各大互联网公司基本上都在部署 RDMA 技术,目前主要的场景就是存储和 AI/HPC,主要分为两个技术路线,RoCEv2 和 Infiniband。

RoCEv2 是 RDMA over Ethernet,就是在传统的数据中心以太网络上面跑 RDMA 协议。Infiniband(IB)的历史就更长了,上世纪 80 年代的 HPC 高性能计算集群用的都是 IB。

RDMA 网卡目前的老大是 NVIDIA 收购的 Mellanox。可以说,RoCEv2 是社区版 RDMA,Infiniband 是企业版 RDMA。社区版的优势在于开放,可配置的东西多,但这也是它的缺点,只有网络专家才能玩得转。而且大规模 RoCEv2 集群还不是一个网络专家就能玩得转的,需要一个团队来搞定 PFC 风暴问题和网卡交换机各种奇奇怪怪的问题。当然,如果只有几台机器和一个交换机,网卡都是同一型号的,这种小规模集群用 RoCEv2 基本上也不会遇到什么问题。

RDMA 这个圈子很小,基本上都有一定的学术背景,如果对上述问题都没听说过,那还是老老实实用 IB 吧,稍微多花点钱,简单省事。我听说有的 AI 公司觉得只要买 A100/H100 就够了,连 SXM 版和 PCIe 版都分不清,也不知道需要买 IB 网卡和交换机才能实现大规模训练,以为用普通 10G 网络连起来就行,这种最好找一个卖 AI 集群解决方案的给配好 IB 网卡、交换机和网络拓扑,千万别自己逞能,别为了省钱去碰 RoCEv2。

OpenAI 的 GPU 集群目前用的大多数是 Infiniband,现在一些中小型 AI 公司用的也是 IB。大多数大型公司的新建 GPU 集群用的是 RoCEv2,因为这些大厂要支持万卡以上的规模,IB 在这种规模上 scale 不上去,而且这种规模的公司成本很重要。有些大厂都已经开始自研网卡了。另外一个原因就是大厂有专业的网络团队,IB 这么封闭的东西很难调优,这让这些网络专家们怎么调性能写 PPT 呀。

Read More

2023-08-05
Load/Store 和缓存一致性有没有必要?

(本文首发于 知乎

CC(cache coherency,缓存一致性)可以分为两个场景:

  1. 主机内 CPU 和 device 之间的 CC
  2. 跨主机的 CC

主机内 CPU 和 device 之间的 CC

我认为主机内 CPU 和 device 之间的 CC 是非常必要的。2017 年我在微软实习的时候,用 FPGA 做了一块内存挂到 PCIe 的 bar 空间上,真能在这块 bar 空间上跑起来一个 Linux 系统,但是本来只要 3 秒的启动流程花了 30 分钟,比 host memory 慢了 600 倍。这就是因为 PCIe 不支持 CC,CPU 直接访问 device memory 只能是 uncacheable 的,每次访存都要通过 PCIe 去 FPGA 转一圈,效率低得不行。

因此目前 PCIe bar 空间只能用来让 CPU 给 device 下发 MMIO 命令,数据传输必须通过 device DMA 来进行。因此现在不管是 NVMe 盘还是 RDMA 网卡,都必须走 doorbell-WQE/command-DMA 这一套复杂的流程,如下图所示。

Read More

2023-07-04
启用新域名 01.me

2012 年 11 月,我的博客随 USTC Blog 诞生。2013 年 5 月,我的博客有了独立域名 bojieli.com。2015 年 1 月,博客启用新域名 ring0.me,ring0 是 x86 体系结构中的最高特权级,意味着我对系统底层技术不懈的追求。

今天,我注册了溢价域名(premium domain) 01.me。0 和 1 是二进制仅有的两个数位,我选择这个域名是希望投身 AGI(通用人工智能)事业,为基于 0 和 1 的硅基生命作出一点微小的贡献。

01.me 这个域名也有一定的投资价值,01.org 是 Intel Open Source 的官网,01.ai 是李开复老师 AI 创业公司零一万物的官网,01.com 曾在 2017 年售出过 $1,820,000 的高价(当然 .me 和 .com 的价值不可同日而语)。

为方便在微信等国内平台上分享文章,本网站另有两个国内备案过的域名 bojieli.comboj.life。待注册局的新注册域名 60 天保护期过后,可能会考虑把 01.me 迁到国内注册商,进行备案。

Read More

2023-06-20
SOSP'17 Talk Transcription: KV-Direct

KV-Direct: High-Performance In-Memory Key-Value Store with Programmable NIC

Bojie Li, Zhenyuan Ruan, Wencong Xiao, Yuanwei Lu, Yongqiang Xiong, Andrew Putnam, Enhong Chen and Lintao Zhang.
Proceedings of the 26th Symposium on Operating Systems Principles (SOSP ‘17). [PDF] [Slides]

Transcription with Whisper.

Read More

2023-06-19
SIGCOMM'16 Talk Transcription: ClickNP

ClickNP: Highly Flexible and High-Performance Network Processing with Reconfigurable Hardware

Bojie Li, Kun Tan, Layong (Larry) Luo, Yanqing Peng, Renqian Luo, Ningyi Xu, Yongqiang Xiong, Peng Cheng and Enhong Chen.
Proceedings of the 2016 ACM SIGCOMM Conference (SIGCOMM ‘16). [PDF] [Slides]

Transcription with Whisper.

Read More

2023-06-14
FastWake: Revisiting Host Network Stack for Interrupt-mode RDMA

Polling and interrupt has long been a trade-off in RDMA systems. Polling has lower latency but each CPU core can only run one thread. Interrupt enables time sharing among multiple threads but has higher latency. Many applications such as databases have hundreds of threads, which is much larger than the number of cores. So, they have to use interrupt mode to share cores among threads, and the resulting RDMA latency is much higher than the hardware limits. In this paper, we analyze the root cause of high costs in RDMA interrupt delivery, and present FastWake, a practical redesign of interrupt-mode RDMA host network stack using commodity RDMA hardware, Linux OS, and unmodified applications. Our first approach to fast thread wake-up completely removes interrupts. We design a per-core dispatcher thread to poll all the completion queues of the application threads on the same core, and utilize a kernel fast path to context switch to the thread with an incoming completion event. The approach above would keep CPUs running at 100% utilization, so we design an interrupt-based approach for scenarios with power constraints. Observing that waking up a thread on the same core as the interrupt is much faster than threads on other cores, we dynamically adjust RDMA event queue mappings to improve interrupt core affinity. In addition, we revisit the kernel path of thread wake-up, and remove the overheads in virtual file system (VFS), locking, and process scheduling. Experiments show that FastWake can reduce RDMA latency by 80% on x86 and 77% on ARM at the cost of < 30% higher power utilization than traditional interrupts, and the latency is only 0.3~0.4 𝜇s higher than the limits of underlying hardware. When power saving is desired, our interrupt-based approach can still reduce interrupt-mode RDMA latency by 59% on x86 and 52% on ARM.

Publication

Bojie Li, Zihao Xiang, Xiaoliang Wang, Han Ruan, Jingbin Zhou, and Kun Tan. FastWake: Revisiting Host Network Stack for Interrupt-mode RDMA. In 7th Asia-Pacific Workshop on Networking (APNET 2023), June 29–30, 2023, Hong Kong, China. [Paper PDF] [Slides PPTX] [Slides PDF] [Video] [Talk Transcript]

APNet group photo @ HKUST campusAPNet group photo @ HKUST campus

APNet group photo @ Victoria Harbour CruiseAPNet group photo @ Victoria Harbour Cruise

People

  • Bojie Li, Technical Expert at Computer Networking and Protocol Lab, Huawei.
  • Zihao Xiang, Senior Developer at Computer Networking and Protocol Lab, Huawei.
  • Xiaoliang Wang, Associate Professor, Nanjing University.
  • Han Ruan, Senior Technical Planning Expert at Computer Networking and Protocol Lab, Huawei.
  • Jingbin Zhou, Director of Computer Networking and Protocol Lab, Huawei.
  • Kun Tan, Director of Distributed and Parallel Software Lab, Huawei.
Read More

2023-06-11
计算机网络的新黄金时代(三):无线网络

本文系笔者根据 2022 年 12 月 12 日在北京大学的演讲整理,首先将会议录音使用科大讯飞语音识别转换成口水稿,然后用 GPT-4 加以润色,修正语音识别的错误,最后人工加入一些新的思考)

无线网络是一个非常广阔的领域,对应华为的两大产品线,一是无线,二是消费者 BG。无线主要就是我们熟悉的 5G 和 Wi-Fi,而消费者 BG 做的是包括手机在内的各种智能终端。

在上一章广域网开头我们就提到,当前的传输协议对无线网络和广域网的带宽并没有充分利用,导致很多应用实际上无法体验到 5G 和 Wi-Fi 标称的数百 Mbps 高带宽,这就是我们常说的 “最后一公里” 问题。随着无线网络的性能越来越接近有线网络,一些原本适用于数据中心的优化将适用于无线网络。之前我们提到分布式系统,想到的都是数据中心,而现在家中这么多终端设备和智能家居设备,也组成了一个分布式系统,未来有可能一个家庭就是一个迷你数据中心。

Read More

2023-05-28
计算机网络的新黄金时代(二):广域网

本文系笔者根据 2022 年 12 月 12 日在北京大学的演讲整理,首先将会议录音使用科大讯飞语音识别转换成口水稿,然后用 GPT-4 加以润色,修正语音识别的错误,最后人工加入一些新的思考)

广域网主要分为两大类通信模式,一类是端云通信,一类是云际通信。我们先从端云开始讲起。

端云网络

我们一般提到广域网,就认为它是不可控的,运营商的网络设备都不是自己能控制的,还有大量其他用户在并发访问,很难做到确定性。但今天的很多应用又需要一定程度的确定性,比如视频会议、网络游戏,时延高到一定程度用户就会感觉卡顿。如何调和这一对矛盾呢?这就是我们今天的课题。

就像我们在上一章数据中心网络中讲到的,应用实际感受到的带宽与物理带宽差距很大,因此才有优化的空间。我们知道现在 5G 和 Wi-Fi 的理论带宽都是数百 Mbps 乃至上 Gbps,家庭宽带的带宽很多也是几百 Mbps 甚至达到了千兆,理论上 100 MB 的数据一两秒钟就能传输完成。但我们在应用市场里面下载应用的时候,有几次是 100 MB 的应用一两秒钟就能下载完的?另外一个例子,压缩后的 4K 高清视频只需要 15~40 Mbps 的传输速度,听起来远远没有达到带宽的理论上限,但我们有多少网络环境能流畅看 4K 高清视频?这一方面是端侧无线网络的问题,一方面是广域网的问题。要把理论带宽用好,还有很长的路要走。

我当年在微软实习的时候,微软大厦二楼的中餐厅就叫做 “云 + 端”(Cloud + Client),12 楼 sky garden 那里的背景板也写着 cloud first, mobile first,数据中心和智能终端确实是 2010~2020 年最火的两个领域。但可惜的是微软的移动端一直没做起来。华为恰好是在端云两侧都有强大的实力,因此在端云协同优化方面有着独特的优势。

Read More
RSS