為 AI 調校的 Linux

選擇發行版

沒有單一最佳的 AI 用 Linux。正確的選擇取決於它在哪裡運行、由誰支援，以及還需要與哪些系統配合。這是我們通常的決策方式。

針對 AI 工作負載的核心與作業系統最佳化

GPU 只有在主機持續餵料時才會跑得快。以下是我們在每套 AI 系統上檢查的設定，之後再針對客戶自己的工作負載調校。沒有任何一項是通用的：我們在調整前後都會量測。

起點（依各工作負載測試，絕不盲目照搬）

# /etc/sysctl.d/90-ai.conf
kernel.numa_balancing = 0
vm.swappiness = 10
vm.max_map_count = 1048576
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456

# kernel command line (GRUB)
iommu=pt transparent_hugepage=madvise

# services
systemctl enable --now nvidia-persistenced
systemctl enable --now nvidia-fabricmanager   # NVSwitch (HGX) systems
cpupower frequency-set -g performance

適用於 AI 的 Kubernetes 與 Docker

我們建置的 AI 系統大多在容器中運行，從單一工作站上執行的 Docker 到多節點 GPU 叢集。無論哪種發行版，建構模組都相同。

原生 LLM API 及其擴充方式

我們在相容 OpenAI 的 API 之後提供模型服務，因此應用程式不必在意背後是哪個模型或引擎。擴展隨後朝四個方向進行。

1. 1

   單一 GPU 內部

   量化（FP8、Blackwell 上的 NVFP4、AWQ）、分頁注意力與 vLLM、SGLang 或 TensorRT-LLM 中的連續批次處理，讓每顆 GPU 能容納更多使用者。

2. 2

   節點內跨 GPU

   透過 NVLink 的張量平行，以最低延遲服務單一 GPU 放不下的超大型模型。

3. 3

   跨節點

   針對最大型的模型，使用 Ray 或 Kubernetes LeaderWorkerSet 進行管線平行化，並在叢集規模下採用分離式 prefill 與 decode（NVIDIA Dynamo、llm-d）。

4. 4

   更多副本

   在閘道後方進行水平擴展，並以 KEDA 或 HPA 依佇列深度或每秒 token 數自動擴縮，搭配感知 KV 快取的路由，並透過 KServe 縮減至零。

我們部署的引擎：vLLM、SGLang、搭配 Triton Inference Server 的 TensorRT-LLM、NVIDIA NIM，以及供桌邊與邊緣系統使用的 Ollama 或 llama.cpp。許多 LoRA 配接器可在相同 GPU 上共用同一個基礎模型。

LLM、代理與資料管線的 CI/CD

AI 的變動比一般軟體更頻繁：新的模型版本、新的提示詞、新的資料。我們為這三者各建一條管線，並遵循相同的紀律：一切皆有版本控管、經過測試、簽署，並透過環形逐級晉升。

CI 在您網路內的自託管 Runner 上執行，包括用於評估的 GPU Runner，因此模型與資料永遠不會離開網路。

我們如何為 AI 保護 Linux

AI 伺服器存放著您最有價值的資料與一些最昂貴的硬體。我們分層加以保護，讓任何單一疏失都不會同時暴露兩者。