小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻
-
一、部署
1、硬件与系统环境
2、部署基础资料
3、显存依据
4、部署方案
1.）Docker方式（首选，完全不懂系统ROCm7.2.4）
pip方式（备选：需Python3.14虚拟环境）
2.）Ollama / llama.cpp（单用户 / 桌面体验）
3.）LM Studio（图形界面速开）
5、 性能预期
6、本机的特定事项
二、本机四项硬指标定制的最终方案
1、 单用户使用：单用户 decode 是纯显存带宽瓶颈，正是 llama.cpp 系最擅长的场景。
2、 128K+ 上下文：32GB 正好是社区公认「长上下文 + MTP + 视觉」全都要的起点档。
3、 ≥30 t/s：短/中上下文（≤64K）轻松 40~55 t/s；128K 全程填满时约 25~35 t/s，属R9700 的 640 GB/s 带宽物理上限决定的临界区，须靠 MTP 与量化压线。
4、稳定 + 准确：关键在量化档位 + reasoning effort + 采样温度三个设置
三、 关键数字分析
四、搭建步骤
① 环境保持
保持 amdgpu.runpm=0（已修复的 SMU 挂起问题，是长期稳定运行的命根子）
rocm-smi --showproductname # 确认显示 gfx1201
② 编译 llama.cpp（ROCm 7.2.4 直接可用）
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1201 -DCMAKE_BUILD_TYPE=Release
cmake --build build -j20兜底：官方 AMD 实测 51.8 t/s 就是用 Vulkan 后端跑的；HIP 编译遇阻时，直接下官方预编译 Vulkan 版二进制同样达标。
③ 下载模型
huggingface-cli download unsloth/Qwen3.8-27B-GGUF UD-Q5_K_XL.gguf
--local-dir /home/magicz890/models/qwen3.8 （我的部署文件夹）备选：AtomicChat/Qwen3.8-27B-GGUF 的 AD-Q5_K_M（20.2GB，质量再高半档）
需视觉：加下 DhruvalLabs 的 mmproj
④ 启动服务（核心参数全在这条命令里）
./build/bin/llama-server
-m /home/magicz890/models/qwen3.8/Qwen3.8-27B-UD-Q5_K_XL.gguf
-c 131072 \ # 128K 上下文
-ctk q8_0 -ctv q8_0 \ # KV 缓存量化：省一半显存+提速，质量几乎无损
--spec-type draft-mtp \ # ★ MTP 投机解码（对应 LM Studio 的 MTP=2），必开
-fa on \ # FlashAttention：长上下文提速关键
-lm none \ # 对应 LM Studio 的「取消勾选 Try mmap」，权重钉死显存
--reasoning-effort medium \ # ★ 控制思考链长度，省上下文+提速+不掉质量
-ngl all \ # 全部层进显存
-np 1 \ # 单用户 1 个槽位，KV 池全归你
--temp 0.4 --top-p 0.9 \ # 低温采样：准确度↑ + MTP 草稿接受率↑（双重提速）
--host 127.0.0.1 --port 8080⑤ 网页前端 + 开机自启
docker run -d --name open-webui --restart unless-stopped -p 3000:8080
-e OPENAI_API_BASE_URL=http://127.0.0.1:8080/v1
-e OPENAI_API_KEY=dummy
-v open-webui:/app/backend/data
ghcr.io/open-webui/open-webui:mainsystemd 单元（ /etc/systemd/system/qwen38.service ）要点： User=magicz890 、 ExecStart=上述完整命令 、Restart=on-failure 、 RestartSec=5 。
⑥ 部署后验收
./build/bin/llama-bench -m 模型路径 -c 8192 -n 64 # 先看短上下文速度
rocm-smi # 跑推理时盯着 GPU 频率，确认没卡在 idle 时钟五、速度预期
六、 准确度保障清单（按重要性排序）
七、7 稳定性保障清单（RDNA4 两个已知坑均已规避）
八、关于 256K 上下文的说明
九、注意事项
三、 多模态（视觉）方案
1、知识点
2、工作原理与显存账
结论：视觉不用降量化档，Q5_K_M 主力地位不变；只有 Q6_K 因余量不足被排除。
3、下载
DhruvalLabs 的 VLM 版 GGUF 仓库（主权重 + mmproj 配套，官方架构同源）
huggingface-cli download DhruvalLabs/Qwen3.8-27B-GGUF
Qwen3.8-27B-Q5_K_M.gguf Qwen3.8-27B-mmproj-f16.gguf
--local-dir /home/magicz890/models/qwen3.8
mmproj 必须与主权重配套（同一仓库、同一架构），不同作者混用会导致图像输出乱码或崩溃。4、 最终启动命令
./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 \ # ★ 视觉投影
-c 131072 \ # 128K 上下文
-ctk q8_0 -ctv q8_0 \ # KV 缓存量化
--spec-type draft-mtp \ # MTP 投机解码（必开）
-fa on \ # FlashAttention
-lm none \ # 权重钉死显存
--reasoning-effort medium \ # ★ 思考强度（默认 xhigh，必须压）
-ngl all -np 1 \ # 全层进显存、单槽位
--temp 0.4 --top-p 0.9 \ # 低温采样（图像 OCR/图表理解也受益）
--host 127.0.0.1 --port 8080
懒人方式： --hf-repo DhruvalLabs/Qwen3.8-27B-GGUF:Q5_K_M 会自动下载主权重和 mmproj（llama-server 内置支持）。5、使用方式
① Open WebUI（推荐，零成本）
OpenAI 兼容接口原生支持 image_url ，对话框直接拖图上传即可：OCR、图表分析、截图问 bug 都能用。② 直接调 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>"}}
]
}]
}'③ 视频
模型本身支持小时级长视频，但 llama.cpp 对该模型的视频采样支持属于前沿（官方长视频建议走 vLLM/
SGLang 调 video_preprocessor_config ）。建议：图片路线先用 llama.cpp 主力，有长视频刚需再单独起官方vLLM 容器。6、 多模态场景注意事项
1）图像 tokens 计入 128K 预算：连续贴图的长对话比纯文本更快填满上下文，控制单轮贴图数量；
reasoning-effort medium 在此更重要（省下的思考长度就是图像空间）。
2）默认思考强度是 xhigh：不设 --reasoning-effort 会「雷霆大思考」烧掉几十 K 上下文；medium 是底
线，图多时用 low；也可透传 chat_template_kwargs: {"enable_thinking": true, "reasoning_effort":"medium"} 。
3）低温采样对视觉任务同样重要：OCR/图表/数学题在 temp 0.3~0.5 下准确率明显更高，还顺带提高 MTP 草稿接受率。
4）别上 Q6_K 开视觉：余量只有 ~2GB，多图并发容易 OOM；Q5_K_M 是视觉场景的天花板档。
5）KV 缓存保持 q8_0：图像 tokens 会进 KV，q4_0 对长文档/图表问答有可测退化。
6）MTP 与视觉无冲突：32GB 档验证过「视觉+MTP+128K」同开；个别版本 mmproj 报错时优先升级最新llama.cpp（RDNA4 修复一直在进）。7、最终档位表
8、本机硬件参考
四、验收
1、总结：直接走「llama.cpp HIP 自编译 + DhruvalLabs Q5_K_M + mmproj + MTP(=2) + KVq8_0 + FlashAttention + 128K + reasoning-effort medium + 低温采样(temp
0.3)」， 前端 Open WebUI，systemd 常驻——这是针对「单用户、128K+、≥30 t/
s、稳定准确、多模态」全部需求、 在 R9700 32GB 上经过社区实测验证并已在本机实
测复核的最优组合； 128K 填满时的速度临界点按「压线四招」处理。2、需求对标
3、快照
-
@Magic629 自己的帖子不能修改吗？发帖之后可以修改的吧。只要没超时。另外你不用赌钱拿不发截图啊，你复制让AI整理成markdown就可以了。跑的时候有些日志，实拍显卡之类的，才需要图片。
-
@Magic629 自己的帖子不能修改吗？发帖之后可以修改的吧。只要没超时。另外你不用赌钱拿不发截图啊，你复制让AI整理成markdown就可以了。跑的时候有些日志，实拍显卡之类的，才需要图片。
-
@Magic629 自己的帖子不能修改吗？发帖之后可以修改的吧。只要没超时。另外你不用赌钱拿不发截图啊，你复制让AI整理成markdown就可以了。跑的时候有些日志，实拍显卡之类的，才需要图片。
-
@terry 这位道友可能碰到了跟我一样的问题， 发帖后我的时间显示是“8小时后”， 不知道为啥， 应该是时区的问题， 所以刚发完贴， 只能等8小时之后才能修改帖子， 因为“不能修改还未发表的帖子” （未来的帖子）。
-
@terry 这位道友可能碰到了跟我一样的问题， 发帖后我的时间显示是“8小时后”， 不知道为啥， 应该是时区的问题， 所以刚发完贴， 只能等8小时之后才能修改帖子， 因为“不能修改还未发表的帖子” （未来的帖子）。
