CUDA IPC怎麼共享GPU記憶體？Handle、Event、VMM與生命週期

Legacy IPC 與 VMM IPC：先選對抽象層

CUDA Programming Guide 把跨程序 GPU 記憶體共享分成 Legacy CUDA IPC 與 Virtual Memory Management（VMM）兩種主要路徑。Legacy IPC 以 cudaIpcGetMemHandle 從既有 Device Allocation 產生 process-portable handle，接收程序再用 cudaIpcOpenMemHandle 取得自己的 local device pointer。VMM 則把 physical allocation、virtual address、mapping 和 access rights 拆開，以 Driver API 更細緻地控制哪些程序或 GPU 可以看到哪一段記憶體。

兩者都不是「把 pointer 傳給另一個 process」。pointer 只是建立它的 address space 中的數值；真正跨程序傳遞的是 opaque handle 和必要的 metadata。Handle 必須走受控的 Unix socket、shared memory、pipe、file descriptor、MPI 或其他 IPC channel，接收端還要重新 import、reserve、map 和 set access。程式若把 pointer 字串寫進 queue，通常只是把位址誤當成資源識別。

VMM 的完整順序：Allocate、Export、Import、Map、Access

VMM 的關鍵不是單一函式，而是不可跳過的順序。Exporter 先依 allocation property 建立 physical memory，並以 cuMemGetAllocationGranularity 取得對齊要求；接著以 cuMemExportToShareableHandle 匯出可分享 handle。接收程序 import 後，必須在自己的 virtual address space reserve 一段範圍，再用 cuMemMap 把 physical allocation 映射進來，最後以 cuMemSetAccess 設定可讀寫的 location。

cuMemMap 完成不代表記憶體已可讀寫；mapping 和 accessibility 是兩件事。size、address、offset 也要符合 granularity 和 alignment。若不同 GPU、不同 process 或不同 node 使用不同 mapping，控制面要保存 allocation identity、size、granularity、source device、target device、mapping generation 和 access policy，否則很難在錯誤時判斷是 handle、alignment、peer access 還是 kernel 本身失敗。

physical = cuMemCreate(size, properties)
shareable = cuMemExportToShareableHandle(physical)
send(shareable, authenticated_ipc_channel)

imported = cuMemImportFromShareableHandle(shareable)
va = cuMemAddressReserve(size, alignment)
cuMemMap(va, size, imported)
cuMemSetAccess(va, size, allowed_locations)

use only after ready_event and generation check

OS-specific Handle 與 Fabric Handle 的邊界

CUDA VMM 的 OS-specific handle 通常適合同一台主機上的 process 間共享；Fabric handle 則針對支援的高頻寬 fabric，可能讓跨 GPU 或跨 node 的共享成為可行路徑。兩者的安全條件不同。OS handle 需要正確的 file descriptor 傳遞與 process identity；Fabric handle 需要系統管理員啟用 IMEX channel、正確的 driver capability 和每個使用者的存取範圍。

目前 CUDA 文件提到 nvidia-caps-imex-channels 及其 per-user security model。多使用者環境不能只因為同一台機器或同一個 fabric 就假設所有程序可以互相共享；若要做租戶隔離，應配置分離 channel、OS credential、container boundary 和明確的 access descriptor。Fabric handle 的功能可用，不代表你的 driver、GPU、container runtime 和網路 fabric 已經具備相同能力。

• 先以 device attribute 查詢 handle type 是否受支援。
• 確認 driver、CUDA、GPU topology、IMEX daemon／channel。
• 確認 export、transport、import、map、access 每一步的錯誤碼。
• 把 user、tenant、process credential 與 allocation identity 寫入控制面。
• 在沒有 fabric 能力時，保留 Host Copy 或 RDMA fallback。

Legacy CUDA IPC 的正確生命週期

Legacy IPC 中，Exporter 擁有原始 allocation；Importer 只擁有 mapping。Importer 完成使用後呼叫 cudaIpcCloseMemHandle，不能把 imported pointer 當成自己的 allocation 直接 cudaFree。Exporter 必須等所有 importer 都完成，才可釋放原始 allocation；如果 exporter 提早退出，consumer 需要 coordinator 判斷 resource lease、程序存活與 recovery，而不是繼續讀取已失效的 handle。

CUDA Event 的 IPC 也只解決同步訊號，不會自動解決資料版本。Producer 在 stream 上完成 copy 或 kernel 後 record event；consumer 開啟 event 並讓自己的 stream wait。Ring buffer 還要額外保存 slot state、generation、producer／consumer sequence、bytes、checksum、ready event 和 done event，避免 consumer 讀到上一輪資料，或 producer 覆寫尚未讀完的 slot。

Container、MIG 與多租戶的實際檢查

兩個 container 能否共享，不只取決於 CUDA API 是否成功。它們要看到相容的 GPU、driver、device node、IPC namespace、Unix socket 權限與 security policy；MIG instance 之間的 handle、peer access 與 fabric 能力也要以目前環境的官方支援矩陣確認。對不同租戶，最安全的預設是獨立 exporter、獨立 allocation、獨立 socket ACL 和獨立 cache namespace，而不是共用一個大 buffer 再以 offset 自行分割。

Handle 本身不能寫入一般 application log、metrics label 或公開 artifact。錯誤報告只保留 opaque allocation id、generation、size、device class、錯誤碼和 trace id；真正的 handle 傳輸只走受控 channel。若使用 file descriptor，還要驗證接收端的 process credential 和 descriptor ownership，避免一個不應該有權限的程序取得可映射 GPU memory。

何時選 IPC、VMM、RDMA 或直接複製？

同一台主機、固定的 producer／consumer pipeline、資料量大且交接頻繁時，Legacy IPC 可能是較低整合成本的選擇；需要 per-allocation access、不同 mapping、較複雜的多 GPU topology 或 fabric memory 時，再評估 VMM。跨 node 或需要可觀測的網路傳輸時，RDMA、NCCL、NIXL 或專用 KV transfer backend 可能比把 CUDA IPC 硬延伸到遠端更合適。資料小、頻率低、租戶隔離優先或 recovery 要簡單時，Host Copy 反而是更可維護的 baseline。

驗收不是只測 bandwidth

先建立 Host Copy 與 Device-to-Device Copy baseline，再分別測 Legacy IPC、Event IPC、VMM 同機、VMM peer 和可用的 fabric 路徑。每次都固定 bytes、allocation alignment、stream、GPU topology、producer／consumer rate 和 buffer depth，記錄 handoff latency、端到端 latency、GPU idle、CPU usage、memory leak、mapping error、event wait、recovery time 和資料完整性。

1. 正常一寫一讀，驗證 byte pattern、generation 與 checksum。
2. Producer 在 READY 前退出，驗證 consumer 不會讀取半成品。
3. Consumer 在 READING 中退出，驗證 coordinator 能回收 slot。
4. 重複 export／import／close，檢查 mapping 和 allocation 沒有累積。
5. 切換 GPU topology、container、MIG 或 driver，確認 unsupported path 清楚失敗。
6. 把 IPC 失敗降級到 Host Copy，驗證結果正確且可觀測。

效能結論必須包含硬體、CUDA 版本、driver、API 路徑、bytes、同步方式和失敗行為。只報出一個 memcpy 或 IPC microbenchmark 數字，無法代表真正的推論、編碼、KV 交接或視覺化 pipeline。

控制面與資料面要分開設計

GPU buffer 的共享通常同時包含控制面與資料面。資料面負責搬運真正的 tensor、影像或 KV block；控制面則負責傳遞 handle、size、offset、generation、layout、dtype、stream、event 與權限。兩者若混在同一個無版本的 queue 裡，任何一方重啟、重試或延遲，都可能讓接收端把上一代 allocation 當成目前的資料。實作上應為每一個 allocation 建立不可重用的 allocation id，並讓 generation 在每次重新 export、重新 map 或 recovery 時遞增。

控制面訊息至少要有 schema version、producer identity、consumer identity、device ordinal 或 UUID、memory type、allocation bytes、有效 payload bytes、alignment、stride、資料格式、ready sequence、done sequence、TTL 和 checksum。對固定長度 ring buffer，slot index 不能單獨代表資料版本；slot index 只表示循環位置，generation 才能判斷這是第幾次使用。當 producer 看到 consumer 的 done sequence 落後時，必須回到 backpressure 或暫存策略，而不是直接覆寫 GPU 記憶體。

跨 process 傳送 handle 時，最好把握手分成 announce、accept、map、ready 四個階段。announce 只公布 metadata 與 allocation id；accept 驗證 credential、版本與支援的 handle type；map 完成 import、address reserve、mapping 和 access；ready 才表示 consumer 可以讀取。任何中途錯誤都要回傳可分類的 error code，並讓 exporter 決定是否撤銷、重試或退回 Host Copy。這種狀態機比「send handle 後立即使用」更能處理 consumer 尚未初始化、driver 不支援或 container 權限錯誤。

常見錯誤與可觀測性

最常見的錯誤不是 kernel 算錯，而是兩個程序對同一個 buffer 的生命週期理解不同。Exporter 可能已經 close 或 free，但 consumer 的 stream 還在使用；consumer 可能收到正確 handle，卻以不相容的 size、offset 或 alignment map；也可能 mapping 成功，但 access policy 沒有包含實際執行 kernel 的 GPU location。這些情況若只記錄「IPC failed」，現場很難區分傳輸問題、權限問題、topology 問題和同步問題。

可觀測性也要避免把秘密變成遙測資料。metrics 應以雜湊後的 allocation id、拓樸類別和錯誤分類統計，不要把可重建的 file descriptor、shareable handle 或完整 socket payload 放進 log。trace 可以串起 announce 到 close 的時間線，並標示每一次 map、access、event wait 和 fallback；這樣才能回答「卡在建立共享、等待同步，還是實際 kernel」而不是只看到總延遲。

重啟、逾時與回滾策略

共享記憶體服務必須假設 producer、consumer、coordinator 和 container 都可能獨立重啟。重啟後不能依賴 process-local pointer 或上一輪的 event；coordinator 應先把舊 allocation 標成 SUSPECT，再等待 lease、heartbeat 和 in-flight fence 的結果。若無法確認所有 consumer 已停止，寧可建立新 allocation 並讓舊 allocation 進入 quarantine，也不要冒險重用相同的 slot 和 generation。

逾時要有清楚的分層：短暫的 event wait 可重試，map 或 access 的不支援錯誤不可盲目重試，transport 斷線可重新握手，driver reset 則應重建整條 pipeline。每次重試都要帶 attempt id 和相同的 allocation generation；若重試產生新 handle，generation 必須改變，讓遲到的舊訊息在接收端被拒絕。fallback 到 Host Copy 時也要維持相同的資料 schema、checksum 和 sequence，讓上層不用猜測目前走哪條路。

回滾不只是刪掉 pointer。安全回滾包含停止新工作、發出 revoke、等待或隔離 in-flight stream、解除 mapping、close imported handle、釋放 physical allocation、清理 socket 端點與刪除 coordinator 狀態。測試時應故意在每個步驟後注入 crash，確認下一次啟動不會把殘留的 IPC metadata 當成有效資源。對多租戶服務，quarantine 資源還要有上限與告警，否則正確的安全策略可能轉成 GPU memory 慢性洩漏。

把 IPC 納入部署前的相容性矩陣

部署前應把「可呼叫 API」與「實際可用能力」分開驗證。矩陣至少涵蓋 CUDA toolkit、driver、GPU 型號、compute capability、MIG 設定、container runtime、IPC namespace、security policy、同機或跨節點 topology、handle type 與 fallback。每一格都要記錄支援、明確拒絕或尚未驗證，不能因為開發機成功就把整個 production fleet 標成可用。

對推論服務而言，建議先用小尺寸固定 pattern 做相容性 smoke，再用真實 batch、KV cache 或影像格式做整合測試。smoke 需要驗證資料值、generation、event ordering、close ordering 和錯誤碼；整合測試再觀察吞吐、尾端延遲、memory pressure、GPU idle 和 fallback 比例。若 topology 改變、driver 升級或 container 權限調整，應重新執行 smoke 與一輪壓力測試，並保留測試環境快照。

最後，文件要讓維運者能在故障時做出保守決定：看到 unsupported handle，就切換支援的路徑；看到 stale generation，就丟棄訊息並重新握手；看到 owner 消失，就隔離 allocation；看到映射或 access 失敗，就記錄 device 與 topology 後回到 baseline。這些規則比追求單次 benchmark 的最高數字更重要，因為共享 GPU 記憶體的真正風險通常發生在重啟、升級、權限變更與高併發交接，而不是穩態的單一測試。

官方資料與圖片來源

本文依據 CUDA Programming Guide：Interprocess Communication、CUDA Programming Guide：Virtual Memory Management、CUDA Driver API：Virtual Memory Management與 CUDA Features 官方導覽整理。OS-specific handle、Fabric handle、IMEX channel、MIG、driver 與 container 能力均具有環境與版本條件，本文提供查核與故障演練方向，不把任何單一硬體的結果宣稱為通用保證。圖片使用 CUDA Programming Guide 官方 VMM 圖片，來源頁與圖片URL均保留，不主張超出 NVIDIA 原始文件的授權範圍。

__IPC_SHARED_GPU_MEMORY_26507_SOURCE_IMAGE_RECONCILE_20260816__