上手做大模型评测的人，最近大概率绕不开 DeepSeek Harness 这个名字。它本质是一套面向大语言模型的评测与任务管理框架，而 Web 版则把任务提交、进度查看、日志追踪、结果导出这些操作搬进了浏览器，省去了整天 SSH 到服务器上敲命令的麻烦。但真要动手把 DeepSeek Harness Web 从源码部署到 Linux 服务器，网上资料一直比较零散，官方 README 又默认读者有一定基础，不少人卡在环境依赖那一关就放弃了——更别提还要让办公室其他的机器，或者家里网络能直接访问到这个 Web 界面。这篇我就把在 Linux 服务器上源码部署 DeepSeek Harness Web 的完整过程写出来，从系统准备、Python 环境、依赖安装、配置文件逐项说明，到局域网和公网远程访问的完整链路，再到实际踩过的坑和排查思路，全部摊开讲。适合正在搭评测环境、做模型评估的工程师，也适合刚接触 Linux Web 部署、想找一份可参照步骤的新手。
1. DeepSeek Harness Web 是什么，先弄懂再动手
1.1 它不是聊天机器人，而是一套评测与任务管理框架
第一次看到 DeepSeek Harness 这个名字的人，容易把它当成另一个网页版对话界面。实际不是。Harness 这个词在机器学习圈子里通常指"测试套具"，也就是把模型、数据集、评测指标串起来跑实验的那层脚手架。DeepSeek Harness 解决的是一个很具体的需求：今天你要评测一个开源模型的推理能力，明天要跑一组数学基准，后天还要对比两个版本的输出差异，如果每个任务都靠手敲命令行去完成，过程零散、结果难管理，也不利于多人协作。Harness 把整个流程封装成可复用的任务管线，Web 版再把任务状态、日志、结果统一收口到浏览器，让评测这件事变得标准化、可重复、可追溯。
举个例子你就明白了。把大模型比作一辆车，Harness 不是发动机，而是检测线——它按照预设的科目（推理、数学、代码、长文本理解等）对车做统一测试，记录每一项的得分，还能横向对比不同车辆的差异。它本身不产生模型能力，但能让"这个模型到底行不行"这件事有据可查。另外，Harness 并不局限于 DeepSeek 自家的模型，本地部署的开源模型，或者通过接口接进来的模型，都可以纳入评测管线管理。很多人问"离线局域网能不能用"，答案是可以的——只要模型和依赖都在本地，整条链路不依赖外网。
1.2 部署 Web 版解决的核心痛点
命令行版不是不能用，但用久了你会遇到几个绕不开的问题。
第一是协作效率。团队里有三五个工程师都想跑评测，总不能每个人 SSH 到服务器上轮流操作，命令冲突、环境变量互相覆盖都是隐患。Web 版把入口统一成浏览器页面，谁要用谁登录，互不干扰。
第二是任务可视化。命令行任务一旦跑起来，中途想确认进度就得重新连进去盯输出，任务一多，日志一刷屏，人很容易看花眼。Web 界面把进度、状态、错误信息结构化展示，扫一眼就知道哪些任务还在跑、哪些失败了。
第三是结果沉淀。命令行输出的结果散落在各种终端记录里，想对比历史结果还得自己整理。Web 版天然有结果记录和导出的能力，做实验记录、写评测报告都方便得多。
1.3 为什么我不建议用一键脚本，坚持源码部署
网上确实有一些"一键部署"脚本和打包好的镜像，但我的态度是：除非你只是临时看个界面效果，否则请走源码部署。原因有三个。
一是可控性。脚本和镜像往往是某个时间点的快照，版本可能滞后，也可能被第三方改动过。你不知道里面依赖的具体版本，出了问题也不知道从哪查起。源码部署虽然步骤多，但每一步都知道装了什么、改了什么配置、依赖锁在哪个文件里。
二是内网场景。不少做模型评测的团队服务器在隔离网络，没法直接拉取外部镜像或者访问在线仓库。源码方式配合离线依赖包，反而是更可靠的一条路径。把代码包和依赖包都准备好，通过内网传输进去，照样完成部署。
三是后续维护。Harness 项目本身还在活跃迭代，源码部署可以方便地固定版本、查看更新记录，需要回退时直接切换代码版本就行。用镜像的话，升级和回退都比较被动。
2. Linux 部署前的环境准备与源码获取
2.1 系统选型与服务器基础配置
我部署用的系统是 Ubuntu 22.04 LTS，这个选择不是随手定的：LTS 版本维护周期长，apt 源里自带 Python 3.10，依赖都能通过常规途径装上，社区资料也最全。如果你手头是 Debian 12 或者 Rocky Linux 9 也可以，但要注意包管理命令和 Python 默认版本有差异。老旧的 CentOS 7 已经过了维护期，很多新依赖装上会报版本过旧，不建议再用于新项目。
服务器配置方面，DeepSeek Harness Web 本身属于"控制面"程序，对 CPU 和内存要求不高，2 核 4G 跑 Web 服务本身够用。但如果你要在同一台机器上跑模型评测，资源大头在模型推理侧——比如同时加载一个 7B 参数量的本地模型，8G 内存会非常紧张。我的建议是：Web 服务和模型推理尽量分开部署，或者至少给服务器加 swap 兜底。我测试用的机器是 4 核 8G 的轻量云服务器，跑 Web 服务绰绰有余，但要同时跑大模型评测就明显吃力，后来我把模型服务挪到了另一台机器，问题才解决。
部署前的基础操作，我建议按这个顺序来一遍：
sudo apt update && sudo apt upgrade -y sudo timedatectl set-timezone Asia/Shanghai sudo useradd -m -s /bin/bash dsh sudo swapoff --all最后一条只是示意，意思是如果你内存偏小，优先检查 swap 是否已经配置。另外创建一个独立的普通用户来运行服务，不要直接用 root，这是安全习惯，也避免后续文件权限混乱。
2.2 Python 虚拟环境：安装前的关键一步
DeepSeek Harness 是 Python 项目，官方要求 Python 3.10 以上，Ubuntu 22.04 自带的 Python 3.10 可以直接用。但我不建议把项目依赖直接装进系统 Python 环境，原因很现实：系统环境里的 Python 被 apt 里的各种包依赖着，你为了装项目依赖升级某个库，可能顺带把系统组件搞坏。用虚拟环境隔离，是最省心的做法。
sudo apt install -y python3 python3-venv python3-pip git curl python3 --version mkdir -p /opt/dsh cd /opt/dsh python3 -m venv venv source venv/bin/activate pip install --upgrade pip setuptools wheelvenv 创建好并激活后，你的 shell 提示符前面会出现(venv)，说明当前所有 pip 操作都落在独立环境里了。这一步虽然简单，但很多人图省事跳过，后面要么把系统环境搞乱，要么项目之间依赖互相冲突，麻烦都在后面等着。
2.3 两种获取源码的方式，含版本固定建议
获取源码最常见的方式是 git clone。服务器能正常访问代码托管平台的话，直接拉取即可：
cd /opt/dsh git clone <DeepSeek Harness Web 项目仓库地址> dsh-web cd dsh-web git checkout <发布版 tag>需要注意的是：不要直接 clone 完就跑 master 分支。master 分支通常包含开发中的代码，依赖变动频繁，今天部署能用，过几天一更新可能就起不来。固定到发布版 tag，代码回退也方便——git checkout <上一个tag>一条命令就能切回旧版本。我见过不少人在项目更新后服务起不来，花了半天排查，最后发现就是 master 分支的依赖变了。
如果服务器访问不了代码托管平台，或者下载速度很慢，可以在自己电脑上先把仓库 clone 下来，打包后用 scp 传上去：
tar czf dsh-web.tar.gz dsh-web scp dsh-web.tar.gz 用户名@服务器IP:/opt/dsh/传完记得校验文件完整性，比如计算 sha256 值对比一下，别文件传输到一半损坏了还不知道，解压报错时才一头雾水。
3. 源码部署核心步骤：依赖、配置、启动、验证
3.1 依赖安装与编译报错的通用解法
进入项目目录后，按照官方 README 的说明安装依赖。大多数 Python Web 项目会提供requirements.txt，也有的用pyproject.toml管理。两种安装方式我都用过：
cd /opt/dsh/dsh-web pip install -r requirements.txt或：
pip install -e .pip install -e .会以开发模式安装，把项目本身也注册到当前虚拟环境里，好处是后续修改源码不用重新安装，项目自带的命令行入口也能直接用。我个人推荐这种方式。
依赖安装阶段最容易踩的坑是编译报错。一些核心库（比如涉及加密、tokenizer 的组件）在 PyPI 上没有当前平台的预编译包，或者版本太新，pip 会现场拉取源码编译，这时候如果系统缺少编译工具链，或者依赖需要新版编译器，就会报一堆看不懂的错误。我第一次部署时就遇到某个 C 扩展编译失败，日志刷了好几屏。后来总结出两条经验：
- 先安装
build-essential，把 gcc、make 这些基础编译工具补齐：
sudo apt install -y build-essential- 遇到编译报错别从头看日志，直接翻到最后几十行，真正的错误原因通常在那里。如果是某个依赖版本不兼容，可以用
pip install '包名==具体版本'锁到兼容版本。
还有一个小技巧：如果安装速度特别慢，可以配置 pip 走更近的软件源，这个根据自己的网络环境调整即可。当然，前提是你的环境能访问到包仓库，内网离线部署时则需要提前把依赖包下载好带进去。
3.2 配置文件必改的几类参数
依赖装完后进入配置阶段。DeepSeek Harness 的配置一般通过配置文件或环境变量注入，具体路径看项目文档，但需要关注的参数类型基本是固定的。
第一是监听地址与端口。监听地址必须设为0.0.0.0，否则外部请求无法到达，只能本机访问，这是后面远程访问能不能通的关键。端口建议避开系统常用端口，用 8000 或 9000 这类高位端口。如果你打算后面用 Nginx 对外提供服务，那 80 和 443 要留给 Nginx，Web 服务本身继续用高位端口。
第二是数据目录。评测结果、任务日志要存到独立目录，我放在/opt/dsh/data，同时在配置里指定好路径。这条我特别强调：不要把数据目录放 /tmp 下，服务器一重启全没了。也别放系统盘根目录，日志增长后迟早把系统盘占满。
第三是日志级别。平时用 INFO，排查问题时临时切 DEBUG，不要一直在 DEBUG 下跑，不然日志量非常大，反而掩盖关键信息。
第四是访问密钥。如果 Web 界面需要登录，务必设置一个强密钥，长度至少 32 位的随机字符串。不要用默认值，不要用 123456 这种，否则公网环境下就是给扫描器送菜。
3.3 前台启动验证与 systemd 托管
配置写好后，先以前台方式启动一次，验证配置和依赖是否正确。不同版本的项目启动入口可能不一样，以 README 为准，命令格式大致是这样：
source /opt/dsh/venv/bin/activate cd /opt/dsh/dsh-web python -m dsh.web serve --host 0.0.0.0 --port 8000看到启动日志正常、没有报错后，另开一个终端验证：
curl http://127.0.0.1:8000/health有正常响应，说明服务本体没问题。Ctrl+C 停掉，接下来把它做成 systemd 服务，这样服务器重启后 Web 能自动拉起，不用每次手动操作。也顺带回答很多新手的问题："后台运行怎么搞，退出 SSH 不会断吗？" 用nohup ... &确实可以，但 systemd 才是正道，它能处理开机自启、崩溃自动重启、日志统一收集，这些 nohup 都做不到。
创建/etc/systemd/system/dsh-web.service：
[Unit] Description=DeepSeek Harness Web Service After=network.target [Service] User=dsh Group=dsh WorkingDirectory=/opt/dsh/dsh-web Environment="PATH=/opt/dsh/venv/bin" Environment="DSH_CONFIG=/etc/dsh/config.yaml" ExecStart=/opt/dsh/venv/bin/python -m dsh.web serve --host 0.0.0.0 --port 8000 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target然后执行：
sudo systemctl daemon-reload sudo systemctl enable --now dsh-web sudo systemctl status dsh-webRestart=always加上RestartSec=5的意思是：进程无论因什么原因退出，5 秒后自动拉起来。这在长时间评测任务场景下非常重要——Web 进程崩了，至少服务能自动恢复，不影响后续任务提交。
3.4 部署成功的四条验证标准
很多新手觉得"能启动就行"，其实差得远了。我每次部署完会按这个清单过一遍，全绿才算完成：
- 端口监听正常：
ss -tlnp | grep 8000，能看到LISTEN状态，并且监听地址是0.0.0.0而不是127.0.0.1。 - 接口响应正常：
curl -I http://127.0.0.1:8000/，HTTP 状态码 200。 - 浏览器访问正常：打开浏览器输入
http://服务器IP:8000，页面能加载，样式和脚本没有缺失。 - 数据目录可写：提交一个小测试任务，确认任务能正常创建、进度能记录。
如果页面能打开但样式残缺、接口 404，大概率是静态文件路径没配好，检查配置里的静态目录路径和实际文件位置是否一致。
4. 远程访问配置：局域网、公网与安全加固
4.1 局域网访问：监听地址和防火墙一起改
先画一条逻辑链：浏览器要能访问 Web 服务，前提有三——服务在监听、防火墙放行、网络可达。任何一环断了都连不上。
服务监听方面，启动命令已经加了--host 0.0.0.0，确保不只听本机回环地址。防火墙方面，Ubuntu 上一般用 ufw：
sudo ufw allow 8000/tcp sudo ufw reload如果你用的是云服务器，别忘了云平台的安全组也要放行对应端口，这两处经常有人只改了一处，结果怎么都连不通，排查方向整个就错了。
改完后，在局域网内另一台电脑浏览器里访问http://服务器IP:8000，能打开界面说明局域网这一关过了。这里我专门提醒一个隐蔽问题：很多人本地调试时习惯监听127.0.0.1，部署到服务器后忘了改启动参数，外部防火墙全放行了还是连不上，最后才发现服务一直监听在 localhost，流量根本没到应用层。
4.2 公网访问的可行方案与选择逻辑
想从外部网络访问，我按推荐程度讲三种思路。
第一种，适合内网服务器：用一台有公网 IP 的云服务器作为中转，内网服务器和云服务器之间建立一条经过认证的加密通道，把内网服务的端口映射到云服务器的公网端口。这样内网服务器不用暴露任何额外的入站端口，外部请求先进云服务器，再经通道转发到内网。通道两端要校验访问方的身份，设置好密钥和访问控制，不要裸奔。这个方案的好处是内网拓扑不用动，安全性也相对好控制。
第二种，最简单直接：直接把 Web 服务部署在有公网 IP 的云服务器上，安全组放行端口，然后通过公网 IP 访问。代价是服务完全暴露在公网，密码强度、访问日志、暴力破解防护这些工作变成必修课，一条都不能省。
第三种，有域名的话：把域名解析到服务器公网 IP，然后用 Nginx 监听 443 端口，配置 HTTPS 证书加密流量，再把请求转发给本机 8000 端口的 Web 服务。这一套做下来，用户记住的是域名而不是 IP，数据传输也是加密的。HTTP 明文模式下，账号密码、任务数据在网络里都是裸奔的，除非只在完全可信的内网用，否则我强烈建议至少走到 HTTPS 这一步。
关于远程访问的本质，我多说一句：它解决的是"让可信的外部终端安全地连到你的服务"这个问题，核心永远两件事——身份认证和传输加密。把这个逻辑想明白，具体用什么方案都是围绕这两点做文章。
4.3 公网暴露的安全底线
如果你决定让服务可以在公网访问，下面这几条当底线来执行：
- 给 Web 界面设置高强度密码，并开启登录频率限制，防暴力破解。
- 用 HTTPS 替换 HTTP，证书用 Let's Encrypt 这类免费证书就可以，到期自动续期。
- 对外入口交给 Nginx，不要把后端服务的原始端口直接暴露公网。Nginx 层可以做访问控制、请求限速、访问日志记录，相当于给后端加了一道闸门。
- 数据目录每天备份一次。评测结果丢了可以重跑，但时间成本太高。
- 如果服务实际使用人数很少，直接做来源 IP 白名单，非白名单地址一律拒绝。
安全这块没有银弹，但有个底线不能碰：永远不要在公网开放一个没有认证的管理界面。之前有个团队图省事，把内部工具裸奔在公网，没两天就被扫描器盯上，机器直接被挂马，评测数据全被加密勒索。这不是吓唬人，是真事。
5. 常见问题排查与避坑心得
5.1 高频问题速查表
部署过程中最容易遇到的几类问题，我整理成一张表：
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 浏览器访问提示连接被拒绝 | 服务没启动 / 监听地址不对 / 防火墙拦截 | 先本机 curl 127.0.0.1，再用 ss -tlnp 确认监听地址，最后查防火墙和安全组 |
| 页面能打开但接口 404 | 静态文件路径错误 / 前端路由没配置 | 检查静态目录配置，确认文件存在且路径正确 |
| 依赖安装出现大量编译日志 | 缺少编译工具链 / 依赖版本冲突 | 安装 build-essential，锁定兼容版本，看日志末尾的错误原因 |
| 服务启动后立刻退出 | 配置文件语法错误 / 端口被占用 | 看 journalctl -u dsh-web -n 50，确认配置格式和端口占用 |
| 重启后服务没自动起来 | systemd 未 enable | 执行 systemctl enable --now dsh-web |
| 远程访问很慢 | 带宽不足 / 跨网络延迟高 | 确认服务器带宽，考虑把静态资源和接口走不同链路 |
5.2 我踩过的四个坑
第一个坑：端口冲突。我以前习惯把服务放在 8080，结果那台服务器上有个 Java 应用也占了 8080，两个进程互相抢端口，日志报错非常诡异。后来我统一规划端口段：Web 应用用 8000-9000，中间件用 9000-10000，跟同事约定好，再没出过这类问题。
第二个坑：数据目录权限。我把结果目录放在/opt/dsh/data，但运行用户已经换成了 dsh，目录属主还是 root，导致服务起来后提交任务一直报权限错误。查了半天，其实就是chown -R dsh:dsh /opt/dsh一条命令的事。教训是：创建目录后第一件事就是确认属主和属组。
第三个坑：监听地址忘了改。本地调试时监听的是127.0.0.1，部署到服务器后没改参数，外部怎么都访问不了，防火墙、安全组全放行了也白搭。这个教训让我养成了一个习惯：每次部署完先ss -tlnp检查监听地址，确认是0.0.0.0才算过。
第四个坑：证书续期后忘了重载。HTTPS 证书一般三个月一续，我写了定时任务自动续期，但有一次续期成功后忘了重载 Nginx，浏览器一直报证书错误。后来我把续期命令后面直接追加了重载命令，问题才根治。自动化任务不仅要考虑"任务本身成功"，还要考虑"任务完成后依赖它的服务是否需要联动操作"。
写到这里，你照着操作应该已经能把 DeepSeek Harness Web 在 Linux 上跑起来了。最后说点实际体会：源码部署这种事，第一次花的时间最多，但只要每一条命令和背后的原因都搞明白了，第二次第三次部署基本就是复制粘贴加微调。我现在手头三台服务器跑着不同版本的 Harness，都是源码部署，维护起来反而是当年"图省事"装的错误依赖最折腾人。还有个建议是：部署完成后，把自己用到的启动命令、配置参数、踩过的坑整理成一个 Markdown 文件放在服务器上，下次换机器或者同事接手，照着这份文件操作，能省掉大量沟通成本。评测任务跑起来容易，跑得稳、跑得可复现，才是真正有价值的地方。
