作者：ZStack

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

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

　　本文目錄

　　一、場景 1：知識庫

　　二、場景 2：代碼輔助

　　三、場景 3：智能體（Manus）

　　四、企業 AI Infra 建設方案建議

　　五、總結與展望

　　場景 1：知識庫

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

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

　　多跳問題處理
多跳問題常見于企業報告數據整理環節、大量同義近義用語乃至指代等場景，如"從多份報表中找出企業近三年的復合增長率并與競對比較"。這類問題需要模型具備理解意圖、拆分實體和進行多步推理的能力。

　　上下文內容丟失問題

　　企業文檔中的關鍵信息如時間、區域標記往往分散在文檔不同位置，傳統 chunking 方法容易造成信息丟失。例如，財報中年份信息可能只在文件名和大標題出現，導致分割后的文本片段失去時間背景。

　　結構化數據處理
企業需要同時處理結構化數據（如數據庫、Excel 表格）和非結構化數據。大模型原生處理的是非結構化數據，但企業場景中結構化數據同樣重要。

　　計算與邏輯推理問題

　　在一些場景里，需要對輸入信息進行綜合計算和推理，例如已知某些配件的價格，需要計算總體的成本等。

　　多模態內容解析
企業文檔中包含大量圖表、思維導圖等復雜視覺內容，需要布局識別和理解能力，而非簡單的 OCR。

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

　　（圖片來自網絡）

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

　　階段 1：知識構建

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

　　如圖，通過 ZStack AIOS 智塔所支持的顯存切分，可以將 24GB 卡切分出 4GB，足以滿足高性能向量模型的需要，并能夠提供 360 以上 QPS。

　　階段 2：知識檢索

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

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

　　階段 3：答案生成

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

　　如下面視頻所示，ZStack AIOS 智塔支持 Nvidia、Huawei、Hygon 等 GPU/NPU 的大模型推理，充分發揮多芯片集群的性能，并且在橫向擴展方面具備出色的靈活性，為企業優化算力資源、降低成本提供了有力支持。

　　小結

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

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

　　在實踐中不斷運用各類工具，充分結合業務數據的多樣性和特定場景達到比較好的效果，這都需要底層平臺的強大支撐。

　　若想了解 ZStack 在 RAG 場景的經驗，可參考此前文章

　　場景 2：代碼輔助

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

　　1.開發者以對話形式向 AI 提問

　　2.開發者完成代碼后由 AI 進行代碼評審

　　3.開發者通過 IDE 集成 AI 來完成代碼補全

　　4.開發者提出思路或目標由 AI 完成代碼或任務

　　1、對話場景

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

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

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

　　2、代碼評審場景

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

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

　　AI 難以洞悉整個代碼庫的代碼風格；

　　AI 無法掌握代碼片段的依賴關系與上下文；

　　AI 無法結合傳統 lint 工具進行細致檢查。

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

　　在虛擬機（適用于測試代碼涉及復雜現有環境操作的情況）或容器（適用于僅進行靜態 lint 檢查等場景）中運行測試及代碼掃描；

　　支持用戶對話，并將相關內容結合 Jira 等問題跟蹤平臺存入向量數據庫，便于搜索；

　　借助依賴分析工具為代碼搜索更豐富的上下文。

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

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

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

　　3、代碼補全場景

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

　　4、AI 直接完成任務

　　以上場景都是以人為主，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存在一定差距。

　　5、小結

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

　　多樣化應用場景：目前 AI 在代碼輔助領域應用廣泛，涵蓋對話問答、代碼評審、IDE 補全以及自動化任務執行等場景。在不同場景中，企業可按需選用通用模型、推理模型或專用模型，實現精準適配。

　　合理權衡模型選擇與性能：在短小函數生成和基本代碼補全方面，多數模型已能獲得較高分數。但面對復雜代碼片段以及需反復修改的上下文場景，就需要得分更高且支持長上下文的模型，如 DeepSeek V3、Qwen2.5 系列等進行規劃。企業應依據實際需求，綜合考量成本效益，合理調整模型部署。

　　代碼評審和上線檢驗：盡管最簡單的評審方式只需傳遞 diff 補丁，但為了更準確識別代碼問題與安全風險，需要結合傳統的 lint 工具、虛擬機/容器測試環境，以及依賴分析工具。通過將 AI 評審建議與內部版本控制、 issue 跟蹤系統結合，能夠更好地滿足企業級質量控制要求。

　　本地化部署的重要性：通過自建本地化基礎設施，企業可以利用內部代碼庫和專有工作流來對 AI 模型進行調優，確保模型能更好地理解項目代碼風格、依賴關系和特定業務邏輯，從而在安全性、準確性與效果上取得更高保障。與此同時，本地化部署也便于整合企業現有工具體系（如 Gitlab、Gerrit 等），推動 AI 輔助編碼方案的落地。

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

　　場景 3：智能體（Manus）

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

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

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

　　充分運用Browser Use，即通過 AI 使用瀏覽器閱讀網頁

　　充分運用Computer Use，即通過 AI 操作電腦，編寫文件、運行代碼等

　　通過沙盒運行代碼，模仿熟悉計算機和編程的人類來完成任務

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

　　1、Browser Use

　　瀏覽器自動化是個非常“古老”的課題。在 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 模型目前的性能也不錯且可以大幅提升運行速度。

　　2、Computer Use

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

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

　　3、沙盒技術

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

　　4、小結

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

　　模型能力提升驅動優化：隨著模型不斷進步，其對 Computer Use 的理解將愈發迅速且深入，制定計劃的能力也會相應增強。當下，Manus 存在多 Agent 配合時錯誤可能逐步放大的隱患，但隨著模型能力提升，這一問題有望得到緩解。

　　解決企業老舊應用自動化難題：企業內部存在大量無法 API 化的老舊應用，或缺乏 API 支持的業務。借助Browser Use、Computer Use 實現自動化不失為一種可行方案。相較于 RPA，編寫 Prompt 更為靈活、便捷。

　　推動生成式 AI 融入企業業務：目前生成式AI主要以文字形式輸出，然而文字難以直接對接業務。唯有通過工具調用、函數調用、網頁調用等方式，才能加速生成式AI融入企業業務流程。

　　企業 AI Infra 建設方案建議

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

　　不同的模型，例如小尺寸的 embedding、rerank、語音，中等尺寸的圖形理解、文生視頻，大尺寸的推理模型和通用模型等；

　　不同的算力形式，例如沙盒需要啟動云主機，模型啟動可能通過容器；

　　充分測試工具，快速檢驗模型服務可支撐的線上并發、比較模型之間的能力差距等；

　　良好的運維輔助，監控和分析模型負載狀態、GPU 的工作狀態，提供掉卡報警等。

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

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

　　總結與展望

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

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

　　 因此 ZStack AIOS 智塔實現了上述的三層架構：

　　智算底座：確保運維人員能夠安全、便捷的運維智算集群，通過多芯片兼容保障供應鏈安全；

　　模型層：允許用戶及時使用到新發布的模型、簡化模型的運維，如果企業自身具有 AI 的團隊，AI 團隊也可以將自身優化過的模型或測試的模型直接發布到云上，供業務部門測試和對比；

　　運營層與應用層：不僅提供了服務評測對比不同模型的效果和性能，還內置了一些常用的 AI 應用方便企業快速部署搭建常見應用，加速創新，如果有門戶運營的需求，也可以實現多租戶管理、計費賬單等功能。

　　基于上述三層架構，充分融合云平臺本身具備的云主機、VPC 網絡、多租戶等功能，ZStack AIOS 智塔為多個企業打造了智算創新的底座，為企業發揮 AI、落地 AI 奠定了堅實的基礎。