GPUWorks GitHub 开源代码仓库地址：https://github.com/flitai-io/gpuworks
前言：租 GPU 的人都懂这几堵墙
当我想跑个开源模型做自测的时候，就去租了一台 RTX 4090 容器实例。ssh 进去一看，root 倒是给了，但 docker 命令压根不存在——共享容器没有内核权限，装了 daemon 也起不来；我就想着把服务端口开出去，也不行，租用实例只给映射端口，任意入站全封。
跑不了容器、开不了端口，这就是租用 GPU 实例（Vast、RunPod、AutoDL、优云智算这类）的日常，给你一张卡的算力，其他什么都锁死。下面这张就是当时 ssh 进去的实测，root 有、docker 没有：
但这次我想较个真，这种「毛坯房」里能不能正经搭一套推理平台——有目录、有部署、有监控、有 API 的那种。答案是能。我用的是 ZStack 家的 GPUWorks，从装控制面到打出第一条模型回复，整条链路走通了。下面是完整流程。
我的环境
- 控制面（server），一台最普通的腾讯云 Linux 服务器，GPUWorks 内测版（构建号 31178e80，linux-amd64 包，40 多 MB）
- GPU 节点，优云智算租的 RTX 4090 容器实例（24GB 显存）
- 说一句，server 不需要 GPU，也不依赖 K8s、Docker、Python 这些，一台最低配云服务器就够
一、40 多 MB 一个文件，控制面一条命令起来
先搞控制面。安装包就一个 tar.gz，40 多 MB，我直接从 Windows 传到腾讯云服务器上：
scp gpuworks-31178e80-linux-amd64.tar.gz root@<服务器IP>:/root/
然后 ssh 登上去，解开就俩文件——一个说明文档，一个可执行程序，一条命令安装：
tar -xzf gpuworks-31178e80-linux-amd64.tar.gz
cd gpuworks-31178e80-linux-amd64
./gpuworks install -addr :8800
:8800 表示监听所有网卡（默认绑的是内网地址，公网访问得显式指定）。跑完它直接把访问地址、管理员账号密码和数据目录打印出来，服务也就地跑起来了。装完我在服务器上看了眼状态，服务 active、版本号清清楚楚，顺带瞄到控制面常驻内存才 96MB，比我开的一个浏览器标签页还省：
接着去腾讯云控制台把安全组的 8800 入站放行（这步漏了页面怎么都打不开，别问我怎么知道的）。就加一条规则的事儿，协议 TCP、端口 8800：
放行之后浏览器打开 http://<服务器IP>:8800，用安装时打印出来的管理员账号密码登录，进去的概览页长这样：
这个架构我想给个好评，server 是 Go 编译的静态单二进制，不依赖 K8s、不依赖 Docker、也不依赖 Python 环境。对租用场景来说这不是锦上添花，是能不能跑的问题。
二、把租来的 GPU 接进来：免 Docker，零入站端口
控制面有了，接下来把租的 4090 接进来。节点就是优云智算上一台按量计费的 RTX 40 系容器实例，ssh 登录指令和密码直接贴在实例卡片上，点一下复制就能连：
然后到控制台「资源 → 计算节点 → 添加节点」。这个弹窗信息量很大：目标机支持 SSH 的，填 user@host 或直接粘整条 ssh 命令；不支持 SSH 的，复制安装命令自己去机器上执行。连接方向有「Agent 发起连接」和「Server 发起连接」两档，后者是给出口受限的节点准备的兜底。我把操作顺序直接标在图上了：
认证方式选密码就行——平台登录一次后自动把自家公钥写进实例的 authorized_keys，之后只保留密钥认证，你填的密码不会保存，这个细节挺讲究。点「开始预检查」，平台先替你把目标机摸一遍底，18 项检查覆盖系统、GPU、sudo、目录权限、磁盘。这张是全部通过的复查结果：
其实第一次没这么顺。实例默认只给 50GB 盘，首查就弹了个黄牌：推理引擎镜像加模型权重至少要 50.0 GiB，当前只剩 48.9 GiB，差一口气。我把盘扩容之后重查，才是上面那排全绿。这种把问题拦在动手之前的提示，真的比我瞎猜盘够不够用强多了：
预检查过了点「安装 Agent」，几分钟后节点上线。打开节点详情，硬件信息一目了然：在线状态、1× GeForce RTX 4090、Agent 版本、CPU 内存都认出来了。跑不了 Docker 怎么办？ 看「运行时」那一栏（我框出来了）：runveil，平台自带的用户态运行环境，不需要 Docker、不需要特权、也不碰宿主机内核，纯用户态就能把推理引擎跑起来。哪怕在连 root 都不给的租用平台上，它照样能干活：
开不了入站端口怎么办？ 常规做法是 server 去连节点上的端口，租用实例入站全封，死路一条。GPUWorks 把方向反过来，agent 主动外连 server，所有通信都走这条出站连接，节点的入站端口数是 0。相当于我不开店等你上门，而是主动给你打电话、这通电话还一直不挂——双向都能说话。
节点上还有个 doctor 自检命令，驱动、CUDA、卡间连通性一遍过，出问题先看它。
三、选模型：按卡型策划的档位目录
节点上线后就可以挑模型了。推理模板页是我觉得最有意思的设计，写作本文时共 390 个模型、1230 个部署档位，全部按卡型策划。以 Qwen3.8-27B 为例，一个模型挂 10 个档位，按 NVIDIA 通用 / Hopper / Blackwell / 昇腾 / 海光 / 平头哥 / Apple 分组，每个档位连运行镜像都定好了，选卡型等于选一套完整的预置方案：
先泼一盆冷水。27B 的 bf16 权重就要 51.8 GiB，单张 4090 物理上塞不下；退一步选它省显存的 Hopper fp8 档（28.8 GiB），调度器照样不放行——这个档按 Hopper 适配，要求计算能力 CC ≥ 9.0，4090 只有 8.9，连门槛都够不着。拒绝原因直接写在页面上，「没有 GPU 通过部署硬件检查」，一点不含糊：
于是我选了 Qwen3.5-9B 的 NVIDIA 通用档，bf16 原生精度，权重 18.0 GiB。
提交部署前有个环节我特别喜欢，部署评估。写过 vLLM 启动参数的人都知道，以前调 tensor-parallel、gpu-memory-utilization 这些全靠启动失败日志反复试；现在它先给你一张显存账单，每卡 21.6 GiB（24G × 0.9）排得明明白白：权重 18.0 + 引擎预留 2.0 + KV 池 1.6。默认的 262144 上下文它也不放过，直接提醒按这个配置 KV 缓存只能容纳 51,726 个 token，比上下文小得多，建议调小再部署：
我把上下文改成 8192，重新评估，通过。
四、下载与启动
评估通过提交部署，接下来就是等。权重 18 GiB 从模型仓库拉到节点，速度快慢主要看源站线路，建议选离实例近的源，或者提前预下载。引擎镜像走的是华为云 SWR 源，我实测 40+ MB/s，几分钟就拉完了。控制台的部署路标会同步把阶段亮出来，下载、拉镜像、启动引擎、健康检查走到哪一步一目了然：
启动阶段 ssh 到节点上，还能看到 vLLM 的完整启动日志——加载权重、torch.compile、CUDA 初始化一行行走出来，跟控制台的路标对得上。健康检查一过，状态转绿。
五、调用：跟调 OpenAI 一模一样，还附赠透明账单
服务起来之后，对外就是一个 OpenAI 兼容的 /v1 接口。控制台建一个 API 令牌（明文只显示一次，立刻保存），OpenAI SDK 换个 base_url 直接用：
from openai import OpenAI
client = OpenAI(
base_url="http://<server地址>:8800/v1",
api_key="<平台发的令牌>",
)
resp = client.chat.completions.create(
model="Qwen/Qwen3.5-9B-smf9",
messages=[{"role": "user", "content": "用一句话介绍你自己"}],
max_tokens=200,
# Qwen3.5 默认思考模式，简单任务可以关掉，响应更快
extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)
print(resp.choices[0].message.content)
模型的回答：「我是 Qwen3.5，阿里巴巴最新推出的超大规模语言模型，能够流畅对话、深度解析长文档，并胜任多模态处理与专业领域任务。」
还有个惊喜，响应里自带逐请求指标，首 token 延迟、生成耗时、每秒 token 数、排队时间，每个请求都带账单：
"metrics": {
"time_to_first_token_ms": 98.3,
"generation_time_ms": 3228,
"queue_time_ms": 0.03,
"tokens_per_second": 30.06
}
首 token 98ms、30 tok/s，一台租来的单卡 4090 跑 bf16 权重，这个水平做对话类应用绰绰有余，而且做性能调优时这些数字直接就能用，不用自己埋点。
控制台的「试验场」还能直接跟模型对话，带实时延迟显示，拿来快速验证效果很顺手：
六、内置压测：一张租来的 4090 能扛多少并发
最后是压测，这也是我最关心的部分——租的卡到底能扛多少并发。平台内置压测工具，连容器都不用自己起。「评测」里选吞吐上限探测，它会自动一级一级加并发找拐点，另外还有按延迟目标搜最大可用并发的 SLA 模式，和自由组合的参数扫描。我按输入 256 / 输出 128 token、发压点选节点（引擎本机直连）跑了一轮：
|
并发 |
输出吞吐 (tok/s) |
单请求完成时间 P50 |
成功率 |
|
1 |
28.5 |
4.48s |
100% |
|
2 |
51.3 |
4.93s |
100% |
|
4 |
103.3 |
5.00s |
100% |
|
8 |
205.2 |
~5.0s |
100% |
|
16 |
385.2 |
~5.0s |
100% |
说两个我在意的点。一是并发从 1 加到 16，吞吐近乎线性爬升（28.5 → 385 tok/s），这轮的结论直接写着「未探到容量上限」，一张租来的 4090 在这套部署上还有余量。二是并发翻了 16 倍，单请求完成时间只慢了 12%（4.48s → 5.0s），说明并行请求是靠 batch 把算力吃满，而不是互相抢，这对「一张卡跑多个用户」的场景是最关键的指标。
评测跑完的结果页长这样，每个并发点的吞吐、延迟、成功率、缓存命中率都列得清清楚楚，还能导出 md / csv / html 三种格式的完整报告：
口径说明：发压点为节点本机、直连推理引擎（未经网关）；部署开启了强制 Eager（无 CUDA 图捕获），开启图捕获吞吐还会更高；本轮为非流式请求，未统计 TTFT 分项。
七、最后一个彩蛋：把平台接进终端
写到这本来该收尾了，结果翻控制台设置的时候发现有个 MCP 开关。打开，平台就多出一个只读的 MCP 端点，带着六个工具：集群概览、API 检索、指标查询、GPU 拓扑这些。配进 Claude Code 就一条命令：
claude mcp add --transport http gpuworks http://<server地址>:8800/api/v1/mcp --header "Authorization: Bearer <平台令牌>"
这里有个小细节：鉴权用的不是前面调推理接口的令牌，而是「API 令牌」页单独创建的平台令牌（gwp_ 开头，只读权限就够）。我一开始拿推理令牌去连，401，看了设置页的说明才反应过来这是两套体系。
配好之后在 Claude Code 里直接问「集群状态怎么样」，它自己调 cluster_overview，把节点在线情况、GPU 健康、部署状态拉回来总结成一段话：
对我来说这条是真能改工作流的——平时人就在终端里，查个节点状态、翻个日志不用再切回浏览器开控制台，顺嘴一问就行。
八、几点实用建议
- 权重下载走国内源或提前预下载，能省不少等待时间
- 磁盘给足 100G 以上，引擎镜像加权重比直觉占地方
- 显存排得比较满时，部署表单里可以开「强制 Eager」，启动更稳，吞吐略降
- runveil 用户态模式下，多线程引擎靠线程上限缓解资源争用，极限并发场景留意
- server 没有原生 Windows 包，Windows 用户走 WSL2 或一台 Linux 云服务器
- 本文为内测版本体验，功能以正式发布为准
写在最后
我们回到开头那几堵墙，跑不了 Docker，runveil 纯用户态搞定；开不了端口，agent 反向外连。至于装平台本身这道隐形墙，40 多 MB 单二进制什么都不依赖。
从一条 ssh 命令到第一条模型回复，整套流程走下来最大的感受就是「顺手」，每一步该有的信息都有，该拦的提前拦，该给的账单明着给。租 GPU 做验证的开发者、手里握着一堆杂牌算力又不想搭 K8s 的团队，这套东西值得等它正式开源发布。
它的产品标语是 Make Any GPU Work，走完这一趟再看这句，我觉得不虚——Docker 装不了、端口开不了，一张租来的 4090 照样干活。
机器是租的，服务是自己的。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2401_86326742/article/details/170048004
