共績科技 2023 年成立于清華，面向 AIGC 企業(yè)和科研機構提供算力平臺與 MaaS 服務，致力于緩解彈性算力需求與供給之間的錯配。平臺通過聚合 IDC 閑置資源和邊緣資源，以容器化服務為主，為 AI 推理、視頻渲染、數(shù)據(jù)處理和數(shù)據(jù)合成等波動性場景提供可快速調度的算力資源。

在跨云彈性推理場景中，計算任務可以調度到不同地域、云環(huán)境和集群，但模型文件和業(yè)務數(shù)據(jù)體積較大，難以像計算資源一樣快速遷移。尤其是在線推理場景，模型倉庫以讀為主且訪問頻繁，存儲訪問能力會直接影響服務啟動、彈性擴容和請求延遲。

為此，共績科技基于 JuiceFS 封裝了“對象存儲加速”方案，將用戶已有對象存儲接入彈性推理集群，并通過統(tǒng)一命名空間、元數(shù)據(jù)導入、FUSE 掛載、分布式緩存和數(shù)據(jù)預熱，提升模型倉庫在跨云、跨集群環(huán)境中的訪問效率。以一家頭部文生圖模型社區(qū)實踐為例，該方案支撐了幾十 TB 級模型倉庫、checkpoint 與 LoRA 動態(tài)加載，以及高峰期數(shù)百卡彈性資源擴容，并將彈性集群的額外延遲控制在客戶驗收范圍內。

01 彈性需求廣泛存在，供給卻難以匹配

隨著 AI 應用快速發(fā)展，算力需求持續(xù)增長，但不同場景的資源使用特征并不相同。相比訓練任務相對穩(wěn)定的資源需求，AI 推理、數(shù)據(jù)處理和數(shù)據(jù)合成等場景通常具有更強的波動性：辦公類應用可能在白天流量更高，娛樂類應用可能在傍晚或周末迎來高峰；項目制的數(shù)據(jù)處理任務則可能在短時間內集中消耗大量算力，任務結束后又進入空窗期。對于中小團隊或探索型業(yè)務而言，彈性算力還能幫助其更清晰地評估單次請求成本與商業(yè)收益之間的關系。

但在供給側，算力基礎設施建設屬于重資產投入。資源方通常并非不具備彈性服務能力，而是更傾向于通過長期整租回收成本、降低風險。這使得市場上低價、穩(wěn)定、彈性三者難以同時滿足：整租資源價格較低且供應穩(wěn)定，但缺乏彈性；Spot 資源價格低且具備彈性，但供應不確定；On-demand 資源彈性和穩(wěn)定性較好，但成本較高。在中國市場，這種矛盾進一步表現(xiàn)為交易主要集中在整租訂單，彈性資源供給占比較低。

共績科技希望解決的，正是彈性算力需求與供給之間的錯配問題。通過聚合 IDC 閑置資源及更分散的邊緣資源，平臺以容器化服務為主，為 AI 推理、視頻渲染、數(shù)據(jù)處理和數(shù)據(jù)合成等場景提供可快速調度的算力資源，在較低資源成本基礎上，幫助用戶在業(yè)務高峰時快速拉起任務、調度至不同集群并承接彈性需求。資源方也可以在整租之外，提高閑置資源的利用率和變現(xiàn)效率。

02 算力可以調度，存儲如何跟上？

隨著彈性算力平臺的發(fā)展，計算資源的調度相對容易實現(xiàn)。容器鏡像可以通過鏡像倉庫和分發(fā)網(wǎng)絡同步到不同集群，計算任務可以由調度系統(tǒng)在不同資源池中拉起，業(yè)務流量也可以通過統(tǒng)一接入層和流量治理能力進行分發(fā)。

但模型和數(shù)據(jù)文件通常體積較大，跨云、跨集群遷移成本高、耗時長，難以匹配計算資源秒級拉起和釋放的節(jié)奏。因此，在跨云彈性推理架構中，真正限制系統(tǒng)彈性的往往不是算力調度，而是數(shù)據(jù)和模型的分發(fā)效率。

不同業(yè)務場景對存儲的要求并不相同。第一類是模型訓練、開發(fā)和調試場景。這類場景通常涉及復雜的讀寫需求，包括代碼倉庫、模型文件、實驗結果和中間狀態(tài)等。同時，開發(fā)調試對環(huán)境穩(wěn)定性要求很高，用戶無法接受主機頻繁切換導致狀態(tài)丟失。因此，在這類場景中，平臺通常會為用戶提供長期穩(wěn)定的計算資源和運行環(huán)境，相關存儲需求也可以通過集群內已有的穩(wěn)定存儲體系來承載。

第二類是數(shù)據(jù)處理場景。這類業(yè)務又可以分為兩種情況：如果單次數(shù)據(jù)處理的業(yè)務價值較高，能夠覆蓋跨云網(wǎng)絡傳輸成本，就可以直接構建數(shù)據(jù)處理流水線，從 S3 或其他對象存儲持續(xù)拉取數(shù)據(jù)，在計算集群內處理后再流式寫回。此時系統(tǒng)不必依賴大規(guī)模本地存儲。如果數(shù)據(jù)規(guī)模更大，或者單次處理的經(jīng)濟價值較低，本地存儲更多也只是一次性緩存，數(shù)據(jù)在處理流程中流過即可，并不需要長期沉淀在計算集群內。

真正更具挑戰(zhàn)的是在線推理場景。在線推理業(yè)務不能接受服務中斷，但彈性算力平臺所使用的資源可能來自閑置資源池，存在被撤出的可能。一旦某個機房或集群資源不可用，平臺必須能夠及時將任務遷移到其他供應商或其他集群。這意味著不僅計算任務要能夠遷移，模型文件和相關存儲訪問能力也必須能夠同步遷移。

在線推理雖然對服務連續(xù)性和跨集群遷移能力要求更高，但它的存儲訪問模式也相對更明確。與訓練、開發(fā)和調試場景相比，推理業(yè)務通常以讀為主，核心需求集中在高效加載模型、讀取模型權重和訪問模型倉庫上。對于大型模型和在線應用而言，模型加載速度直接影響服務啟動時間、彈性擴容效率和請求響應穩(wěn)定性。因此，推理場景并不適合簡單沿用傳統(tǒng)讀寫混合型存儲架構，而更適合圍繞模型分發(fā)、只讀訪問和緩存加速進行專門優(yōu)化。

此外，彈性算力平臺通常并不承載用戶完整的業(yè)務系統(tǒng)。用戶的主云賬號、業(yè)務數(shù)據(jù)庫、模型管理系統(tǒng)，甚至部分固定算力資源，往往已經(jīng)存在于其他云或自有環(huán)境中。平臺要接入用戶業(yè)務，就必須與其現(xiàn)有模型倉庫和模型管理流程兼容，不能要求用戶重新遷移整套系統(tǒng)。

因此，要支撐跨云彈性推理，需要的不只是計算調度能力，而是一套面向模型推理場景的跨云高性能存儲與模型分發(fā)方案：既要支持大模型倉庫的托管和高性能讀取，又要適配用戶已有的模型管理體系，并能夠在資源跨云、跨集群遷移時提供穩(wěn)定的數(shù)據(jù)訪問能力。

03 Why JuiceFS：跨云統(tǒng)一訪問、強一致元數(shù)據(jù)與高性能緩存

面對跨云彈性推理場景，存儲系統(tǒng)需要同時滿足幾個條件：

• 能夠在不同云和不同集群之間提供統(tǒng)一訪問入口，支持共享讀寫和統(tǒng)一元數(shù)據(jù)管理；
• 能夠兼容用戶已有的對象存儲和模型倉庫，避免用戶遷移現(xiàn)有數(shù)據(jù)；
• 同時還要具備較低的運維復雜度和較好的讀性能。

在存儲方案選型過程中，我們曾評估過 Ceph。Ceph 技術成熟，適合在單一數(shù)據(jù)中心或相對穩(wěn)定的資源域內構建統(tǒng)一存儲。但在跨云彈性推理場景下，Ceph 對網(wǎng)絡穩(wěn)定性和運維能力要求較高，整體接入成本相對更高，因此沒有作為最終方案。

Alluxio 也曾進入評估范圍。但在多云環(huán)境下，多個集群需要并發(fā)訪問同一份底層對象存儲數(shù)據(jù)，且業(yè)務并非完全只讀，也存在少量寫入。該場景對數(shù)據(jù)強一致性要求較高，因此 Alluxio 最終未作為生產方案。

最終選擇 JuiceFS，主要是因為它以對象存儲作為數(shù)據(jù)底座，并通過獨立元數(shù)據(jù)服務提供統(tǒng)一命名空間和一致的文件系統(tǒng)視圖，能夠讓多個集群以文件系統(tǒng)方式訪問同一份模型數(shù)據(jù)。這種架構既適合跨云、跨集群的模型分發(fā)和共享讀取，也能夠較好兼容用戶已有的對象存儲和模型倉庫，降低數(shù)據(jù)遷移和業(yè)務接入成本。

進一步采用 JuiceFS 企業(yè)版，則主要看重其分布式緩存能力和元數(shù)據(jù)托管能力。在這個場景中，JuiceFS 的價值并不只是提供一個文件系統(tǒng)接口，而是把對象存儲、統(tǒng)一命名空間、元數(shù)據(jù)管理和緩存加速組合成一套更適合跨云彈性推理的存儲訪問層。

04 實踐方案：基于JuiceFS 的對象存儲加速

基于 JuiceFS，平臺封裝了“對象存儲加速”產品，用于將用戶已有的對象存儲接入彈性推理集群，并以高性能文件系統(tǒng)的形式提供給業(yè)務使用。整體流程如下。

首先是創(chuàng)建文件系統(tǒng)。用戶提供對象存儲的訪問憑證，例如 S3 兼容存儲的 AK/SK。憑證權限可以根據(jù)業(yè)務需求配置為只讀或讀寫，平臺基于該對象存儲創(chuàng)建對應的 JuiceFS 文件系統(tǒng)。

其次是導入元數(shù)據(jù)。平臺通過 JuiceFS import 能力掃描對象存儲中的文件元數(shù)據(jù)，并將其導入 JuiceFS 元數(shù)據(jù)服務。這樣，用戶原本存放在對象存儲中的模型文件，就可以在 JuiceFS 中以文件系統(tǒng)目錄的形式被訪問。

第三是建立緩存組。在可能承載任務的各個集群內，平臺會建立 JuiceFS Cache Group，形成分布式緩存組。任務運行前，平臺可以先對模型文件進行數(shù)據(jù)預熱，將熱點數(shù)據(jù)提前緩存到目標集群，減少推理服務啟動時從遠端對象存儲拉取數(shù)據(jù)的耗時。

第四是掛載到業(yè)務 Pod。用戶業(yè)務運行時，平臺通過 FUSE 客戶端將 JuiceFS 文件系統(tǒng)掛載到業(yè)務 Pod 中。對于應用而言，模型文件表現(xiàn)為本地文件系統(tǒng)路徑，因此通常不需要改造原有的模型讀取邏輯。

第五是啟用節(jié)點緩存。除了集群級 Cache Group，F(xiàn)USE 客戶端所在節(jié)點也可以提供本地緩存，用于提升重復讀取和模型加載性能，進一步降低對遠端對象存儲的直接訪問。

這個“對象存儲加速”產品，本質上是將 JuiceFS 的元數(shù)據(jù)導入、分布式緩存、數(shù)據(jù)預熱和 FUSE 掛載流程產品化，使用戶已有的對象存儲能夠以更接近本地文件系統(tǒng)的方式服務于跨云推理任務。

此外，JuiceFS 的 Cache Group 與文件系統(tǒng)訪問入口相對獨立。這個特性一方面會增加平臺側的管理復雜度，因為平臺需要同時管理文件系統(tǒng)、緩存組、掛載入口和任務調度之間的關系；另一方面，也為后續(xù)按集群、按用戶或按業(yè)務場景進行緩存隔離、獨立調度和精細化管理提供了基礎。

05 業(yè)務實戰(zhàn)：頭部文生圖模型社區(qū)

場景、挑戰(zhàn)與驗收標準

在這套對象存儲加速方案中，一個比較典型的實踐案例來自國內頭部文生圖模型社區(qū)，其托管了幾十 TB 規(guī)模的模型數(shù)據(jù)，既包括體積較大的 checkpoint 基座模型，也包括數(shù)量更多、體積相對較小的 LoRA 模型。在實際推理過程中，業(yè)務通常需要先加載 checkpoint，再加載一個或多個 LoRA，完成組合推理。

該公司自身已經(jīng)擁有較大規(guī)模的算力資源，規(guī)模達到數(shù)千卡級別。但由于其面向創(chuàng)意設計等生產場景，業(yè)務負載具有明顯波動性，整體平均利用率不到 50%。在工作日的上午和下午高峰時段，負載甚至可能達到常規(guī)承載水位的 140%，導致服務體驗下降。因此，客戶需要一種高度彈性的算力供給方式。

共績?yōu)槠涮峁┑氖且环N高彈性的資源模式：僅在工作日高峰時段，即上午 10:00–12:00 和下午 14:00–18:00，提供數(shù)百卡規(guī)模的算力支持，其余時間資源規(guī)模降為 0。

這意味著平臺需要在分鐘級時間窗口內完成數(shù)百卡資源的快速擴容，而在非高峰時段完全不占用資源。對客戶而言，這種模式可以在峰值時段獲得大量算力支持，同時避免為低谷資源付費；對平臺而言，也可以更高效地利用閑置算力資源，具備較好的商業(yè)價值。

但這一場景的技術挑戰(zhàn)也非常突出。首先，這類幾十 TB 級模型倉庫無法簡單復制到每一個彈性集群。其次，推理服務并不是在啟動時一次性加載全部模型，而是會隨著用戶請求持續(xù)發(fā)生模型讀取和切換，訪問頻率較高。這意味著對象存儲加速方案不僅要支持大規(guī)模模型倉庫訪問，還要在持續(xù)動態(tài)加載場景下保持穩(wěn)定的讀取性能。

與此同時，該公司對性能要求非常嚴格。在驗收過程中，會將部分生產流量引入彈性集群進行測試，并要求彈性集群與其自有集群相比，推理耗時的中位數(shù)和平均值差異都必須控制在 2 秒以內。考慮到單次推理耗時本身在幾十秒量級，這一要求意味著對象存儲加速方案幾乎不能引入額外延遲。在最初幾輪測試中，彈性集群的推理耗時中位數(shù)和平均值均比客戶自有集群高出約 10 秒，未能通過驗收。

性能優(yōu)化：降低彈性集群的額外延遲

優(yōu)化首先從中位數(shù)入手。中位數(shù)偏高意味著有相當比例的請求都存在性能損耗，而不是少量偶發(fā)請求造成的長尾問題。通過 JuiceFS 監(jiān)控發(fā)現(xiàn)，集群緩存命中率沒有達到預期。在當前架構下，一旦緩存未命中，請求就需要跨公網(wǎng)訪問客戶在阿里云上的對象存儲進行回源，這會顯著拉高模型加載耗時，并進一步影響推理請求延遲。

針對這一問題，平臺利用 JuiceFS Cache Group 的隔離能力，為該客戶分配專屬緩存節(jié)點，并預留充足緩存空間，對核心模型數(shù)據(jù)進行充分預熱。完成預熱后，核心模型訪問路徑基本實現(xiàn) 100% 緩存命中，有效避免了跨公網(wǎng)回源帶來的性能損失。

第二個影響中位數(shù)的因素是元數(shù)據(jù)訪問延遲。由于平臺采用跨集群統(tǒng)一架構，元數(shù)據(jù)服務需要通過公網(wǎng)訪問，例如使用 JuiceFS 云服務或部署在其他云主機上，因此元數(shù)據(jù)訪問延遲會影響整體模型讀取性能。

針對這一問題，平臺采取了兩項措施：一是開啟 JuiceFS 的 open cache，將元數(shù)據(jù)盡可能緩存到本地內存中。由于該場景以只讀訪問為主，適合通過緩存降低元數(shù)據(jù)訪問開銷。二是優(yōu)化集群網(wǎng)絡限流策略。盡管平臺無法直接控制邊緣機房的網(wǎng)絡設備，但可以通過節(jié)點級限流，避免單個節(jié)點占滿帶寬，從而提升整體網(wǎng)絡穩(wěn)定性。完成這些優(yōu)化后，集群整體性能明顯提升，中位數(shù)逐步達到客戶要求。

當中位數(shù)達標后，平均值仍然存在偏差。這說明系統(tǒng)中仍存在長尾請求，即少量請求耗時顯著高于正常水平，并拉高了整體平均值。進一步分析發(fā)現(xiàn)，這主要與節(jié)點本地緩存，也就是 FUSE 緩存配額有關。由于緩存容量較小，相比客戶自有集群，彈性集群更容易發(fā)生緩存換出，導致部分請求需要重新加載模型數(shù)據(jù)，從而拉高平均推理耗時。針對這一問題，平臺在生產環(huán)境中擴大了 FUSE 本地緩存配額，降低緩存換出頻率，改善長尾表現(xiàn)，最終使平均值指標也滿足驗收要求。經(jīng)過上述優(yōu)化，系統(tǒng)順利通過驗收，并穩(wěn)定運行。

多租戶緩存治理

場景驗證通過后，這套能力也進一步進入多租戶運行階段。隨著不同租戶按時間片復用同一批彈性節(jié)點，新的問題開始暴露出來，即節(jié)點緩存競爭問題。

在彈性資源模型下，F(xiàn)USE 客戶端退出時不會主動清理節(jié)點緩存。這個設計在單租戶場景下是合理的，因為歷史緩存可以被后續(xù)任務復用，從而提高命中率。但在多租戶場景下，前一個租戶的數(shù)據(jù)可能長期占用節(jié)點緩存空間，使后續(xù)租戶無法獲得足夠緩存資源，最終不得不回源訪問對象存儲，導致性能明顯下降。

為了解決這一問題，共績在每個節(jié)點上部署了獨立的守護進程，由該進程在業(yè)務 FUSE 客戶端啟動前執(zhí)行全局緩存垃圾回收。具體策略參考 JuiceFS FUSE 客戶端的實現(xiàn)，采用 2-random 策略，在回收效率和性能之間取得平衡。同時，各節(jié)點之間通過 Kubernetes 分布式鎖進行協(xié)調，只有搶到鎖的客戶端才執(zhí)行 GC，避免多個客戶端同時回收緩存，從而造成額外的網(wǎng)絡和 I/O 壓力。

通過這一機制，我們有效緩解了多租戶場景下緩存資源被歷史任務占用的問題，使不同租戶在共享彈性資源時，仍然能夠獲得相對穩(wěn)定的緩存性能。

06 結語

彈性算力要穩(wěn)定承接生產流量，不能只依賴計算調度，還需要模型數(shù)據(jù)和熱點數(shù)據(jù)在跨云、跨集群環(huán)境中保持穩(wěn)定訪問。

基于 JuiceFS，共績科技將對象存儲、統(tǒng)一命名空間、元數(shù)據(jù)管理、分布式緩存和 FUSE 掛載能力組合起來，形成了一套面向彈性推理場景的對象存儲加速方案。它并不是簡單地把對象存儲掛載成文件系統(tǒng)，而是圍繞模型推理的訪問模式，提供可預熱、可緩存、可隔離、可治理的數(shù)據(jù)訪問層。

以上是共績科技在彈性算力與跨云存儲加速方向上的階段性探索和實踐。隨著 AI 推理場景持續(xù)演進，模型分發(fā)、緩存治理和多集群數(shù)據(jù)訪問仍會不斷出現(xiàn)新的工程問題。我們也希望與更多開發(fā)者、AI 應用團隊和基礎設施從業(yè)者交流，共同探討彈性算力場景下更穩(wěn)定、更高效的數(shù)據(jù)訪問方案。