Ray 2.59 於 2026 年 10 月 2 日發布，最受關注的變化是 Ray Data 與 Ray Serve 的 LLM API 正式進入一般可用階段，推論後端同步升級至 vLLM 0.27.0。這個專案目前擁有 44,099 顆星標、8,183 個分支與 1,700 餘位貢獻者，是 Python 生態中少數同時覆蓋資料處理、模型訓練與線上服務的分散式運算引擎。
Ray 2.59 是什麼？
Ray 是開源分散式運算引擎，提供核心執行環境與資料、訓練、調參、服務等函式庫，2.59 版把資料與服務層的 LLM API 推進至正式可用。
專案建立於 2016 年 10 月，採用 Apache 2.0 授權，主要語言為 Python。它的設計目標是讓同一份程式碼從筆記型電腦直接搬到叢集執行，開發者不需要為了擴充而重寫應用。核心抽象只有三種：無狀態任務、具狀態角色與跨節點共享的不可變物件。
在架構上，Ray 把 AI 工作負載拆成多個專用函式庫。Data 負責大規模資料集與前處理，Train 處理分散式訓練，Tune 執行超參數搜尋，RLlib 支援強化學習，Serve 則把模型包成可水平擴充的線上服務。這種分層讓團隊可以在同一個執行環境內串接訓練與推論，不必在兩套基礎設施之間搬移資料。
專案的維護由 Anyscale 主導，社群貢獻密集。官方文件記載約 1,700 位貢獻者，累積超過百次正式版本發布，本次 2.59.0 之後仍有 2.57.1 與 2.58.1 兩條修補分支在同日更新，顯示維護團隊對舊版分支的支援並未中斷。
Ray Data 與 Ray Serve 的 LLM API 為何值得關注？
兩個 LLM API 在 2.59 版由預覽轉為正式可用，介面因此遵循穩定承諾。對批次推論與線上服務而言，這降低了升級時介面變動的風險。
正式可用與預覽狀態的差別，在於介面穩定性的承諾。當一套 API 仍屬預覽，小幅版本就可能調整參數與回傳結構；進入正式可用後，破壞性變更通常需要經過棄用週期。對於把推論流程接進生產線的團隊，這項差異直接影響升級排程與測試成本。
技術層面的關鍵是底層推論引擎的版本。2.59 把 vLLM 升級至 0.27.0，這個版本決定支援的模型架構、量化格式與排程策略。Ray Serve 的價值在於把推論從單一程序擴展為多副本服務，並在同一個控制平面內處理路由、副本擴縮與可觀測性。
兩層分工也值得留意。Data 的 LLM API 針對離線批次處理，適合大量文件摘要、標註與資料清洗；Serve 的 LLM API 針對即時請求，需要處理延遲與併發。兩者共用同一套模型載入與資源配置邏輯，讓團隊在批次與即時之間切換時，不必重新建立部署管線。
Ray 2.59 在資料處理層有哪些變化？
新增的外部 shuffle 後端把中繼資料寫入磁碟，降低記憶體壓力並支援 Join 與聚合。此版同時加入 ORC 原生讀取與影片讀取參數。
shuffle 是分散式資料處理中最耗資源的環節。過去版本以雜湊分區為主，資料量超過記憶體時容易失敗。2.59 引入外部、以磁碟為後盾的 shuffle 執行環境，讓中繼結果可以落盤，運算不再被單一節點的記憶體上限綁住。
這次改版也留下遷移成本。原本的 hash_shuffle_v2 策略更名為 shuffle_v2，壓縮設定由 hash_shuffle_compression 改為 shuffle_compression。使用舊名稱的設定檔在升級後會失效，需要在部署前完成替換。
資料來源的支援同步擴充。此版可原生讀取 ORC 檔案，read_lance 支援多路徑輸入，read_videos 則新增幀率與縮放參數，讓影片資料集不必先離線轉檔。官方同時加入對外部 shuffle 的 Join 與聚合支援，使磁碟型 shuffle 能覆蓋關聯式處理，而不限於單純的重新分區。
Ray 2.59 的安全機制改變了什麼？
本機叢集預設啟用權杖認證，ray.init 會自動產生並重複使用權杖。儀表板同時遮蔽 runtime_env 的值，並防範 Hudi 反序列化攻擊。
權杖認證是這次最具實務影響的變更。本機叢集在本版改為預設啟用認證，ray.init() 若未指定位址，會自動產生權杖並寫入 ~/.ray/auth_token。既有腳本若在多個程序中啟動獨立叢集，可能因為權杖不一致而出現連線失敗，需要事先確認權杖來源一致。
官方保留退出的開關。設定環境變數 RAY_AUTH_MODE=disabled 可以關閉認證，回復舊行為，但這屬於過渡手段。版本說明已預告 2.61 會把權杖認證擴展到所有叢集，包含遠端與多節點部署，屆時每個節點與客戶端都必須持有相同權杖。
另外兩項屬於供應鏈與資料面的加固。儀表板在瀏覽器端點遮蔽 runtime_env 的值，這類欄位經常夾帶憑證；讀取 Hudi 檔案時加入反序列化防護，阻止透過惡意檔案觸發遠端程式碼執行。對於共用叢集或處理外部資料的團隊，這兩項修正降低了誤用帶來的暴露面。
Ray 2.59 的主要數據有哪些？
儲存庫累積 44,099 顆星標、8,183 個分支與約 3,600 個未結議題，主要語言為 Python。專案自 2016 年創立，採 Apache 2.0 授權。
星標與分支的比例反映採用深度。44,099 顆星標對上 8,183 個分支，分支比例接近五分之一，明顯高於一般教學型專案。這種分布通常出現在團隊實際部署並維護自有分支的場景，而非單純的收藏行為。
議題數量則是另一面訊號。約 3,600 個未結議題說明使用密度高，也反映專案功能面廣。對評估導入的團隊而言，議題列表本身是判斷特定功能成熟度的實用來源，尤其在硬體加速與特定雲端供應商的整合項目上。
版本節奏趨於穩定。2.59.0 於 10 月 2 日發布後，10 月 21 日仍有 2.57.1 與 2.58.1 兩條分支的修補更新，這種並行維護模式讓企業可以選擇「先修補、後升級」的路徑，而不必每次都跟隨最新主線。
哪些團隊適合升級到 Ray 2.59？
同時執行批次推論與線上服務、或資料量已超過單機記憶體的團隊最適合。已在 Kubernetes 上維運 Ray 叢集、需要更明確背壓語義的平台團隊，也能從本版直接受益。
第一類是把 LLM 推論同時用在離線與線上場景的團隊。過去常見做法是以兩套系統分別處理批次摘要與即時問答，資料與模型版本容易不同步。2.59 把兩者的 API 統一在正式可用狀態，讓同一份模型設定可以覆蓋兩種負載。
第二類是資料管線受記憶體限制的團隊。外部 shuffle 讓中繼資料落盤，對於每日處理量超過單節點容量的管線，這是能否在不加機器前提下完成的關鍵。若工作負載以關聯式處理為主，本版新增的 Join 與聚合支援正好補上缺口。
第三類是平台維運團隊。Ray Serve 在這個版本加入可設定的背壓回應，超過佇列上限時可以回傳 429 並附上 Retry-After，讓負載平衡器與重試策略能區分「刻意限流」與「服務故障」。同時新增宣告式追蹤設定與批次排程部署的縮至零能力，這些都是平台層長期缺少的調整項。
Ray 2.59 有哪些升級風險要注意？
設定重新命名與預設認證可能中斷既有部署，CUDA 11.7 映像在此版後停止發布。升級前應確認權杖來源與舊 shuffle 參數名稱。
映像支援的終止需要提前規劃。2.59.0 是最後一個發布 CUDA 11.7 映像的版本，仍在使用該驅動版本的環境，必須在下一個版本前完成升級或自行維護映像。這類底層依賴的變動，往往在部署當日才會顯現。
參數更名屬於無聲的破壞性變更。舊的 shuffle 策略與壓縮設定名稱在新版不再生效，若未同步調整，管線可能退回預設行為，效能與記憶體曲線都會改變，但不會出現明確錯誤訊息。
權杖認證的影響範圍取決於部署形態。單機開發環境通常會自動處理，但以腳本批次啟動多個叢集的流程，可能因為權杖路徑或權限問題失敗。建議先在測試環境完整跑一次 ray.init() 與儀表板連線，確認權杖產生與讀取都正常。
其餘細節包括 protobuf 降版至 5.27.5，以及 ray-ml 映像在文件中被棄用並停止推薦。若專案曾依賴浮動標籤取得映像，應改為固定版本，避免下一次部署取得非預期的內容。
出處連結有哪些？
本文數據取自 ray-project/ray 官方儲存庫、Ray 2.59.0 版本說明與 ray.io 官方文件，皆於 2026 年 10 月 21 日讀取。
官方儲存庫：https://github.com/ray-project/ray
版本說明刊載於儲存庫的 Releases 頁面，內容涵蓋 Ray Data、Ray Core、Ray Serve、Ray Train 與 RLlib 各層的變更明細。完整文件位於 ray.io，另提供 llms.txt 與以 Markdown 提供的文件頁面，方便編碼代理直接取用。
總結：Ray 2.59 適合什麼團隊？
適合已把 LLM 推論納入生產流程、且需要批次與即時共用同一套管線的團隊。若僅有小規模實驗，或仍綁定 CUDA 11.7 映像，宜先完成環境盤點再升級。
2.59 的意義不在功能數量，而在成熟度的宣告。LLM API 進入正式可用、背壓語義明確化、追蹤設定改為宣告式，這些都是把分散式推論從「可以跑」推進到「可以維運」的必要條件。對於已經把模型接進產品流程的團隊，這些變化直接影響日常的值班成本。
升級的判斷標準相對清楚。若工作負載同時包含離線批次與線上服務、資料量已逼近單機上限，或平台需要更細緻的流量控制，這一版提供的項目都能立刻派上用場。反之，若專案仍在實驗階段，或硬體環境停留在舊版 CUDA，先把環境整理好會比追版本更實際。
