1、环境检测
1）rocm-smi --showproductname 确认 gfx1201（R9700 原生识别）；
2）runpm=0 通过 modprobe.d 生效（不在内核 cmdline，但内核参数文件确认 = 0，状态正确）；
3）工具链：git/gcc/g++/hipcc 已有；cmake、aria2 缺失，通过 apt 补装；
4）lama-server 运行库依赖：RUNPATH 指向 /opt/rocm-7.2.4/lib，ldd 无缺失项。

2、编译 llama.cpp（HIP / gfx1201）
git clone https://github.com/ggml-org/llama.cpp # 锁定 master 提交 03dbcc5（GitHub tag 拉取超时，改用提交号锁定，等效）
cd llama.cpp
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1201 -DCMAKE_BUILD_TYPE=Release
cmake --build build -j20

build/bin/llama-server、llama-bench 等，编译一次通过

启动时 llama-bench 输出确认： found 1 ROCm devices … AMD Radeon AI PRO R9700, gfx1201 (0x1201) ，HIP运行时原生工作，无需 HSA_OVERRIDE_GFX_VERSION 兜底。

3、模型下载
#自行下载好（两文件均做 SHA256 校验，与 Hugging Face 官方值完全一致）

4、参数名核对

二、服务器配置

1、完整启动命令（文件夹名称请自行修改）
/home/magicz890/llama.cpp/build/bin/llama-server
-m /home/magicz890/models/qwen3.8/Qwen3.8-27B-Q5_K_M.gguf
--mmproj /home/magicz890/models/qwen3.8/Qwen3.8-27B-mmproj-f16.gguf
--alias qwen3.8
-c 131072 \ # 128K 上下文
--override-kv qwen35.context_length=int:131072 \ # 让前端界面正确显示 128K（而非模型原生
256K）
-ctk q8_0 -ctv q8_0 \ # KV 缓存量化（省一半显存+提速，质量几乎无损）
--spec-type draft-mtp \ # ★ MTP 投机解码（必开，实测 ≈1.6x 提速）
--spec-draft-n-max 2 \ # ★ 草稿数=2（AMD 官方 R9700 建议值，实测优于 3）
-fa on \ # FlashAttention（长上下文提速关键）
--load-mode none \ # 权重钉死显存（对应 LM Studio「取消勾选 Try mmap」）
--reasoning-effort medium \ # ★ 思考强度（默认 xhigh 会烧掉几十 K 上下文）
-ngl all -np 1 \ # 全层进显存、单槽位（KV 池全归单用户）
--temp 0.3 --top-p 0.9 \ # 低温采样：准确度↑ + MTP 接受率↑（94.2%）
--host 127.0.0.1 --port 8080

2、参数作用对照表

3、systemd 单元要点（/etc/systemd/system/qwen38.service）
[Service]
Type=simple
User=magicz890
ExecStart=…（上节完整命令）
Restart=on-failure # 崩溃自愈（实测 kill -9 后 5 秒内自动拉起）
RestartSec=5
TimeoutStartSec=600
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target # 开机自启

4、Open WebUI 前端（open-webui.service，端口 3000）（我是用deepseek harness）（自行修改文件名）
本机无 docker，ghcr.io 拉取在国内网络风险高，改用官方同样支持的 pip + venv + systemd 方案：
[Service]
User=magicz890
Environment=DATA_DIR=/home/magicz890/open-webui/data
Environment=OPENAI_API_BASE_URL=http://127.0.0.1:8080/v1
Environment=OPENAI_API_KEY=dummy
Environment=PORT=3000
Environment=HF_ENDPOINT=https://hf-mirror.com # ★ 关键：修复启动时卡死在 huggingface.co 的问
题
ExecStart=/home/magicz890/open-webui/venv/bin/open-webui serve --port 3000
Restart=on-failure

版本：Open WebUI v0.11.3。首次启动会从 hf-mirror 下载默认 RAG 嵌入模型（约 90MB），之后秒开。

三、性能实测数据（实际使用中速度比测试速度快）

1、解码速度（llama-server 官方计时，含 MTP）

注：128K 两次实测差异主要来自生成内容（简短回答 vs 长篇解释）导致的草稿接受率波动，均落在文档预告的 25~35 t/s 物理带宽临界区；日常 ≤64K 场景稳超 40 t/s。

2、llama-bench 基准（无 MTP 裸速度，验证带宽账）

3、预填充（prompt processing）实测
1）128K 冷预填充：全量 116,525 token 用时 333.4 秒（平均 349 t/s），约 5.6 分钟——符合文档「全量128K 一次性约 3~6 分钟」；
2）分段速率：前 4K 段 1171 t/s，随 KV 增长缓降至 16K 处的 880 t/s；
3）后续增量对话：前缀命中 KV 缓存，首 token 延迟 < 0.5 秒。

4、显存实测（rocm-smi）

四、功能验证

1、文本对话
数学概念题（矩阵乘法三句话解释 + 2×2 示例）：回答结构清晰、示例正确，46.6 t/s（墙钟）。

2、长文精确检索（Needle-in-Haystack）

3、多模态（mmproj 视觉）
测试图：程序生成的 2026 年月度 GPU 利用率柱状图（含 6 个月数值、峰值标注、费用注释）。

4、API 兼容性
GET /health → {"status":"ok"} ； GET /v1/models → 模型名 qwen3.8 ；OpenAI 格式 chat/
completions（含 image_url 多模态输入）全部正常。

五、稳定性验证清单（已修复网络暴露面）

六、偏差记录（模型文件可事先下载好）
1）下载通道：huggingface.co 被网关 fake-IP 劫持，改用 /etc/hosts 固定 hf-mirror.com 真实 IP（X.X.X.X）+ aria2 16 连接；mmproj 因 CDN 不支持 aria2 Range 改用 curl 分段并行。
2）Open WebUI 安装方式：本机无 docker，改 pip + venv + systemd（官方支持），并设置 HF_ENDPOINT=https://hf-mirror.com 解决启动卡死
3）llama.cpp 版本锁定：GitHub tag 拉取超时，改锁定 master 提交 03dbcc5（等效）。
4）文档笔误修正： -lm none → --load-mode none ；llama-bench 无 -c 参数（用 -p/-n ）；MTP=2 → --spec-draft-n-max 2 。
5）最终温度取 0.3：文档允许范围 0.3~0.5 内取低值，实测 MTP 接受率 94.2%（0.4 为 83.9%）、28.7K 解码 42.4 t/s（0.4 为 40.7），准确度与速度双赢。
6）MTP 草稿数维持 2：对照实验证实 AMD 官方「R9700 设 MTP=2」建议；n-max=3 实测更慢。
7）上下文元数据覆盖：GGUF 原生元数据 context_length=262144（256K），前端会把 256K 当服务上限显示；已用 --override-kv qwen35.context_length=int:131072 覆盖为 128K，与实际服务能力一致（256K 需 ~34GB 显存，本卡放不下）。
8）补装 ffmpeg：llama.cpp 的 WebP 图片解码依赖 PATH 中的 ffmpeg/ffprobe 二进制（MTMD_VIDEO 路径）；DeepSeek Harness 会把带透明通道的 PNG 归一化为 WebP 后发送，未装 ffmpeg 时服务端报400「Failed to load image or audio file」。已 apt 安装 ffmpeg，拖图恢复正常。

七、使用手册
1）日常入口（我后期加入deepseek harness）
网页聊天（OpenWebUI）：http://127.0.0.1:3000 #首次访问创建管理员账号；对话框可直接拖图上传（OCR/图表/截图问 bug）
推理 API：I http://127.0.0.1:8080/v1 #OpenAI 兼容，模型名 qwen3.8，任意客户端可调用

2） API 调用示例（多模态）：
curl http://127.0.0.1:8080/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "qwen3.8",
"messages": [{
"role": "user",
"content": [
{"type": "text", "text": "这张电路图里有什么问题？"},
{"type": "image_url", "image_url": {"url": "data:image/png;base64,<BASE64>"}}
]
}]
}

3） 常用运维命令（记得修改到自己的文件夹）
journalctl -u qwen38 -f # 看推理日志（含每请求 eval 速度、MTP 接受率）
sudo systemctl restart qwen38 # 重启推理服务（约 5 秒恢复）
sudo systemctl restart open-webui # 重启网页前端
rocm-smi # 盯显存/频率/温度/功耗
/home/magicz890/llm-deploy/chat-test.sh "问题" # 命令行测速
/home/magicz890/llm-deploy/bench.sh # llama-bench 基准

注意事项：
图像 tokens 计入 128K 预算：多图长对话会加速填满上下文，控制单轮贴图数量；
MTP 不开 = 自罚约 40% 速度，是 30 t/s 目标的第一依赖，勿删除；
思考链是隐形的「上下文+速度」双重杀手，reasoning-effort 必须保持 medium；
显存余量始终 ≥3GB，勿把 -c 拉到贴边；
amdgpu.runpm=0 与 SMU 修复配置不要被任何「优化脚本」覆盖；
DKMS 驱动随内核升级自动重编，升级完重启一次服务即可。

八、128K 速度临界点与「压线四招」
128K 全程填满时解码落在 23~26 t/s（R9700 640GB/s 带宽物理上限决定）。需要更高速度时按序启用：

256K 说明（供参考）：Q4_K_M + KV q8_0 可塞下 256K（约 34GB 会略超本卡），或 Q5 配 KV q4_0（有长文退化风险）；建议主力固定 128K + Q5，偶尔超长任务再起 Q4_K_XL + 200K 的第二 profile 按需切换。

九、关键实测原始数据

llama-bench（无 MTP）

pp8192: 958.88 ± 5.47 t/s tg128: 26.02 ± 0.02 t/s
build: 03dbcc5 | backend: ROCm | ngl: 999 | fa: on

llama-server（MTP=2 最终配置 temp 0.3）

26-token 提示: eval 8353ms / 400 tok → 47.8 t/s | 接受率 81.5%
28.7K 上下文: eval 1745ms / 75 tok → 42.4 t/s | 接受率 94.2%（mean len 2.88）
116.5K 冷预填充: prompt eval 333.4s / 116525 tok → 349 t/s（前段 1171 t/s）
116.5K 解码: eval 19533ms / 451 tok → 23.0 t/s（长文生成）
多模态图表: 800 prompt tok（图≈774）→ 34.0 t/s，6 值全对
显存 @128K 满载: 27.03GB used / 34.21GB total（79%）
GPU @满载: 2555 MHz ｜ 244W ｜ 63°C
自愈: kill -9 → systemd 5s 内重启 → health ok

十、先到这吧……