Object Storage Service：快速部署基於DeepSeek模型的推理服務

步驟1：構建高效能運算與彈性網路環境

1. 在Elastic Compute Service執行個體頁面，建立ECS執行個體。

   本教程以建立ecs.g8i.48xlarge 執行個體為例（該執行個體提供192核CPU + 1TiB記憶體+內建100Gbit/s基礎網路頻寬），保障足夠的計算資源和基礎網路頻寬，支撐AI/ML任務及OSS資料轉送需求。

   

2. 在彈性網卡頁面，建立彈性網卡。彈性網卡必須與ECS執行個體位於同一專用網路。

   通過多網卡彙總頻寬，實現VPC內OSS的高吞吐訪問，突破單網卡頻寬節流設定。

3. 綁定彈性網卡至已建立的ECS執行個體。

4. 查看彈性網卡介面資訊。

   

步驟2：準備模型資料並安裝推理架構

1. 擷取DeepSeek-R1-GGUF格式Q8量化版本的模型資料。該模型具備較高的推理效能與較低的記憶體佔用，適用於評估大規模模型載入與部署效率。

2. 通過ossutil以內網Endpoint的形式，上傳模型檔案至同一地區的OSS Bucket。

3. 使用推理架構為 llama.cpp，支援 GGUF 格式模型的高效載入與運行。

   1. 從 GitHub 複製 llama.cpp 倉庫到本地。

      git clone https://github.com/ggerganov/llama.cpp

   2. 進入專案目錄。

      cd llama.cpp

   3. 建立構建目錄。

      mkdir build

   4. 產生構建配置。

      cmake -B build -DCMAKE_BUILD_TYPE=Release

   5. 執行編譯。

      cmake --build build --config Release

步驟3：安裝OSS Connector並啟動推理服務

1. 安裝並配置OSS Connector。

   1. 下載安裝包。

      wget https://gosspublic.alicdn.com/oss-connector/oss-connector-lib-1.1.0rc7.x86_64.rpm

   2. 安裝OSS Connector。

      yum install -y oss-connector-lib-1.1.0rc7.x86_64.rpm

   3. 配置OSS Connector。

      1. 修改/etc/oss-connector/config.json路徑下的設定檔。

         {
             "logLevel": 1,
             "logPath": "/var/log/oss-connector/connector.log",
             "auditPath": "/var/log/oss-connector/audit.log",
             "expireTimeSec": 120,
             "prefetch": {
                 "vcpus": 32,
                 "workers": 32
             }
         }

      2. 修改環境變數。

         export OSS_ACCESS_KEY_ID=LTA********
         export OSS_ACCESS_KEY_SECRET=tg********
         export OSS_REGION=cn-beijing
         export OSS_ENDPOINT=oss-cn-beijing-internal.aliyuncs.com
         export OSS_PATH=oss://<BUCKET-NAME>/deepseek/DeepSeek-R1-Q8_0/
         export MODEL_DIR=/tmp/model/DeepSeek-R1-Q8_0/
         export HTTP_SOURCE_IP=172.xx.x.xxx,172.xx.x.xxx

         環境變數 KEY	說明
         OSS_ACCESS_KEY_ID	阿里雲帳號或者RAM使用者的AccessKey ID和AccessKey Secret。 使用臨時存取權杖進行許可權配置時，請設定為臨時訪問憑證的AccessKey ID和AccessKey Secret。 使用OSS Connector需要具有目標Bucket對應目錄的oss:ListObjects 許可權。如果訪問的Bucket及檔案支援匿名訪問，可以不設定 OSS_ACCESS_KEY_ID 和 OSS_ACCESS_KEY_SECRET環境變數，或設定為空白字串。
         OSS_ACCESS_KEY_SECRET
         OSS_SESSION_TOKEN	臨時存取權杖。當使用從STS擷取的臨時訪問憑證訪問OSS時，需要設定此參數。 使用阿里雲帳號或者RAM使用者的AccessKey ID和AccessKey Secret進行許可權配置時，將該欄位設定為空白字串。
         OSS_ENDPOINT	指定OSS服務Endpoint，樣本值為http://oss-cn-beijing-internal.aliyuncs.com。當不指定協議類型時，預設使用HTTPS協議。建議在內網等安全環境中使用HTTP協議，以達到更好的效能。
         OSS_REGION	指定OSS Region ID，樣本值為 cn-beijing。如不指定則可能出現鑒權失敗。
         OSS_PATH	OSS模型路徑，格式為 oss://bucketname/path/，樣本值為oss://examplebucket/deepseek/DeepSeek-R1-Q8_0/。
         MODEL_DIR	本地模型路徑。樣本值為：/tmp/model/DeepSeek-R1-Q8_0/。
         HTTP_SOURCE_IP	指定 Connector 使用的查看彈性網卡介面資訊。（如 172.16.6.121 和 172.16.6.122）。Linux 會根據該 IP 自動選擇對應的網路介面（如 eth0、eth1）和路由，無需額外配置。如需更精細的路由控制（如按源 IP、目標地址等分流），可結合 ip rule 和自訂路由表配置策略路由。

2. 啟動推理服務。

   LD_PRELOAD=/usr/local/lib/libossc_preload.so ENABLE_CONNECTOR=1 llama-server -m /tmp/model/DeepSeek-R1-Q8_0/DeepSeek-R1.Q8_0-00001-of-00015.gguf -t 48 -c 1024 --host 0.0.0.0 --port 9090 --numa isolate

步驟4：效能觀測

啟動推理服務後，一分鐘內雲端服務器內網頻寬變化如下：

通過雲端服務器觀測網卡流量，發現雲端服務器雙網卡網路基礎頻寬持續跑滿100Gbit/s：

基於P2P方案加速大規模推理節點啟動

OSS connector For AI/ML 可與自研的 P2P 分發系統協同工作，實現同一批次模型資料在多節點間的高效共用與傳輸。該 P2P 系統針對多節點同時載入相同資料的典型推理部署情境，顯著降低了對中心資料來源（OSS）的訪問壓力，提升整體頻寬利用效率。系統支援按需分發機制，具備對大檔案的隨機讀取與流式讀取能力，在保障準確性的同時優先降低單次資料片段的訪問延遲。同時，底層設計支援高並發訪問，能夠滿足大規模推理任務對分發效率與穩定性的雙重要求。

• 有效削峰限流：通過節點間資料共用，顯著緩解海量推理節點同時啟動時對 OSS 頻寬的衝擊，極大降低中心資料來源的瞬時壓力。

• 效能無損傳遞：仍依託 Connector 從 OSS 拉取未經處理資料，充分發揮 Connector 的效能，確保首次訪問的低延遲和高吞吐。

• 天然支援橫向擴充：支援推理節點的大規模水平擴充，具備良好的並發啟動能力，即使在百節點層級的叢集中，啟動耗時仍與單節點相近。

• 顯著降低回源量：通過本機快取與 P2P 分發機制，最大限度避免重複拉取，有效控制 OSS 的回源流量，提升整體資源利用效率。

實驗環境和測試方法

1. 使用DeepSeek-R1 模型的 GGUF 格式 Q8 量化版本，總容量664GB。推理架構 llama.cpp。

2. 使用50台機型 ecs.g8i.48xlarge 雲端服務器共同組建推理叢集。實踐中藉助阿里雲Container Service ACK 平台對推理叢集進行統一管理與部署。推理服務作為容器中的主進程運行，確保服務啟動的高效性與穩定性，實現了容器化環境下的靈活調度與資源管理。

3. llama.cpp 推理架構的開機記錄時間戳記作為模型載入完成的時間參考點，用于衡量從啟動到模型可用之間的耗時。

4. 在每個推理節點上均獨立進行計時，並統計以下關鍵效能指標：各節點的平均載入耗時、最長載入耗時，以及在整個部署過程中從 OSS 請求的資料總量，以全面評估模型載入過程中的頻寬利用效率與系統整體效能表現。

測試結果

總結

在本次測試中，推理節點端到端平均啟動耗時約為單節點的 1.5 倍，實測結果說明在節點數量大幅增加的情況下，整體部署耗時並未顯著增長。即使在高並發環境下，系統也能保持穩定的載入效能和資源調度效率，該方案展現出良好的橫向擴充能力。另外，叢集整體回來源資料量僅為模型總容量的約兩倍，有效控制了對中心儲存服務的訪問開銷，顯著削弱了大規模叢集並發載入模型對後端儲存服務造成的瞬時頻寬衝擊。