作者：ZStack

在我們前幾篇文章中，我們深入探討了 DeepSeek-R1 系列模型（蒸餾版7B、32B，以及671B 量化版和非量化版）的部署和推理原理。

然而，面對如此多樣的模型選擇，企業在實際應用中常常困惑：哪種模型適合特定場景？該使用推理模型還是通用模型？不同模型的投入成本與效能表現如何平衡？本文將針對這些問題，先對目前最常見也火爆的知識庫、程式碼輔助和智慧體（Manus）場景進行分析，最後結合當前硬體成本和實際企業應用場景，提供系統的分析和建議。

企業知識庫應用是大模型落地最常見的場景，對於簡單的、對幻覺容忍度較高的場景，例如旅遊景點問答或內部輔助等場景，業界已經形成了非常標準的 RAG 三件套——embedding + LLM + rerank（文件切片、向量化、檢索內容重排、大模型總結答案），在上述簡單場景中已經可以運用到實踐中。

但在要求更高的企業場景中，知識庫常常是“Demo 三天、最佳化半年”，這是因為在企業實際應用中，知識庫的核心技術 RAG 往往會面臨諸多挑戰。根據業內實踐，知識庫部署主要存在以下難點：

對此，業界也提出了諸如問題分類（Routing）、問題最佳化（Rewriting）、知識圖譜（GraphRAG）、複雜文件提取等方法，但這些方法往往涉及不同模型的配合，那麼如何選擇模型、如何讓模型快速配合、確保每個步驟的落地就變成了關鍵問題。

（圖片來自網路）

接下來，我們將這些業界方案分為“知識構建”、“知識檢索”和“答案生成”三個階段來看。

不難發現，知識構建階段會涉及到多種大小各異的模型，例如 embedding、OCR 之類小模型可能最低僅需要幾 GB 視訊記憶體，而企業級的知識圖譜提取、大語言模型則通常需要上百 GB，因此，在 AI Infra 層面一定要考慮到對視訊記憶體的靈活切分，以適應各種模型的測試、推理需求。

如圖，透過 ZStack AIOS 智塔所支援的視訊記憶體切分，可以將 24GB 卡切分出 4GB，足以滿足高效能向量模型的需要，並能夠提供 360 以上 QPS。

結構化輸出 是指大語言模型(LLM)生成的具有預定義格式的輸出，如JSON、XML、表格或其他特定結構的資料，而不是自由形式的文字。這種輸出方式使模型的回答具有一致的格式和明確的資料結構，便於後續程式處理和解析。

如下圖所示，ZStack AIOS 智塔支援結構化輸出（這裡透過 Swagger UI 演示），這樣開發者不需要處理小模型不遵循指令的情況，這樣用小模型處理問題分類或問題最佳化會方便很多。

答案生成階段對大引數模型的依賴更重，需要更加龐大的 GPU 算力叢集，也意味著更高昂的硬體成本，企業需要重視叢集架構、網路傳輸及儲存系統的規劃和效能提升方案，力求將硬體效能發揮到極致。

如下面影片所示，ZStack AIOS 智塔支援 Nvidia、Huawei、Hygon 等 GPU/NPU 的大模型推理，充分發揮多晶片叢集的效能，並且在橫向擴充套件方面具備出色的靈活性，為企業最佳化算力資源、降低成本提供了有力支援。

知識庫是企業應用中常見且需求旺盛的部分。然而，RAG 知識庫 “Demo 易，上線難” 的問題，始終困擾著大模型應用開發者。這不僅依賴大模型能力提升、工程應用創新微調，更離不開底層平臺的支撐最佳化，多方協作才能構建線上 AI 服務。

如今，知識庫不再由單一的大語言模型包攬所有問題，而是在多種工具、模型配合實現，特別是大小模型配合、向量多模態語言模型、OCR 類傳統模型和生成式模型配合，

若想了解 ZStack 在 RAG 場景的經驗，可參考此前文章《DeepSeek 企業應用落地：智慧客服如何助力科技企業》

得益於大量的開源高質量程式碼，目前 AI 在程式碼生成上是非常擅長的，我們將 AI 程式碼輔助分成幾種場景，以方便我們在效果、成本之間進行權衡。

目前適合程式碼輔助的 AI 主要分為通用模型、推理模型和專用模型，其中推理模型意味著模型在生成最終答案之前會輸出“思考過程”，專用模型意味著模型為程式碼場景專門調優。

從上述表格可知，HumanEval 測試生成的程式碼較短，多數模型已經可以取得較高分數，所以在小規模函式生成以及特定程式碼的 UT 生成方面，大部分模型基本可以勝任。但想要更好效果，一方面需要較長上下文（開發者常對程式碼片段反覆修改），另一方面則需要得分更高的模型。據我們經驗，LiveCodeBench 分數達到 DeepSeek V3，對輔助編寫程式碼就會有很大幫助。

如下圖所示，ZStack 產品研發中心每日 Token 消耗量在 300 萬至 500 萬左右（週末用量會減少），主要使用 Qwen2.5 – 72B、DeepSeek 等模型 。

程式碼評審任務的實現門檻較低，但其上限頗高。最基礎的程式碼評審，僅需將程式碼的 diff 補丁傳送至模型即可，開發者依據常見程式碼風格或其他要求設計 prompt，待 AI 回覆後，再將回復發送至 Gitlab、Gerrit 等內部評審系統。

然而，這種方式效果欠佳，主要存在以下問題：

因此，當下 AI 程式碼評審常採用一系列手段來增加模型輸入，以提升評審效果：

以上架構目前在 ZStack 產品研發中心也得到運用，平均每天 200 多個 contributions（包含程式碼總結、評論），Review 30 多個 PR，給出 50 多條可行的建議。

下面是 AI 評審的一個具體例子，可以看到 AI 指出了原本在呼叫的 ZStack 內部庫函式 subprocess.call 不夠安全，建議改用內部的  check_call 庫函式，並給出了示例。

接下來這個例子中，AI 評審的效果更為顯著，AI 指出了程式碼中使用的 SystemTag 可能有誤用，這裡無論 DataVolume、SystemTag 都是 ZStack 內部的程式碼概念。這一成果表明，AI 已深度理解 ZStack 的專有概念與架構思路，不僅能夠精準發現問題，還能提供切實可行的指導建議 。

前面我們看到大部分模型在 HumanEval 上得分都是比較高的，這意味著簡單“程式碼補全”場景使用以上模型基本都可以正常使用，使用小模型可能更有速度和價效比上的優勢。但如果我們希望 AI 更加智慧，當前的 AI IDE 或外掛往往採用了 Plan+Act 的架構，可能需要推理模型和通用模型配合使用，例如 DeepSeek R1 + DeepSeek V3 或者 DeepSeek R1 Distilled Lllama 70B + Qwen2.5 72B。

以上場景都是以人為主，AI 輔助的形式，哪怕是程式碼補全不斷 Tab 或者 Plan+Act 也往往需要人去驗證、測試程式碼。我們最終期望的形式是人只要提要求，AI 就可以自動完成了，這個對系統的要求與程式碼評審類似，但是沙盒的重要性會更高，此外需要更多的儲存來存放執行過程的記錄，下面以 OpenHands 為例進行分析，涉及物件儲存、向量模型、大語言模型、容器沙盒：

當前，AI直接執行任務大多仍處於實驗階段，效果高度依賴大模型自身效能。在2024年的測試裡，Claude 3.5 Sonnet 是表現最為出色的模型，DeepSeek v2.5 的得分僅為 Claude 3.5 Sonnet 的50% 。雖然尚未對DeepSeek V3展開測試，但鑑於 DeepSeek V3 在 SWE Verified 測試中的表現相較於 V2.5 提升了86%，大致可推斷其效能能夠達到 Claude 3.5 Sonnet 的水平。

不過，仍存在以下情況：

– OpenHands目前無法基於推理模型制定計劃，後續仍有最佳化空間；

– DeepSeek系列模型暫不支援Vision功能，在支援任務的多樣性方面相比 Sonnet存在一定差距。

企業應搭建基於本地化基礎設施的AI輔助編碼體系，結合自身程式碼庫與工作流特性，靈活融合AI技術，進而提升開發效率與程式碼質量。具體體現在以下幾方面：

總體而言，企業在構建 AI 輔助編碼方案時，不僅要關注 AI 模型的原始生成能力，更要整合內部資源，構建一個包含程式碼生成、評審、補全及全自動任務執行的閉環體系，實現高效、可靠的編碼輔助與質量管控。 

自上週 Manus 釋出以來，智慧體直接執行通用任務進入了大眾視野，社群中也湧現出 Open Manus、Owl 等各類開源復現成果。這實際上是隨著平臺支撐能力的發展，上層應用綜合運用多種工具所呈現出的成效。

其實在上個月 OpenAI Deep Research 憑藉模型+自主搜尋+自主閱讀已經讓很多人感到 AI 的便利，隨著 Manus 釋出，讓更多人看到了 AI 直接完成報告、計劃、遊戲、網頁、聲音的可能性。

智慧體的概念並不稀奇，但 Manus 相比最早的 Agent 在多個方面實現了革新：

接下來，我們將逐一對這幾項技術進行介紹。

瀏覽器自動化是個非常“古老”的課題。在 UI 測試中，對瀏覽器進行各類自動化操作的需求極為迫切。因此，從 Selenium 到 playwright，無論是採用 headless 設計，還是結合截圖的設計方式，UI 自動化領域幾乎探索了所有可能的途徑。自 Vision 模型釋出後，尤其是 GPT – 4o、Claude 3.5 展現出對網頁極為出色的理解能力以來，人們開始嘗試運用模型以端到端的方式去理解和操作瀏覽器，並且取得了良好的效果。

例如，我們使用開源模型 Qwen2.5 – VL – 72b，成功實現了從 ZStack 官網進入了“幫助與支援”選單，進而跳轉至最新版本特性頁面的操作過程。不過該過程存在較高的延遲，Manus 團隊或許已針對此情況進行了一定程度的最佳化。

透過測試集測試也可以看到目前 Qwen2.5-VL-72B 已經在多個測試上超過 Claude 3.5，甚至 7B 模型目前的效能也不錯且可以大幅提升執行速度。

除了操作瀏覽器之外，有些情況可能需要 AI 編寫程式碼、呼叫程式甚至執行一些測試等，測試需要運用到 Computer Use，例如在下面的演示中我們讓 AI 自動打開了瀏覽器，瀏覽了一些網頁最後生成了 Markdown 格式的檔案（影片已經過加速）。

Computer Use 對模型的能力要求和 Browser Use 基本是類似的，區別在於目前 Computer Use 往往需要大量編寫程式碼，透過檔案來一步步完成工作，對程式碼的要求比較高，因此推薦使用程式碼能力強、支援 Tool Use 的模型。

透過上面的分析可以看到，Browser Use 、特別是 Computer Use 在實際執行過程中是存在一定安全風險的，因此需要考慮透過沙盒來確保安全性，因此我們在看 Manus 工作的時候可以看到右側始終有一個 Manus 的電腦，從最終效果來猜測應該是一個虛擬機器或輕量虛擬機器而非容器。在我們測試 OpenManus 和 Owl 等 Agent 平臺時，均採用了在 ZStack AIOS 平臺智塔上啟動 Ubuntu 的雲主機來測試。

Deep Research 基於深度網頁搜尋構建報告，為我們的調研與學習帶來了極大便利。Manus 在此基礎上更進一步，儘管不少網文認為其技術壁壘不高，主要依靠工程實現，但我們認為 Manus 這類應用的發展，為企業運用 AI 開闢了廣闊的想象空間：

透過上面的介紹可以看到企業完整落地各類 AI 應用需要：

因此如果要構建一個整體化的 AI 平臺，可以通過幾種方式，我們把各自優缺點和適合場景整理到了下面的表格中：

得益於 ZStack AIOS 智塔的靈活架構，我們給客戶提供了多樣性的解決方案，不同的客戶可以根據自身的機房條件、業務需求和未來規劃進行選擇，而且得益於同一品牌的軟體，現有叢集可以透過升級版本納管 GPU，一體機既可以加入現有平臺也可以獨立使用，如果處於業務安全訴求不能升級也可以透過雲管來統一管理、統一監控、統一運維，給予使用者充分的自由度。

在剛過去的2024 年，AI 落地的關鍵場景聚焦於文生圖、知識庫與程式碼輔助領域。在設計、影視、廣告及遊戲行業，文生圖技術已廣泛落地應用。隨著知識提取技術的精進以及大量開源知識庫軟體的興起，知識庫也為更多人所熟知。而程式碼輔助更是成為多數開發者工作中不可或缺的部分。

然而，生成式 AI 融入業務的路徑與上一代決策式 AI 有所不同。決策式 AI 往往直接切入業務，如提升風控準確率、最佳化商品推薦等。新一代 AI 則率先從賦能個體的生產效率起步，首先提升了設計師、軟體工程師以及客服技術支援人員的工作效率。基於此，企業有必要搭建起支撐底層創新的平臺。這一平臺應確保無論有無程式碼基礎的業務人員，都能在無需擔憂 “Token” 費用及 “資訊安全” 問題前提下，藉助流暢且高效能的模型 API，充分釋放自身創造力，快速嘗試各類新興的 AI 應用 。