上个月我在团队内部干了一件说大不大、说小不小的事把 DeepSeek Harness 部署到了公司的一台内网服务器上然后用 Nginx 挂了一个统一入口给组里所有人用。半个月之后测试同事用它在提测前自动生成边界用例产品同学用它把周报时间从一小时压到二十分钟后端同事在群里问这服务能不能接入我们自己的知识库。整个过程我印象很深因为这套东西真正跑起来之后团队使用大模型的方式从各玩各的变成了共用一个基础设施。这篇文章就把这次部署的完整链路写清楚包括为什么选 Harness、服务器和软件栈怎么准备、部署步骤里的关键配置、同事接入阶段做了什么以及上线后踩过的几个坑和排查思路。如果你正准备把大模型能力服务化给团队提供统一入口这篇文章应该能省掉你不少试错时间。1. 为什么要在服务器上部署一套大模型 Harness1.1 团队现状大模型用了三个月效率反而更乱先说背景。我们是一个十几人的研发小组日常涉及后端开发、测试、产品文档、数据分析。大模型工具从半年前就开始有人在用但用得相当碎片化。有一次我拉了一下组里的使用情况有人开着网页版对话框来回复制粘贴有人在自己笔记本里装了本地模型有人写 Python 脚本直接调 API还有同事把密钥贴在共享文档里被我看到后赶紧撤了。碎片化带来几个很实际的问题。第一网页版聊完的内容全留在个人账号里同事问上次那个结论从哪来的只能截图根本没法检索和复用。第二本地模型版本不统一同一条提示词在两个机器上出来的结果可能差很多谁也没法保证上次好用是因为什么。第三自己写脚本的同事倒是灵活但每个人都在重复实现上下文管理、错误重试、结果格式化代码仓库里躺着七八个功能重叠的脚本文件。团队用了三个月大模型效率不但没提升反而多了一种新的沟通成本问别人你用的什么模型什么提示词比问你代码怎么写的还费劲。这是我决定做统一入口的直接原因。1.2 Harness 解决的是模型之下和模型之上的事很多同事第一次听我说部署 DeepSeek Harness以为是部署一个模型服务。这里先把边界讲清楚Harness 不是模型本身它是架在模型调用之上的编排与接入层负责会话管理、提示词模板、用户权限、流式输出、用量统计和结果沉淀。你可以把它理解成给模型 API 包了一层团队协作界面。打个比方模型服务像一台发动机Harness 是变速箱和驾驶舱。发动机再好没有驾驶舱乘客只能蹲在引擎盖上吹风。团队里大多数人要的不是会调 API而是一个能打开就能用的网页、一段能直接复制的结果、一套能共享的工作流。我部署完成之后最直观的感受是同事打开的是一个内网地址能新建会话、能看到自己之前的所有历史对话、能用团队共享的提示词模板、能看到每次请求消耗了多少 token。这些体验靠个人脚本或者网页版是凑不齐的。1.3 为什么不直接用现成的商业协作产品市面上已经有不少带团队协作功能的 AI 产品我一开始也调研过最终没有选有三点考虑。第一是数据边界。我们有一些内部文档摘要、代码审查的需求内容不太适合放到外部公共空间里反复流转。自建服务可以把请求和数据都控制在自有服务器上敏感度高的场景更稳妥。第二是成本和灵活性。商业产品按席收费、按量收费十几人的小组一年下来也不是小数目。自建 Harness 之后底层模型可以随时切换本地模型跑内部任务、官方 API 跑高质量生成哪个便宜用哪个哪个效果好切哪个主动权在自己手里。第三是扩展性。自建服务能接内部知识库、接入公司的统一登录、把提示词模板沉淀成团队资产。通用产品能做好对话已经很好了定制到这种程度基本不可能。当然我不是一刀切否定商业工具。如果团队没有运维能力、没有服务器资源、对数据边界也不敏感用成熟产品确实省事。但如果你和我一样想把大模型能力变成团队自己的基础设施自建是值得投入的方向。1.4 我最终敲定的架构与选型优先级这次选型我有几条明确的优先级稳定性大于功能丰富度易用性大于自定义程度数据可控大于成本最低。按照这个顺序我定下的架构是部署层Docker Compose 编排所有服务容器化宿主机保持干净。推理层官方 API 为主本地模型为辅两条链路并存按场景切换。接入层Nginx 反向代理内网域名 HTTPS统一入口。存储层SQLite 起步等数据量上来再换 PostgreSQL。管理侧多用户账号管理员创建账号禁用自助注册。这套架构不复杂但每一层都考虑到了团队使用这个核心诉求。后面每一层的具体实现我都会一步一步讲。2. 部署前的软硬件准备哪些钱能省哪些不能省2.1 服务器配置没有 GPU 也能跑但有 GPU 体验完全不同很多读者最关心的是得多大机器才带得动。我直接给结论。Harness 服务本身非常轻它主要做请求调度、会话存储和界面展示真正的算力大头在模型推理。如果模型走官方 API一台 4 核 8GB 内存的服务器就能把 Harness 跑得很舒服磁盘有 50GB 富余就行。如果要在内网跑本地模型配置要求就上来了。我们用的生产机器是 8 核 16 线程、32GB 内存、一块 24GB 显存的 GPU。这个配置跑 14B 量级的量化模型很流畅32B 量化模型也能跑起来只是并发数要控制小一些。如果预算有限16GB 显存也能跑 7B 到 14B 的模型日常问答、代码生成都够用。我的建议是分场景配置团队只有十几人、模型走 API、内网只放服务层4C8G 起步。需要在内部跑本地模型、追求效果也追求隐私8C32G 加一块 16G 以上显存。并发高、还要跑大参数模型16 核以上 CPU、64G 内存、双卡起。我第一次部署时图省事把 Harness、数据库、模型推理全部塞进一台 4C8G 的机器结果本地模型一加载权重内存直接见底整个服务被系统 OOM 杀掉。后来把模型推理拆到有 GPU 的机器上Harness 只负责调度和界面故障隔离之后才真正稳定下来。2.2 系统与基础软件Ubuntu、Docker 和 Compose操作系统我们用的 Ubuntu 22.04 LTS选择理由很朴实Docker 和 NVIDIA 容器工具链对它的支持最完善出问题社区资料多好搜。基础软件层只需要三样Docker Engine、Docker Compose、Nginx。我没有直接在宿主机安装模型运行环境而是全部容器化。这样升级、迁移、回滚都方便宿主机环境不会被各种依赖搞乱。有几点安装细节值得提。第一安装完 Docker 后把当前用户加入 docker 组否则每条命令前面都要加 sudo后续维护很别扭。第二Docker Compose 不要依赖系统自带的旧版版本太老会导致 compose 文件里的一些语法解析失败。第三如果拉取外部镜像慢可以考虑配置一个可用的镜像仓库地址这能节省不少等待时间。2.3 模型服务选型本地模型和官方 API 两条腿走路模型服务这一层很多人会纠结到底用本地还是用 API。我的答案是别纠结两个都要按场景切。默认流量走 DeepSeek 官方 API原因是效果稳定、推理速度快。写代码、写文案、分析文档这些绝大多数需求API 返回质量足够好而且不用自己维护推理成本。涉及内部敏感数据、不方便出内网的内容则切换到本地模型。本地模型通过 Ollama 拉取 DeepSeek 的蒸馏版本在有 GPU 的机器上单独跑一个服务端口Harness 这边配置多个模型来源使用时由用户自己选择。这里有个重要的经验别把推理服务、Harness、数据库全部放在同一台机器上。我一开始犯过这个错误本地模型加载权重时把内存吃满连 Harness 的 Web 界面也跟着卡死整个团队一起掉线。后来把模型推理独立出去Harness 与推理服务之间通过内部网络通信故障隔离之后才算真正稳了。2.4 部署前先对齐系统时间这个细节容易忽略这一节很短但特别重要。内网服务器如果系统时间和真实时间不同步后面配 HTTPS 证书、调 JWT 有效期、看日志时间线都会出问题而且问题表现得特别诡异。我在这台机器上部署前一天正好发现系统时间比标准时间慢了 8 分钟当时没当回事。结果第二天配置完证书浏览器一直报证书无效排查了很久发现是时间偏移导致证书校验失败。后来装了时间同步服务一次解决。所以强烈建议部署前先检查一下服务器时间date如果时间偏差大先把时间同步配置好再开始后面的安装。这个步骤不花五分钟但能避免后面一堆莫名其妙的坑。3. 一步步部署从空服务器到可访问的 Harness 服务3.1 用 Compose 把服务编排起来Hatness 部署我是按面向团队的生产服务来做的所以不用手动启动进程的方式而是用 Docker Compose 一次性拉起全部组件。工程目录结构如下/opt/deepseek-harness/ ├── docker-compose.yml ├── .env ├── config/ │ └── harness.yaml ├── data/ │ ├── sqlite/ │ └── logs/ └── nginx/ └── conf.d/ └── harness.confdocker-compose.yml 编排了三个核心服务harness 主服务、Ollama 推理服务、以及后续会讲到的 Nginx。这里贴一个简化版本version: 3.8 services: harness: image: deepseek-harness:latest container_name: harness-main restart: unless-stopped ports: - 127.0.0.1:8000:8000 env_file: - .env volumes: - ./config/harness.yaml:/app/config/harness.yaml:ro - ./data/sqlite:/app/data - ./data/logs:/app/logs depends_on: - ollama networks: - harness-net ollama: image: ollama/ollama:latest container_name: harness-ollama restart: unless-stopped ports: - 127.0.0.1:11434:11434 volumes: - ./data/models:/root/.ollama environment: - OLLAMA_KEEP_ALIVE24h - OLLAMA_NUM_PARALLEL2 networks: - harness-net deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]这个文件里有几个设计点必须解释。第一harness 端口绑定在 127.0.0.1而不是 0.0.0.0。这样服务本身不会直接暴露到办公网所有外部访问统一走 Nginx 反向代理。这个习惯帮我挡掉了很多不必要的安全问题。第二ollama 容器设置了两条环境变量。OLLAMA_KEEP_ALIVE 设为 24h模型加载后保持 24 小时不卸载避免同事每次请求都重新加载权重这对响应速度影响巨大。OLLAMA_NUM_PARALLEL 设为 2限制并发推理数防止显卡显存被突发请求打爆。第三数据全部通过 volume 映射到宿主机。容器重建、升级、损坏会话记录、模型权重、日志都不会丢。有人在生产环境不挂数据卷直接跑容器一删历史数据全没了这个教训希望你不要亲自体验。3.2 配置文件里最值得花时间的几个字段Harness 的主配置是 config/harness.yaml我调试了几轮之后发现有几个字段直接决定了后面团队使用的体验。service: host: 0.0.0.0 port: 8000 secret_key: ${HARNESS_SECRET_KEY} auth: mode: multi_user registration: false token_expire_hours: 168 models: providers: - name: deepseek-api type: api base_url: https://api.deepseek.com api_key: ${DEEPSEEK_API_KEY} models: - deepseek-chat - deepseek-reasoner - name: local-r1 type: ollama base_url: http://localhost:11434 models: - deepseek-r1:14b session: max_history_messages: 40 max_tokens: 4096 default_temperature: 0.7auth 部分最关键的是 registration: false。入口不开放自助注册账号只能由管理员在后台创建。团队规模不大这种方式比邮箱验证码简单得多也安全得多。token_expire_hours 设成 168也就是一周免登录办公场景下这个时间是合适的同事不会每天被要求重新登录。models 部分我配置了两个 provider。API provider 的 base_url 指向官方接口本地模型的 base_url 指向 Ollama 服务。这里有个小细节如果 Harness 和 Ollama 在同一个 Docker 网络里base_url 可以直接写服务名 ollama:11434但我在这个版本里写的是 localhost因为 Nginx 转发到 Harness 后Ollama 端口也映射到了宿主机回环地址这样配置简单直观。session 部分max_history_messages 我设为 40。这个字段非常值得调。很多人刚上手时会把上下文拉满结果 token 消耗暴涨、响应变慢、单次请求动不动就超时。40 条历史消息对日常对话完全够用真正需要长上下文的场景再单独设置。3.3 初始化管理员账号与链路验证配置准备好之后启动过程比想象中简单cd /opt/deepseek-harness docker compose up -d docker compose logs -f harness第一次启动会拉镜像、初始化数据库日志里能看到建表相关的输出。等待一到两分钟用 curl 验证服务是否正常curl -s http://127.0.0.1:8000/api/health | jq返回类似 {status:ok} 的 JSON说明主服务正常。接着要创建一个管理员账号。Harness 提供命令行工具我用的是docker exec -it harness-main harness user create --role admin创建完之后会输出一个临时密码首次登录时需要修改。这里提醒一句临时密码先放到公司密码管理工具里不要直接贴到群里。管理员就位后再验证模型链路。我用一个最小请求测试 API providercurl -s http://127.0.0.1:8000/api/v1/chat/completions \ -H Authorization: Bearer admin-token \ -H Content-Type: application/json \ -d {provider:deepseek-api,model:deepseek-chat,messages:[{role:user,content:说一句你好}]}能正常返回内容后再验证本地模型链路。如果本地模型返回超时多半是第一次加载权重比较慢OLLAMA_KEEP_ALIVE 能解决后续的大部分等待问题。3.4 反向代理与团队统一访问入口服务跑通后我没有让同事直接访问 IP 加端口而是配置了一个内网域名用 Nginx 做反向代理挂上 HTTPS 证书。配置如下server { listen 443 ssl; server_name harness.lan; ssl_certificate /etc/nginx/certs/harness.crt; ssl_certificate_key /etc/nginx/certs/harness.key; client_max_body_size 20m; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }这里有三处容易翻车的地方。第一对话流式输出依赖 SSE 或 WebSocketNginx 必须带 Upgrade 相关请求头否则前端页面能打开但对话输出会一直卡住不动。第二client_max_body_size 如果太小以后上传文件、导入知识库时会直接报 413 错误。第三HTTPS 证书即使内网用自签的也要配上否则浏览器安全策略会阻止一部分接口调用同事看到大红警告页面对工具的第一印象就坏了。到这里同事在内网打开 https://harness.lan登录管理员创建的账号就能看到完整的对话界面了。部署阶段到此结束真正有意思的团队接入才刚开始。4. 团队接入靠的不是通知是能直接少干活的场景4.1 别急着开放注册先建好提示词模板服务部署完如果只是发一条通知大家可以用 AI 了效果大概率很一般。我自己观察到工具真正被团队接受靠的是打开网页就能直接少干活而不是有很大潜力。所以在正式推广之前我先在 Harness 里沉淀了一批团队内部的提示词模板。我建了这么几类周报生成把 git 提交记录、任务平台更新贴进去按团队格式生成周报初稿。代码审查传入 diff让模型按团队规范检查明显问题输出带优先级的修改建议。日志分析把报错堆栈贴进去让模型定位可能原因并给出排查步骤。SQL 转写把一段业务描述转成初始 SQL附带表结构和字段说明。文档摘要长文档丢进去生成结构化要点和待办事项。这些模板本身不复杂但省掉了同事每次组织提示词的麻烦。以前同事用大模型的真实状态是想了半天不知道怎么问有了模板点一下就能用门槛瞬间降下来。之后有同事新增了接口测试数据生成模板效果出奇地好这是后话。4.2 账号、权限和资源分配的落地细节多用户模式上线后账号由管理员统一创建按小组分配权限。我们的做法很直接普通成员默认能使用 API 模型和本地模型但不能修改全局配置我和另一位同事是管理员负责维护模型列表、查看用量报表和处理密码重置。这里有一个重要的边界普通用户能完成日常对话和模板调用但碰不到系统配置、日志和模型供应商密钥。密钥只存在于 .env 文件里通过 Compose 的 env_file 加载不会出现在 Web 界面上。资源分配上我给每个用户设置了速率限制每分钟最大请求数固定超出后排队而不是直接报错。这样既防止单个人瞬间把服务打满也不至于让同事在高峰期频繁遇到失败。我还打开了一个内部测试验证多个用户同时使用时会话之间不会互相串数据。这个测试很重要毕竟团队工具最怕的就是我打开的是我的历史记录结果看到了别人的内容。4.3 同事们的真实使用反馈接入一周后的数据比我预期的好。十几人的团队一周累计请求次数超过一千次平均一人一天十几次。最夸张的是测试组同事他把接口返回的 JSON 样例、数据库表结构、业务校验规则整理成模板每次提测前自动生成一批边界测试用例效果很惊艳。产品同学用得最多的是周报生成和文档摘要。之前她每周五下午要花一个多小时整理周报现在把 git 记录和工作项链接贴进模板生成初稿后再人工补充细节时间压缩到二十分钟左右。还有后端同事把日志分析模板接进了自己的排查流程遇到报错先丢给模型整理思路再决定从哪里下手。我对玩嗨了的理解是工具能被持续用不是因为界面多花哨而是因为它在真实工作流里省下了时间。同事们不需要理解 Harness 内部的架构他们要的只是打开网页、选个模板、得到能用的结果。4.4 使用量上来之后容量问题才开始现形随着同事大量使用服务器状态不再是部署时那种永远低负载的样子。我观察到了几个明显信号API 模式的流量主要集中在白天工作时间本地模型服务的显卡利用率从不到 10% 涨到经常 70% 以上SQLite 文件从几 MB 涨到了几百 MB日志文件成了增长最快的东西。这个阶段我才意识到部署 Harness 只是第一步容量规划、日志轮转、稳定性保障都是后续持续要跟的功课。这些实际运维中撞上的问题比部署环节本身更值得记录下来。5. 上线后踩过的几个坑排查链路与优化手段5.1 并发一高就 502根因在容器内存限制上线第三天组里开晨会十个人同时在 Harness 上生成晨会摘要服务突然开始返回 502。当时我没慌按链路逐步排查。先看 Nginx 错误日志发现大量 connect() failed (111: Connection refused)说明后端 Harness 服务瞬间不可用。接着看容器状态docker ps 显示容器挂了但被 restart 策略拉起来了。再查容器的退出码是 137。137 表示进程被 SIGKILL最常见的场景是内存超限被系统杀掉。继续查容器的内存限制发现 compose 文件里没有显式声明 mem_limitDocker 默认允许容器使用宿主机全部内存。而同一台机器上还跑着 Ollama本地模型加载权重时吃掉大块内存Harness 进程申请不到内存触发 OOM。修复分两步。第一给每个容器设置明确的资源上限把 Ollama 的模型推理安排到有 GPU 的独立机器上第二给 Harness 容器加上 mem_limit 4g让它不会和模型推理争抢资源。改完之后再遇到并发高峰最多只是响应变慢不会再整段 502。这个案子给我最大的教训是容器化不等于自动隔离多服务共宿主机时资源必须显式划分否则互相挤兑造成的故障比单机部署更难排查。5.2 长上下文把 token 消耗撑爆了另一个同事反馈的问题是聊到后面模型变笨了。排查下来不是模型效果退化而是会话越聊越长历史消息全部叠加进上下文token 消耗越来越大单次请求耗时越来越长模型反而被大量历史信息淹没。解决方式就是前面配置文件里提到的 max_history_messages。我把它从默认值调低到 40 之后日常对话场景的响应速度明显改善。对于需要长上下文的场景比如完整分析一份文档我建议单独建立文档分析会话把历史消息限制放宽而不是所有对话都用一个无限长的上下文。后来我养成一个习惯每周在管理端导一次各会话的 token 统计看哪些会话消耗异常高。某个会话一个月涨了几百万 token大概率是上下文没清理及时发现能省掉不少成本。5.3 日志增长和磁盘告警部署完一个月左右磁盘告警把我从午休中吵醒。查下来最大头不是模型权重而是 Harness 加 Nginx 的应用日志加起来占了十几 GB。处理方式不复杂日志按天切割保留最近 14 天Nginx access_log 只保留关键信息或者直接关闭访问日志Harness 内部的 debug 日志调整为 info 级别。调整之后磁盘占用降到一个可控范围内再也没出现过类似告警。小建议日志轮转策略最好在部署第一天就写进配置不要等服务跑一段时间再回来清理。日志文件不像代码不会有版本管理它只会在你处理故障的时候突然占满磁盘。提前配好一劳永逸。5.4 安全边界端口别裸奔密钥别入库最后说安全。这部分我不展开太多只强调几个我守住的红线。第一Harness 和 Ollama 的端口都绑定 127.0.0.1不直接对局域网开放所有外部访问必须走 Nginx。第二模型供应商的 API key 只放在 .env 文件里Compose 通过 env_file 加载绝不放 Git 仓库。第三Harness 管理后台开启二次验证防止管理员密码泄露后被人改全局配置。第四data 目录和 SQLite 文件要定期备份和数据库备份一起跑防止会话记录和团队积累的知识资产丢失。如果团队对安全有更高要求还可以接入公司的统一身份认证做更细粒度的权限控制。这个按需来不是必须。我把 DeepSeek Harness 部署到服务器这件事复盘下来最大的收获不是把服务跑通了而是找到了一条把大模型能力转化为团队基础设施的路径。工具能被同事们主动玩起来靠的是稳定的服务、顺手的工作流和平滑的权限管理少一环都会打折扣。后续我打算把团队常用的提示词模板整理成版本化文件再接入内部知识库让模型能引用团队自己的历史文档。如果你也在做类似的尝试建议先小范围跑两周收集真实反馈后再放开给更多人用这个节奏比一上来全量推广稳妥得多。