那个想法其实很偶然。上周五下午我清理公司一台闲置服务器顺手把 DeepSeek Harness 部署了上去然后把内网访问地址往部门群里一丢。本来只想着自己测试用结果从下午三点开始群消息就没停过——同事们真的玩嗨了。有人拿它写周报有人拿它改 SQL还有人直接把 Excel 里的业务逻辑粘贴进去让 AI 解释。这篇文章就是把整个从零到一的过程完整记录下来服务器怎么选、Linux 环境怎么准备、DeepSeek Harness 怎么安装和配置、模型怎么接入、多用户权限怎么设计、上线之后又踩了哪些坑。信息量比较大建议先收藏再慢慢看。如果你也想在公司内网搭一套“团队都能用”的大模型服务这篇应该能帮你省掉至少两天的试错时间。1. 项目到底要做成什么样需求来源、方案选型与整体架构动手之前我先把“要解决什么问题”想清楚了。这一步看起来不产生代码但恰恰是整套方案能顺利落地的关键。1.1 为什么会有这个想法最初的需求其实特别朴素团队里越来越多的同事想用大模型辅助工作但大家面临同样的困境。第一个人电脑跑不动。部门同事用的多是 Windows 笔记本很多还是 16G 内存、无独显的配置。随便跑一个 7B 参数模型推理速度都慢到让人怀疑人生更别提 14B、32B 这种实用级别的大模型。第二外部在线平台有顾虑。一些同事确实在用各种公开的 AI 网站但聊天内容要经过第三方服务这在涉及内部项目细节、客户数据、未公开方案时很多人心里没底。不是说一定出事而是“数据不出内网”这条底线一旦被突破后面解释成本极高。第三协作场景被忽略了。AI 工具如果只停留在个人电脑上大家各用各的交流起来很麻烦。A 同事发现一个好用的 promptB 同事不知道C 同事调试半天的参数D 同事还要从头试。如果能有一个团队共享的入口模型、配置、插件、历史记录都可以统一管理价值会大得多。所以我想做的不是一个“又一套聊天界面”而是一个对内开放的小型 AI 服务中心统一登录、统一权限、统一模型管理、统一日志。DeepSeek Harness 这个项目很自然地进入了视野。1.2 方案对比为什么是 DeepSeek Harness当时我对比了四条技术路线方案优点缺点适合场景裸装推理引擎vLLM / llama.cpp性能最好控制力最强没有界面没有用户体系每个人要自己拼前端只想自己用、熟悉命令行的开发者通用 ChatUI 推理后端如 Open WebUI Ollama界面成熟部署快用户权限、会话隔离、API 管理偏弱插件生态需要自己折腾小团队快速跑起来自研一套 Web 前端完全可控开发成本高前端和安全都得自己扛有专门研发预算能做长期迭代DeepSeek Harness用户体系、多模型接入、会话隔离、插件机制、API 兼容层都内置了需要花时间读文档项目还在快速迭代想一次性搭好团队可用的平台后续还有插件扩展需求我最终选择 DeepSeek Harness核心原因是它把“模型推理”和“对外服务”这两层解耦了。推理引擎只负责高效计算而 Harness 负责对外的一切浏览器界面、账号体系、会话管理、权限控制、用量统计、模型切换。这样后期如果想把推理后端从 Ollama 换成 vLLM或者新增一张显卡都不需要动面向用户的那一层。另一个加分项是它有插件机制。同事上线后提了一堆需求——联网搜索、知识库问答、企业微信机器人——这些都能通过插件扩展而不是每次都要改主程序重新部署。1.3 一句话看懂整体架构整套系统跑起来之后的结构是这样的用户的浏览器请求先进到内网 Nginx 入口入口把请求转发给 DeepSeek Harness 服务Harness 负责处理登录、权限、会话逻辑再把推理请求交给后端的模型服务Ollama 或 vLLM模型从本地磁盘读取权重文件把结果一段一段地流式返回。数据流看起来简单但每一层都有讲究。比如入口层必须支持 WebSocket 和流式传输否则前端对话会“转圈圈”Harness 层必须做并发控制否则 50 个人同时提问显卡会直接爆显存模型服务层要选对推理引擎否则同样的显卡生成速度能差三四倍。部署形态上我没有搞分布式集群。公司这台服务器就是一台双路工作站级别的机器把所有服务都放在同一台机器上网络开销最小运维也最简单。等以后并发真的上来了再把 Harness、模型后端分离到不同机器也来得及架构上不用推翻重来。2. 服务器准备硬件、系统、网络的三步走很多人装了半天软件发现跑不动问题往往出在硬件预估和系统环境上。这一节把我在准备阶段做的事完整列出来。2.1 硬件配置怎么定内存和显存计算大模型部署最看重的不是 CPU而是显存。显存不够模型根本加载不进去。我习惯用这个公式粗略估算模型显存占用约等于“参数量 × 每参数所需字节数”然后再加上推理时的 KV Cache 开销。以 FP16 半精度为例每个参数大概占 2 个字节如果做 4bit 量化每个参数约 0.5 到 0.6 个字节。模型参数量FP16 理论显存4bit 量化理论显存7B约 14GB约 4-5GB14B约 28GB约 8-10GB32B约 64GB约 18-20GB实际运行时还要给上下文窗口、并发请求预留显存所以建议把上表数字再乘 1.3 到 1.5。我们最终用的是服务器上已有的两张 RTX 3090 24G 显卡单张卡跑 14B 量化模型绰绰有余两张卡分别加载不同模型一个给日常问答一个给复杂推理。CPU 和内存也不能太寒酸。模型加载进显存前要先把权重文件读进内存所以 128G 内存很舒服最低建议也要 32G。CPU 核心数影响并发处理能力我们这台机器有 32 个核心实际跑下来 20 人并发很轻松。如果公司没有 GPU 服务器也不是完全不能玩。纯 CPU 跑 7B 量化模型也能出结果但速度会比较慢我实测大概是每秒 3-5 个 token适合三五个人内部体验不适合做团队正式服务。2.2 Linux 系统与基础环境初始化系统我选了 Ubuntu 22.04 LTS Server 版。LTS 版本维护周期长软件源里的包也比较全适合服务器场景。装完系统第一件事是 SSH 远程连接检查。我习惯用 VSCode 的 Remote-SSH 插件连上去改配置图形界面和终端一体改文件、查日志都方便。连接命令很简单在 VSCode 里配置好 SSH 目标主机就能像在本地开发一样操作远程服务器。基础环境初始化我按下面这个顺序做# 1. 更新软件源 sudo apt update sudo apt upgrade -y # 2. 创建专用运行用户避免用 root 跑服务 sudo useradd -m -s /bin/bash harness sudo passwd harness # 3. 安装基础工具 sudo apt install -y curl git vim htop net-tools # 4. 检查 NVIDIA 显卡驱动 nvidia-smi如果nvidia-smi没输出说明驱动没装好。可以用ubuntu-drivers devices查看推荐版本然后执行sudo ubuntu-drivers install自动安装。装完重启再跑一次nvidia-smi确认。GPU 服务器还建议装好时钟同步服务避免因为时间偏差影响日志排查和证书校验sudo apt install -y chrony sudo systemctl enable chrony sudo systemctl start chrony另外提一句安全习惯。我开了系统自带的防火墙只放行 SSH 和后续要用的服务端口。SSH 端口我也从默认的 22 改成了高位端口虽然内网环境威胁没那么大但这个习惯能省去很多不必要的暴力扫描。2.3 网络与服务暴露方式的三个选择服务部署好之后网络层面有三个常见选择我按推荐程度排个序。最推荐的做法是服务进程只监听本机回环地址然后由内网 Nginx 统一转发出去。比如 DeepSeek Harness 监听 127.0.0.1:8080Nginx 监听 8000 端口对外提供服务同时负责 HTTPS 证书、请求大小限制、流式传输缓冲等。好处是服务本身不直接暴露端口攻击面小而且后续加域名、加证书、配置转发的空间都很大。第二种做法是直接把服务端口暴露在服务器所有网卡上同事用“http://服务器IP:端口”访问。优点是省事缺点是端口管理混乱服务多了容易冲突也没有统一的域名入口证书更难配。第三种做法是把服务映射到公网。除非你有严格的防火墙策略和明确需求否则不建议这么干。大模型对话服务天然包含了大量内部信息和对话数据公网暴露等于把数据放在门口风险完全不可控。内网域名我用的是ai.internal.local只在公司内网 DNS 里做了解析。证书用内网 CA 签发的自签证书同事电脑上第一次访问时手动信任一下就行。HTTPS 在 HTTP/2 和 WebSocket 场景下有明显优势值得花十分钟配好。3. 从装到跑DeepSeek Harness 安装与模型接入实录这一节是整个实操过程的核心。我会把手上的动作、为什么这么做、踩过什么坑都写清楚。3.1 安装前要确认的几件事安装 DeepSeek Harness 之前先把三件事想好避免装到一半返工。第一用 Docker 还是源码运行。如果你只是想让团队用起来我强烈建议用 Docker Compose一条命令把 Harness、依赖服务全部拉起来升级也方便。如果你打算做插件开发或者要改核心源码那用源码方式跑更好代码改动可以即时生效。我们生产环境用 Docker开发环境用源码两边互不干扰。第二数据和模型目录要提前规划。我把 Harness 的数据目录放在/data/harness模型文件放在/data/models日志放在/data/logs。这样备份的时候只要打包一个/data目录就够了不会漏东西。第三端口规划。Harness 主服务用 8080Ollama 用 11434vLLM 用 8000Nginx 对外用 80/443。这些端口提前定好避免后面多个服务抢端口。3.2 安装 DeepSeek Harness推荐 Docker Compose 方式我在服务器上创建了一个/opt/harness目录里面放docker-compose.yml内容大概长这样services: harness: image: deepseek-harness:latest container_name: deepseek-harness restart: unless-stopped ports: - 127.0.0.1:8080:8080 volumes: - /data/harness:/app/data - /data/logs:/app/logs - /data/models:/models environment: - HARNESS_AUTH_MODElocal - HARNESS_DATA_DIR/app/data - HARNESS_LOG_DIR/app/logs - HARNESS_MAX_UPLOAD_SIZE100这里注意两点端口我专门写成了127.0.0.1:8080:8080也就是只允许本机访问外部只能通过 Nginx 入口转发进来这个习惯能减少很多安全问题。HARNESS_MAX_UPLOAD_SIZE100是把上传附件大小限制提高到 100MB不设置的话默认值往往只有几 MB同事传个 CSV 或 PDF 就会失败。启动命令很简单cd /opt/harness docker compose pull docker compose up -d docker compose logs -f看到启动日志里出现类似“listening on 0.0.0.0:8080”的提示后说明服务起来了。第一次访问页面系统会引导你创建管理员账号然后就可以登录后台了。用源码方式跑也不复杂基本流程是切到 Python 3.10 环境安装依赖改配置文件然后用python -m deepseek_harness启动。这块我建议真正需要二次开发的人再去尝试纯使用场景没必要折腾。3.3 接入 DeepSeek 模型Ollama 和 vLLM 两条路Harness 本身不直接运行大模型它需要对接一个推理后端。我同时测试了 Ollama 和 vLLM 两条路线。Ollama 的优势是简单一条命令就可以拉模型跑起来# 安装 Ollama如果还没装 curl -fsSL https://ollama.com/install.sh | sh # 拉取 DeepSeek 系列模型 ollama pull deepseek-r1:14b ollama pull deepseek-r1:7b拉完之后在 Harness 后台的“模型设置”里添加一个 OpenAI 兼容的 Provider地址填http://127.0.0.1:11434/v1模型名填deepseek-r1:14b就能开始对话了。vLLM 则是为高并发高性能设计的推理引擎更适合正式线上环境。它的启动命令稍微复杂一些vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--gpu-memory-utilization 0.9表示允许模型使用 90% 的显存留出一部分给 KV Cache 和临时请求。--max-model-len 8192控制最大上下文长度既能满足大部分日常工作场景又不至于把显存吃光。在 Harness 里添加 vLLM Provider 时接口地址填http://127.0.0.1:8000/v1。Harness 会通过 OpenAI 兼容协议和 vLLM 通信所以理论上 vLLM、Ollama、甚至远程的推理集群都可以无缝接入。我实测下来同一个模型在 vLLM 上吞吐大约是 Ollama 的 2-3 倍尤其在多用户并发场景下优势非常明显。所以我们的最终方案是日常并发入口走 vLLM备用调试用 Ollama。如果你团队并发不超过 5 个人Ollama 完全够用不用上 vLLM。3.4 多用户、权限、会话隔离和基础配置服务跑起来只是第一步真正让“同事们一起用”的关键在用户权限和会话管理。我在 Harness 后台开启了本地账号注册同事第一次访问时自己注册一个账号就行。但注意我默认把新用户的角色设为“普通用户”而不是管理员。普通用户只能使用模型、管理自己的会话管理员才能改全局设置、看系统日志、管理其他人的账号。权限上还做了一件事按角色划分可用模型。管理员可用全部模型包括 32B 大模型普通用户默认只能用 7B 和 14B 模型。这样既保证了高级模型的体验也避免普通用户一上来就用大体量模型把资源占满。会话隔离是哈ness 默认就有的能力每一个用户的对话历史只对自己可见互不干扰。这一点在团队环境里特别重要不然 A 同事问的东西被 B 同事看到那就尴尬了。另外还配了每日限额每个普通用户每天最多 200 次请求每次生成最多 2048 个 token。这个数字看起来大但对日常工作完全够用同时又防止个别人跑批处理脚本把服务器拖垮。上线到现在这个限额没有一个人触发过。4. 同事玩嗨了上线一周的真实使用场景复盘技术部署只是前半场真正有意思的是后半场——看一群非技术背景的同事怎么玩起来。4.1 上线当天的名场面我把访问地址和一句使用说明“内部 AI 工具如需模型回复请注意核对准确性”发到部门群后三分钟内就有同事注册了。下午五点左右群里开始出现各种截图。有人让 AI 把一段需求描述改成标准 PRD 格式有人让 AI 解释一份陌生代码的逻辑还有人让 AI 帮忙写了一个复杂的 Excel 公式。真正把氛围推向高潮的是一位同事把一份残缺的数据表贴进去让 AI 猜测字段之间的关联AI 居然给了一段能直接跑的数据清洗 Python 脚本。当天晚上我看后台日志在线用户数最高 34 人产生了 1100 多次对话。这个数字有点超预期因为我只把链接发在了 40 多人的部门群里。第二天开始有同事主动把链接转发到了其他部门群服务器负载明显上来这也是我为什么后面专门做了并发优化和限额。4.2 四个真实使用场景用了一周后我统计了一下对话记录使用场景高度集中在四类。代码相关是最多的占比接近四成。同事写脚本、调试接口、分析日志时会把报错信息或者一段代码直接丢给 AI。我用的是 14B 量化模型配合 vLLM 并发推理单次响应大约 1-3 秒实测生成速度在 50-80 token/s体验很接近本地 IDE 里的 AI 插件。数据处理和 SQL 查询排在第二位。业务同事经常要写复杂查询把数据字典和需求描述扔进去AI 能生成可运行的 SQL准确率在七八成以上。虽然不能完全不用人检查但已经比从零写快多了。办公文书是第三大场景包括周报润色、邮件草拟、会议纪要整理。这类任务对模型能力要求不高7B 模型就处理得很好响应快成本低。还有一小部分人拿它做百科问答和思路碰撞。不要小看这类使用它让团队慢慢形成了“先问 AI、再问同事”的习惯很多重复性答疑被 AI 承接了。4.3 同事提的新需求上线三四天后群里陆续有人提新需求归纳下来主要有四类。第一是联网搜索。想让 AI 查到最新的外部信息而不只是靠训练数据。第二是知识库接入把公司内部文档、产品手册、历史方案做成可以检索的 RAG 知识库。第三是手机端访问有人希望通勤路上也能随手查一下。第四是企业微信机器人想直接在聊天软件里调用 AI。这些需求验证了当初选 DeepSeek Harness 的判断——它带了插件机制以上四类需求基本都能通过插件或者 API 接入实现不需要重新开发主程序。我现在重点在研究 RAG 和知识库这块对团队价值最大。5. 运维避坑常见问题、性能调优与数据安全服务上线一周多踩了不少坑也积累了一些可复用的运维经验。这一节可能是对实际部署最有参考价值的部分。5.1 性能调优的三个有效动作并发上来之后第一天下午就遇到了响应变慢甚至超时的情况。我做了三个调整效果立竿见影。第一把推理后端换成 vLLM并确保启用了连续批处理continuous batching。Ollama 在并发多时排队现象明显因为一个请求没答完下一个请求只能等着。vLLM 能把多个请求动态拼进同一个批次GPU 利用率大幅提升。换完之后同样人数并发整体吞吐提升了约两倍。第二入口 Nginx 关闭了缓冲开启流式传输。AI 对话是边生成边返回的如果 Nginx 默认缓冲用户要等整个回答生成完才看到内容体感会非常差。我在 Nginx 配置里显式关闭了代理缓冲location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_buffering off; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }这里Upgrade和Connection是给 WebSocket 用的AI 对话的实时流式输出依赖它。proxy_buffering off让内容生成多少就回传多少用户感知到的“打字机效果”立刻出来了。第三限制并发和额度。在 Harness 后台把单用户并发请求数限制在 2全局并发限制在 24。这样即使有人跑批量任务也不会把所有人的体验拖垮。再配合之前说的每日请求限制服务器资源整体可控了。5.2 常见问题速查表我把这段时间遇到的典型问题整理成了一张速查表供参考。现象可能原因解决办法页面能打开但对话一直转圈Nginx 没配 WebSocketUpgrade 头没转发检查proxy_set_header Upgrade $http_upgrade;和Connection upgrade上传 CSV/PDF 文件失败Nginx 默认限制请求体大小为 1MB在 Nginx 配client_max_body_size 100m;部分用户访问很慢单卡显存被打满请求在排队换 vLLM 连续批处理或限制全局并发生成内容中途断开请求超时时间太短调大proxy_read_timeout模型侧同时加长超时服务器重启后服务没起来Docker 容器没有设置自动重启容器配置加restart: unless-stopped显存 OOM 报错并发太高或模型加载过多降低单卡并发数或者换更小量化模型对话内容串到别的用户没有开启会话隔离在 Harness 后台确认用户空间隔离已开启关于 OOM 多说一句。vLLM 进程如果 OOM它会直接崩溃退出而不是报错后自己恢复。所以我在服务器上写了一个简单的守护脚本每分钟检查一次 vLLM 端口是否还在监听不在就自动拉起。上线这一个多星期这个脚本已经自动重启了两次每次都在我还没来得及发现的时候就恢复服务了。5.3 数据安全与备份习惯内部 AI 工具最敏感的就是数据。我们的原则是把它和其他生产业务系统同等对待。聊天记录默认存储在本地的/data/harness目录里我每天凌晨用 crontab 打包上传到内网备份存储保留最近 30 天。整个备份脚本十几行但能让人睡得踏实很多#!/bin/bash backup_dir/backup/harness/$(date %Y%m%d) mkdir -p $backup_dir tar -czf $backup_dir/data.tar.gz -C /data harness find /backup/harness -type d -mtime 30 -exec rm -rf {} \;权限管理上只有管理员能通过后台查看用户列表和全局日志。普通用户只能看到自己的会话记录。服务本身绑定在 127.0.0.1外部流量全靠内网 Nginx 入口转发公网层面上这台服务器没有暴露任何管理端口。另外提醒一句模型生成的内容一定要有人工审核环节尤其是直接对外使用的场景。我们内部达成一个约定AI 回复可以作为初稿和参考但发出前必须人工确认。这个约定比任何技术手段都管用。5.4 后续扩展方向这套系统目前还只发挥了 DeepSeek Harness 的一部分能力后续的扩展方向我大概列一下。第一是接入知识库。把团队多年积累的文档、方案、代码片段做成向量索引让对话时能基于内部资料回答。第二是接入企业微信做成一个机器人让没开网页习惯的同事也能用。第三是做更细的权限分级比如某些敏感模型只开放给特定项目组。第四是接入监控和告警把 GPU 利用率、请求量、响应时延都做成仪表盘异常时自动通知管理员。目前这些扩展都有对应的插件或者接口可以对接整体架构不用大改。这也是我复盘之后觉得最满意的地方——当初没贪快把根基打对了。最后再说一点个人体会。这套东西部署本身真的不难难的是后续对并发、权限和数据边界的持续管理。如果你也想给团队搭一套我的建议很简单先把硬件算明白不要拍脑袋选模型再尽量用 Docker Compose 方式部署后面升级维护都省心最后一定提前想好用户权限和备份策略别等服务火了手忙脚乱。项目跑起来之后每天看到同事在群里分享新用法那种成就感挺实在的。