抡锤者

@williamlouis

我買時 兩張原裝AMD Radeon VII 有視頻端口的 海鮮市場買的 一張800

大概3000多人民幣
原先情況是更慘 他死活不能跑qwen 3.6

這次qwen3.8好像是採用3.5的架構，最後給我搞起來了，上下文跑長了還是大概能用到30t/s。就堪用吧，拿來驅動我的其他台主機跑comfy ui，改改代碼還是挺好用的。

不推薦折騰唷，但是有這樣硬件吃灰的可以拿出來用

我這邊先說結論，我覺得堪用了，不推薦大家折騰。
風扇策略要調整高一點 現在都能壓在85度以內。
沒多少錢，好玩就好，部署直接讓DeepSeek flash 搞，他能搞定的。
我設備是參考斯波圖大大的。

避雷的點
1.思考模式一定要關
2.風扇策略要調整高一點（直接叫agent搞）
3.影像識別也一定要關

一、硬體架構
CPU
型号：Intel Xeon E5-2678 v3 @ 2.50GHz
核心：12 核心 / 24 线程（单路，Haswell 架构）
指令集：AVX2、FMA、F16C、AES-NI
内存
总量：32 GB RAM
Swap：8 GB
存储
NVMe SSD：915 GB
GPU
型号：2 × AMD Radeon VII（Vega 20，16 GB HBM2/卡，共 32 GB）
驱动：ROCm 5.7（Ubuntu 24.04 自带）
无 NVIDIA 显卡，全部依赖 AMD ROCm 栈
二、运行架构
复制
Ubuntu 24.04.4 LTS (Linux 7.0.0-29-generic, x86_64)
│
├── vLLM 0.9.x（ROCm 版）
│ └── 模型: Qwen3.8-27B-awq-int4
│ ├── TP=2（双卡张量并行，每卡 ~10.5 GB 权重）
│ └── OpenAI 兼容 API: 0.0.0.0:8081
│
└── DeepSeek Harness (dsh)
├── node v24.x
├── Web GUI: 0.0.0.0:3080
└── 推理后端 → 127.0.0.1:8081 (vLLM)
三、装置部署
项目 路径 / 说明
模型根目录 /home/kiwi/models/qwen3.8-27b-awq-int4
权重大小 20 GB（5 个 safetensors 分片）
量化格式 AWQ INT4，group_size=32，mse observer
忽略量化层 所有 linear_attn 层 + embedding + norm 保持原始精度
vLLM 启动命令 见下方"启动参数"
dsh 启动命令 dsh --profile web --port 3080
GUI 地址
http://127.0.0.1:3080
API 地址 http://<host>:8081/v1（OpenAI 兼容）
四、模型参数
架构（qwen3_5，27B 参数）
参数 值
总层数 64 层
注意力分布 60 层 linear_attention (GDN) + 4 层 full_attention（每 4 层 1 层 full）
hidden_size 5120
intermediate_size 17408（SwiGLU）
full-attention heads 24 Q / 4 KV（GQA）
head_dim 256（partial_rotary_factor = 0.25）
linear-attn heads 16 K / 48 V，head_dim 128
RoPE θ 10,000,000（MRoPE interleaved）
最大上下文 262,144 tokens（本部署限制 65,536）
词表 248,320
原生精度 bfloat16
多模态 支持图像/视频（本部署 --limit-mm-per-prompt image:0 关闭）
MTP 1 层 multi-token prediction（推理未启用）
生成默认值
temperature: 1.0，top_k: 20，top_p: 0.95
Chat template: 自定义 chat_template_no_think.jinja（关闭思考模式）
五、vLLM 启动参数
bash
复制
vllm serve /home/kiwi/models/qwen3.8-27b-awq-int4
--tensor-parallel-size 2
--max-model-len 65536
--served-model-name qwen3.8-27b-awq
--gpu-memory-utilization 0.9
--max-num-seqs 32
--max-num-batched-tokens 8192
--enable-prefix-caching
--trust-remote-code
--limit-mm-per-prompt '{"image": 0}'
--dtype float16
--enable-auto-tool-choice
--tool-call-parser qwen3_coder
--reasoning-parser qwen3
--chat-template /home/kiwi/models/qwen3.8-27b-awq-int4/chat_template_no_think.jinja
--host 0.0.0.0
--port 8081
关键取舍：

gpu-memory-utilization=0.9：双卡各吃 ~28 GB，KV cache 空间充足
max-num-batched-tokens=8192：控制单批 decode 的显存峰值
enable-prefix-caching：多轮对话/agent 循环场景下命中率较高
dtype=float16：Vega 20 上 FP16 比 BF16 更快（无原生 BF16 支持）
chat_template_no_think.jinja：去掉 /think 段，强制直接回答，降低延迟

六、性能实测

单次请求 — Decode 速度
上下文长度 TTFT (首 token) Decode 速度 256 tokens 总耗时
~50 tok（短） 145 ms 41.1 tok/s 6.36 s
~4K tok 1,470 ms 40.5 tok/s 7.76 s
~16K tok 3,192 ms（中位） 38.3 tok/s 9.84 s
16K 的 TTFT 方差大：第一次 5.67s（冷启动 / page cache 未命中），第二次 0.71s（prefix cache 命中后接近热路径）。

并发 — 4 路并行 × 128 tokens
指标 值
单路 decode 速度 ~17.4 tok/s
聚合吞吐 51.4 tok/s（4 流）
4 路总耗时 9.96 s（512 tokens）
4 路并发的聚合吞吐（51.4）反而高于单路（41.1）——这是 continuous batching 的收益，GPU 算力没跑满时多路能填满。

关键结论
单流 ~41 tok/s，对 27B INT4 在 2× Radeon VII (FP16) 上属于正常水平
TTFT 与上下文长度近似线性：50→4K→16K 对应 145ms→1.5s→5.7s（冷）
Prefix caching 效果显著：16K 上下文命中后 TTFT 从 5.7s 降到 0.7s
4 路并发聚合 51 tok/s，说明 max-num-batched-tokens=8192 的设置对多用户场景是合理的
多模态已关闭（image:0），纯文本推理

R9700玩得飛起️，真厲害

我個人覺得他完全能用，很棒了

各位大神好
我目前是用7900xtx
作業系統Ubuntu 24.04

大模型混合用qwen 3.6與DeepSeek api 生成運行腳本

我在執行生圖時都是Hermes改用 DeepSeek api,初期會有一些東西要修正 確實非常的省心 其實這樣用是也沒什麼差 （也沒多少錢）

最近DeepSeek api執行腳本都沒出問題 感覺有點大材小用了 所以有點好奇大神們都是怎樣做的