企业官网建设流程全解析

我把 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 系列有不同参数规模的版本，我这里把几个常见档位对应的显存需求整理成一个估算表，供大家参考：

注意这只是模型权重占用的空间，实际运行还要算上 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 Harness

3.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_TYPE=deepseek - QUANTIZE=int8 - NUM_GPU=1 - MAX_CONCURRENT=10 - DEFAULT_USER_QUOTA=500 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_CONCURRENT=4跑一轮测试，观察显卡显存占用情况，再逐步往上加。如果一上来就把并发调到 20，14B 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 需要 28GB，Int8 只要 14GB，Int4 更夸张，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 高频问题速查表

部署和使用过程中，我整理了一份高频问题速查表，基本覆盖了团队使用一个月的求助记录：

这张表我打印出来贴在了服务器机柜旁边，同事遇到问题先自己查一下，很多小问题不用专门找我。

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 这套东西用下来，最大的体会是部署本身不复杂，复杂的是后续的调优和运营。一个服务能真正让团队“玩嗨”，靠的不只是模型多强，而是你能不能让每个同事都用得顺、用得稳、不翻车。希望这次分享能帮你少走一些弯路，把精力花在真正有价值的事情上。