11-868 第六份作業第一次放下自己寫的 MiniTorch，改用產業框架。兩題各 50 分：第一題改一支 DeepSpeed 訓練腳本，打開 LoRA，讓 Llama-2-7B 在 2 張 16GB 的 V100 上訓練得起來；第二題填完 SGLang 推論腳本的 TODO，並調參數讓生成跑快一點。兩題要的 GPU 互相衝突：SGLang 不支援 V100，要換 L40S、A6000 或 A100。春季版 4/13 截止，作業頁不提供評分測資。
11-868 用兩講回答同一個問題：一台推論伺服器怎麼同時服務大量請求，又不浪費 GPU 上的 KV cache。第 22 講（Lei Li）從 SGLang 的排程迴圈講起：ORCA 的 continuous batching、用 radix tree 管 KV 的 RadixAttention、依前綴命中率排序與分流、把 CPU 排程藏到 GPU 計算後面。第 24 講由 vLLM 作者 Woosuk Kwon 主講：PagedAttention 把 KV cache 切成固定大小的 block，用 block table 做虛擬化，讓同一張 A100 的 batch 從 8 撐到 40；後半講 vLLM 怎麼壓 CPU overhead、用 piecewise CUDA graph、切模型平行與管理混合架構的記憶體。
2026 年開源模型在 coding benchmark 追平閉源，但自架不只是選模型——vLLM 適合高併發生產服務、SGLang 在前綴重用場景快 29%、Ollama 是本地開發首選、llama.cpp 吃最少資源。A100 雲端租金約 $1.4-2.2/hr，自架損益兩平點大約在每月 100M tokens。
自架推論的關鍵不在引擎多快，而在你的 GPU 使用率：一張打滿的 A100 約 $0.70 / 百萬輸出 token，使用率掉到一成就變 $7，比多數雲端 API 貴。這篇是系列導讀，把七套工具分成三層，幫你判斷該選哪一層。
自架推論伺服器分三層：執行引擎（llama.cpp）、服務引擎（vLLM、SGLang）、模型管理平台（Ollama、Xinference、Triton）。選對層級比選對工具重要——先問你的瓶頸在排程還是在部署流程，再決定複雜度放在哪裡。
Xinference 把 vLLM、SGLang、llama.cpp、Transformers、MLX 五種後端包在同一個管理層，用 Web UI 和 OpenAI 相容 API 統一管理 LLM、embedding、rerank、語音和圖像模型，適合需要多類型模型共存的自架部署；但管理層的解析邏輯也讓攻擊面比純 serving engine 大（CVE-2026-61539 是案例）。
SGLang 是專攻生成式模型的推論引擎：用 RadixAttention 重用共同前綴的 KV cache，提供 OpenAI 相容 API、結構化輸出與多 GPU 平行化；它解決的是高吞吐 LLM serving，不是完整的產品後端。
官方 provider 目錄現在有 60 個條目。接本地模型最常見的失敗是把 Ollama 的 base URL 寫成 /v1——那會破壞 tool calling，模型會把 tool JSON 當純文字吐出來。