书接上回，主包终于逮到机会在一台八卡服务器上继续推进龙虾养成计划。这回显存管够，足以塞下一个完整的 Qwen3.5-27B。趁热打铁，主包还准备对较火的Ollama 和 vLLM这两个推理部署框架实测进行实战测试，看看谁更能打。

服务器配置：
CPU：Intel® Xeon® Gold 6242R
GPU：8卡2080Ti 11GB
系统：Ubuntu 22.04 LTS

1）框架安装

1.1 安装 Ollama

使用官网脚本一键安装：

curl -fsSL https://ollama.com/install.sh | sh

1.2 安装 vLLM

官方推荐用 uv 管理环境（示例 Python 3.12）：

uv venv --python 3.12 --seed --managed-python
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

---

2）模型下载

2.1 通过 Ollama 下载 GGUF 模型（用于 Ollama）

Ollama 可直接拉取对应 GGUF 格式模型：

ollama pull qwen3.5:27b

2.2 从魔塔下载完整模型（用于 vLLM）

魔塔社区可直接下载千问 3.5-27B 完整模型（Qwen3.5-27B）。
下载到当前目录下的 ./models 文件夹内：

modelscope download --model Qwen/Qwen3.5-27B --local_dir ./models/Qwen/Qwen3.5-27B

---

3）运行服务

3.1 启用 Ollama 服务（脚本方式）

Ollama 安装后默认注册为系统服务并自启动。为了便于开发调试，先关闭 systemd 服务：

sudo systemctl stop ollama
sudo systemctl disable ollama

使用 .sh 脚本启动 Ollama（包含常用环境变量配置）：

#!/bin/bash
# Ollama 完整环境变量配置脚本
# 使用方法: source ollama-env.sh && ollama serve
# 或: chmod +x ollama-env.sh && ./ollama-env.sh

# 停止当前的 ollama 进程
pkill ollama

# 指定使用哪张 GPU
export CUDA_VISIBLE_DEVICES="0,1,2,3,4,5,6,7"

# 多 GPU 时强制均匀分布
# export OLLAMA_SCHED_SPREAD=1

# 模型保存时长
export OLLAMA_KEEP_ALIVE=-1

# 单个模型的最大并行请求数
export OLLAMA_NUM_PARALLEL=2
# 同时最大模型加载数
export OLLAMA_MAX_LOADED_MODELS=2

echo ""
echo "=========================================="
echo "启动命令: ollama serve"
echo "=========================================="

# 自动启动服务
read -p "是否立即启动 Ollama 服务? (y/n): " confirm
if [[ $confirm == "y" ]]; then
    ollama serve
fi

保存后执行：

source ./ollama-env.sh

启动后可直接测试：

• 命令行：ollama run qwen3.5:27b
• 或用 API 调用测试

---

3.2 启动 vLLM 服务

使用 vllm serve 启动（示例参数如下）：

vllm serve ./models/Qwen3.5-27B \
    --gpu-memory-utilization 0.85 \
    --tensor-parallel-size 8 \
    --max-model-len 8192 \
    --dtype half \
    --enforce-eager \
    --max-num-seqs 48

看到启动日志并显示监听端口等信息，即表示服务启动成功。

---

看到“龙虾养成计划”推进到 8 卡实测阶段，主包这波硬核操作确实给力！

针对你提供的测试数据和描述，我进行了风格统一化的润色与调整。保持了你前面“硬核技术+风趣表达”的博文基调，同时对 vLLM 的并发表现做了更具技术深度的补充描述。

---

4）性能实测与对比

为了贴合 OpenClaw 的实际生产场景，本次测试统一采用 API 调用 方式压测。

• Ollama 侧：使用官方自动量化的 GGUF 版本。
• vLLM 侧：直接跑 Qwen 官方的 FP16 全精度版本。

4.1 Ollama 实测

在 8 卡 2080 Ti 这种多路低显存架构下，Ollama 的调度逻辑显现出了明显的局限。

• 并发瓶颈：尽管配置了 OLLAMA_NUM_PARALLEL，但在实测中，Ollama 无法在当前硬件环境下触发多用户并行处理。其 serve 进程在自检阶段判定环境不满足并行条件，导致请求进入线性排队。
• 推理优势：值得注意的是，在单用户访问时，Ollama 凭借高度优化的 GGUF 内核，其推理速度优于 vLLM。对于低频次、长回复的单人场景，其响应体感更为轻快。

4.2 vLLM 实测

vLLM 的并发表现则相当优秀，得益于 PagedAttention 技术对显存碎片的极致利用，它在 8 卡并行环境下展现出了极佳的线性扩展性。

测试数据汇总（TPS, Tokens Per Second）：

并发数	vLLM (FP16) TPS	Ollama (GGUF) TPS
1	12.16	20.61
2	22.12	无法并发
8	83.51	-
16	161.57	-
24	244.98	-
32	316.22	-
48	282.00	-

4.3 结果分析

• 线性增长：在并发数 1-32 之间，vLLM 的总吞吐量几乎呈线性增长（TPS $\approx$ 单用户 TPS $\times$ 并发数）。这意味着 8 张 2080 Ti 被充分榨干，算力分配非常均匀。
• 性能拐点：当并发数推到 48 时，由于 KV Cache 耗尽 触发了频繁的请求排队或 Swap 机制，总 TPS 开始掉头向下。（在KV Cache 未完全耗尽前，观察到过500+的TPS峰值）

---

5）总结与展望

后续先试验当前生成速度是否能够满足OpenClaw使用，同时进一步探索提升模型推理速度的方法，包括但不限于尝试进一步对完整模型进行量化、更换服务器等。