Inferact 與 Google 在 10 月 20 日推出 vLLM TorchTPU，讓 vLLM 裡既有的 PyTorch 模型定義，可以直接接上 Google Cloud 的 TPU。對想增加硬體選擇、又不想另養一套模型程式的團隊，這次降低的是搬移服務的開發負擔。
應用程式仍可呼叫熟悉的 OpenAI 相容介面，部署人員也繼續使用 vllm serve。改變主要發生在底層：TorchTPU 負責編譯與執行，搭配為 TPU 調整的運算核心。模型定義能沿用，原本的 GPU 部署參數則仍需調整。
保留 PyTorch，讓硬體多一個選項
這不是 vLLM 首次支援 TPU。原有的 JAX 路徑仍在維護；Google 的發布說明指出，開發者希望能繼續在 PyTorch 裡修改模型、除錯，因此團隊另建原生 PyTorch 後端。差別在於模型程式如何接上硬體，而非只多一個晶片名稱。
新後端採平台外掛形式。安裝後由 vLLM 自動載入，原有排程器、工作程序、KV 快取管理與 API 伺服器繼續使用；需要針對 TPU 最佳化的部分，則放在編譯與運算核心中。這讓上層服務與底層硬體可以分開演進，也減少維護兩份模型實作的工作。
快速入門用 Llama 3.2 1B 展示單晶片服務，另以 Qwen3-Coder 示範八裝置與專家並行。服務啟動後，請求仍送到 /v1/chat/completions，帶入模型名稱、訊息與輸出長度。這些是官方示例，本文沒有在 TPU 上重跑，也不把範例配置當成所有模型通用的設定。
對台灣已有內部助理或文件問答服務的開發團隊，這代表既有的API 串接較容易保留。前端對話流程與後端業務邏輯不必全部重做，開發工作可以集中到模型支援、硬體配置與服務行為。
這套後端也把長對話需要的功能帶到 TPU。多輪代理會反覆送出愈來愈長的上下文，前綴快取可重用已計算的部分；TPU Sync 則協助把 KV 資料移到主機記憶體，或在負責讀取提示與生成文字的不同主機間傳送。它處理的是對話推論的資料流，與服務啟動時保存編譯產物的快取不同。
部署負擔轉到哪裡？
第一次啟動仍要編譯設定範圍內的運算圖，官方說可能花上數分鐘。因此，評估搬移服務時，不能只從「已經啟動的模型回答多快」開始算。首次準備、重啟後恢復服務，以及使用者收到回答的時間，反映的是不同成本。
編譯快取文件把可保留的產物分為兩層：一層是 Python 框架追蹤與計算圖資料，另一層是原生後端編譯好的二進位執行檔。前者由 VLLM_CACHE_ROOT 管理，後者使用 TORCH_TPU_TIER3_COMPILATION_CACHE_ROOT。若容器重建時把這些資料一起丟掉，重啟就失去重用既有產物的機會。
發布文與快速入門仍提到另一個變數 VLLM_XLA_CACHE_PATH，與專門文件不同。本文保留固定版本連結，讓差異可以追查；實際部署應依所安裝版本確認設定，現有文字不足以判定舊變數已失效。文件也提到，暖機未涵蓋的輸入形狀或程式路徑，仍可能在服務中觸發編譯。
硬體方面，設定指南建議 v7x／Ironwood，這也是持續整合測試覆蓋的機型；v6e 被列為支援，但未納入該測試。10 月 20 日發布文仍將 v6e 列為實驗性，評估時要區分這兩份資料的版本。安裝指南則要求 Python 3.12，並需要可用的雲端 TPU 配額與計費專案。
專案程式採 Apache 2.0 授權，可自行部署；使用的模型權重與雲端硬體仍各有條款及費用。
我的判斷是，這次讓 PyTorch 團隊更容易把 TPU 納入硬體比較，尤其是原本不願為了換晶片重寫模型的人。是否值得搬移，仍取決於同一個服務的整體結果：除了吞吐量與雲端費用，也要把啟動等待納入，並用既有模型評測與輸出格式驗證確認應用行為。少掉一段重寫工作，是明確的工程價值；能省下多少成本，則需要實際部署數據。
常見問題
既有模型程式要改寫成 JAX 嗎？
這條路徑不需要。TorchTPU 讓 vLLM 使用既有 PyTorch 模型定義；原本採 JAX 實作的 TPU 後端也仍在維護，可依團隊的模型程式選擇。
建議用哪一代 TPU 試跑？
文件建議 v7x／Ironwood，也是持續整合測試使用的機型。v6e 雖列為支援，並未納入相同測試。
重啟前應保留哪些快取？
專門文件分別列出框架追蹤資料與原生二進位執行檔。兩者各有儲存位置，應確認都能持久保存，並對照安裝版本設定。