AI 基礎設施
Hetzner 試行 OpenAI 相容推論 API，以單一 FP8 MoE 模型測試歐洲託管需求
Hetzner 悄然開放實驗性 LLM 推論服務，目前僅提供 Qwen3.6-35B-A3B-FP8，現有 OpenAI SDK 可透過替換 base URL 接入。社群低負載測試錄得 153 毫秒中位首 token 延遲與約 224 token/s，但服務沒有 SLA、計費或生產保證。
德國雲端與主機供應商 Hetzner 開始測試自有 LLM 推論 API。服務位於 Hetzner Experiments，介面相容 OpenAI Chat Completions；開發者可沿用 OpenAI Python SDK，把 `base_url` 改為 `https://inference.hetzner.com/api/v1`，再換上實驗平台產生的 token。這降低了既有應用切換推論供應商的整合成本。
目前模型目錄只有 `Qwen/Qwen3.6-35B-A3B-FP8`。它是約 35B 總參數、每 token 啟用約 3B 參數的 MoE，支援文字、影像及 262K 上下文，權重採 FP8。這種配置可在相對有限的顯存內提供高吞吐，適合摘要、分類、抽取與 RAG 前後處理，但不應視為前沿推理模型的替代品。
Sliplane 工程師在 7 月 23 日以單一客戶端測得：七次短請求的中位 TTFT 為 153 毫秒，五次較長生成約為每秒 224 個輸出 token。測試也發現格式遵循、資訊找回及影像輸入大致可用，卻在兩道簡單算術題失敗。這些數據沒有併發壓力、尾端延遲或持續負載資訊，只能作為早期觀察。
技術上更值得注意的是基礎設施方向。OpenAI 相容介面使 Hetzner 能把共享 GPU 容量包裝成按請求服務，不必要求客戶自行營運 vLLM；對已在歐洲主機環境部署應用的團隊，也可能減少跨供應商網路與治理成本。不過官方目前明確把它定位為實驗：免費、沒有帳單系統、SLA 或生產承諾，支援範圍和底層硬體也未公布。
下一步應觀察模型目錄、價格、速率限制、批次與串流語義，以及是否補上 DPA、資料保留政策和可用性承諾。在這些條件出現前，工程師宜只使用合成或非敏感資料做相容性及負載測試，不能因伺服器位於歐洲就推定服務已符合正式資料治理要求。