繼《》、《》、《》之后，知名 Linux 內核一線開發(fā)者，經典書籍《Linux 設備驅動開發(fā)詳解》作者宋寶華老師又給大家?guī)砹?2025 年 Linux 內核開發(fā)中，十個最典型的patchset，為大家呈現(xiàn)干貨滿滿的硬核技術年貨。

作者 | 宋寶華 責編 | 張紅月

出品 | CSDN（ID：CSDNnews）

從明天起，做一個幸福的人。喂馬，劈柴，周游世界。從明天起，關心糧食和蔬菜。我有一所房子，面朝大海，春暖花開。 ——海子《面朝大海，春暖花開》

2026 農歷新年的鐘聲即將敲響，在這全球共慶的跨年時刻，Linux 內核年度十大技術創(chuàng)新盤點如約而至。

回望過去的一年，平凡的日子里夾雜著些許苦澀與無奈。每一個渺小的個體，無論心中藏著怎樣的悲傷或喜悅，都讓它隨風而去吧。新的一年里，縱然現(xiàn)實仍有諸多束縛，也愿諸君心底已然面朝大海，春暖花開。

過去的一年，內核開發(fā)者們廢寢忘食地沉浸在代碼的純粹世界中，不斷提交patch，推動 Linux 內核前行。

本文將盤點其中最具代表性的十個 patchset:

1

slab per-CPU cache機制：Sheaves(一捆)和barns(谷倉)

2

sched_ext: cgroup sub-scheduler支持

3

代理執(zhí)行proxy-execution以解決優(yōu)先級翻轉

4

swap table替代xarray

5

TCP零拷貝發(fā)送DMABUF

6

調度器時間片擴展time slice extension

7

multi-kernel

8

io_uring的網(wǎng)絡零拷貝收包

9

io_uring dmabuf讀寫支持

10

dmem cgroup

下面一一展開描述。

slab per-CPU cache 機制：Sheaves(一捆)和barns(谷倉)

內存管理的 buddy 是有 pcp(Per-CPU Page frame cache) 的，針對 buddy 申請和釋放的內存，維護一定量的 Per-CPU 的 free 內存 list，以減小每次都從底層 buddy 獲取、釋放 pages 的鎖競爭：

對于 Linux 內核 kmalloc/kfree 底層的 slab，實際上我們也需要類似的 per-CPU 機制，來減小 object 申請和釋放時候跨 CPU 的鎖競爭和跨 CPU 的 cache 同步等開銷。Vlastimil Babka 的 patchset，把“農場”的 Sheaves 和 Barns 概念借用到內核中，以支撐 slab 的 per-CPU cache 能力。

(圖源：https://www.reddit.com/r/linux/comments/1nd8hav/what_that_means/)

Sheaves（束/捆）

字面意思是“麥束”或“一捆”，內核中指每個 CPU 本地的一小批 slab object緩存，用于加快本地分配/釋放，減少鎖競爭。是一種per?CPU 對象緩存，用來快速滿足分配和釋放請求。每個 CPU 維護兩個小緩存（主 sheaf 和備用 sheaf），只要其中有對象，就直接返回/放回，不用去訪問全局 slab 頁或鎖住別人，從而提高性能。分配/釋放 object 大多數(shù)情況下是本地、無鎖的操作。

Barns（谷倉/倉庫）

字面意思是“谷倉”或“倉庫”，內核中指全局 slab 池（但是是按照NUMA來管理的），供各個 CPU 的 sheaves 補充或回收，其功能是保證全局內存平衡，處理 sheaves 空或滿的情況。barn 里有兩類隊列：full（裝滿對象的 sheaf）和empty（空 sheaf），方便快速交換。

當某個 CPU 的 sheaves滿了或空了時，才涉及到barn（谷倉）：

• 空 sheaves：如果分配時 sheaves 空了，CPU 會嘗試從barn取一個 full sheaf。

• 滿 sheaves：釋放時 sheaves 都滿了，會往 barn 里放一個 full sheaf 或把 sheaf 里的對象回寫 slab 頁面。

sched_ext: cgroup sub-scheduler 支持

這個 patchset 來自 Tejun Heo，為 sched_ext 增加了基于 cgroup 的子調度器（sub-scheduler）支持，使多個 BPF 調度器可以按 cgroup 層級結構協(xié)同運行：父調度器負責在不同 cgroup（租戶/分區(qū)）之間分配 CPU 資源，子調度器負責各自 cgroup 內部的任務調度。這樣系統(tǒng)就能按 workload 分區(qū)部署不同調度策略，滿足多租戶服務器和混部場景下對差異化調度（如延遲優(yōu)先、吞吐優(yōu)先等）的需求。比如不同的業(yè)務類型需求不一樣，可以組成如下層次化的調度系統(tǒng)：

上圖中，數(shù)據(jù)庫系統(tǒng)的調度器能夠理解查詢的優(yōu)先級和鎖持有者的重要性（criticality）。虛擬機管理程序（VMM）可以與虛擬機內部的調度器協(xié)同，并智能地安排 vCPU 的位置。游戲引擎的調度器則知道渲染的截止時間，以及哪些線程對延遲敏感（latency-critical）。

每個 cgroup 可綁定一個 scheduler，父 scheduler 通過 dispatch 驅動子 scheduler 獲得 CPU 時間，從而形成自頂向下的帶寬分配 + 組內調度兩級（或多級）結構，目前控制最大深度SCX_SUB_MAX_DEPTH = 4，防止調度路徑過深、復雜度失控。

父 scheduler 在ops.dispatch()里面決定哪個子 scheduler 運行以及給多少 CPU 時間。每個 sub-scheduler 都是獨立實例，維護自己的運行參數(shù),典型包括：默認時間片（time slice）、watchdog（卡死檢測）、bypass mode（旁路模式）、本地 DSQ / runqueue 狀態(tài)，因此,每個 cgroup可能成為一個獨立調度域。父 scheduler的ops.dispatch()可以調用scx_bpf_sub_dispatch()來觸發(fā)子調度器的 dispatch，child 再選具體 task 運行。

tj 的 patchset 一共 34 個 patch：

代理執(zhí)行 proxy-execution 以解決優(yōu)先級翻轉

如下圖，P2 求 P1 的持有的鎖，但是 P1 因為被搶占（時間片耗盡等原因）拿不到 CPU，從而 P2 要等很久才拿到鎖，造成用戶層面的卡頓體驗。

代理執(zhí)行的邏輯是，在調度層面把調度上下文和執(zhí)行上下文分開。假設 P2 上下求鎖而不得的時候，它會在它的 task_struct 里面記錄 block_on 什么任務上面，在這里是 P1，于是 P2 會把自己的時間（調度上下文）“捐獻”給 P1 去跑，P1 用 P2 捐獻給自己的時間執(zhí)行 P1 的代碼（執(zhí)行上下文）。

如上圖所示，現(xiàn)在 P2 把時間捐給 P1 后，很快 P1 就把鎖釋放了。然而，魔鬼都在細節(jié)里，實際上，這里面有一些復雜的問題：

1. P2 把時間捐給 P1 后，P1 運行的過程中說不定會要求持有第 2 個鎖等待，因此再次阻塞；顯然我們需要把這個捐贈的過程變成一個鏈條。

2. P1 和 P2 可能不在一個 CPU 上，不在一個 runqueue 上面，跨國沒法捐。所以我們很可能要把 P2 的調度上下文先遷移到 P1 上面去給 P1。

目前 6.17 合入的是一個 baby step，支持 P1 和 P2 本身在一個 CPU 上的時候的代理執(zhí)行，目前顯然沒有實際意義，因為哪怕手機只有 8 個核，P1 和 P2 在同一個 CPU 的機會也很渺茫。但是，基于社區(qū)迭代開發(fā)的流程意義上來講，這是極其重大的一個進展，它為 proxy execution 的未來開啟了一扇大門。 關于 Donor Migration 的支持，已成為一個單獨的 patchset 來開發(fā)和 review。

proxy execution 主要由 Google 的 John Stultz 領導開發(fā)，由多名 developer 聯(lián)合貢獻，其首要目的在于改善 Android 系統(tǒng)的用戶體驗。

swap table 替代 xarray

swap table 本質上是一種替代目前 xarray 管理方式的，更簡潔、更高性能的 swapcache 實現(xiàn)。

在 Linux 內核中，我們用 xarray 來描述一個文件的 pagecache 命中情況。比如一個很大的文件，在 pagecache 中只命中了很少的頁。拿到相應位置的文件 offset，則可通過 xarray 樹形結構的逐級查詢(類似多級頁表從虛擬地址到物理地址的方式)來獲知這些命中頁的指針，而其他絕大多數(shù)區(qū)間由于未在 pagecache 命中，并不需要在 xarray 上分配出元數(shù)據(jù)。

在 Linux 內核的實現(xiàn)中，針對匿名頁，也存在一種與文件頁的 pagecache 類似的東西，叫 swapcache。swapcache 可簡單理解為一張表，給到一個 offset，可以查詢到對應 swap slot，是否在內存也有副本，如果有，副本是哪一個 page。

在 swapcache 的管理上，Linux 內核采用了與文件頁 page cache 管理相似的做法，甚至底層 swapcache 的查詢 API 都間接是文件的 API：

目前 Linux 內核把 swap 分區(qū)/文件的每 64MB 組織為一個 address_space，每 64MB 作為 1 個 xarray 來描述。

swap 相對文件其實是有顯著區(qū)別的：

1. swap 分區(qū)/文件的數(shù)量是相對有限的，往往就是 1 個，常見的配置也很難超過 4、5 個。不像文件，可能成千上萬無數(shù)個。

2. swap 的大小相對來說是固定的，可預測的。比如開機配置好了，就基本不動了。 不像文件，有大有小，大則多少個 T，小則多少個 B，五花八門。

3. swap 的訪問模型相對可控，針對特定的 workload 場景，有多少 swap 空間會被用到，相對來說是可預測的。

這為 swapcache 的至簡化設計創(chuàng)造了可能性， swap table 的設計和實現(xiàn)誕生了 。

假設一個swap分區(qū)是 2GB，我們先把這 2GB swap 空間按照 2MB 拆分為cluster：

而每個 cluster 內部則有 512 個 swap slot。

swap table 的設計理念非常簡單，它為每個 cluster 給出 512 個 unsigned long 型數(shù)據(jù)，這個 unsigned long 數(shù)據(jù)可以存放 swapcache 命中的 page(現(xiàn)在我們或可別扭地稱呼它為“folio”)的指針，或者是 shadow（用于 refault 機制），或者是 NULL。

}

這樣，對于 64 位的 arm64， x86_64 等 arch 而言，每個 cluster 的 swap table 占據(jù)的內存正好是 4KB。

根據(jù) swap offset，我們通過它的高位可以找到它屬于哪個 cluster，而通過它的低位可以找到它對應 512 個 slot 里面的哪一個 slot：

}

由此可見，這個檢索過程是相對于 xarray 而言是更快的，相對于 xarray 原先的 O(logN)，現(xiàn)在可認為是 O(1)。原先 swapcache 雖然限制了每個 address_space 的大小為 64MB，但是樹的深度還是可以達到 3 級的。

另外，由于一個 cluster 的 swap table 的內存都聚集在同一個 page 里面，當 swap out 密集發(fā)生在同一個 cluster 的時候，它能表現(xiàn)出更強的 locality 局部性，有利用減小 cache miss 等。xarray 的樹形結構以及基于 slab 的內存管理方式，則更可能在多個 page 里面來回跳躍訪問。

xarray 的樹管理一個更廣闊的范圍，每個 address_space 為 64MB，這意味著，會跨越多個 cluster，64MB 的范圍需要統(tǒng)一管理和加鎖，并且 cluster 內部的訪問也需要 cluster lock。而 swap table，本身不會垮 cluster，僅在一個 cluster 內部訪問，只需要對 2MB 的 cluster 本身加鎖。由此去掉了原先管理 xarray 樹形結構的鎖需求。

最后，大道至簡，swap table 這種類似數(shù)組的設計思路，寫出來的代碼人人都能看得懂。

關于 swap table 內存占用方面的優(yōu)化，在[PATCH 8/9] mm, swap: implement dynamic allocation of swap table 中，Chris 和 Kairui 實際安排了 swap table 的動態(tài)釋放，在一個 cluster 里面的 512 個 slot 都沒人用的時候，這個 cluster 的 swap table 可以釋放。

由于 swap table 的顯著優(yōu)勢來源于查詢路徑的縮短、locality 的提升、lock contention 的減小，相對 xarray 加速了 swapcache 的查詢、修改等操作，屬于基礎設施的改善，其優(yōu)勢在服務器等場景會呈現(xiàn)較大的實用價值，對一些關鍵業(yè)務的吞吐量帶來提升。

TCP 零拷貝發(fā)送 DMABUF

Device Memory TCP (devmem TCP)完成了 2 個目標：

• 通過網(wǎng)絡發(fā)送設備 memory。底層的設備 memory 采用 dma-buf 機制；

• 通過網(wǎng)絡接收設備 memory 并直接存入本地的設備 memory。

因此，它是一種 Direct-to-device 的網(wǎng)絡方法。

我們知道 dma-buf 提供了一種本機內部設備與設備、設備與設備共享內存的方法，之前筆者已經在《)》中有論述。簡單地來說，dma_buf 可以實現(xiàn) buffer 在多個設備的共享，應用可以把一片底層驅動 A 的 buffer 導出到用戶空間成為一個 fd，也可以把 fd 導入到底層驅動 B。當然，如果進行 mmap() 得到虛擬地址，CPU 也是可以在用戶空間訪問到已經獲得用戶空間虛擬地址的底層 buffer 的。

devmem TCP 實際上把 dma-buf 的傳輸擴展到網(wǎng)絡上并非本機的設備、CPU 之間了。由于是 A 機器的 dma-buf 送到 B 機器的 dma-buf，這樣避免了設備的 dma-buf 和 host buffer 之間的拷貝。

跨節(jié)點的 device 到 device 的傳輸，在下面的一些應用場景中可能受益：

• 分布式訓練，即在不同主機上的機器學習加速器（如GPU）之間交換數(shù)據(jù)。

• 分布式 raw block storage 應用與遠程 SSD 傳輸大量數(shù)據(jù)。其中大部分數(shù)據(jù)不需要主機處理。

相關的 patchset 主要由 Google 的 Mina Almasry 完成，Linux 6.12 中支持了 rx，而 6.16 內核中，也支持了 TCP dmabuf 的 tx 路徑。接收端的網(wǎng)卡應支持 header 的自動分離，并且支持 flow steering 、RSS，確保目標是 devmem 的網(wǎng)絡包能流向正確的 RX queue。

調度器時間片擴展 time slice extension

想象用戶態(tài)的線程 A 拿到了 spinlock，由于用戶態(tài) spinlock 并不會像內核態(tài) spinlock 那樣禁止搶占，完全有可能線程 B 搶占線程 A，線程 B 可能運行很久，而假設線程 C 需要等待線程 A 的 spinlock 釋放，這個 C 的等待可能是非常長的。

如果我們提供一個機制，比如線程 A 拿到了 spinlock，在 critical section 里面執(zhí)行的過程中，若發(fā)生時間片用完或者其他什么事情要搶占 A，調度器可以擴展一點點時間片給 A，比如 50 微妙內讓 A 不被搶占，則線程 A 大概率可以執(zhí)行完 critical section，從而規(guī)避一系列問題。而具體擴展時間片的長度則可由新增的 rseq_slice_extension_nsec 這個 sysctl 決定。

用戶空間線程通過 prctl() 顯式地告訴內核，它需要時間片擴展：

prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET, +          PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);

有一個 per-cpu 的 Restartable sequences（簡稱rseq）供用戶態(tài)和內核態(tài)交互，需要時間片擴展的一個典型的用戶態(tài)偽代碼如下：

如果線程通過 prctl() 啟用了該機制，就可以把 rseq::slice_ctrl::request 設為 1 來請求延長當前時間片。當線程被中斷且內核因此產生重新調度請求時，內核看到了用戶態(tài)設置了 rseq::slice_ctrl::request =1，它可能選擇不立即把線程換下 CPU，而是批準一次 rseq_slice_extension_nsec 時間片擴展并直接返回用戶態(tài)繼續(xù)執(zhí)行。

當內核同意時間片擴展時，會把 rseq::slice_ctrl::request 清零，并將 rseq::slice_ctrl::granted 置為 1，表示擴展已批準；如果在擴展之后線程仍然被resched（被換下 CPU），內核會再把 granted 位清零，用來通知用戶態(tài)這次擴展已經結束或失效。

基于 RSEQ 的時間片擴展工作，主要由 Thomas Gleixner 和 Peter Zijlstra 完成。

multi-kernel

Cong Wang 在 LKML 發(fā)送了一個 RFC 序列，支持 multi-kernel。multi-kernel 與容器、hypervisor 都有本質不同,它在同一臺機器上并行運行多個 Linux kernel，每個 kernel 獨占一部分硬件，并通過消息通信協(xié)作。

在 Cong Wang 建議的方法中，host kernel 管理 spawn kernel。

Host kernel 負責：硬件資源管理、創(chuàng)建 / 銷毀子 kernel、跨 kernel 協(xié)調。Spawn kernel 負責跑應用、具備獨立調度 / 內存 / IO 并與其他 kernel 隔離。Cong Wang 的 multi-kernel 實現(xiàn)可以概括為：

1. 用 kexec 在同機啟動多個 Linux

2. 用 CPU / 內存 / IO 硬件分區(qū)做隔離

3. 用 IPI + 共享內存通信

4. 用 hotplug + DT overlay 動態(tài)調資源

5. 用硬件 queue 切分 IO

6. 每 workload 跑定制 kernel

這個 multi-kernel 方案未來會走向何方、能否在 Linux 內核上游社區(qū)引起足夠關注和投入，都會是很值得觀察的看點。

io_uring 的網(wǎng)絡零拷貝收包

由 Pavel Begunkov 和 David Wei 完成的工作，正式合入 Linux 內核 6.15，為 io_uring 增加了零拷貝接收（zero-copy receive）支持，使數(shù)據(jù)能夠直接批量、快速地接收并寫入應用程序內存，而無需再從內核內存中拷貝一份。

io_uring 的零拷貝與 DPDK 有很大不同，DPDK 完全 bypass 了內核，而 io_uring 這種內核為 userspace 提供的 async I/O 模式，則仍然重用了內核的網(wǎng)絡機制，如下圖，借鑒硬件的支持，payload 被硬件直接 DMA 到 userspace 的 buffers。

io_uring 提供了一種“混合旁路（hybrid bypass）”機制：在保持與 Linux 內核體系緊密集成的同時，實現(xiàn)了顯著的性能提升。相比 DPDK 這種完全旁路（full bypass）方案，它在使用上更加便捷，對現(xiàn)有系統(tǒng)的侵入性也更低。

它的整個工作流程如下：

在 io_uring中，用戶和內核通過 2 個 queue 交互：SQ（Submission Queue）、CQ（Completion Queue）。

由于 DMA 要直接往 userspace 的 buffers 里面?zhèn)鬏敂?shù)據(jù)，所以 buffer 需要在內核 pin 住，相關 API 是：io_uring_register_buffers()。

與前面的 devmem TCP 相似，該機制也依賴于硬件的報文頭/數(shù)據(jù)分離（header/data split）、流量引導（flow steering）以及 RSS（接收端擴展），以確保數(shù)據(jù)包頭部保留在內核內存中，而只有目標流量才會被導向配置為零拷貝的硬件接收隊列。

io_uring dmabuf 讀寫支持

這個 patchset 試圖讓存儲設備（如 NVMe）可以直接 DMA 到 dmabuf 所代表的內存，而不是走用戶頁緩存 / copy 路徑。

用戶態(tài)發(fā)起：

    { dma_buf_fd, file_fd });

即：

• 提供 dmabuf fd

• 提供目標 file fd（如 nvme block）

發(fā)起讀：

io_uring_prep_read_fixed(..., reg_buf_idx);

注意這套能力不是給通用文件 I/O 準備的，而是給高性能數(shù)據(jù)管線 / 設備直通 pipeline 用的，不是 ext4 / f2fs 等文件讀寫。

該 patchset 把 dmabuf 封裝成一種可被 block 層提交和 DMA 的 buffer 類型，讓存儲設備可以直接對 dmabuf 做 DMA。主要實現(xiàn)原理（4 步）:

A.注冊：dmabuf → dma_token

用戶用 dmabuf fd 注冊 io_uring buffer 時：

dma_buf_get()

dma_buf_attach(target_device)

dma_buf_map_attachment()

→ stable

然后封裝成一個內部對象：dma_token，它代表一塊可 DMA 的共享內存。

B. 提交 IO：新 iterator 類型

新增一種 buffer 迭代器：ITER_DMA_TOKEN

提交 read/write 時：

SQE → dma_token → iov_iter

讓 block 層識別這是 dmabuf，而不是用戶頁。

C. 構建 bio / request

block 層改造后可以：

bio → dma_token → sg_table

不再依賴 page，而是直接用 dmabuf 的 scatter-gather 表。

D. Driver DMA

以 NVMe 為例：

sg_table → PRP / SGL → device DMA → dmabuf

實現(xiàn)存儲設備直接 DMA 到 dmabuf 內存。

dmem cgroup

在較早的內核中，cgroup 已經可以管理普通系統(tǒng)內存（RSS、swap 等），但缺少針對 GPU / 加速器設備內存的統(tǒng)一計量與限制機制。

dmem cgroup 是用來對“設備私有內存（device memory）”做資源隔離與計量的 cgroup 控制器。它管的不是普通 DRAM，而是 GPU、accelerator 和其他的 device 本地內存。dmem cgroup 目的在于：

• 讓 cgroup 能統(tǒng)計設備內存使用量；

• 能針對這些內存設置 min/low/max 限制；

• 能在資源過度使用時做 eviction（回收/驅逐）

在 Linux 6.14 中，DMEM cgroup 支持已經集成到 Intel Xe 內核圖形驅動中，用于根據(jù) cgroup 層級限制顯存（vRAM）的使用。這個用于顯存內存計數(shù)的 DMEM cgroup 代碼，也可以“輕松地”被其他依賴 TTM（Translation Table Maps）進行內存管理的內核圖形驅動復用。

dmem 的 cgroup 接口如下：

• dmem.current：當前 cgroup 使用的 device memory 字節(jié)數(shù)；

• dmem.max, dmem.min, dmem.low： nested-keyed（支持層級鍵值），用于配置不同 cgroup 的內存資源限制；

• dmem.capacity：顯示該內存區(qū)域的最大容量，僅存在于 root。

dmem 的整個實現(xiàn)原理如下：

作者簡介

宋寶華，經典讀書《Linux設備驅動開發(fā)詳解》作者。Linux 主線內核dma-mapping benchmark、SWAP、THP 的維護者或審核者，累計給 Linux 主線內核貢獻數(shù)百個補丁。在 Linux 調度器、內存管理、ARM arch、DMA、中斷、驅動等領域有廣泛的貢獻，是 SCHED_CLUSTER、PER_NUMA CMA、zswap 硬件壓縮解壓、ARM64 TLB batch unmap、swap entries 批量 unmap、mTHP swap-in、madvise PER_VMA lock 等特性的 author 或 co-author。

參考文獻：

[1]slab sheaves和barns

https://lore.kernel.org/linux-mm/20260123-sheaves-for-all-v4-0-041323d506f7@suse.cz/

[2]sched-ext sub-schedulers:

https://lore.kernel.org/lkml/20260121231140.832332-1-tj@kernel.org/

[3]代理執(zhí)行Proxy Execution:

https://lwn.net/ml/all/20250712033407.2383110-1-jstultz@google.com/

https://lwn.net/ml/all/20250722070600.3267819-1-jstultz@google.com/

[5]scheduler時間片擴展：

https://lore.kernel.org/lkml/20251215155615.870031952@linutronix.de/

[6]tcp dmabuf tx零拷貝：

https://lore.kernel.org/netdev/20250508004830.4100853-1-almasrymina@google.com/

[7] io_uring zero_copy rx:

https://lwn.net/Articles/1004591/

[8] io_uring file->dmabuf:

https://lore.kernel.org/all/cover.1763725387.git.asml.silence@gmail.com/

[9]dmem cgroup:

https://lore.kernel.org/lkml/20241204134410.1161769-1-dev@lankhorst.se/

[10]swap table:

https://lore.kernel.org/linux-mm/20250822192023.13477-1-ryncsn@gmail.com/

https://lore.kernel.org/linux-mm/20250514201729.48420-25-ryncsn@gmail.com/

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯(lián)合主辦「2026 奇點智能技術大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術大會上海站，我們不見不散！