抡锤者

本来是双卡vllm的 （用的club-3090的脚本），稳定运行，性能中规中矩。 后来想要腾出一张显卡玩comfyui， 所以想要一个靠谱的单卡方案。

club-3090里只有llama.cpp的单卡方案，prefill性能不行。于是用了 syv-ai/qwen38-27b-rtx3090 的vllm+dflash2 的方案。 直接把github仓库地址丢给dsh远程配置的，起来以后效果不错，单人使用的话，打开

SPEC=dflash2
PREFIX_CACHE=1
CTX=huge
DFLASH_MAX_LEN=180000 #我最终用的是160k

实测性能如下， 128k上下文时，prefill ~800tps， decode 33~38tps ：

整体感觉和club-3090的双卡vllm的性能已经差不多了。接dsh跑了一下，整体感觉还行，TFTT第一次会比较长，后面因为PREFIX_CACHE就短下来了(当然也可能是tool calling的结果太短，没影响上下文)：

#DSH的第一个回答
Started 2026-08-28 14:39:15.324
Total duration 23.4 s
TTFT 20.8 s
Generation 2.60 s
Throughput 75.8 tok/s

#下一个回答
Started 2026-08-28 14:39:45.347
Total duration 2.18 s
TTFT 1.23 s
Generation 947 ms
Throughput 99.3 tok/s

#再下一个
Started 2026-08-28 14:39:49.862
Total duration 2.81 s
TTFT 779 ms
Generation 2.03 s
Throughput 92.1 tok/s

DSH里跑了4轮47步，最后一次的Throughput是49.1 tok/s，此时上下文 57.7k，基本和测试相符。
以后可以用gpu0配置gpu1上的comfyui了。

另外，有一个坑，就是开了单人的这些参数以后，不要多人或者多agent同时使用，争抢资源，缓存失效，两个速度都卡出翔。 单个DSH的话，还是非常丝滑的。多人可以考虑官方的多人配置，损失decode速度，换多人可以同时使用。

我觉得本地化部署就两个场景适合：

1. 你有私密的数据。local agents场景，Openclaw或者Hermes真要能帮你干活，你得给他很多私密的数据，服务器的用户名密码，邮箱密码什么的。
2. 你的需求没有现成的外部算力平台，比如老特的那种定制化的数字人生产流水线。
   其他你要是写代码，爬资料之类的公共信息相关需求，直接买coding plan肯定更划算。

@terry 说:

@davidwei0826 DSH不错的话，Hermes和Codex测试了没？不过有一个Agent能用，就差不多了。

最近痴迷DSH,已经很久没有长时间使用Hermes和Pi等其他agent了，都是发些短任务。 感觉DSH一个Agent就包揽了所有其他Agent的功能了，连im远程遥控，知识库这种需求，都已经通过插件实现了，我刚刚卸载了CherryStudio,升级到2.0以后太不稳定。 Opencode在开发完手里的项目以后，也不准备用了。全面转向DSH哈。

不过讲真，Hermes我感觉在我手里没有你说的那么好用，也可能是我给他一直配的是Minimax-M3模型，也不用他做开发吧。 后面我再重新更新下Hermes,接ds4 flash试试。

双卡3090 vLLM跑Qwen3.6-27B，强烈建议关注： https://github.com/noonghunna/club-3090 。
我自己的环境： 双卡3090 nvlink，模型Qwen3.6-27B-autoround-int4。 kv cache fp8_e5m2量化, 上下文长度 262144 。采用 dual-mtp 的vllm运行参数和测试脚本(soak-test.sh)， p50_decode_tps：61.34；p95_ttft_ms：4864 。
官方给的测试，应该能到接近70tps，我的还有优化空间，但是能用了就没折腾，参考DUAL_CARD.md。
num_speculative_tokens我测了2,3,4,5。效果上3最好。

启动脚本：

root@NV-AI-3090Dual2:~# cat vllm.qwen3.6-27b.sh 
#!/bin/bash
source /root/.bashrc
source /root/venv/bin/activate
# vLLM 启动脚本 — Qwen3.6-27B-AutoRound-INT4
# 用法: bash start-vllm-qwen3.6.sh [TP] [PP]
#   TP: tensor-parallel size，默认 2
#   PP: pipeline-parallel size，默认 1

set -e

# ========== 参数 ==========
TP="${1:-${TP:-2}}"
PP="${2:-${PP:-1}}"
MODEL_PATH="/root/models/qwen3.6-27b-autoround-int4"
PORT="${PORT:-8000}"
HOST="${HOST:-0.0.0.0}"
MAX_MODEL_LEN="${MAX_MODEL_LEN:-262144}"
GPU_MEM_UTIL="${GPU_MEMORY_UTILIZATION:-0.92}"
KV_CACHE_DTYPE="${KV_CACHE_DTYPE:-fp8_e5m2}"
TEMP="${TEMP:-${TEMPERATURE:-0.6}}"
TOP_P="${TOP_P:-0.95}"
TOP_K="${TOP_K:-20}"
MIN_P="${MIN_P:-0.0}"
REPEAT_PENALTY="${REPEAT_PENALTY:-1.0}"

# speculative decoding
SPECULATIVE_CONFIG='{"method":"mtp","num_speculative_tokens":3}'

# 推理模板参数（关闭 thinking）
CHAT_TEMPLATE_KWARGS='{"enable_thinking": false}'

# ========== 环境变量 ==========
export NVIDIA_VISIBLE_DEVICES="${NVIDIA_VISIBLE_DEVICES:-all}"
export HUGGING_FACE_HUB_TOKEN="${HF_TOKEN:-}"
export VLLM_WORKER_MULTIPROC_METHOD=spawn
export NCCL_CUMEM_ENABLE=0
export NCCL_P2P_DISABLE=0
export VLLM_NO_USAGE_STATS=1
export VLLM_USE_FLASHINFER_SAMPLER=1
export OMP_NUM_THREADS=1
export PYTORCH_CUDA_ALLOC_CONF="expandable_segments:True,max_split_size_mb:512"

# NVLink 检测（自行补充 detect_nvlink.sh 逻辑，或删掉这两行）
# source /etc/club3090/detect_nvlink.sh
# _NVLINK_ENABLED=0  # 手动设置：0=无NVLink, 1=NvLink开启

# ========== 构建命令 ==========
ARGS=(
    --model "$MODEL_PATH"
    --served-model-name qwen3.6-27b-autoround
    --quantization auto_round
    --dtype float16
    --tensor-parallel-size "$TP"
    --pipeline-parallel-size "$PP"
    --max-model-len "$MAX_MODEL_LEN"
    --gpu-memory-utilization "$GPU_MEM_UTIL"
    --max-num-seqs 2
    --max-num-batched-tokens 8192
    --kv-cache-dtype "$KV_CACHE_DTYPE"
    --trust-remote-code
  #  --chat-template "${CHAT_TEMPLATE}"      # 没有自定义模板文件则删除此行
    --reasoning-parser qwen3
    --default-chat-template-kwargs "$CHAT_TEMPLATE_KWARGS"
    --enable-auto-tool-choice
    --tool-call-parser qwen3_coder
    --enable-prefix-caching
    --enable-chunked-prefill
    --disable-custom-all-reduce
    --speculative-config "$SPECULATIVE_CONFIG"
    --override-generation-config "{\"temperature\":${TEMP},\"top_p\":${TOP_P},\"top_k\":${TOP_K},\"min_p\":${MIN_P},\"repetition_penalty\":${REPEAT_PENALTY}}"
    --host "$HOST"
    --port "$PORT"
)

echo "=========================================="
echo "启动 vLLM | TP=$TP PP=$PP | $MODEL_PATH"
echo "=========================================="
echo "命令: vllm serve ${ARGS[*]}"
echo ""

exec vllm serve "${ARGS[@]}"
deactivate

@Xiaote 说:

@huaye XU 你这个问题我在 TID:1308 那个帖答过一半，这里把另一半补上：

1. 40t/s 对你的卡是正常的：5090 Laptop 是 256-bit GDDR7，实际带宽约 1TB/s，decode 35~45 t/s 就是这条带宽下的物理上限，不是配置问题。B 站那些 80t/s 是台式 5090 的 1.2TB/s+ 带宽，笔记本物理上做不到。
2. 这个仓库的 dflash2 是 DeepSeek 系专用投机（DFLASH2 只对 DeepSeek 架构生效），qwen3.8 用不上，抄这个配置白抄；qwen 系要提速用 llama.cpp 的 MTP（投机解码 draft head），27B 上接受率约 40%，能提 30~50%。
3. vllm 单卡 24G 笔记本性价比低：vllm 的优势在多卡/高并发，单卡单人用 llama.cpp 更省事，而且你 96G 内存还能开 --cache-ram 兜底长上下文，vllm 那套在笔记本上反而是负担。

@huaye-xu
xiaote说的我持怀疑态度， 你的显存带宽如果能达到1TB/s,应该比3090还快一点。 算力你更是快一大截。 你用NVFP4的模型，肯定效果会好很多。我觉得速度的话，MTP或者用DFLASH是关键。你这个速度更像纯模型速度。

如果你用DSH或者hermes的话，可以和我一样把 合适的github仓库地址给他, 让他去给你配置。 我就给他发了3090那个仓库的地址，说我需要用cuda0配置single profile,然后他就配好了，大概也就不到1小时。 中间就让我提供了一次翻墙的代理。模型都是它自己下的。

Agent时代了，运维的逻辑变了。

我第一台自己的PC也是手搓的，2000年 毒龙750+256M内存，20G硬盘。用了5年，最后加到512M内存做archlinux的NAS. 跑了电驴、samba、nfs什么的。记得当时硬盘都是并口，动静老大了，而且还特别烫手。

今天看到一篇微信公众号文章： https://mp.weixin.qq.com/s/KQo-UBEOvtRMW5dK1bz6PQ
按照文章内容搭建了测试环境：

git clone https://github.com/ggml-org/llama.cpp llama.cpp-mtp
cd llama.cpp-mtp
git fetch origin pull/22673/head:pr-22673
git checkout pr-22673
mkdir build && cd build
cmake .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CUDA=ON \
  -DLLAMA_CURL=ON \
  -DGGML_NATIVE=ON \
  -DGGML_CUDA_GRAPHS=ON \
  -DGGML_CUDA_F16=ON \
  -DGGML_CUDA_FA_ALL_QUANTS=ON \
  -DCMAKE_CUDA_ARCHITECTURES=75   # 按需调整，89=Ada/4090，86=Ampere/3090
cmake --build . --config Release \
  --target llama-server llama-bench --parallel

下载了unsloth的开启MTP模型： https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF/resolve/main/Qwen3.6-27B-Q4_K_M.gguf -O ~/models/Qwen3.6-27B-MTP-Q4_K_M.gguf
不加载vision的情况下， 启动：

~/llama.cpp-mtp/build/bin/llama-server -m ~/models/Qwen3.6-27B-MTP-Q4_K_M.gguf \
--ctx-size 131072 \
--n-gpu-layers 999 \
-fa on \
--port 8000 \
--host 0.0.0.0 \
--cache-type-k q4_0 \
--cache-type-v q4_0 \
--no-mmap \
--no-warmup \
--reasoning off \
--jinja \
--parallel 1 \
--spec-type mtp \
--spec-draft-n-max 2 \
--chat-template-kwargs "{\"enable_thinking\": false, \"preserve_thinking\": false}"

128k上下文，显存占用20.5G，简单用cherrybox提了几个问题，prompt大概2k上下。 TPS从之前的27提升到了33左右。整体感觉快了20%。 coding场景没有测试，理论上应该提升更多。
另外，对于--spec-draft-n-max 的值，测了1,2,3。发现2时收益最大，能跑到33~34； 1和3都在30上下。 总体都比裸跑有提升。
最后挂上了vision，发了一张1M左右的图片测试了一下，TPS在28左右，显存占用21.75G。 我准备测几天，看看会不会OOM。
另外还有一个发现，开了MTP以后，显卡的utility下来了。之前基本上都在95%以上，功率一直顶着上限250W。开了MTP，tps上升的同时，utility基本上都在80%左右，功率也基本上不会满载了。估计是降低了开销，输出也降低，但是被MTP补偿了。

总体来讲，2080Ti这个卡应该没什么压榨空间了，跑Hermes太慢，适合跑好skill，布置好cron让他后台自己干活，不适合前台交互。

Rustdesk我一直在用效果不错。建议自架服务，不要用官方服务，安全第一。
内网穿透，方案很多了，我现在是手机ipv6的wireguard穿回来；如果你传大文件，建议用vmess这种伪装的协议，我架了一个vmess的ws，放在ipv6的网站下，作为传大文件和wg的备用。wg是基于udp的，用的多了容易被运营商卡速度，vmess+ws基于tcp没有这个问题。
如果不愿意用ipv6或者嫌不方便，可以考虑nat打洞，具体youtube上各大博主都有介绍，嫌麻烦就cloudflare，不怕麻烦就弄个小水管的vps做信息中转。我实测nat打洞还是挺方便的，各种网络环境都能回来。 cloudflare反代方案好在不用改端口，但是速度不太行，小流量延时不敏感的可以考虑。

两张nvlink我跑过，用的club-3090的vllm docker. 之前发过一片朋友圈如下：

双卡3090+nvlink，模型Qwen3.6-27B-autoround-int4。 kv cache fp8_e5m2, 上下文长度 262144 。采用 club-3090 的vllm运行参数和测试脚本 soak-test.sh， p50_decode_tps：61.34；p95_ttft_ms：4864 。

不过，最近用了 syv-ai/qwen38-27b-rtx3090 用一张3090也跑出了不错的速度（见我另一篇帖子。用的int4量化，上下文减到160k， 不支持并发。 不过一个人用的话够了）。

我觉得双卡3090跑qwen3.8-27b,最好的场景，应该是多人/Agent并发。 用SGLang的redix tree缓存，加上双卡nvlink高带宽, 再配合HiCache应该有不错的效果。等我有时间和需求时搞一下。