手搓Manus+DeepSeek企业私有化 AI 场景实战全攻略

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

然而，面对如此多样的模型选择，企业在实际应用中常常困惑： 哪种模型适合特定场景？该使用 推理模型还是通用模型？不同模型的 投入成本与性能表现如何平衡？本文将针对这些问题，先对目前最常见也火爆的 场景进行分析，最后结合当前硬件成本和实际企业应用场景，提供系统的分析和建议。

企业知识库应用是大模型落地最常见的场景，对于简单的、对幻觉容忍度较高的场景，例如旅游景点问答或内部辅助等场景，业界已经形成了非常标准的 RAG 三件套—— （文档切片、向量化、检索内容重排、大模型总结答案），在上述简单场景中已经可以运用到实践中。

但在要求更高的企业场景中，知识库常常是“Demo 三天、优化半年”，这是因为在企业实际应用中，知识库的核心技术 RAG 往往会面临诸多挑战。根据业内实践，知识库部署主要存在以下难点：

对此，业界也提出了诸如 问题分类（Routing）、 问题优化（Rewriting）、 知识manus 教程图谱（GraphRAG）、 复杂文档提取等方法，但这些方法往往涉及不同模型的配合，那么如何选择模型、如何让模型快速配合、确保每个步骤的落地就变成了关键问题。

接下来，我们将这些业界方案分为“知识构建”、“知识检索”和“答案生成”三个阶段来看。

不难发现，知识构建阶段会涉及到多种大小各异的模型，例如 embedding、OCR 之类小模型可能最低仅需要几 GB 显存，而企业级的知识图谱提取、大语言模型则通常需要上百 GB，因此，

如图，通过 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 场景的经验，可参考此前文章

得益于大量的开源高质量代码，目前 AI 在代码生成上是非常擅长的，我们将 AI 代码辅助分成几种场景，以方便我们在效果、成本之间进行权衡。

目前适合代码辅助的 AI 主要分为通用模型、推理模型和专用模型，其中推理模型意味着模型在生成最终答案之前会输出“思考过程”，专用模型意味着模型为代码场景专门调优。

从上述表格可知，HumanEval 测试生成的代码较短，多数模型已经可以取得较高分数，所以在小规模函数生成以及 特定代码的 UT 生成方面，大部分模型基本可以胜任。但想要更好效果，一方面需要较长上下文（开发者常对代码片段反复修改），另一方面则需要得分更高的模型。据我们经验， LiveCodeBench 分数达到 DeepSeek V3，对辅助编写代码就会有很大帮助。

如下图所示，ZStack 产品研发中心 每日 Token 消耗量在 300 万至 500 万左右（周末用量会减少），主要使用  Qwen2.5 – 72B、DeepSeek 等模型 。

代码评审任务的实现门槛较低，但其上限颇高。最基础的代码评审，仅需将代码的 diff 补丁发送至模型即可，开发者依据常见代码风格或其他要求设计 prompt，待 AI 回复后，再将回复发送至 Gitlab、Gerrit 等内部评审系统。

然而，这种方式效果欠佳，主要存在以下问题：

因此，当下 AI 代码评审常采用一系列手段来增加模型输入，以提升评审效果：

以上架构目前在 ZStack 产品研发中心也得到运用，

下面是 AI 评审的一个具体例子，可以看到 AI 指出了原本在调用的  ZStack 内部库函数 不够安全，建议改用内部的  库函数，并给出了示例。

接下来这个例子中，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 模型发布后，尤其是  以来，人们开始尝试运用模型以端到端的方式去理解和操作浏览器，并且取得了良好的效果。

例如，我们使用 ，成功实现了从 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 则率先从 ，首先提升了设计师、软件工程师以及客服技术支持人员的工作效率。基于此，企业有必要搭建起支撑底层创新的平台。这一平台应确保无论有无代码基础的业务人员，都能在 前提下，借助 ，充分释放自身创造力，快速尝试各类新兴的 AI 应用 。