我把 DeepSeek Harness 部署到公司服务器上这事原本只是为了解决“团队里每个人都抱着自己的笔记本跑本地模型”的混乱局面结果部署完第二天同事群就炸了连行政都在问怎么申请账号。这篇就把我这次从选型、装环境、跑通到给团队开放使用的完整过程写下来包括每一步为什么这么做、踩了哪些坑、哪些配置改完立刻见效想在自己服务器上搭一套的朋友可以直接照着抄作业。DeepSeek Harness 说到底就是一套把 DeepSeek 系列模型服务化的部署管理工具它把模型加载、推理引擎、Web 对话界面、API 网关、多用户权限这些原本要自己拼装的东西打包成了一个整体。对内网团队使用来说它最大的价值不是跑分有多高而是装完之后同事们只需要打开浏览器输入地址就能用不用关心模型文件、显存、进程这些底层细节。我这次部署主要用到的环境是 Ubuntu 22.04、一块 24G 显存的显卡、Docker Compose 编排模型选的 DeepSeek 系列量化版。下文会把我怎么算显存、怎么下载模型权重、怎么写编排文件、怎么配置用户权限全部拆开讲也会附带我把服务开放给同事后遇到的一系列实际问题。1. 为什么要把 DeepSeek Harness 放到服务器上1.1 从“每人一台本地模型”到“一套团队服务”先说最开始的问题。我所在的小组经常要做文本总结、代码解释、文档润色这类事情之前同事们的方案五花八门有人用 Ollama 在笔记本上跑小模型有人直接调外部 API还有人在自己电脑上装各种 WebUI。表面看大家都有工具用实际上问题一堆。最直接的问题是资源浪费。同一个 7B 模型组里五六个人各自下载一份每人的笔记本都被拉得风扇狂转真到用的时候内存和显存又不够。然后是模型版本不统一有人用 7B有人用 14B量化方式也不一样同样的问题问出来的答案风格差别很大。外部 API 还有数据安全方面的顾虑公司内部的一些文档内容不方便直接送去第三方服务。把模型服务统一部署到服务器上再通过 DeepSeek Harness 提供一个统一入口本质上就是把这些分散的尝试收拢成一套内部基础设施。一个人维护所有人使用底层模型、参数、版本完全一致行为可预期资源利用率也提高了很多。1.2 为什么不是 Ollama、vLLM 或者直接裸跑推理脚本可能有人会问部署大模型服务的工具那么多Ollama 足够简单vLLM 性能又强为什么选 DeepSeek Harness。我的理由很务实我需要的不只是一个能跑模型的进程而是一个能直接给非技术同事使用的服务。Ollama 本身确实简单一条命令就能把模型跑起来但它默认的定位更像单机模型管理工具多用户权限、前端界面、API Key 管理都需要另外再搭东西。vLLM 在高并发推理场景下吞吐表现很好但它是给偏底层集成准备的团队里几个同事连 Python 环境都不想折腾你让他们直接对着 OpenAI 兼容接口写代码不太现实。自己写推理脚本就更不用提了模型加载、显存管理、并发排队、前端页面每一项都是工作量。DeepSeek Harness 相当于把这些东西整合好之后又加了一层适合小团队使用的管理界面。既有 Web 聊天界面也有兼容多种调用方式的 API 入口还能分用户、分权限这正好卡在“开箱即用”和“灵活扩展”之间的平衡点上。对我这种要同时服务开发同事和普通同事的运维角色来说少拼一个组件就少一个维护负担。1.3 部署形态与适用范围这次我采用的是单机部署一台 24G 显存显卡的服务器通过 Docker Compose 跑整套服务模型文件放在独立数据盘上。这个部署方式比较适合 100 人以内的小团队日常同时在线人数在几十人左右任务以文本对话、总结、代码辅助为主。如果你的团队规模更大或者需要同时跑多个超大参数模型那就得考虑多机部署、模型并行或者接入专业的推理加速框架。不过绝大多数公司的内部使用场景单机加一块大显存显卡就够用了。先跑起来再谈扩展这是最稳的路径。部署形态上我强烈建议一开始就用容器化方案。DeepSeek Harness 的依赖链不算短涉及 Python 环境、CUDA 版本、推理框架、前端资源直接装在宿主机上很容易出现“这台机器能跑、换台机器跑不起来”的问题。用 Docker 做编排整个服务对环境是隔离的后面迁移服务器、升级版本都轻松很多。时间服务器、服务器虚拟化这些周边设施可以先不用管先把核心跑通。2. 服务器准备与部署方案选型2.1 硬件选型与显存估算部署大模型服务第一道坎永远是显存。选服务器配置之前先想清楚准备跑哪个规模的模型。DeepSeek 系列有不同参数规模的版本我这里把几个常见档位对应的显存需求整理成一个估算表供大家参考模型规模FP16/BF16 权重显存Int8 量化Int4 量化建议最低显存7B约 14GB约 7-8GB约 4-5GB12GB14B约 28GB约 14GB约 9GB16GB32B约 64GB约 32GB约 20GB24GB注意这只是模型权重占用的空间实际运行还要算上 KV Cache、CUDA context、推理过程中的中间张量。我个人的经验是显存规划要比权重占用多留 20% 到 30% 的空间否则并发一上来就会 OOM。这次我选择的是 14B 模型的 Int8 量化版权重占 14GB 左右加上推理开销24G 显卡能比较舒服地跑起来还能同时服务多个人。如果你预算有限只有 12G 显卡老老实实跑 7B Int4 或 Int8体验会比硬上大模型好得多。显存是硬约束不要抱侥幸心理。2.2 软件栈系统、驱动、容器运行时服务器系统我用的是 Ubuntu 22.04 LTS。选它的原因很实际NVIDIA 驱动和 CUDA 生态对 Ubuntu 的支持最好相关的容器镜像也最多遇到问题搜解决方案最容易。NVIDIA 驱动建议装 535 或更新版本然后在宿主机上装好 NVIDIA Container Toolkit。这个工具是让 Docker 容器能访问 GPU 的关键一环很多新手在这步翻车。装完之后可以用nvidia-smi确认驱动正常再用一个简单的容器测试 GPU 是否透传成功docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能看到显卡信息就说明容器里能正常调用 GPU。这步搞定后面部署 DeepSeek Harness 就顺了。另外还要确认 Docker 版本在 24 以上旧版本对 GPU 设备和 Compose 文件的支持都有不少坑。2.3 模型权重下载与校验模型文件是最大的体积来源一个 14B Int8 模型动辄十几 GB下载和存放路径都得提前规划。我建议单独准备一块数据盘放模型比如挂载到/data/models不要放在系统盘。原因很简单模型文件占用空间大如果你后面想同时保留多个版本的模型系统盘很快就会爆掉。而且系统盘一旦满了服务器各种服务都会出问题。下载模型权重我优先用 ModelScope在国内网络环境下速度明显比 Hugging Face 稳。下载完不要急着直接用先做一次文件大小和哈希校验确认文件完整。这一步能省掉后面“模型加载到一半报错”的很多烦恼。模型文件放好后目录结构最好保持清晰。我是这样组织的/data/models/ └── deepseek-14b-int8/ ├── config.json ├── model-00001-of-00007.safetensors ├── ... └── tokenizer.json这样后面在 DeepSeek Harness 里指定模型路径时一目了然往里加新模型也不会乱。3. 从零开始部署 DeepSeek Harness3.1 安装 Docker 与 NVIDIA Container Toolkit部署的第一步是在服务器上装好基础运行环境。我用的是 Docker Engine 和 Docker Compose 插件的方式具体命令如下# 安装 Docker Engine curl -fsSL https://get.docker.com | bash # 启动并将当前用户加入 docker 组 sudo systemctl enable --now docker sudo usermod -aG docker $USER # 安装 NVIDIA Container Toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker这里有几个容易踩的点。第一装完 Docker 后要重新登录 SSH 会话docker组权限才会生效。第二NVIDIA Container Toolkit 装完必须重启 Docker 守护进程否则容器里识别不到显卡。第三如果服务器上有旧版本 Docker建议先彻底卸载干净再装新的避免配置残留冲突。3.2 编写 docker-compose 编排文件DeepSeek Harness 推荐用 Docker Compose 方式部署我用的编排文件大致长这样version: 3.8 services: deepseek-harness: image: deepseek-harness:latest container_name: deepseek-harness restart: unless-stopped ports: - 8080:8080 volumes: - /data/models:/models - /data/harness-data:/app/data environment: - MODEL_PATH/models/deepseek-14b-int8 - MODEL_TYPEdeepseek - QUANTIZEint8 - NUM_GPU1 - MAX_CONCURRENT10 - DEFAULT_USER_QUOTA500 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] logging: driver: json-file options: max-size: 50m max-file: 5这里面我单独解释几个关键配置。MODEL_PATH指定模型目录容器内统一映射到/models这样以后换模型只需要改环境变量。NUM_GPU表示使用几张显卡单卡服务器固定为 1。MAX_CONCURRENT是最大并发请求数这个参数直接决定了显存会不会被撑爆我后面会单独讲怎么调。DEFAULT_USER_QUOTA是给每个用户设置的每日调用次数配额这是给团队开放服务后防止被几个人刷爆的关键。日志限制也要加上不然大模型服务的日志增长速度快得吓人几天就能写满磁盘。3.3 配置模型路径、显存与访问端口编排文件写好后在真正启动之前还有几个配置要确认。首先是模型路径。我的模型放在宿主机/data/models下通过 volume 映射到容器/models。这里有个细节宿主机目录权限最好设置成 755否则 Docker 容器内的用户可能读取不到模型文件启动时会报权限错误。其次是显存相关配置。第一次启动时不要贪心把并发数设得太高先用MAX_CONCURRENT4跑一轮测试观察显卡显存占用情况再逐步往上加。如果一上来就把并发调到 2014B Int8 模型很可能会直接 OOM服务崩溃后所有同事都会来找你。访问端口默认用 8080。如果服务器上已经跑了 Nginx 或者其他 Web 服务建议换一个不冲突的端口比如 18080。端口冲突这个问题看着小实际操作中特别常见因为很多开发者习惯 8080 已经被占用了也不查启动半天发现端口起不来。3.4 启动服务与验证配置完成后进入编排文件所在目录执行docker compose up -d首次启动会拉取镜像、初始化数据可能需要几分钟时间。可以通过日志观察启动进度docker compose logs -f deepseek-harness看到类似Model loaded successfully、Server started on 0.0.0.0:8080的日志就说明跑起来了。这时候先别急着打开浏览器先用命令验证一下服务状态curl http://localhost:8080/api/health返回 JSON 格式的正常状态信息就代表服务是通的。再确认一下显卡占用nvidia-smi能看到python进程占着显存就说明模型确实加载到 GPU 里了。如果这里看不到显存占用那多半是容器没有正确访问到 GPU回头检查 NVIDIA Container Toolkit 的安装。3.5 初始化管理员与基础设置服务启动成功后打开http://服务器IP:8080会进入初始化页面。第一步是创建管理员账号这个账号用来管理整个 Harness 实例包括用户、模型、配额、API Key 等等。管理员账号创建后我建议立刻做三件事。第一修改默认的访问端口绑定如果服务不是只给内网少数人用。第二开启登录认证避免局域网内任何能访问到该端口的人都直接使用服务。第三在管理界面里把“新用户注册”关掉改为由管理员手动创建账号。之所以强调这三点是因为我把服务开放给团队后第一天就发现同事之间会互相转告地址如果开放注册很快就会有不相干的人涌进来资源占用直线上升。手动创建账号虽然看起来麻烦一点但能确保每个使用者都知道自己在用什么出问题也知道找谁。4. 团队接入后的调优与日常维护4.1 合理选择量化等级别盲目追求最大模型服务上线后同事的第一反应往往是能不能跑一个更大的模型我的建议是在个人体验和团队可用性之间找平衡而不是一味追求参数规模。量化等级对显存占用影响非常大。同样是 14B 模型FP16 需要 28GBInt8 只要 14GBInt4 更夸张9GB 就能跑。量化带来的质量损失在日常文本处理任务里并不明显但显存节省是实打实的。把省下来的显存留给并发和上下文长度对团队整体体验的提升比硬上大模型更明显。我实际对比过同一个 14B 模型的 Int8 和 Int4 版本在摘要、改写、基础问答这类任务上差距很小。Int8 因为保留了更好的数值精度复杂推理和代码生成质量会稍好一些所以我最终选了 Int8。如果你的显卡只有 12G那就老实选 7B Int8 或者 14B Int4。4.2 并发、限流与多用户权限团队接入后最大的挑战不是模型能力而是多人同时用的时候怎么保证服务稳定。这里我要重点讲并发数这个参数。MAX_CONCURRENT设置的是同时处理的请求数量。假设你的显卡跑一个推理请求需要 2 秒、占用 10GB 显存那并发设置为 4 就意味着最多同时处理 4 个请求显存峰值大约 40GB 左右再加原有模型权重总占用会非常接近显存上限。实际设置时要留足缓冲把并发设为 4但显存余量要按 2 倍请求占用预留。更稳妥的做法是先设为 2压测没问题再逐步提高。配合并发控制我还给每个账号设置了每日调用配额。这招非常管用。之前没有配额的时候有同事写了个脚本批量处理几千条文本直接把服务堵死其他所有人都用不了。加了配额之后单用户最多一天调用 500 次对正常使用完全够用但能挡住无意识的扫库行为。用户权限这块DeepSeek Harness 区分管理员和普通用户。普通用户只能使用对话和 API不能修改系统配置。给外部协作的同事创建账号时一定只给普通权限。API Key 也要单独管理让开发者用独立的 Key 接入不要共用一个。4.3 通过 Nginx 做反向代理与内网域名直接通过 IP 加端口的方式访问不是不行但长期用会有几个问题。一是所有同事都要记一个带端口的地址二是如果后面要加 HTTPS 证书端口方式配置起来很别扭。我建议在服务器上加一层 Nginx 反向代理用一个内网域名指向 DeepSeek Harness 服务。Nginx 配置大致如下server { listen 80; server_name ai.internal.example.com; client_max_body_size 50m; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }关键配置是client_max_body_size如果同事要上传文档让模型处理默认的 1MB 限制根本不够我直接调到了 50MB。加完反向代理后同事只需要访问一个简单的域名HTTPS 证书也可以由 Nginx 统一管理后面想切换端口、升级服务都不会影响使用。4.4 监控与日志出事前先发现服务跑起来之后不是万事大吉。大模型服务是资源大户一个异常请求就可能把显存吃满。我平时主要盯三样东西显存、磁盘、日志。显存监控用nvidia-smi但加个定时循环比如watch -n 5 nvidia-smi这样每隔 5 秒刷新一次显存和 GPU 利用率。磁盘方面模型文件加日志增长很快我写了一个简单的磁盘告警脚本当使用率超过 85% 就发消息提醒。日志方面Docker 的 json-file 日志驱动我已经限制了单文件 50MB、最多保留 5 个文件避免日志无限增长。如果团队对稳定性的要求更高可以再引入 Prometheus 加 Grafana 做监控面板不过这属于加分项小团队前期没必要一上来就上全套。5. 常见问题与排查技巧实录5.1 高频问题速查表部署和使用过程中我整理了一份高频问题速查表基本覆盖了团队使用一个月的求助记录现象可能原因处理方式容器启动后 nvidia-smi 看不到 GPUNVIDIA Container Toolkit 未正确安装或未重启 Docker重装 toolkit执行sudo systemctl restart docker模型加载到一半进程被杀显存不足换更小的量化模型降低并发数API 返回 429 错误用户超出配额在管理后台提高配额或等待次日重置页面打开很慢首次加载模型权重需要时间确认模型是否已预热或在配置里开启常驻内存磁盘写满日志和模型文件占用过高清理旧日志限制日志文件大小多人同时使用时响应变慢并发数设置过高导致排队或频繁切换降低最大并发数给单用户加配额这张表我打印出来贴在了服务器机柜旁边同事遇到问题先自己查一下很多小问题不用专门找我。5.2 一次典型排查过程GPU 利用率上不去这里分享一次实际排查过程。有次同事反馈一句话要等 20 多秒才回复但我看nvidia-smi发现 GPU 利用率只有 30% 左右明显不对劲。排查路径是这样的。先看 DeepSeek Harness 日志确认有没有报错或者排队记录。日志里显示请求确实进来了但处理时间异常长。接着看容器状态docker stats发现 CPU 和内存占用都很高而 GPU 利用率低说明瓶颈不在推理计算而在数据准备或并发等待上。最后定位到是MAX_CONCURRENT设置为 8但显存只够同时跑 3 个请求导致请求在排队等待每个请求的等待时间被拉长。把并发数降到 3 后响应时间立刻恢复到 3 到 5 秒。GPU 利用率低不一定是坏事可能只是并发设计保守关键是找到瓶颈在哪个环节。5.3 我踩过的几个坑与最后的小技巧最后分享几个只有实际用了才会注意到的细节。第一个坑不要把模型文件放在系统盘。我刚开始图省事放在/root/models结果系统盘被模型和日志塞满Docker 服务直接罢工排查了一下午才发现是磁盘问题。第二个坑升级镜像前一定要备份配置和数据目录。DeepSeek Harness 的管理数据存在/data/harness-data里包括用户账号、配额、API Key。有次我升级服务时没注意数据目录映射容器重建后所有账号都没了重新创建账号搞了一个多小时。后来我的习惯是改任何配置前先备份数据目录升级前必做。第三个技巧模型热切换。DeepSeek Harness 支持在同一服务里配置多个模型路径通过管理界面可以动态切换当前生效的模型。这意味着你可以同时准备好 7B 和 14B 两个模型平时用 14B遇到多人高并发或者显存紧张时切到 7B不用改配置重启服务。这个功能在团队使用场景下救过我很多次。还有一个值得养成的习惯每次调整配置后在低峰期做一次并发测试观察显存峰值和响应时间变化记录下不同并发数下的表现。这样后续扩容或者换显卡时你有明确的数据支撑而不是靠感觉拍脑袋。DeepSeek Harness 这套东西用下来最大的体会是部署本身不复杂复杂的是后续的调优和运营。一个服务能真正让团队“玩嗨”靠的不只是模型多强而是你能不能让每个同事都用得顺、用得稳、不翻车。希望这次分享能帮你少走一些弯路把精力花在真正有价值的事情上。