上周我把 DeepSeek Harness 部署到了公司内网的一台服务器上原本只是想自己测试一下结果不到半天隔壁组的同事就开始排队问我要账号。一周下来这台服务器成了团队里最热闹的基础设施有人拿它写周报有人拿它调 SQL还有人把它接进了自己的脚本里做批量总结。说实话我一开始也没想到效果会这么好但复盘整个部署过程我发现这件事能跑通靠的并不是某个神秘技巧而是一套清晰的需求拆解和几个关键决策做对了。为了让你也能顺利复现我把从需求确认、环境准备、部署配置到团队接入、问题排查的完整过程整理成这篇记录。里面有我实际敲过的命令、用过的配置也有踩过坑之后才明白的原理。如果你正打算在公司或自己的服务器上部署一个大模型服务这篇文章应该能帮你少走不少弯路。1. 这东西到底是干什么的先别急着装搞清楚需求再动手1.1 我为什么会在服务器上折腾一个“模型套件”事情还得从一次需求说起。我们团队经常需要处理长文档、生成代码注释、整理会议纪要之前大家各用各的网页版模型效率不高而且很多内部数据不方便往外部平台发。所以我一直想在内网搭一个统一的大模型服务让同事用起来像访问一个内部网站一样简单。当时我调研了几个方案有的偏重对话有的偏重 API 网关但配置都比较重不太适合我们这种小团队。后来我注意到 DeepSeek Harness 这个项目它的定位很精准把 DeepSeek 模型也可以对接其他兼容模型封装成一套开箱即用的服务自带 Web 界面、API 接口、用户体系和会话管理。换句话说它不是一个模型本身而是一个“套在模型外面的壳”让模型从命令行玩具变成一个团队可用的基础设施。这个定位正好卡在我们的痛点上。我不需要从零开发前端和管理后台也不用自己去写用户认证和接口鉴权Harness 已经把这些都做了。我要做的就是把它部署到服务器上再接上模型后端然后让同事通过浏览器访问。1.2 DeepSeek Harness 解决了什么痛点可能有人会问直接用官方 API 不就行了为什么要自己部署一个 Harness这里有一个关键区别。官方 API 只给你了一个“接口”你仍然需要自己去写客户端、做界面、管权限。而 Harness 解决的是“如何把模型能力变成团队公共服务”这个问题。具体来说它解决了三个痛点。第一是统一入口以前每个人装不同的客户端、用不同的提示词模板现在大家访问同一个地址就有统一的使用体验。第二是权限与数据边界内网部署可以控制谁能访问、能访问什么模型敏感数据不出内网比大家各自把数据贴到外部网页上安全得多。第三是可用性管理模型挂了、显存满了、并发超了都能从管理端看到而不是等同事来抱怨“怎么又卡了”。所以说DeepSeek Harness 适合的不是“只想在本地跑个模型看看效果”的个人用户而是那些想让大模型真正服务一个团队、一个部门甚至一个小公司的人。它是把“模型能力”转化成“团队生产力”的一座桥。2. 部署前的准备工作硬件、系统和方案选型2.1 服务器硬件怎么选有卡没卡是两条路在动手之前我先把硬件条件摸了一遍。服务器是一台之前闲置的机器配置大概是这样CPU 是 16 核内存 64GB没有独立 GPU硬盘还剩 1TB 不到。这个配置跑大模型其实有点尴尬因为现在主流的大模型推理都依赖显卡但也不是完全不能跑。如果你手头有 NVIDIA GPU比如 3090、4090 或者 A100那恭喜你可以直接跑量化后的 7B、14B 模型体验会流畅很多还可以支持更多人同时使用。如果是纯 CPU 服务器也有一条路选小参数模型比如 DeepSeek 的量化版 7B 模型配合足够的内存依然能跑只是速度会慢一些适合对实时性要求不高的场景。我最终选择了“CPU 量化小模型 并发限制”的路线。原因很简单不想为了一两次实验就去申请 GPU 资源。而且我们团队的实际场景是“写周报、读文档、改代码”这类任务对延迟没那么敏感一句话等 10 秒和等 3 秒体验差距并没有想象中大。如果你想追求流畅的对话交互我还是建议至少有一张 24GB 显存的显卡。2.2 系统环境与软件依赖我最终选了什么组合硬件定下来接下来是软件栈。我预期要装的东西有这么几类容器运行环境Docker、模型推理后端Ollama、以及 DeepSeek Harness 本体。为什么用 Docker因为 DeepSeek Harness 的官方文档提供了现成的镜像用容器跑能隔离依赖、方便升级也避免污染服务器上其他服务。我用的系统是 Ubuntu 22.04 LTS这算是服务器上最稳的选择之一。Docker 我选择安装 Docker Engine Compose 插件因为之后要用 docker compose 来编排 Harness 和 Ollama 两个容器。Ollama 是一个非常好用的本地模型运行工具一条命令就能下载并启动模型而且暴露的 API 与 OpenAI 兼容Harness 可以直接对接。还需要注意一个细节服务器的防火墙和安全组要放行 Harness 和 Ollama 的端口。我们内网环境用的是 8080 端口跑 Web 界面11434 端口留给 Ollama API。这些端口在云服务器上通常需要在安全组里配置在公司内网则要确保防火墙规则允许访问。3. 完整部署过程实录从零到同事能用的每一步3.1 第一步安装 Docker 和 Compose 插件所有东西都是从一个干净的服务器开始的。我先做了一点基础更新然后安装 Docker。Ubuntu 上安装 Docker 官方源比较快具体命令也很常规sudo apt update sudo apt install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin装完之后把当前用户加入 docker 组省得每次敲 sudosudo usermod -aG docker $USER newgrp docker验证一下环境docker version docker compose version这两个命令能打印出版本号说明 Docker 和 Compose 已经就绪。这一步其实没什么难度但很多人会忽略加入 docker 组后的重新登录问题导致后面 docker 命令一直报权限错误。实际上你重新 SSH 连接一次或者执行 newgrp docker就能解决。3.2 第二步拉取 DeepSeek Harness 镜像并编写 Compose 编排文件Docker 就绪后接下来的核心任务是让 DeepSeek Harness 跑起来。我先是按文档把项目仓库克隆下来里面有现成的 docker-compose.yml 示例git clone https://github.com/your-repo/deepseek-harness.git cd deepseek-harness注意具体仓库地址以你实际使用的版本为准我这里用的是一个示意路径。如果你拉不到代码也可以直接拉镜像然后自己写 compose 文件。我的做法是参考项目里的配置模板做了一些精简最终的 docker-compose.yml 大致长这样version: 3.8 services: ollama: image: ollama/ollama:latest container_name: ollama restart: always volumes: - ./ollama_data:/root/.ollama ports: - 11434:11434 harness: image: deepseek-harness:latest container_name: deepseek-harness restart: always depends_on: - ollama environment: - MODEL_PROVIDERollama - OLLAMA_BASE_URLhttp://ollama:11434 - DEFAULT_MODELdeepseek-r1:7b - WEB_PORT8080 ports: - 8080:8080 volumes: - ./harness_data:/app/data这里有一个很关键的细节Harness 容器内访问 Ollama不应该是 localhost而是服务名 ollama。因为 Docker Compose 会在内部网络里做 DNS 解析你写 localhost 指向的是容器自己而不是 Ollama 容器。我第一次部署时就在这里栽了跟头后面排查了很久才反应过来。3.3 第三步配置模型后端先拉一个能用的模型在启动整个编排之前我先把 Ollama 跑起来并下载了模型。虽然 Compose 会在启动时拉起 Ollama但模型不会自动下载。所以我先单独启动 Ollama 容器然后再用 docker exec 去拉模型docker compose up -d ollama docker exec -it ollama ollama pull deepseek-r1:7b这条命令会从模型仓库下载 DeepSeek R1 7B 模型。如果网络状况不好下载时间会很长我这边大概花了几分钟到十几分钟不等取决于服务器带宽。下载完成后可以先用命令行验证一下模型是否正常docker exec -it ollama ollama run deepseek-r1:7b 你好用一句话介绍自己如果能正常输出说明本地模型后端已经通了。这一步非常重要因为如果 Ollama 这边都不通接上 Harness 后大概率也是一堆报错。如果你想用官方的 DeepSeek API 而不是本地模型那就不需要 Ollama只需要在 Harness 环境变量里配置 API Key 和接口地址。但我个人建议在内网场景优先用本地模型原因很简单数据可控不会把内部信息发到外部服务。3.4 第四步启动完整服务并验证 Web 界面模型就绪后就可以把整个栈拉起来了docker compose up -d启动完成后用 docker compose ps 查看状态。如果两个容器都是 Up并且没有异常退出就可以在浏览器里访问服务器的 8080 端口了。如果你是云服务器记得先配置安全组放行 8080如果是公司内网确认防火墙规则没问题。我第一次访问的时候页面加载出来了但输入对话后一直转圈。后来看日志才发现是 Harness 容器解析不到 Ollama 的地址因为我写的是 localhost。改成 http://ollama:11434 后刷新页面再试对话就通了。那一刻还是很兴奋的毕竟从零到能访问完全没有写业务代码。验证通过之后我立刻做了一轮“自测清单”多轮对话是否正常、会话刷新后是否还在、是否支持流式输出、并发访问会不会挂。这些都在 Harness 的管理页面或 API 里能测到。确认没问题我才开始邀请同事体验。4. 让同事“玩嗨了”的团队玩法权限、分享与自动化4.1 用户体系和权限隔离不再互相干扰部署完成只是第一步真正让同事“玩嗨了”的是 Harness 自带的用户体系。它支持创建多个账号每个账号的会话记录互不可见。这一点太重要了如果没有隔离几个同事同时用互相能看到对方的提问内容体验会非常尴尬。我创建账号的时候按小组来分组每组用不同的前缀比如 dev-xxx、ops-xxx、product-xxx。分配权限的时候也给不同角色设置了不同的模型访问范围。比如产品同事主要用通用对话和总结功能开发同事可以访问代码生成相关的模型运维同事则允许调用 API 做自动化脚本。实际使用中用户隔离还带来一个额外的好处每个人都有自己的历史会话可以随时翻看之前的对话记录。这比大家挤在同一个公共网页里强太多了更像是每个人都有一个私人的 AI 助手。4.2 会话分享与协作把对话变成团队资产除了基础的用户隔离Harness 还支持把某个会话分享给团队里的其他人。这个功能看起来不起眼用起来却很香。产品经理写了一份很长的需求文档让 AI 帮忙提炼出关键点生成之后一键分享到团队群研发同事点开就是完整的上下文不用自己再重复一遍。我们后来还形成了一个小习惯每次项目复盘前先让 AI 把这一个月的会议纪要、周报汇总起来生成摘要然后把摘要会话分享给项目组所有成员。这样大家看的是同一份由 AI 整理的内容信息对称了很多。这种场景如果靠各自去外部网页提问完全无法实现。我觉得这就是“Harness”这个词的精髓它把模型能力“套”进了团队协作流程里而不是让每个人孤军奋战。4.3 通过 API 接入现有工具从“玩”到“用”如果说 Web 界面让大家觉得新鲜好玩那 API 接入就是让团队效率真正起飞的关键。Harness 暴露了一个标准的 REST API兼容不少工具链。我们做了两件比较典型的事情。第一件事是接了一个内部的小助手机器人。因为我们企业 IM 支持自定义机器人回调我在机器人后台配置了 Harness 的 API 地址同事在群里艾特机器人提问消息就会转发到 Harness再把模型回复推回群里。整个过程大概只花了一个下午。第二件事是写了一个简单的 Python 脚本批量处理历史工单的分类和摘要。以前需要人工读一遍的工单现在先让 AI 打上标签再做关键词统计效率提升非常明显。需要注意的是API 接口一定要加访问控制。Harness 本身支持 API Token 认证我在调用脚本里都配置了 Token并且把 Token 的有效期设置得比较短到期再换。千万不要把没有认证的 API 暴露到不可信的网络里否则别人可以直接调用你的模型服务刷爆资源。5. 部署过程中的坑排错与优化实录5.1 常见问题速查表这些我都替你踩过了部署过程中遇到的坑我整理了一个速查表希望能帮你省下排查时间。问题现象可能原因解决方法Harness 页面一直转圈Harness 连不上 Ollama 地址确认环境变量 OLLAMA_BASE_URL 使用http://ollama:11434而不是 localhost拉取模型很慢或失败网络带宽不足或源不稳定换更接近的网络源或分时段重试对话响应很慢CPU 推理、模型参数过大换更小参数的量化模型或开启并发限制并发一多就卡死未限制最大并发数在 Harness 或 Ollama 层设置并发上限容器日志里出现权限报错挂载目录权限不对确保宿主机挂载目录对容器内运行用户可写重启后数据丢失未挂载持久化卷在 compose 中配置 volumes 保存数据这张表看着简单每一条背后都是我实际碰到过的问题。尤其是“重启后数据丢失”这个问题刚开始我没挂载数据卷结果容器一删所有用户会话全没了同事立刻来找我“讨说法”。后来我加了挂载卷再配合定时备份才算安心。5.2 性能优化并发、流式输出和显存控制因为没有 GPU我一开始对 CPU 推理并发是没什么底气的。16 核 CPU 跑 7B 量化模型单次请求最快也要几秒如果多人并发很容易直接把 CPU 打满然后大家集体超时。我的解法分两层外层在 Harness 里设置了最大并发数比如最多 4 个请求同时处理多余的排队等待内层在 Ollama 环境变量里设置 OLLAMA_NUM_PARALLEL 为 2限制单个模型实例的并行度。还有一个很实用的优化是开启流式输出。Harness 支持 Server-Sent Events 或 WebSocket 流式响应这样用户看到的是打字机一样的效果首字延迟会大幅降低。虽然总耗时没有减少但体感快了很多同事普遍反馈比“转圈半天再一次性输出”好太多。如果你有 GPU还可以关注一下显存控制。Ollama 默认会根据模型大小占用显存你可以在启动时设置 OLLAMA_MAX_LOADED_MODELS 控制同时加载的模型数量避免多模型互相挤占显存。我们目前只有一个小模型暂时没这个烦恼但等以后增加模型这个参数很有用。5.3 安全加固访问控制与数据隐私最后说安全。大模型服务一旦开放给团队使用就必须认真对待访问控制和数据隐私。我在部署完成后做了一次安全自查主要包括四件事。第一所有服务都绑定在内网地址或经过反向代理不直接暴露公网。如果确实需要远程访问我建议在 Harness 前面加一层反向代理并启用 HTTPS而不是把裸端口映射出去。第二开启 Harness 的认证功能所有用户必须登录才能访问不能让未认证请求直接打到底层模型。第三限制 API Token 的权限范围只给脚本需要的模型和接口权限而不是一把万能钥匙。第四明确告知同事不要在服务里提交高密级敏感数据因为虽然模型部署在内网但数据的存储和日志记录仍然需要管理。这些措施说起来不难但它决定了这个服务能走多远。毕竟模型能力再强如果安全和隐私没有保障团队管理一关就过不去。最后再分享一个小技巧如果你也想在公司内部复刻这件事我建议你部署完成之后先不要急着宣传而是找两三个对 AI 工具感兴趣的同事小范围试用让他们提需求和反馈。我这次就是因为先让一位产品同事和一位开发同事用了一下午他们提出“希望会话能分享、希望能接机器人”其实是很真实的需求我按优先级排好了功能之后才大规模开放。这样既不会因为一上来就所有人都用导致服务被打爆也能根据真实反馈优化使用体验。根据我这一周的观察DeepSeek Harness 现在已经是团队里使用频率最高的内部服务之一。每天早上打开后台都能看到昨晚还有人半夜在跑批处理任务。虽然我只是做了一个“搬运”和配置的工作但看到同事用它节省了大量的重复劳动还是很有成就感的。如果你也在考虑把大模型能力带到自己的团队里希望这篇记录能给你一个清晰的路标。