一、 VM 與 container 差異
在雲端運算與軟體開發中，虛擬機器 (Virtual Machine, VM) 與 容器 (Container) 是兩種最常見的虛擬化技術。簡單來說，兩者的核心差異在於「虛擬化的層級」以及「對資源的消耗方式」。
1. 核心技術架構
(1) 虛擬機器 (VM)
VM 是硬體層級的虛擬化。它透過 Hypervisor（如 VMware, KVM, 或 Hyper-V）在實體硬體上模擬出一套完整的硬體環境。
組成： 每個 VM 都包含一份完整的客用作業系統 (Guest OS)、必要的驅動程式、二進位檔案 (Binaries) 及函式庫 (Libraries)。
特性： 檔案體積大（通常 GB 起跳），啟動較慢（需經過 OS 開機流程）。
(2) 容器 (Container)
容器是作業系統層級的虛擬化。它直接運行在宿主機的 OS 核心上，透過 Container Runtime（如 Docker, containerd）進行隔離。
組成： 容器不包含 OS 核心，只封裝應用程式及其依賴環境（Libraries/Bins）。
特性： 極度輕量（通常 MB 級別），啟動僅需幾秒鐘。
2. 關鍵差異對照表
| 特性 | 虛擬機器 (VM) | 容器 (Container) |
| 隔離性 | 強 (完全隔離，擁有獨立 OS 核心) | 較弱 (共享 OS 核心，透過 Process 隔離) |
| 啟動速度 | 分鐘級 (需引導作業系統) | 秒級 (直接啟動應用程序) |
| 資源消耗 | 高 (每個 VM 都要預留固定記憶體) | 低 (僅消耗應用程式運行的必要資源) |
| 移植性 | 較低 (受限於 Hypervisor 格式) | 極高 (可輕易在不同環境、雲端間移動) |
| 作業系統 | 可運行不同 OS (如 Linux 主機跑 Win VM) | 必須與宿主機 OS 核心相容 |
3. 該如何選擇？
選擇 VM 的場景：
需要極高安全性與完全隔離（例如多租戶環境）。
需要運行不同作業系統的應用（例如在 Ubuntu 上跑 Windows 專屬軟體）。
需要完整的硬體模擬或特定的內核修改。
選擇 Container 的場景：
微服務架構 (Microservices)：將大型應用拆分成多個小服務。
CI/CD 流程：需要快速構建、測試並部署。
雲端原生開發：追求高擴展性（Scalability），如使用 Kubernetes 進行管理。
💡 小提醒： 在現代的開發環境中（如 Google Colab 或一般的雲端伺服器），這兩者經常是結合使用的。例如在一個大型的 VM 實體內部署多個 Docker 容器，以兼顧安全隔離與部署效率。
4. 深度學習環境中的特殊考量：GPU 虛擬化
在進行 AI 相關研究（如電腦視覺或影像處理）時，最核心的問題在於如何存取實體 GPU。
VM 的 GPU 存取 (GPU Passthrough)：
通常需要透過 VT-d 技術將整張顯示卡直接「掛載」給特定的 VM。
優點： 效能損耗極低，且 VM 內的驅動程式與宿主機完全隔離。
缺點： 設定繁瑣，且一張卡通常只能給一個 VM 使用（除非使用昂貴的 vGPU 技術）。
Container 的 GPU 存取 (NVIDIA Docker)：
透過 NVIDIA Container Toolkit，容器可以直接調用宿主機的 GPU 驅動。
優點： 多個容器可以輕易共用同一張 GPU 的運算資源。
缺點： 容器內的 CUDA 版本必須與宿主機的 NVIDIA Driver 版本相容，否則會發生錯誤。
5. 部署流程與生態系
了解這兩者的工具鏈可以幫助您決定如何管理實驗環境：
| 項目 | 虛擬機器 (VM) | 容器 (Container) |
| 主要工具 | VMware, VirtualBox, Proxmox, QEMU | Docker, Podman, containerd |
| 編排管理 (Orchestration) | OpenStack, vSphere | Kubernetes (K8s), Docker Swarm |
| 映像檔格式 | .ova, .vmdk, .qcow2 | Docker Image (存放在 Docker Hub / GitHub Registry) |
| 備份方式 | 快照 (Snapshot) 整機備份 | 修改 Dockerfile 並重新 Build |
6. 現代開發的最佳實踐：截長補短
目前主流的學術與工業界作法並非「二選一」，而是 「Container on VM」：
基礎層 (IaaS)： 在雲端（如 GCP, Azure）或自建伺服器（Ubuntu）上開一個 VM，確保基本的作業系統安全性與資源分配。
應用層 (PaaS)： 在該 VM 內使用 Docker 跑多個容器。
例如：一個容器跑 GitLab Runner 做程式碼同步。
另一個容器跑 Jupyter Lab 進行模型訓練。
第三個容器跑 Conda 環境 以相容舊版的 Torch7/Lua 程式碼。
專業建議： > 如果研究需要頻繁更換實驗環境（例如從 PyTorch 2.0 切換到舊版的 1.4），容器化 是最佳選擇，因為您可以透過撰寫
Dockerfile紀錄所有依賴項，避免發生「在我電腦上可以跑，在你那邊不行」的情況。
二、環境遷移 (Docker)、遠端管理 (xrdp/SSH) 以及 Colab 資源調度
1. 環境遷移：將 Conda/Ubuntu 環境容器化 (Docker)
當在 Ubuntu 實體機或 VM 上開發好一套研究環境（例如特定的 CUDA + PyTorch 組合）後，使用 Docker 可以確保這套環境在任何地方運行結果都一致。
核心邏輯： 撰寫一份
Dockerfile，像食譜一樣紀錄安裝步驟。實作流程：
選擇基底： 使用 NVIDIA 官方提供的映像檔
nvidia/cuda:11.x-base-ubuntu22.04。安裝依賴： 在 Dockerfile 中寫入
apt-get install與pip install指令。打包映像： 執行
docker build -t my-research-env .。遷移： 將打包好的 Image 上傳至 Docker Hub 或私有雲，在另一台機器只需
docker pull即可還原。
優點： 徹底解決「環境衝突」問題，特別是當論文需要交給編輯部或協作者重現實驗時。
2. 遠端管理：xrdp 與 SSH 的分工
在管理遠端伺服器（無論是實體機還是 VM）時，通常會根據工作性質選擇不同的連線方式。
SSH (Secure Shell)：
場景： 程式碼編寫、模型訓練監控、系統設定。
特性： 純文字介面，速度最快、最穩定。搭配
tmux或screen可以讓訓練程式在斷線後持續執行。
xrdp (Remote Desktop Protocol)：
場景： 需要使用圖形化工具（如影像標註軟體、查看實驗結果圖表、或使用 IDE 介面）。
特性： 提供類似 Windows 的遠端桌面體驗。在 Ubuntu 上需安裝 XFCE 或 GNOME 桌面環境。
兩者結合： 建議平時用 SSH 進行開發與訓練，僅在需要查看視覺化結果或操作 GUI 軟體時才開啟 xrdp。
3. 資源調度：在 Google Colab 運行舊版環境 (Legacy Code)
Google Colab 本質上是一個基於容器的環境，但它預裝的是最新的工具鏈。若要運行 7 年前（如 Torch7/LUA）的程式碼，需要特殊的調度技巧。
降級與共存：
CUDA 降級： 在 Colab 中透過指令解除安裝預設的 CUDA，並重新下載舊版（如 10.1）的
.run檔進行安裝。LUA/Torch7 安裝： 透過 Shell 指令在 Colab 的暫存空間內編譯 Torch7。
硬體適配：
Colab 分配的 GPU（如 T4 或 A100）通常較新，必須確認舊版軟體是否支援該硬體架構。
持久化存取： 透過
google.colab.drive.mount()將程式碼與大型資料集（如 SenseReID 或運動影片）串接，避免容器重啟後資料遺失。
三、Dockerfile 的範本
1. 深度學習研究用 Dockerfile 範本
可以將以下內容儲存為名為 Dockerfile 的檔案：
# 步驟 1: 選擇基底映像檔 (根據您的 GPU 需求調整 CUDA 版本)
# 建議使用 devel 版本，因為它包含編譯 code 所需的工具
FROM nvidia/cuda:11.8.0-cudnn8-devel-ubuntu22.04
# 步驟 2: 設定環境變數，避免安裝過程出現互動視窗
ENV DEBIAN_FRONTEND=noninteractive
ENV PYTHONUNBUFFERED=1
# 步驟 3: 安裝系統基礎工具與 OpenCV 所需的函式庫
RUN apt-get update && apt-get install -y \
git \
curl \
vim \
wget \
pkg-config \
libgl1-mesa-glx \
libglib2.0-0 \
python3-pip \
python3-dev \
&& rm -rf /var/lib/apt/lists/*
# 步驟 4: (選用) 安裝 Miniconda 以管理複雜的 Python 依賴
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda.sh && \
/bin/bash ~/miniconda.sh -b -p /opt/conda && \
rm ~/miniconda.sh
ENV PATH /opt/conda/bin:$PATH
# 步驟 5: 設定工作目錄 (對應您在容器內的實驗路徑)
WORKDIR /workspace
# 步驟 6: 複製環境設定檔並安裝依賴
# 先複製 requirements.txt 可以利用 Docker 的 Layer Cache 機制加速後續 Build 過程
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 步驟 7: 複製所有專案程式碼到容器內
COPY . .
# 步驟 8: 預設啟動指令 (例如直接開啟 Jupyter Lab 或執行訓練腳本)
CMD ["bash"]
2. 關鍵部分說明
(1)關於 CUDA 版本選擇
在 Dockerfile 的第一行 FROM 中，版本號非常關鍵。
若要執行較舊的 Torch7/LUA 專案，可能需要將基底更換為
nvidia/cuda:10.1-devel-ubuntu18.04。若宿主機（Host）驅動程式版本較舊，請確保
nvidia-smi顯示的 CUDA 版本大於或等於容器內的版本。
(2) 關於 OpenCV 與多媒體處理
在研究電腦視覺（如 Saliency Detection 或 Re-ID）時，常會遇到 ImportError: libGL.so.1 錯誤。範本中的 libgl1-mesa-glx 與 libglib2.0-0 就是專門用來解決這個問題的。
3. 如何使用此範本？
A. 建立映像檔 (Build)
在程式碼根目錄下執行：
docker build -t my_research_env:v1 .
B. 啟動容器 (Run)
為了讓容器能抓到 GPU，啟動時必須加上 --gpus all 參數：
docker run --gpus all -it --rm \
-v $(pwd):/workspace \
my_research_env:v1
-v $(pwd):/workspace：這會將當前的主機目錄掛載到容器內，這樣在容器內產生的實驗數據或模型權重會直接存回主機磁碟。
4. 針對 xrdp 遠端桌面的補充
如果希望在 Docker 內也使用 xrdp（雖然較不建議，通常是在 VM 層裝 xrdp），需要在 Dockerfile 中額外安裝 xrdp 與 xfce4。但更高效的做法是：
VM 層 裝 xrdp（處理圖形介面）。
Docker 層 跑運算（處理模型訓練）。
在 VM 的圖形介面中開啟終端機，執行
docker run。
四、VMM 安裝的 Guest OS 如何直接用到 Nvidia 顯卡
在虛擬機器（VM）中，Guest OS 看到的通常是 Hypervisor 模擬出來的「虛擬顯卡」（效能極差，僅能顯示畫面）。若要讓 Guest OS 直接使用實體 NVIDIA 顯卡進行運算（如 CUDA 訓練或圖像處理），主要有以下兩種方案：
1. 方案一：GPU Passthrough (核心技術)
這是最常見的做法，將主機上的 PCIe 顯卡直接「許配」給某個特定的 VM。
運作原理： 透過 VT-d (Intel) 或 AMD-Vi (AMD) 硬體虛擬化技術，繞過宿主機（Host）的作業系統，讓 Guest OS 直接控制硬體暫存器。
優點： 效能幾乎與實體機相同（約 95% - 99% 效能）。
缺點： * 獨佔性： 一張顯卡只能給一個 VM 使用。當該 VM 啟動時，宿主機本身會失去該顯卡的控制權（畫面會黑掉，除非你有兩張顯卡）。
設定複雜： 需修改 BIOS/UEFI 設定、調整 GRUB 參數（隔離 GPU），並處理 NVIDIA 驅動程式對虛擬機的偵測（雖然後期驅動已放寬限制）。
2. 方案二：vGPU (NVIDIA GRID / vCS)
這是企業級的解決方案。
運作原理： 將一張強大的顯卡（如 A100, H100 或部分 RTX 伺服器級卡）切分成多個虛擬 GPU 實例，分配給多個 VM 同時使用。
優點： 資源利用率高，多個 Guest OS 可同時共享 GPU。
缺點： 需要授權費（NVIDIA 軟體授權非常昂貴），且通常僅支援特定的資料中心等級顯卡（Tesla/Quadro 系列），消費級 GeForce 卡官方支援度有限。
3. 不同 VMM (Hypervisor) 的支援狀況
| Hypervisor | 支援度 | 備註 |
| Proxmox (KVM) | 極佳 | 社群文件最豐富，是目前學術界最推薦的開源方案。 |
| VMware ESXi | 優良 | 企業級標準，介面直觀，但硬體相容性要求較嚴。 |
| Hyper-V | 普通 | 支援「GPU Partitioning」，但對 Linux Guest OS 的 CUDA 支援設定較繁瑣。 |
| VirtualBox | 極差 | 僅支援 3D 加速模擬，無法進行 CUDA 運算或硬體直通。 |
4. 情境建議
如果是在 Ubuntu 伺服器上管理多個實驗環境：
若只有一張顯卡： 建議直接在宿主機（Host）裝好 NVIDIA Driver，然後用 Docker (NVIDIA Container Toolkit)。這樣不僅能發揮全效能，還能讓多個容器同時使用顯卡。
若有多張顯卡且需要完整作業系統隔離： 使用 Proxmox 進行 GPU Passthrough，將 GPU 01 給實驗 A (VM)，GPU 02 給實驗 B (VM)。
⚠️ 特別提醒： > 以前 NVIDIA 會在驅動程式中偵測
Error 43來阻擋 GeForce 卡在 VM 內執行，但 NVIDIA 已在 2021 年後的驅動（465.89 版本以上）移除了這個限制，現在 GeForce 30/40 系列在 VM 內做 Passthrough 已經容易許多。
方案 A：首選建議 — WSL2 (Windows Subsystem for Linux)
WSL2 是微軟開發的輕量化虛擬化技術，它直接與 Windows 共用 GPU 驅動，不需要複雜的「硬體直通 (Passthrough)」設定。
實作步驟：
Windows 端： 確保 NVIDIA 驅動程式已更新至最新版（支援 CUDA on WSL）。
安裝 Ubuntu 24.04： 在 PowerShell 執行
wsl --install -d Ubuntu-24.04。驗證 GPU： 進入 Ubuntu 後，執行
nvidia-smi。會發現不需要在 Ubuntu 裡裝驅動，就能直接看到 1060 Ti。安裝 Docker： 在 Ubuntu 內安裝 Docker Desktop 或原生 Docker Engine。
安裝 NVIDIA Container Toolkit： 這是關鍵步驟，讓 Docker 容器能調用 WSL 看到的 GPU。
Bash# 在 Ubuntu 內執行 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg # (後續步驟為設定 repo 並 apt install nvidia-container-toolkit)執行測試：
docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi。
優點： 記憶體動態分配、GPU 效能損耗極低、Windows 與 Ubuntu 檔案互通極快。
缺點： 它不是「完整獨立」的 VM，如果需要測試 Linux 內核層級的開發，WSL2 限制較多。
方案 B：完整虛擬機 — Hyper-V (GPU Partitioning)
如果堅持要用獨立的 VMM（如 Hyper-V），Windows 10 支援一種叫 GPU-PV (GPU Paravirtualization) 的技術。
建議 VMM：Hyper-V (Windows 10 專業版/企業版內建)
注意：家用版 (Home) 不支援 Hyper-V 管理員，需另行開啟。
實作邏輯：
建立 VM： 在 Hyper-V 中建立一個 Ubuntu 24.04 的虛擬機器。
設定 GPU 分配： Hyper-V 預設介面沒有 GPU 選項，必須透過 PowerShell 腳本 (例如著名的
Easy-GPU-PV 驅動程式掛載： 需要將 Windows 端的驅動檔案手動複製到 Ubuntu VM 的特定目錄（
/usr/lib/wsl/lib/），讓 Linux 內核誤以為它在 WSL 環境下執行。
優點： 真正的作業系統隔離，安全性高。
缺點： 設定極度繁瑣，且對於 Ubuntu 24.04 這種較新的內核，驅動掛載常會失敗。
為什麼不建議用 VMware 或 VirtualBox？
VirtualBox： 完全不支援 NVIDIA GPU 直通（CUDA 運算）。
VMware Workstation： 雖然支援 3D 加速，但並不支援將實體 GPU 的 CUDA 核心完整映射給 Guest OS。
傳統的「硬體直通 (GPU Passthrough)」是獨佔式的。一旦顯卡分給了 VM A，Host 和 VM B 就完全看不見這張卡。
針對需求，以下是三種實作方案的深入分析與建議：
方案一：Proxmox / KVM + vGPU (推薦研究路徑)
如果希望多個 VM 同時共享 1060 Ti 的運算能力，目前 Linux 下唯一的解法是使用 Libvirt/KVM 搭配 nvidia-vgpu-mgr (LibreVGPU/mdevctl)。
VMM 建議： QEMU/KVM (可透過
virt-manager介面管理)。實作原理： 由於 1060 Ti (Pascal 架構) 原生不支持企業級 vGPU 授權，社群開發了
vgpu_unlock 技術。它能欺騙驅動程式，將消費級顯卡模擬成工作站等級的 Tesla 卡，從而將一張 GPU 切分成多個「虛擬 GPU (vGPU)」。配置流程：
在 Ubuntu 24.04 安裝 KVM 與
virt-manager。套用 vgpu_unlock 補丁並安裝 NVIDIA GRID 驅動。
建立兩個 vGPU 實例（例如每個分 3GB VRAM）。
在 VM 設定中，以 MDEV (Mediated Device) 方式分別掛載給 Win11 與 Ubuntu 22.04。
方案二：雙系統/切換式 GPU Passthrough (最穩定，但不可同時使用)
如果不需要兩個 VM 「同時」跑訓練，只需在需要時切換。
VMM 建議： QEMU/KVM。
實作原理： 準備兩份 XML 設定檔。當啟動 Win11 時，動態將 1060 Ti 從 Host 解除綁定並掛載給 VM；關閉後再還給 Host 或分給另一個 VM。
優點： 效能 100% 發揮，不需複雜的解鎖補丁。
缺點： 運作時 Host OS 會失去圖形介面（除非用 SSH 遠端管理 Host）。
方案三：容器化與虛擬化並行 (最佳實踐建議)
考慮到 1060 Ti 只有 6GB VRAM，切分給兩個 VM 後，每個環境的資源會非常侷促。建議改變架構如下：
Host (Ubuntu 24.04)： 作為主要的運算節點，裝好 NVIDIA Driver 與 Docker。
Ubuntu 22.04 環境： 不要用 VM，改用 Docker Container。它能直接共用 Host 的 GPU，效能損耗為 0，且 VRAM 動態共享。
Windows 11 環境： 使用 KVM + GPU Passthrough (獨佔)。
當需要用 Windows 軟體時，啟動 VM（此時 Docker 會暫時無法使用 GPU）。
當要跑實驗（Ubuntu 22.04 / Torch7）時，關閉 Windows VM，資源全數回歸 Linux。
具體工具與設定建議
| 組件 | 建議選擇 | 說明 |
| 虛擬化引擎 | QEMU/KVM | Linux 下效能最強，支援最深度的 GPU 控制。 |
| 管理介面 | Virt-Manager | 圖形化介面，方便掛載 PCIe 裝置。 |
| Windows VM 驅動 | VirtIO Drivers | 必須安裝，否則 VM 內的硬碟與網路效能會極慢。 |
| GPU 分享技術 | 針對 10 系列顯卡的開源共享方案。 |
實作步驟綱要 (以 KVM 為例)
開啟 IOMMU： 修改
/etc/default/grub，加入intel_iommu=on或amd_iommu=on。隔離 GPU (僅限 Passthrough)： 找到 1060 Ti 的硬體 ID，告訴 Linux 啟動時不要載入圖形驅動，改載入
vfio-pci。設定 Win 11 VM：
晶片組選 Q35。
韌體選 OVMF (UEFI)。
添加硬體：PCI Host Device -> 選取你的 1060 Ti。
解決 NVIDIA 偵測： 在 VM 的 XML 設定中隱藏 Hypervisor 標記（防止驅動報錯）。
既然這兩個虛擬機器（VM）不會同時啟動，那麼複雜的 vGPU 切分就不必要了。您最理想的方案是採用 KVM/QEMU 搭配 GPU Passthrough (硬體直通)。
在 Ubuntu 24.04 (Host) 下，這就像是一個「切換開關」：當啟動 Win11 時，顯卡交給 Windows；關閉後，顯卡回到 Host 或交給 Ubuntu 22.04 (VM)。
1. 核心工具建議：QEMU/KVM + Virt-Manager
在 Linux 環境下，這是效能最強大且最穩定的方案。
VMM: QEMU/KVM (核心虛擬化引擎)。
管理介面: Virt-Manager (圖形化介面，操作最直覺)。
核心技術: VFIO (Virtual Function I/O)。這能讓 Host 的核心暫時釋放 1060 Ti，讓 VM 取得硬體控制權。
2. 實作邏輯與步驟
由於只有一張顯卡，這屬於 "Single GPU Passthrough"。關鍵在於編寫一組啟動/停止腳本 (Hooks)，讓 VM 啟動時自動切換。
第一步：環境準備 (Host)
開啟 IOMMU: 修改
/etc/default/grub，在GRUB_CMDLINE_LINUX_DEFAULT加入intel_iommu=on(Intel) 或amd_iommu=on(AMD)。更新並重啟:
sudo update-grub後重啟。
第二步：準備 Hook 腳本 (自動化切換)
因為只有一張卡，啟動 VM 時 Ubuntu Host 的桌面會暫時關閉。需要建立 /etc/libvirt/hooks/qemu 腳本：
Start Script: 停止顯示管理器 (gdm/sddm)、卸載 NVIDIA 驅動、將 1060 Ti 綁定到
vfio-pci。Stop Script: 解除
vfio-pci綁定、重新加載 NVIDIA 驅動、恢復顯示管理器。
第三步：設定 Windows 11 VM
韌體: 必須選 UEFI (OVMF) 且晶片組選 Q35。
TPM: Windows 11 需要虛擬 TPM 模組。
添加硬體: 選擇 "PCI Host Device"，選中 1060 Ti (Video 與 Audio 兩個裝置都要選)。
ROM File: 有些 10 系列顯卡需要提供 VBIOS (.rom 檔)，可以從
TechPowerUp
第四步：設定 Ubuntu 22.04 VM
步驟與 Win11 幾乎相同，但在 VM 內：
驅動: 進入系統後直接執行
sudo ubuntu-drivers autoinstall安裝 NVIDIA 官方驅動。驗證: 執行
nvidia-smi即可看到 1060 Ti。
3. 為什麼這是最佳方案？
| 特性 | GPU Passthrough (獨佔式切換) |
| 效能 | 原生等級 (98%+)，1060 Ti 的 CUDA 核心完全釋放。 |
| 相容性 | Win11 可以跑 Direct X 遊戲或 AI 工具；Ubuntu 22.04 可以跑 Torch7/CUDA。 |
| 穩定性 | 不需修改驅動補丁 (vgpu_unlock)，降低系統崩潰風險。 |
| 便利性 | 透過 virt-manager 點選即可，且 VM 關閉後 Host 桌面會自動恢復。 |
4. 潛在挑戰與解決建議
黑畫面問題: 由於啟動 VM 時 Host 桌面會關閉，建議先準備好另一台筆電或手機透過 SSH 連線到 Host。這樣萬一腳本寫錯導致畫面沒恢復，您還可以透過遠端指令救回來。
1060 Ti 的 VBIOS: 如果啟動 VM 後螢幕沒反應，通常需要在 Virt-Manager 的 XML 模式下，手動指定
<rom file='/path/to/your/gpu.rom'/>。
專業建議： > 雖然說這兩個 VM 不會同時啟動，但如果 Ubuntu 22.04 只是為了跑特定的深度學習程式碼，其實將 Ubuntu 22.04 做成 Docker 容器會比做成 VM 方便得多。因為容器啟動不需要關閉 Host 桌面，且能與 Win11 VM 輪流使用 GPU。
以上文件由 Gemini 產生
