三档免费算力#

24G 和 192G 差八倍，这不是「跑得快一点」的区别，是模型规模差一个档位。

一个 27B 的 dense 模型，BF16 权重 54GB。24G 装不下，只能压到 4bit 左右，13GB 能塞进去。192G 装得下原样的，还能剩下 130 多 G 给上下文。

上下文也是钱。256K 的 KV cache 按这个架构算下来大约 17GB，24G 那台根本开不到这个数，192G 那台可以满开。

还有一点：这些都不是「送一张卡」，是按小时计的体验额度。实例一停，上面装的东西就没了，只有 /mnt/workspace 挂的 NAS 还在。额度烧完就得等下一次。

24G 那台：量化是唯一解#

Qwen3.8-27B，BF16 权重 54GB，A10 只有 23G 可用。量化到 Q3_K_XL，13GB，再带一个 889MB 的视觉模块。

llama.cpp 编译时开 CUDA，A10 是 Ampere，arch 86。

1
llama-server \
2
  -m models/Qwen3.8-27B-Unleashed-UD-Q3_K_XL.gguf \
3
  --mmproj models/mmproj-model-bf16.gguf \
4
  --host 127.0.0.1 --port 8081 \
5
  -ngl 999 -c 262144 -np 1 \
6
  --flash-attn on \
7
  --cache-type-k q5_1 --cache-type-v q5_1 \
8
  --alias qwen3.8-27b

-ngl 999 是把所有层都放到 GPU 上，不够就分层，剩下的回 CPU，速度会掉一个数量级。

-c 262144 是上限，实际开多大看显存。13GB 权重压着，KV cache 再一挤，256K 跑不满。这个数别照抄，按剩余显存调。

--cache-type-k q5_1 是把 KV cache 也量化，省显存，代价是长上下文里精度掉一点。

实测生成 16 token/s，prompt 处理 378 token/s。写代码能用，跑 agent 也能跑，秒回是别想。一次长回答要等几十秒，思考链一长更明显。

192G 那台#

硬件是 MI308X，ROCm 7.2.3，单卡显存 205822885888 字节，191.7 GiB。23 vCPU，200 GiB 内存，无 swap。Ubuntu 22.04.5，内核 5.10.134。/mnt/workspace 挂在 NFS 上，池子 1 PB，剩 972 TB；/tmp 是本地盘，30 GB。

有两个地方容易误判。

amd-smi 只列 GPU 0，容器里 torch.cuda.device_count() 返回 1。PCI 上能看到多张卡，实际只给一张切片。所以 --tensor-parallel-size 8 这种想法可以直接放弃，单卡跑。

/mnt/workspace 是 NFS。编译放 /tmp，源码可以留 NFS。在 NFS 上编译又慢又容易踩文件锁。

模型选的是 Qwen3.8-27B-abliterated，BF16，55.56GB，18 个 shard。魔搭上没有这个模型，HF 直连超时，走 hf-mirror.com 拉到 /mnt/workspace/models/Qwen3.8-27B-abliterated。

本来想沿用 llama.cpp，省事。走不通，两条路都堵。

convert_hf_to_gguf.py 没注册 qwen3_5 架构，转换脚本不认这个模型。仓库里现成的 llama-cli 是 CUDA 编的，libggml-cuda.so 在 ROCm 机器上加载就报错。要重编，得加 -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx942。

那就换 vLLM。0.28.0，torch 2.12.0（hip 7.2.53211）。模型注册表里 Qwen3_5ForConditionalGeneration 是认识的。

1
vllm serve /mnt/workspace/models/Qwen3.8-27B-abliterated \
2
  --served-model-name qwen3.8-27b-abliterated \
3
  --max-model-len 262144 \
4
  --gpu-memory-utilization 0.92 \
5
  --reasoning-parser qwen3 \
6
  --enable-prefix-caching \
7
  --async-scheduling

--max-model-len 262144 是模型支持的最大上下文，直接拉满。显存够就不用缩。

--gpu-memory-utilization 0.92 是允许 vLLM 占用 92% 的显存，剩下的留给系统和其他进程。这台机器只有模型在跑，可以给高一点。

--reasoning-parser qwen3 是让 vLLM 认识这个模型的思考格式，把思考内容和正文分开。不加的话，思考链会混在正文里返回。

--enable-prefix-caching 是前缀缓存。同一段 system prompt 反复用的时候，不用每次重算，首字延迟会低很多。

--async-scheduling 是异步调度，并发请求下吞吐会好一些。

单卡加载 51.1 GiB，262144 上下文没炸。显存账：权重 55.56G，256K KV 大约 17G，合计 73G，占 192G 的 38%。余量很大，这台机器再跑一个模型都行。

速度：TTFT 0.06 秒，decode 52 到 54 token/s，思考模式关掉，端到端快 24%。

TTFT 0.06 秒这个数有点夸张，是因为 prefix caching 生效了，同一段系统提示词不用重算。冷启动第一次请求会慢一些。

两边对比：

两个框架不一样，速度差不能全算在显存头上。llama.cpp 的 GGUF 推理和 vLLM 的 PagedAttention 本来就是两种设计。

但 24G 那台就算换成 vLLM，13GB 的量化权重也装不出全精度的效果。量化损失在长上下文和复杂推理里会放大，尤其是代码和数学。

中间层#

vLLM 的接口是 OpenAI 兼容的，但「兼容」不等于「一样」。客户端和上游之间有三处不一致，需要在中间加一层代理处理。

字段名。vLLM 把思考内容放在 reasoning，很多客户端读的是 reasoning_content。这是两套约定，不是谁写错了。代理里做一次字段重命名，流式和非流式都要处理。

思考 token 算进预算。max_tokens 给小的时候，思考把预算吃完，正文一个字没有，返回的 content 是 null。客户端不报错，就是空回复。处理方式有两种：给足预算，或者在代理里把思考内容分离出去，不占正文的额度。

流式分块的结构。SSE 每一块都要是合法的 JSON，思考内容和正文可能在同一块里交替出现。代理要按块解析，改完再拼回去，不能整段读完了再一次性发。

这一层不复杂，但必须有。没有它，客户端要么连不上，要么拿到空回复，要么流式断在半路。

顺手把生图接上#

192G 空着也是空着。

选的是 Qwen-Image 2.1 Turbo 的 abliterated 版，8 步出图。三个文件：

先试的 ComfyUI。Radeon 上 1024x1024 一步超过五分钟，不可用。换 stable-diffusion.cpp，源码编 HIP 版：

1
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx942

产物 sd-cli，直接命令行出图：

1
sd-cli --diffusion-model models/qwen-image/Q5_K_M.gguf \
2
  --llm models/qwen-image/TE-4bit.gguf \
3
  --vae models/qwen-image/vae.safetensors \
4
  --steps 8 --cfg-scale 1.0 --sampling-method euler \
5
  --diffusion-fa --vae-tiling \
6
  -W 1024 -H 1024 -p "prompt" -o out.png

--steps 8 是这个 Turbo 版本的特点，普通扩散模型要 20 到 30 步。--cfg-scale 1.0 是蒸馏模型的标准值，不需要 classifier-free guidance 的放大。--diffusion-fa 开 flash attention，--vae-tiling 把 VAE 解码分块做，省显存。

1024x1024 八步的耗时分解：每步 1.62 秒，采样总计 23.75 秒，VAE 解码 7.78 秒，冷启动 43.5 秒。

和 27B 的 vLLM 同时开着，不 OOM。两个模型加起来占用不到 80G。

命令行不好用，包了一层 FastAPI，暴露 /v1/images/generations，返回 b64。端口选 8083，因为 8082 被 code-server 占了。开服务之前先 ss -ltn 看一眼，别硬撞。

把服务接出来#

实例没有公网 IP，也不给开入站。只能让实例主动连出来，在自己的服务器上开监听。

1
ssh -N -p 14413 -i ~/.ssh/dsw_key \
2
  -R 172.21.0.1:16384:127.0.0.1:2222 \
3
  -R 172.21.0.1:16385:127.0.0.1:8000 \
4
  root@tunnel.example.com

16384 转发到实例的 22，16385 转发到模型端口。从服务器上看，模型就像跑在本地。

绑定地址写 127.0.0.1 只有服务器本机能连，容器里的网关连不上，得写网关 IP。这个地址在实例里看到的是 172.21.0.1。

加第三个端口给生图的时候，一直报 remote port forwarding failed for listen port 16386。

服务器上 ss -ltn 看，端口空着。sshd_config 里 GatewayPorts clientspecified，permitlisten 是 any。改了配置、reload 了 sshd，还是不行。

日志里有一行关键：

1
Received request from x.x.x.x port xxxxx to remote forward to host 172.21.0.1 port 16386, but the request was denied.

denied，不是 bind 失败。开 LogLevel DEBUG1：

1
debug1: active: permitted listen: 172.21.0.1:16384
2
debug1: active: permitted listen: 172.21.0.1:16385

原因在 authorized_keys。当初为了安全，那把 key 前面挂了 restrict,port-forwarding,permitlisten="172.21.0.1:16384",permitlisten="172.21.0.1:16385"，白名单只有两个端口。新端口不在名单里，sshd 直接拒。

补一条 permitlisten="172.21.0.1:16386"，立刻通。

这是安全配置的副作用：白名单越严，加新端口越容易忘。报错只到 denied，不会说哪条规则拒的。LogLevel DEBUG1 一行就能定位，比翻配置快。

客户端怎么用#

任何 OpenAI 兼容的客户端都行，Base URL 填服务器上隧道的地址：

1
http://172.21.0.1:16385

密钥填模型启动时的 --api-key，模型名填 --served-model-name 的值。

Base URL 不要带 /v1，客户端自己会拼。带了就是 404，很容易顺手加上。

生图走 http://172.21.0.1:16386/v1/images/generations，参数是 prompt、size（WxH）、n（最多 4）、negative_prompt、seed、steps。

实测：512x512 直连 7 秒，1024x1024 约 25 秒。请求是串行的，同时发会排队。

值不值#

免费 192G 是真的，但不是免费 API。

额度按小时烧，实例会停，重开一台 IP 和端口全变，脚本得重跑。适合试模型、跑一次性任务、给 agent 当备用后端。不适合长期在线、对外服务、对延迟敏感。

还有，别把 0.0.0.0 开到公网。全程监听 127.0.0.1，出口走 SSH，入口是带 restrict 的 key。免费算力是别人的，机器上的东西泄了，麻烦是自己的。

真正的变化不是显存，是门槛。

以前要查文档、试环境、踩驱动坑，一个模型折腾一天。现在把 SSH 丢给 AI，探环境、下模型、选框架、配参数、排协议差异，它自己一条条过。我只开了个实例，回了两句话。

免费算力是别人的，时间和试错才是自己的。