核心概念

Hugging Face 在 2026 年 6 月 26 日發布技術指南，說明如何透過 hf jobs run 單一指令，在 HF 雲端基礎設施上啟動一個私有的、OpenAI 相容的 vLLM 推論伺服器——無需自行架設伺服器、無需管理 Kubernetes，按分鐘計費。

為什麼這件事有意義

過去，想在雲端 GPU 跑自己的 LLM 端點，開發者必須：申請 GPU 雲端帳戶 → 配置 VM → 安裝 CUDA / Docker → 設定 vLLM → 開放網路端口 → 處理認證。這個流程輕則花幾小時，重則因環境問題卡住數天。

HF Jobs 把這個流程壓縮成：

hf jobs run --flavor a10g-large --expose 8000 --timeout 2h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000

等待 Application startup complete 出現，端點即可使用。暴露的 URL 格式為 https://{job_id}--8000.hf.jobs，每個請求都需要 HF Token 進行認證，不對外公開。

底層架構：vLLM 的 OpenAI 相容層

vLLM 選擇模仿 OpenAI 的 Chat Completions API，使現有工具無需修改即可切換到自架模型。用 Python openai 客戶端連接時，只需更換 base_url 和 api_key：

from openai import OpenAI
from huggingface_hub import get_token

client = OpenAI(
    base_url="https://<job_id>--8000.hf.jobs/v1",
    api_key=get_token(),
)

這個設計讓「從 OpenAI 商業 API 切換到自架模型」的成本降到接近零——程式碼不用改，只換端點和金鑰。

大型模型的多 GPU 擴展

對於 100B+ 的大型模型（如 Qwen3.5-122B），可以用 tensor parallelism 橫跨多張 GPU：

hf jobs run --flavor h200x2 --expose 8000 --timeout 2h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3.5-122B-A10B \
  --host 0.0.0.0 --port 8000 --tensor-parallel-size 2 \
  --max-model-len 32768 --max-num-seqs 256

--tensor-parallel-size 對應 GPU 數量，--max-model-len 與 --max-num-seqs 控制記憶體上限，防止 OOM。

HF Jobs vs Inference Endpoints

HF 同時提供兩種部署路徑，定位不同：

特性 HF Jobs Inference Endpoints
適合場景 實驗、一次性評估、批次生成 生產服務、長期運行
計費方式 按秒計費（運行期間） 含縮容到零
控制彈性 完整（自選映像檔、參數、硬體） 託管服務，較少自訂
存取控制 Token 驗證（帳戶層級） 更細粒度（公開/保護/私有）

Jobs 的定位是「探索與實驗」：快速驗證想法、跑評估基準、開發階段測試——任務完成後 hf jobs cancel 停止計費。不適合需要 SLA 保證的生產流量。

關鍵要點

  • 前置條件極少：只需 pip install -U "huggingface_hub>=1.20.0" 加 hf auth login，有信用卡或預付點數即可啟動
  • 認證即護欄：暴露的端口預設需要 HF Token，不公開，降低 API 濫用風險，但細粒度存取控制仍不如 Inference Endpoints
  • 三種進階用途：
    1. Gradio Chat UI：連接 vLLM 端點建立互動介面，支援 streaming 和 Thinking 模式展示
    2. SSH 進容器：加 --ssh 參數可直接 SSH 進入運行中的 Job，方便除錯
    3. Coding Agent 後端：搭配工具呼叫（--enable-auto-tool-choice）可作為終端機 AI Agent 的推論後端，直接替換 OpenAI API
  • 成本範例：a10g-large 每小時 $1.50，跑 2 小時評估基準約 $3，遠低於包月 GPU 方案
  • 免費工具是鑰匙：hf jobs hardware 列出所有可用硬體規格與定價，方便預算估算

實務應用

評估基準的最佳場景

這個工作流最適合「一次性高強度 GPU 需求」：

  • 跑 lm-evaluation-harness 對某個開源模型做基準測試
  • 做 A/B 比較：同時開兩個 Job 跑不同量化版本
  • 為訓練完的微調模型做上線前品質驗證

相比租 Colab Pro+ 或 Lambda Labs 的限制，HF Jobs 的優勢是直接整合 HF Hub 的模型——vllm serve Qwen/Qwen3-4B 會自動從 Hub 下載，不用手動管理模型權重。

Coding Agent 整合

搭配 Pi（終端機 AI Agent）的設定範例：

{
  "providers": {
    "hf-jobs": {
      "baseUrl": "https://<job_id>--8000.hf.jobs/v1",
      "api": "openai-completions",
      "apiKey": "!hf auth token",
      "models": [{ "id": "Qwen/Qwen3.5-122B-A10B" }]
    }
  }
}

這讓開發者可以用開源頂尖模型驅動 AI 編程助理，而不受商業 API 的速率限制或資料隱私疑慮。

延伸觀點

vLLM 的生態地位正在固化

多個 2026 年的技術分析（The AI Engineer Substack、VRLA Tech）一致確認：vLLM 已成為生產 LLM 推論的預設選擇，主因是其 PagedAttention 架構將 GPU 記憶體浪費從傳統連續分配的 60-80% 壓縮到不足 4%，在多請求並發場景下吞吐量是競品的 3.5 倍。

四大框架定位已趨於明確：

  • Ollama：開發者體驗優先，適合本地單機測試，不適合並發
  • vLLM：生產環境預設，跨硬體通用，最活躍的開源社群
  • SGLang：Chatbot / RAG 等有前綴共享的工作負載，RadixAttention 帶來 29% 吞吐優勢
  • TensorRT-LLM：NVIDIA 硬體極致效能（比 vLLM 快 15-30%），但編譯耗時 28 分鐘以上且鎖定 NVIDIA

值得注意的是，HuggingFace 自家的 TGI（Text Generation Inference）已進入維護模式，事實上是在主推 vLLM 生態。

雲端 vs 自建的成本邏輯

HF Jobs 這類按秒計費方案最適合的是「不穩定、峰值型」工作負載。從成本分析來看：

  • 雲端（按需）：4 GPU 月費 $5,840–$13,140，有 spot 搶占風險但零前期成本
  • 自建（高端 GPU）：相同算力月電費約 $200，硬體在 4-8 週可回本

對於需要持續跑推論服務的用戶，自建硬體中長期更划算；但對於間歇性需求（如每週跑一次評估），HF Jobs 的靈活性與低門檻更具優勢。HF 選擇將 Jobs 定位為「探索工具」而非取代 Inference Endpoints，符合這個成本邏輯。

相關頁面：vLLM V0 升級 V1：強化學習訓練的後端正確性優先原則 · Hugging Face 推論供應商生態系：DeepInfra 整合實錄 · GitHub CI 遷移至 Hugging Face Jobs · HF CLI：為 AI 代理最佳化的 Hugging Face 命令列工具 · 非同步連續批次推論：LLM 推論的 CPU GPU 並行加速

反向連結

以下頁面引用了本頁：