「客戶自帶雲」不只是搬進客戶帳號:Omnistrate 拆解 BYOC 部署的五道光譜
Omnistrate Blog · 2026-07-16
背景
雲端基礎設施平台 Omnistrate 創辦人 Kamal Gupta 於 2026 年 7 月 16 日發表文章,指出「BYOC」(Bring Your Own Cloud,客戶自帶雲)常被業界簡化成「把軟體部署進客戶的雲端帳號」,但實務上這個詞底下藏著至少五種責任劃分完全不同的部署模式。文章的核心論點是:BYOC 不是單一架構,而是一條從純代管 SaaS 延伸到完全氣隙(air-gapped)環境的光譜,越往光譜右端移動,客戶保留的控制權越多,供應商能自動化與觀測的範圍就越少。這個框架借用了雲端服務常見的「共同責任模型」(shared responsibility model)邏輯,用來描述軟體供應商與客戶之間的責任邊界。
五種部署模式的技術邊界
文章依控制權轉移程度列出五個層級,差異不在「軟體裝在哪裡」,而在帳號、憑證、更新流程與可觀測性的邊界畫在哪一層。整理如下:
| 模式 | 雲端帳號/憑證 | 部署方式 | 供應商保留的能力 |
|---|---|---|---|
| Vendor SaaS | 供應商持有 | 供應商全權管理生命週期 | 完整基礎設施、資料平面、網路 |
| BYOC-Account | 客戶建立專屬帳號,供應商用受限 IAM 角色存取 | 部署代理(agent)或 Terraform/CloudFormation 腳本 | 產品生命週期(部署、擴縮、升級) |
| BYOC-VPC | 客戶提供 VPC/子網路邊界 | 整合既有路由、DNS、防火牆、私有端點(如 PrivateLink) | 應用層邏輯,不含網路拓樸 |
| BYOC-K8s | 客戶提供受管 K8s 叢集 | Helm chart、operator、CRD、service account | 僅應用層元件,不含叢集本身 |
| Air-gapped | 客戶掌控全部產物與離線倉庫 | 簽章產物(signed artifacts)離線匯入、本地安裝 | 幾乎不保留即時能力(無遙測、無遠端除錯) |
第四層 BYOC-K8s 值得特別注意:供應商甚至不負責底層基礎設施建置,叢集版本、CNI 行為、儲存驅動與 autoscaling 全由客戶的平台團隊掌控,文章特別點出這一層的「協調成本」最容易被低估,尤其是在地端(on-premises)環境。第五層 Air-gapped/Disconnected 常見於國防、公部門與醫療等受管制產業,供應商不能假設有即時遙測、遠端除錯或線上授權檢查,更新與修補都必須透過受控流程「鏡射」進環境。
責任邊界如何隨光譜移動
文章用一句話總結整條光譜的邏輯:「BYOC 在軟體供應商與客戶之間引入了類似的共同責任模型——客戶擁有環境,但供應商仍必須交付可代管的產品體驗。」光譜每往右移一格,客戶取得的控制權就多一分,但供應商能自動化的範圍就少一分,兩者是互為代價而非單純疊加。文章也點名 Terraform 這類單純的基礎設施即程式碼(IaC)工具,在多租戶感知、交易安全與跨模式一致部署上並不足夠,因此才需要專門的「BYOC 控制平面」銜接這五層之間的落差。
驅動企業選擇光譜較右端模式的理由包括:
- 資料主權與地區法規要求
- 希望用私有網路與自有金鑰強化安全控制
- 將既有雲端合約用量(committed spend)導向工作負載
- 資料重力(讓運算貼近既有資料位置)
- 內部平台標準化要求
- 國防、醫療等受管制或離線環境的硬性規定
這些理由彼此獨立,意味企業不會只落在光譜的單一點上,同一家供應商往往需要同時支援 BYOC-VPC 客戶與氣隙環境客戶,而不是選定一種模式就能一體適用。
影響範圍
對正評估「該不該做 BYOC」的軟體供應商而言,這篇文章的實際意義是:「支援 BYOC」不能只回答是或否,而要先決定支援光譜上的哪一段。只做到 BYOC-Account 的產品,無法滿足要求 VPC 私有連線或 K8s 平台標準化的企業客戶;反過來,直接支援氣隙部署又會大幅墊高工程與維運成本,因為遙測、授權檢查、映像檔拉取等一切「連網假設」都得重寫成離線流程。文章沒有提出具體的 API 或規格,但提供了一套比較不同 BYOC 產品說法的共同詞彙,方便採購方在供應商之間做「同層級」比較。
不裝 d3d11.dll、直接寫驅動:UTM 用 Triton 讓 QEMU 虛擬機跑起 DirectX 11 遊戲
UTM Blog · 2026-07-24
背景:Neptune 協定與 Venus 的先例
UTM 專案(開源 macOS/iOS 虛擬化工具)開發者 osy 於 2026 年 7 月 24 日在官方部落格發布 Triton,一個實作 Windows 顯示驅動模型(WDDM)使用者模式/核心模式驅動介面的全新 DirectX 11 驅動程式。Triton 搭配先前發布的 Neptune 協定,讓 QEMU 虛擬機裡的 Windows 客體系統取得完整的 DirectX 11 硬體加速,不再需要逐應用程式置換 d3d11.dll 的變通做法。
Neptune 是把 Direct3D API 呼叫序列化後跨越 hypervisor 邊界傳輸的 VirtIO 協定。Neptune 仿造的是 virtio-gpu 生態系裡已經成熟的 Venus 協定——Venus 由 Mesa 專案定義,用來序列化 Vulkan 指令:客體端驅動把 Vulkan 呼叫編碼進共享的 ring buffer,主機端的 virglrenderer 解碼後在真正的 GPU 上執行,自 virglrenderer 1.0.0 起就支援這個協定。Neptune 沿用同一套高層核心介面(DMA、command buffer 等),因此使用者模式驅動(UMD)與核心模式驅動(KMD)之間的介面幾乎與 Venus 一致。
但 Neptune 只解決了「怎麼把 Direct3D 呼叫送到主機」,沒有解決「Windows 客體要怎麼發出這些呼叫」。把 Neptune 產生的 d3d11.dll/dxgi.dll 直接放進遊戲資料夾雖然能跑,但視窗合成器(DWM)只能把畫面當成一張圖片用 CPU blit 貼上桌面,效能不佳且無法通過反外掛的系統檔案完整性檢查。正確做法是不去實作 DirectX API,而是實作 DirectX 的裝置驅動介面(DDI,Device Driver Interface),這正是 Triton 要解決的問題。
核心架構:把 DDI 呼叫反向轉譯回 API 呼叫
Windows 圖形堆疊的標準路徑是:應用程式呼叫 d3d11.dll 與 dxgi.dll,這兩個系統元件做狀態追蹤後,把整理過的指令流送進使用者模式驅動(UMD)實作的 DDI;UMD 再透過 DXGI 與核心模式驅動(KMD)溝通,KMD 負責驅動實體或虛擬硬體。Triton 要做的就是實作這層 UMD 的 DDI,並與既有的 KMD 串接——團隊選用 anonymix007 的 viogpu3d-venus 分支作為基礎,因為該分支在核心模式驅動側已有較完整的功能。
團隊參考了兩個既有的開源實作。Mesa 的 DirectX 10 UMD 提供了乾淨的程式碼整合範例,但上游只支援軟體光柵化;VirtualBox 則擁有唯一可用的開源 DirectX 11 UMD,做法是把 DDI 呼叫翻譯成中介 bytecode,再由主機端直譯回 DirectX API。UTM 團隊刻意不採用 VirtualBox 的中介 bytecode 做法:一是認為多一層轉譯會放大相容性錯誤且難以維護,二是 VirtualBox 的 GPLv3 授權與 virglrenderer 的 MIT、QEMU 的 LGPLv2 授權不相容。Triton 改採「反向轉譯」——把 DDI 呼叫直接轉回對等的 DirectX API 呼叫,再交給已驗證過的 Neptune 協定序列化送往主機,主機端因為收到的本來就是 DirectX API 呼叫,不需要額外的直譯器或分派邏輯。
這個做法最複雜的部分是 DXBC(DirectX Byte Code)著色器的還原。DXBC 是微軟著色器編譯器 FXC 從 HLSL 編譯出的舊版中介碼,實際傳給 DDI 的只有 DXBC 本體(即 SHDR 區塊),但 d3d11.dll 呼叫 ID3D11Device::CreateVertexShader 時預期收到的是包含 ISGN、OSGN 等輸入輸出簽章中繼資料的完整 DXContainer 檔案。Triton 必須在不重新反組譯位元組碼的前提下,單靠 DDI 傳入的 bytecode 重新合成這些中繼資料欄位,團隊形容這是實作中「最脆弱、最容易出錯的部分」。
跨行程共享材質與圍欄:macOS 後端的取捨
把 Direct3D 呼叫送到主機後仍要有渲染後端。Linux 主機沿用先前fork 過的 DXVK(D3D11 轉 Vulkan);macOS 上團隊評估了三個後端:
DXVK + MoltenVK:再把 Vulkan 轉一層到 Metal,穩定性不足- DXMT:直接把 D3D11 轉 Metal,團隊 fork 出可獨立運作的
dxmt-native - 蘋果 Game Porting Toolkit 內建的
D3DMetal.framework,團隊封裝為 d3dmetal-native
由於 virglrenderer 會為每個客體的 D3D context 各自產生獨立的 virgl_render_server 行程,材質必須能跨行程共享。團隊最終採用 shm_open() 建立共享記憶體,再用 newBufferWithBytesNoCopy 把它映射成 MTLBuffer,利用 Apple Silicon 的統一記憶體架構(UMA)讓 CPU 與 GPU 直接看到同一塊記憶體,不需要額外的 GPU blit。
同步問題則靠「模擬圍欄」解決:生產端呼叫 ID3D11DeviceContext::ClearUnorderedAccessViewUint 把時間軸數值寫進共享記憶體,GPU 執行順序保證這個寫入發生在所有繪圖指令之後;消費端在 CPU 上輪詢(spin-poll)這塊記憶體,看到數值更新才開始合成畫面。這個設計把延遲侷限在「每畫完一幀等一次」,而非逐指令同步。實測顯示走 Rosetta 的 D3DMetal 後端效能優於原生 ARM64 的 DXMT 後端,但 D3DMetal 授權條款明文限制只能用於「開發、測試或評估遊戲」且僅能非商業散布,UTM 因此無法直接把它打包進應用程式散布。
影響範圍
Triton 與 Neptune 的程式碼已經全部開源,分散在多個倉庫:
utmapp/qemu(utm-edition分支)utmapp/virglrenderer(macos-next分支)utmapp/dxmt、utmapp/d3dmetal-native- Windows 端
osy/kvm-guest-drivers-windows(KMD)與osy/virtio-win-mesa(UMD),皆為neptune分支
團隊已提供預先簽署的 Windows 驅動供測試,但強調目前仍不穩定,不建議裝在正式使用的虛擬機上。macOS 建置流程需要 Meson 1.3+、LLVM 15,以及切到特定 commit(6a7f464047e2f6f2b65fe315aaad5d1ff3229cb7)的 WebKit ANGLE 原始碼樹。QEMU 端只需在裝置參數加上 neptune=true 即可讓客體系統辨識這個新的 capset:
-device virtio-ramfb-gl,hostmem=8G,blob=true,venus=true,neptune=true \
-display cocoa,gl=es原始來源:UTM Blog: Introducing Triton、UTM Blog: Introducing Neptune、Mesa3D: Virtio-GPU Venus