抡锤者

Brian

最后MTP 3比较稳定。

之前MTP 5有长任务会卡

Brian

开了above 4g和rebar，非常成功，速度和使用感觉好很多

Brian

还是要开思考，不开拉垮的很

Brian

Hermes+Deepseek整理，不保证全对。

硬件环境

组件	详情
CPU	Intel Xeon E5-2686 v4
主板	X99（无 GPU P2P 直连）
GPU	2× AMD Radeon AI PRO R9700 (RDNA4 / gfx1201)
显存	每卡 32 GB GDDR6
系统内存	62 GB
OS	Ubuntu 24.04
ROCm	7.2.4
Python	3.12 (conda: sglang-triton36)

模型信息

参数	数值
模型	Qwen3.6-27B-FP8（HuggingFace 本地缓存）
架构	Qwen3.5 (GDN + 混合注意力)，64 层
量化	Native FP8 (e4m3, dynamic activation scheme)
模型大小	29 GB（磁盘）
隐藏维度	5120
注意力头	24 (Q) / 4 (KV)，head_dim=256
词表	248,320
最大上下文	262,144 (256K)

当前配置 (2026-06-15)

启动命令

# 激活环境
export PATH="/home/xxx/miniforge3/bin:/home/XXX/.cargo/bin:$PATH"
source /home/XXX/miniforge3/etc/profile.d/conda.sh
conda activate sglang-triton36

# 启动服务
python -m sglang.launch_server \
  --model-path /home/XXX/models-hf/Qwen3.6-27B-FP8 \
  --tp-size 2 \
  --mem-fraction-static 0.75 \
  --context-length 262144 \
  --attention-backend triton \
  --fp8-gemm-backend triton \
  --trust-remote-code \
  --port 23334 \
  --host 0.0.0.0 \
  --disable-custom-all-reduce \
  --cuda-graph-max-bs 1 \
  --cuda-graph-bs 1 \
  --max-running-requests 1 \
  --num-continuous-decode-steps 8 \
  --max-mamba-cache-size 8 \
  --chunked-prefill-size 8192 \
  --disable-overlap-schedule \
  --tool-call-parser qwen3_coder \
  --chat-template /home/XXX/models-hf/Qwen3.6-27B-FP8/chat_template_nothink.jinja \
  --speculative-algorithm NEXTN \
  --speculative-num-steps 5 \
  --speculative-num-draft-tokens 2 \
  --speculative-eagle-topk 1 \
  --allow-auto-truncate \
  --log-requests

关键参数说明

参数	值	原因
`--tp-size 2`	双卡 TP	256K 单卡装不下 KV cache
`--mem-fraction-static 0.75`	75% 显存	MTP draft graph 额外占用，0.80 会 OOM
`--context-length 262144`	256K 上下文	模型最大上下文
`--fp8-gemm-backend triton`	Triton GEMM	RDNA4 最优 FP8 矩阵乘后端
`--disable-custom-all-reduce`	禁用	X99 无 GPU P2P，必须禁用
`--cuda-graph-max-bs 1`	单 batch graph	CUDA graph 解码提速
`--disable-overlap-schedule`	禁用 overlap	Mamba no_buffer 不兼容
`--tool-call-parser qwen3_coder`	Qwen3 工具调用	Hermes Agent function calling
`--chat-template nothink.jinja`	自定义模板	关闭 thinking（无 reasoning_parser，模板去掉了 `<think>` 标签）
`--speculative-algorithm NEXTN`	MTP (EAGLE)	内建 MTP 加速解码
`--speculative-num-steps 5`	5 步 draft	最优值：4.38 accept_len，68% accept_rate
`--speculative-num-draft-tokens 2`	每步 2 token	配合 steps=5
`--speculative-eagle-topk 1`	单分支	topk=2 无额外收益且占更多显存
`--allow-auto-truncate`	自动截断	超过 KV cache (147K tokens) 自动截断而非 400 报错
`--max-running-requests 1`	单请求	单用户优化
`--log-requests`	请求日志	生产调试

显存分配 (256K 上下文 + MTP)

GPU	模型权重	KV Pool	Draft Graph	CUDA Graph + 驱动	余量
GPU0	~17 GB	~8 GB	~0.3 GB	~5 GB	~5.6 GB
GPU1	~17 GB	~8 GB	~0.3 GB	~5 GB	~5.6 GB

max_total_num_tokens=146964，allow_auto_truncate=True 超过自动截断。

思考模式

reasoning_parser=None — 无 reasoning parser
chat_template_nothink.jinja — 自定义模板，add_generation_prompt 中不输出 <think> 标签
enable_thinking 变量处理已完全移除
模型训练行为残留的 <think> 标签（output_ids 以 248068=`

<｜｜DSML｜｜tool_calls>
<｜｜DSML｜｜invoke name="write_file">
<｜｜DSML｜｜parameter name="content" string="true"> 开头）属于模型输出内容，不影响 reasoning_tokens（始终为 0）

NOTE: 编辑 chat_template_nothink.jinja 后禁止还原 <think> 标签。如 SGLang 版本升级后模板行为变化，参考本文件的"思考模式"说明进行调试。

性能基准

Decode 速度 (MTP steps=5)

场景	速度 (MTP)	速度 (无 MTP)	提升
短上下文 (<1K)	~34 tok/s	~18 tok/s	+89%
中等上下文 (4K–32K)	~30 tok/s	~18 tok/s	+67%

MTP 参数对比测试结果

steps	draft_tokens	topk	速度	accept_len	accept_rate
无 MTP	-	-	~18 tok/s	-	-
1	2	1	~24 tok/s	1.88	88%
3	2	1	~29 tok/s	3.08	69%
4	2	1	~30 tok/s	3.38	56%
5	2	1	~34 tok/s	4.38	68%
6	2	1	~33 tok/s	4.62	60%
5	4	2	~28 tok/s	3.23	72%

最优：steps=5, draft_tokens=2, topk=1。Steps=2 以上会在 CUDA graph 捕获阶段增加 draft graph（约 0.3GB 显存开销）。

Prefill 速度 (chunk_size=8K)

上下文	速度
16K	~473 tok/s
64K	~450 tok/s
108K	~407 tok/s

环境搭建步骤

1. 安装 Miniforge3

curl -L -o /tmp/miniforge.sh "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh"
bash /tmp/miniforge.sh -b -p /home/gaopy/miniforge3

2. 安装 Rust (SGLang 编译需要)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y

3. 克隆并运行 SGLang RDNA4 setup

git clone https://github.com/mattbucci/2x-R9700-RDNA4-GFX1201-sglang-inference.git sglang-rdna4
cd sglang-rdna4
export PATH="/home/gaopy/miniforge3/bin:/home/gaopy/.cargo/bin:$PATH"
bash scripts/setup.sh

4. 修复依赖冲突

conda activate sglang-triton36
cp components/sglang/sgl-kernel/python/sgl_kernel/*.py $CONDA_PREFIX/lib/python3.12/site-packages/sgl_kernel/
pip install kernels==0.14.1
pip install --force-reinstall --no-deps transformers==5.8.0
bash scripts/build_awq_gemv.sh --env sglang-triton36
cd components/sglang
git checkout v0.5.12
for p in ../../patches/0*.patch; do git apply --3way "$p" 2>/dev/null; done
pip install -e "python[all]" --no-build-isolation --no-deps

5. 下载模型（FP8）

huggingface-cli download Qwen/Qwen3.6-27B-FP8 \
  --local-dir /home/gaopy/models-hf/Qwen3.6-27B-FP8 \
  --max-workers 4

服务接口

# 健康检查
curl http://localhost:23334/health

# 模型列表
curl http://localhost:23334/v1/models

# 推理 (OpenAI 兼容)
curl http://localhost:23334/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/home/XXX/models-hf/Qwen3.6-27B-FP8",
    "messages": [{"role": "user", "content": "Hello"}],
    "max_tokens": 100,
    "temperature": 0.7
  }'

已知问题

thinking 残留 — 模型训练行为，</think> 标签以 248068/248069 token 形式出现在输出开头，不影响内容质量
X99 无 GPU P2P — 多卡必须用 --disable-custom-all-reduce
首次启动慢 — 模型加载 + KV cache 分配 + CUDA graph + draft graph 捕获约 90 秒
FP8 GEMM 警告 — 启动时提示 Using default W8A8 Block FP8 kernel config，性能可能未达最优，等待社区提交 R9700 调优配置
Triton deprecation warning — tl.where with non-boolean condition，当前不影响运行

版本历史

日期	变更
2026-06-15	MTP 加速 (+89%, ~34 tok/s)；思考关闭 (no-think v2 模板)；添加 --allow-auto-truncate；上下文 256K
2026-06-14	从 AWQ 切换到 Native FP8；添加 no-think 模板绕过 reasoning_parser 自动检测
2026-06-13	初始部署：AWQ + 256K，后因 OOM 切换 FP8

Brian

@terry 说:

@neo 其实只有SG-Lang能跑，本地才有意义，没有Radix缓存树，本地hermes挂机做任务好可以，要实时做事太慢了。

Sglang可以跑了，但是FP8 256k上下文速度还是不太行，还在测

Brian

最近请求性能（task 25136, ~71K tokens context）

 | 阶段            | 速度                    |                              
 |-----------------|-------------------------|                              
 | prompt 处理前期 | 1319 tok/s (16K tokens) |                              
 | prompt 处理中期 | 909 tok/s (49K tokens)  |                              
 | prompt 处理后期 | 577 tok/s (71K tokens)  |                              
 | 总 prompt 时间  | 123.87s / 71,419 tokens |                              
 | 生成速度        | 17.4 tok/s (稳定)       |

当前运行状态

 | 指标       | GPU 0          | GPU 1          |                           
 |------------|----------------|----------------|                           
 | 温度       | 64°C           | 66°C           |                           
 | 功耗       | 205W / 300W    | 193W / 300W    |                           
 | VRAM       | 27.67 GB (80%) | 27.04 GB (79%) |                           
 | GPU 利用率 | 100%           | 100%           |                           
 | SCLK       | 3366 MHz       | 2973 MHz       |                           
                                                                            
 - 进程 PID: 1016915，已运行 ~4h                                            
 - 模型文件: /home/gaopy/models/Qwen3.6-27B-Q4_K_M.gguf (约 16 GB)          
 - 生成速度: 实测 ~17-22 tok/s (当前 71K context 时 17.4 tok/s)

Brian

硬件环境

 | 项目     | 值                                         |                  
 |----------|--------------------------------------------|                  
 | GPU      | 2× AMD R9700 32GB (gfx1201, device 0x7551) |                  
 | 总显存   | 64 GB                                      |                  
 | ROCm     | 7.2.4 (AMD 官方 repo)                      |                  
 | PyTorch  | 2.10.0 + HIP 7.2.53211                     |                  
 | 系统内存 | 62 GB                                      |                  
 | OS       | Ubuntu, Linux 6.17.0-35                    |

Brian

   -m /home/gaopy/models/Qwen3.6-27B-Q4_K_M.gguf \                          
   -ngl 99 \                                                                
   -c 262144 \                                                              
   --host 0.0.0.0 \                                                         
   --port 8080 \                                                            
   --reasoning off \                                                        
   -fa on \                                                                 
   -b 16384 \                                                               
   -ub 16384 \                                                              
   -np 1 \                                                                  
   --cache-type-k q8_0 \                                                    
   --cache-type-v q8_0 \                                                    
   --split-mode layer \                                                     
   --mlock \                                                                
   --no-cache-prompt \                                                      
   --cache-ram 0

Brian

先说下感受，256k上下文，速度是真的慢，但是做研究真是很细。

同时偶然发现在线API虽快，但是比较粗糙，需要驾驭很好才行。

但是本地Qwen3.6，推理能力极强，工具调用，加上联网检索，最终效果挺好。

即使是模型和hermes都设置256k上下文，herems还会触发压缩，最终效果还是很够用的。

折腾了很多，Vllm和sglang搞不定，用了deepseek claude codex都搞不定，不是工具的问题，是我一点都不懂。只会说看看社区有什么成功的方案去尝试（我TM社区是啥都不知道）。

以下是llama cpp参数。问了AI 256k上下文，就是这个速度，不知道有没有好的优化方法。

硬件： 双 AMD Radeon AI Pro R9700（各 32GB VRAM）+ Intel Xeon E5-2686 v4

参数	值	说明
`-m`	`Qwen3.6-27B-Q4_K_M.gguf`	标准版模型
`-ngl`	`99`	全部层卸载到 GPU
`-c`	`262144`	262K 上下文（医疗文档长文本需要）
`-np`	`1`	单并行槽（避免 OOM）
`--split-mode`	`layer`	双卡按层切分（tensor 模式在 PCIe 瓶颈下更慢）
`--cache-type-k/v`	`q8_0`	KV cache 精度，保持质量
`--cache-ram`	`0`	禁用跨请求 prompt cache（规避 crash）
`--no-cache-prompt`	—	禁用 prompt cache
`--mlock`	—	锁内存防 swap
`--defrag-thold`	`0.1`	KV cache 碎片整理阈值
`--reasoning off`	—	关闭 thinking 模式
`-fa on`	—	Flash Attention

性能基准

指标	数值
llama.cpp 版本	b9586
Decode 速度	~24 tok/s（MTP版）；~24 tok/s（标准版）
Prefill 速度	~562 tok/s（MTP版）；~21 tok/s（标准版，短 prompt）
tensor split 测试	19.4 tok/s（PCIe 瓶颈，不如 layer）

Brian

@ping-lin 我也没装成功

Brian

@Terry 确实，网配不好说明了一个问题，一个人不是不努力，也不是不学习，是没有意识，1是问AI问不到点子上，2是AI回答了也不见得看明白。门槛跨不过去就放弃了。

我一直想用大模型+提示词+搜索做一个稳定的多文档生成系统，文档之间逻辑相关。业余时间搞了个软件。
听你说模型的变化会导致输出不稳定，我觉得很有道理，我也试了不同家的api出来的差别很大。所以就搞个本地27b试试水。
claude做的太好了，自己的llm+agent确实是典范，普通人有没有必要自己搞个软件接自己部署的本地API，还是直接拥抱claude和codex，但是持续给claude和codex输送最佳实践会加速自己被取代。
提个问题，希望可以做你的视频素材

Brian

@terry 有没有必要先连 deepseek api让hermes积累一些skills，再接qwen27b，感觉27b做研究不行，看长文件也不行，特别是联网有问题，开梯子也不行。不知道是不是配置的不对。
感觉hermes不如claude cli 和 codex cli，但是接入后两个，也就打个招呼就断了，也都是用hermes 连deepseek pro配置的，不好搞，有没有什么思路提供，谢谢。

Brian

@terry 说:

9700也算是神卡了，你用服务器版的驱动是什么鬼，它原本就是专业计算卡，现在HIP驱动没统一？
我比较幸运，装系统，装驱动都比较顺。
32g显存感觉不够，是双9700还是搭配个N卡

Brian

还是要多看帖子，ubuntu26装上，deepseek claude gpt搞了一天都没搞定vllm，看了才知道要装24

Brian

安装了hermes，配了ds V4 pro，太省事了，不用怎么折腾

Brian

我刚配好，拼多多2800元, 2686v4*2,x99,1T，64g，不带显卡，显卡京东1.1万，电源700w，我自己换了1200w，长城750元。预装win10,本来想玩玩游戏再搞模型，win弹窗弹的难受，赶紧装了ubuntu，还在摸索，洋垃圾太强了

抡锤者

Brian

帖子

硬件环境

模型信息

当前配置 (2026-06-15)

启动命令

关键参数说明

显存分配 (256K 上下文 + MTP)

思考模式

性能基准

Decode 速度 (MTP steps=5)

MTP 参数对比测试结果

Prefill 速度 (chunk_size=8K)

环境搭建步骤

1. 安装 Miniforge3

2. 安装 Rust (SGLang 编译需要)

3. 克隆并运行 SGLang RDNA4 setup

4. 修复依赖冲突

5. 下载模型（FP8）

服务接口

已知问题

版本历史