@AGI 本地大模型部署在虚拟环境下的具体方案可以简单说一下吗？谢谢。
M
Magic629
@Magic629
-
Ubuntu 24 系统与 llama.cpp 服务器 健康度 · 功耗 · 温度控制 综合检查报告 （小白慢慢补图，我先报告完供大神审阅指正，谢谢！） -
测试SGLang 部署方案后最终恢复llama.cpp方案 —— 单卡AMD Radeon AI PRO R9700（gfx1201 / RDNA4） -
测试SGLang 部署方案后最终恢复llama.cpp方案 —— 单卡AMD Radeon AI PRO R9700（gfx1201 / RDNA4）1. 本机硬件 / 软件配置（实测）
项目 实测值 CPU Intel Core Ultra 7 265K（Arrow Lake，20 核 20 线程，最高 5.5 GHz，单 NUMA） 内存 64 GB（62 GiB 可用），8 GB swap GPU AMD Radeon AI PRO R9700（ gfx1201，RDNA4 / Navi 48，64 CU，300 W 功耗墙）显存 32 GB（ 34208743424 B≈ 31.9 GiB）硬盘 Kingston NV2 915 GB NVMe（剩余 721 GB） 操作系统 Ubuntu 24.04.4 LTS，内核 7.0.0-31-generic ROCm 7.2.4（HIP 7.2.5 / hipcc 22.0），amdgpu 驱动 7.1.3 Python 3.12.3（ /usr/bin/python3），pip 24.0其它 无 conda、无 Docker、无 uv；有 git 2.43 / cmake 3.28 / gcc 13.3 / make 4.3 GPU 状态 已就绪： rocm-smi正常识别 R9700，/dev/kfd存在，当前用户在render、video组网络 HuggingFace / PyPI / GitHub / repo.radeon.com 全部可达（200） 已有模型 ~/.cache/huggingface含mattbucci/Qwen3.8-27B-AWQ、Qwen/Qwen3.5-0.8B；另有 llama.cpp 的Qwen3.8-27B-Uncensored-Q5_K_M.gguf
2. 核心结论：SGLang 对 gfx1201 的支持现状
- 官方 ROCm 支持只覆盖数据中心卡：
gfx942（MI300/MI325）、gfx950（MI350）。官方 AMD 文档几乎只以 MI300X 为例。 - 消费级 RDNA 未被官方支持：SGLang 官方 tracking issue #30599 明确把 RDNA4
gfx1201列为「blocked /
不支持」，并指出 sgl-kernel 的 setup_rocm.py白名单会直接sys.exit(1)。 - 最新稳定版不含 gfx1201：截至整理时最新稳定版为 v0.5.19（2026-09-05）；实测
main分支sgl-kernel/setup_rocm.py白名单为gfx942 / gfx950 / gfx1250，不含 gfx1201。 - 可行路径 = PR #32092：开源 PR #32092 [AMD] Add experimental gfx1201 inference support 处于未合并（open）状态，但恰好是在「Radeon AI PRO R9700 + ROCm 7.2」上验证通过的（与本机显卡完全一致）。它自带完整构建/启动文档。
- 对比：vLLM 已把
gfx1200/gfx1201列入其 ROCm 构建（PYTORCH_ROCM_ARCH），对 RDNA4 的官方支持更成熟，可作为备选（见 §9）。
一句话：在本机这块 R9700 上跑 SGLang，今天只能走「从源码 + PR #32092」这条路；这是功能可用、但属实验性、单卡限定的方案。
3. gfx1201 实验支持的范围（PR #32092 实测边界）
支持（单卡、--tp 1）：- BF16 / FP16 稠密模型
- 在线 FP8 量化（稠密模型，
--quantization fp8） - BF16 / FP8 的 Triton 融合 MoE
- GPT-OSS 原生 MXFP4 检查点（
triton_kernelMoE runner）
不支持 / 未验证：- 多卡（张量并行 TP / 专家并行 EP）、custom all-reduce
- AITER（必须关闭：
SGLANG_USE_AITER=0） - AWQ / GPTQ / Marlin / gguf / modelopt / Quark MXFP4 等其它量化（官方标注「未支持」；AWQ 在 AMD 上走 Triton 反量化，理论上可能能跑，但不在 gfx1201 验证范围内，需自行试）
- 注意力后端只能用 Triton（FlashInfer / FA3 等不可用）
4. 最优部署步骤（从源码构建，gfx1201）
4.0 系统级调优（AMD 官方建议，单卡消费级可选但推荐）
# 1) 关闭 NUMA 自动平衡（AMD 官方 AMD GPU 文档建议；本机单 NUMA，影响较小） sudo sh -c 'echo 0 > /proc/sys/kernel/numa_balancing' # 2) 可选：/etc/default/grub 的 GRUB_CMDLINE_LINUX 追加（AMD MI300X 文档建议，单卡可跳过） # pci=realloc=off iommu=pt # 然后 sudo update-grub && reboot关键点：ROCm 7.2 原生支持 gfx1201（自 ROCm 6.4.1 起），无需
HSA_OVERRIDE_GFX_VERSION之类的兼容变量。4.1 创建独立虚拟环境（避免污染系统 Python）
sudo apt install -y python3-venv python3-dev python3 -m venv ~/sglang-gfx1201 source ~/sglang-gfx1201/bin/activate pip install -U pip setuptools wheel4.2 安装 ROCm 版 PyTorch（先装，避免被覆盖）
ROCm 7.2.4 对应的官方 pin 是 torch 2.11.0（SGLang
pyproject_other.toml的srt_hip_rocm724extra 明确torch==2.11.0）：# 只跑文本 LLM，装 torch 即可；torchvision/torchaudio 仅多模态需要 pip install torch==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2 # 需要多模态再加（版本号以 index 实际为准）： # pip install torchvision==0.26.0+rocm7.2 torchaudio==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2验证 GPU 可见：
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available(), torch.cuda.get_device_name(0))" # 期望: 2.11.0+rocm7.2 / True / AMD Radeon AI PRO R97004.3 克隆 SGLang 并检出 PR #32092（gfx1201 支持）
git clone https://github.com/sgl-project/sglang.git ~/sglang cd ~/sglang git fetch origin pull/32092/head:gfx1201 git checkout gfx12014.4 为 gfx1201 编译 sgl-kernel（单架构）
cd ~/sglang export AMDGPU_TARGET=gfx1201 export PYTORCH_ROCM_ARCH=gfx1201 export GPU_ARCHS=gfx1201 export SGLANG_USE_AITER=0 # RDNA4 上必须关闭 AITER cd sgl-kernel python setup_rocm.py install cd ..
️ 不要在同一份 sgl-kernel 构建里混入 CDNA 目标（gfx942/gfx950）；gfx1201 必须单独构建（wave32 vs wave64 差异）。4.5 安装 SGLang 所依赖的 triton_kernels 固定版本
PR #32092 依赖特定 revision 的
matmul_ogsAPI：pip install --no-deps \ "git+https://github.com/triton-lang/triton.git@4a24bf0b19a027ec0833b31cbc9ac29add7b17af#subdirectory=python/triton_kernels"4.6 安装 SGLang Python 包（HIP 版）
cd ~/sglang # 切到 ROCm 版 pyproject（AMD 官方文档的标准步骤） rm -rf python/pyproject.toml && mv python/pyproject_other.toml python/pyproject.toml pip install -e "python[all_hip_rocm724]" # 若安装过程把 torch 覆盖成 CUDA 版，强制装回 ROCm 版： # pip install --force-reinstall --no-deps torch==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2all_hip_rocm724= 面向 ROCm 7.2.4 / torch 2.11 的依赖集（pyproject_other.toml中已定义，pintorch==2.11.0）。
5. 启动服务器（32 GB 显存的最优参数）
5.1 推荐方案：Qwen3.8-27B 在线 FP8（gfx1201 已验证的稠密量化路径）
source ~/sglang-gfx1201/bin/activate cd ~/sglang export SGLANG_USE_AITER=0 python3 -m sglang.launch_server \ --model-path Qwen/Qwen3.8-27B \ --quantization fp8 \ --dtype bfloat16 \ --attention-backend triton \ --sampling-backend pytorch \ --model-loader-extra-config '{"enable_multithread_load": false}' \ --tp 1 \ --mem-fraction-static 0.90 \ --chunked-prefill-size 2048 \ --host 0.0.0.0 \ --port 30000参数说明：
--quantization fp8：在线 FP8 量化，把 BF16 权重动态量化为 FP8（~28.5 GB），是 gfx1201 上已验证的稠密模型量化方式。--dtype bfloat16：计算 dtype。--attention-backend triton：gfx1201 只能走 Triton 注意力。--sampling-backend pytorch：配合 Triton 使用（AMD 常见组合）。--model-loader-extra-config '{"enable_multithread_load": false}'：PR 文档明确要求——单线程加载，规避 RDNA4 上并行 checkpoint 加载时的 host→device 拷贝卡顿（不影响推理速度）。--tp 1：gfx1201 只支持单卡。--mem-fraction-static 0.90：给 32 GB 显存留 ~2.9 GB 余量，27B-FP8 能放进且不会 OOM。--chunked-prefill-size 2048：小分块 prefill，兼顾 TTFT 与 decode 延迟（27B 混合 GDN 模型上尤其实用）。
️ 在线 FP8 需要先完整下载 BF16 版 Qwen3.8-27B（~54 GB），再量化进显存。下载量大但显存占用只有 ~28.5 GB，32 GB 卡上只能低并发（bs ≤ 2）。5.2 备选：直接跑本机缓存的 AWQ 模型（需自行验证）
python3 -m sglang.launch_server \ --model-path mattbucci/Qwen3.8-27B-AWQ \ --quantization awq \ --dtype bfloat16 \ --attention-backend triton \ --sampling-backend pytorch \ --model-loader-extra-config '{"enable_multithread_load": false}' \ --tp 1 --host 0.0.0.0 --port 30000- AWQ 4-bit 权重 ~15 GB，显存压力小很多、并发更高。
- 但 AWQ 不在 gfx1201 官方验证范围内（官方文档明说「其它量化格式未支持」）。AMD 上 AWQ 走 Triton 反量化，理论上可行，建议实测；报错就回退到 §5.1 的 FP8。
5.3 更稳的小模型（首次跑通验证环境用）
# Qwen3.5-0.8B（你已缓存）——先验证整条链路能跑通 python3 -m sglang.launch_server \ --model-path Qwen/Qwen3.5-0.8B \ --dtype bfloat16 \ --attention-backend triton \ --sampling-backend pytorch \ --model-loader-extra-config '{"enable_multithread_load": false}' \ --tp 1 --host 127.0.0.1 --port 30000看到日志输出
The server is fired up and ready to roll!即启动成功。然后用 OpenAI 兼容接口测试：curl http://127.0.0.1:30000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"Qwen/Qwen3.5-0.8B","messages":[{"role":"user","content":"你好"}]}'
6. 32 GB 显存能装什么（模型选型建议）
模型 精度 显存占用 可行性 Qwen3.8-27B BF16 ~54 GB 放不下Qwen3.8-27B 在线 FP8 ~28.5 GB ️ 紧，仅低并发（已验证路径）Qwen3.8-27B AWQ 4bit ~15 GB ️ 需实测（AWQ 未验证）Qwen3-30B-A3B / Qwen3.8-35B-A3B（MoE） BF16/FP8 ~18–22 GB Triton MoE 已支持，性价比高Qwen3-14B / Qwen2.5-14B BF16 ~28 GB 稳Qwen3-8B / Qwen2.5-7B BF16 ~16 GB 稳、并发高GPT-OSS-20B 原生 MXFP4 ~13 GB 已验证（MoE 路径）
7. 性能 / 调优要点
- 只跑单卡：gfx1201 不支持 TP/EP，
--tp 1是唯一选择。 SGLANG_USE_AITER=0必须设置：AITER 是 CDNA 专用，RDNA4 上会报错。- 注意力后端锁死
triton，采样后端配pytorch。 --mem-fraction-static：32 GB 卡上给 0.85–0.90，留余量避免 OOM。--chunked-prefill-size 2048：长输入/混合负载下让 decode 不被长 prefill 卡住。- KV cache 量化：
--kv-cache-dtype fp8_e4m3可进一步省显存（若模型/后端支持）。 - 大检查点加载慢：ROCm 下 host 内存注册可能耗时数分钟，属正常；PR 要求单线程加载。
- 若追求吞吐，优先选 MoE 小参数（Qwen3-30B-A3B 类）而非硬塞 27B 稠密。
8. 风险与注意事项
- PR #32092 未合并：属实验代码，可能不跟随最新 main；建议锁定其分支 commit 后不要再
git pull main。 - 无预编译 wheel / 官方 Docker 镜像支持 gfx1201：本机也没装 Docker，因此源码构建是唯一现实路径。
- 量化限制：不要用
awq_marlin / gptq_marlin / gguf / modelopt_fp8 / modelopt_fp4（Marlin/gguf 是 CUDA 专用）。 - 构建时间长：sgl-kernel 全量 HIP 编译可能需 20–60 分钟，
MAX_JOBS可调（CPU 20 线程可设MAX_JOBS=16）。 - gfx1201 与 CDNA 不可混编：一份构建只对一个架构。
9. 备选方案（若 SGLang 实验路径不稳）
- vLLM：已官方支持
gfx1200/gfx1201（其Dockerfile.rocm_base的PYTORCH_ROCM_ARCH含这两个目标），对 RDNA4 更成熟，同样有 ROCm 版安装/Docker 路径，是「想要稳定 OpenAI 兼容推理服务」时最直接的替代。 - llama.cpp / Ollama：你机器上已装 llama.cpp 且有
Qwen3.8-27B-Uncensored-Q5_K_M.gguf，现在就能跑，无需任何额外构建；适合本地对话/低门槛场景，但没有 SGLang 的连续批处理/radix cache 等高级特性。 - 若必须用 SGLang 的全套特性（radix cache、speculative decoding、结构化输出等），则按本方案 §4–§5 走 PR #32092。
10. 参考链接 （感兴趣可以自查）
- SGLang 官方 AMD GPU 文档
- SGLang 官方安装文档
- SGLang 量化兼容矩阵
- GitHub issue #30599：官方 RDNA3/RDNA4 支持追踪
- GitHub PR #32092：Add experimental gfx1201 inference support（本方案核心）
- PyTorch ROCm 轮子索引
- AMD Radeon/Ryzen PyTorch 安装指南
11.后续查资料继续实验及恢复
本机硬件 / 软件配置（实测）
项目 值 CPU Intel Core Ultra 7 265K（Arrow Lake，20 核 20 线程，最高 5.5 GHz，单 NUMA） 内存 64 GB，8 GB swap GPU AMD Radeon AI PRO R9700（gfx1201 / RDNA4 / Navi 48，64 CU，300W） 显存 32 GB 硬盘 Kingston NV2 915 GB NVMe 系统 Ubuntu 24.04.4 LTS，内核 7.0.0-31-generic ROCm 7.2.4（HIP 7.2.5），amdgpu 驱动 7.1.3 Python 3.12.3
12、SGLang 调研结论
- SGLang 官方 ROCm 支持只覆盖数据中心卡
gfx942（MI300）、gfx950（MI350）；消费级 RDNA4gfx1201属实验性、未合并（官方 tracking issue #30599，PR #32092）。 - 最新稳定版 v0.5.19 的 sgl-kernel 白名单不含 gfx1201，需从源码 + 社区补丁构建。
- 已在本机从源码（release/v0.5.18 + gfx1201 补丁）构建并部署，模型 Qwen3.8-27B-AWQ。
13、SGLang 部署结果（已被清理，此处留档）
- 部署形式：systemd 用户服务
sglang，端点http://127.0.0.1:30001。 - 配置：AWQ 4-bit + float16 + triton 注意力 + CUDA graph 解码，显存 ~29.9/32 GB。
- 实测速度：~4.3 tok/s（27B AWQ 在 RDNA4 上走未优化 Triton 反量化，偏慢）。
- 结论：27B 在 R9700 上物理上限约 16.6 tok/s（社区 70 补丁 + FP8 极限），达不到 50 tok/s。
14、快速方案研究结论
- 要 ≥50 tok/s 只能换 7–8B 小模型，实测 ~98 tok/s（llama.cpp/Ollama 原生 gfx1201）。
- 本机 llama.cpp（HIP 后端）实测 27B 可达 ~38–57 tok/s，远快于 SGLang 的 4.3 tok/s。
15、最终清理（按用户要求）
已删除：
- SGLang 运行服务（systemd 用户单元
sglang.service+ 软链） ~/sglang-test/整个目录（含 25GB venv、227MB 源码、全部脚本与日志，共约 45GB）~/.cache/sglang编译缓存loginctl enable-linger（已还原为 disable）- 桌面 5 个 SGLang 相关文档（.md / .pdf）
已保留（模型文件）：
~/models/Qwen3.8-27B-AWQ（18GB，HF 格式 AWQ 模型）~/models/Qwen3.5-0.8B（1.7GB）~/models/qwen3.8/（38GB：Qwen3.8-27B-Uncensored-Q5_K_M.gguf、Qwen3.8-27B-Q5_K_M.gguf、mmproj-f16.gguf）
16、llama.cpp 恢复与测试（当前状态）
- 服务：systemd
qwen38.service（active运行中 +enabled开机自启） - 启动命令：
/home/magicz890/llama.cpp/build/bin/llama-server- 模型
-m Qwen3.8-27B-Uncensored-Q5_K_M.gguf+--mmproj mmproj-f16.gguf - 别名
--alias qwen3.8，上下文-c 131072（128K），KV 量化q8_0 - 推测解码
--spec-type draft-mtp --spec-draft-n-max 2，flash attention-fa on -ngl all（全 GPU）、--host 0.0.0.0 --port 8080
- 模型
- 健康检查：
/health→{"status":"ok"}；/v1/models正常（含多模态能力） - 推理测试：中文输出正确、3 路并发全 200、无错误日志
- 实测解码速度：长生成 ~50 tok/s，短回答 90–105 tok/s（MTP 命中时）
17、最终状态一览
项 状态 SGLang 服务/软件/缓存/文档 已全部删除（零残留） 模型文件 保留在 ~/models/（共 ~57GB）llama.cpp（qwen38.service） 运行中、自启、端口 8080、稳定 桌面文件 AMD_AI_Pro_R9700_SGLang_部署研究报告、ceshi/、llama_cpp服务端待机诊断报告.pdf、本文件
常用管理命令
# llama.cpp 服务 systemctl status qwen38.service # 查看状态 sudo systemctl restart qwen38.service # 重启 journalctl -u qwen38.service -f # 看日志 # 测试接口 curl http://127.0.0.1:8080/health curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen3.8","messages":[{"role":"user","content":"你好"}]}' - 官方 ROCm 支持只覆盖数据中心卡：
-
Ubuntu 24 系统与 llama.cpp 服务器 健康度 · 功耗 · 温度控制 综合检查报告 （小白慢慢补图，我先报告完供大神审阅指正，谢谢！） -
Ubuntu 24 系统与 llama.cpp 服务器 健康度 · 功耗 · 温度控制 综合检查报告 （小白慢慢补图，我先报告完供大神审阅指正，谢谢！） -
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。@imbiplaza-ASUS 我也想试试sglang怎么样？今晚是不是要搞搞看啥是sglang，我也很好奇。
-
小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻 -
小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻 -
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。@williamlouis 感谢指点，我已换到Ubuntu24.04中，确实提速很明显。我在Ubuntu中部署的时候，显卡驱动安装时有几次失败，在彻底断电以后等待10秒，然后重启驱动加载成功，这个是我遇到的一个坑，希望其他人别遇到。
-
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。@imbiplaza-ASUS 谢谢指点！感谢
-
Qwen3.8-27B 本地服务器部署与验收报告（AMD Radeon AI PRO R9700 32GB ｜ llama.cpp HIP ｜ 128K 上下文 ｜ 多模态 ｜ MTP 投机解码）请参考指正，谢谢！ -
小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻 -
Ubuntu 24 系统与 llama.cpp 服务器 健康度 · 功耗 · 温度控制 综合检查报告 （小白慢慢补图，我先报告完供大神审阅指正，谢谢！）主机名：magicz890-Ai
操作系统：Ubuntu 24.04.4 LTS (Noble Numbat)
内核：7.0.0-30-generic
处理器：Intel Core Ultra 7 265K（20 线程）
计算 GPU：AMD Radeon AI PRO R9700（32 GB）
显示 GPU：Intel 核显（Arrow Lake-U，4K 输出）
推理服务：qwen38.service（Qwen3.8-27B-Q5_K_M）本报告汇总了三次只读检查的完整结果：① 系统整体健康度与功耗；② 待机功耗与温度控制机制；③ 针对"学习 +日常办公 + 7×24 推理"用法的 GPU 功耗模式建议。所有数据均为实测，未执行任何修改操作。
一、系统健康度与功耗报告
1、系统概况
2、温度（全部正常）
3、功耗（RAPL + rocm-smi 实测）
整机估算：推理时约 80–100 W，空闲时更低。功耗水平健康。
4、llama.cpp 服务器（qwen38.service）
近期推理性能（日志实测，30 分钟内多次任务）
- 生成速度：37–44 tokens/s（tg_3s 峰值 47.4 t/s）
- Prompt 处理：163–420 tokens/s
- MTP 草稿接受率：0.78–0.88，平均长度 2.57–2.76（投机解码效果很好）
- 单次任务上下文 1.9–2.1 万 token，无截断、无报错
日志健康度
近 30 分钟日志全部为正常推理记录，无 error/warning。系统日志中仅有两类无害告警：gnome-shell dock 布局的常规噪音，以及 Canonical Livepatch 检查网络失败（livepatch.canonical.com 连接 EOF，会自动重试，不影响系统）
5 结论
- 系统健康度：优 —— 负载低、内存充裕、磁盘充足、CPU 温度 44°C、无 OOM/硬件错误。
- llama.cpp 服务器：健康且活跃 —— 服务稳定运行 19 小时，推理吞吐 ~40 t/s，投机解码接受率 ~0.8，正在持续处理请求。
- 功耗：CPU ~32 W + GPU ~50 W，整机推理时约 80–100 W，水平正常。
- 唯一可留意点：GPU 显存温度 82°C 略偏高（推理满载时），以及显存占用 86%——均为 131k 长上下文 + 27B 模型的预期行为，暂无风险。
二、整机待机功耗与温度控制深度检查报告
重要前提：这台机器没有真正的"待机"状态——
qwen38.service（llama-server）在持续对外服务，检查期间它一直在处理推理任务。因此下面的"待机功耗"实际上是"轻载基线"：CPU 只忙 6.8%（推理在 GPU 上），但 GPU 随时会被唤醒。2.1 待机（轻载）功耗实测
CPU 包（turbostat 两轮 5 秒采样）
指标 第 1 轮 第 2 轮 PkgWatt（整包） 32.8 W 31.5 W CorWatt（核心） 23.6 W 22.3 W GFXWatt（核显） 0.45 W 0.44 W RAMWatt 未测量（无 PMT 计数器） — CPU 忙碌度 6.8% 6.6% 平均频率 254 MHz 237 MHz 包温度 39 °C 39 °C GPU（Radeon AI PRO R9700，rocm-smi 多次采样）
采样点 功耗 使用率 采样 1 56 W（滑动平均） 3% 采样 2（6 秒后） 23 W 3% GPU 空闲时自动降频：sclk 1128 MHz（最高 2350）、mclk 96 MHz（最高 1258）——降频策略工作正常。
其他部件
部件 状态 NVMe (nvme0n1) 温度 40 °C，IO 仅 ~184 KB/s，基本静默 核显（显示输出） 0.45 W，RC6 空闲态 17.6% 内存控制器 (SAM) 99.2% 时间处于 mc6 深度空闲 整机待机功耗估算
部件 功耗 CPU 包 ~32 W GPU（空闲波动） ~23–56 W 内存 + 主板 + NVMe + 外设（估算） ~15–25 W 整机合计（轻载基线） 约 70–110 W 对比：推理满载时 CPU ~32 W + GPU 明显升高，整机约 100–150 W。
2.2 温度控制情况
当前温度（全部健康）
部件 温度 评价 CPU 包 39–40 °C 很凉 CPU 核心 38–40 °C 正常 GPU edge 62 °C（推理时 68–72） 正常 GPU junction 74 °C（推理时 79） 正常 GPU 显存 71 °C（推理峰值 82–91） 可接受，见建议 NVMe 40 °C 正常 主板 (acpitz) 27.8 °C 正常 热保护与调频机制（重点检查项）
检查项 结果 评价 热节流计数（package/core） 0 次 / 0 次 从未触发过热保护CPU 调频驱动 intel_pstate + HWP 硬件调频 最优方案调频策略 powersave，EPP：核心 0x40（balanced）、包 0x80（powersave） 偏节能配置系统电源策略 power-profiles-daemon = balanced 合理C 状态驻留 c1 40% / c6 30% / c7 22% 深度睡眠使用充分内存控制器空闲 mc6 99.2% 优秀GPU 空闲降频 sclk/mclk 均降至最低档 正常GPU 功耗模式 BOOTUP_DEFAULT（默认档） 可用，见建议 磁盘/定时任务 无异常 IO；定时任务正常 部件健康度
- NVMe：磨损 3%、备用块 100%、无 critical warning、通电 7269 小时——非常健康。
- llama-server 服务：运行 19 小时无重启、无错误日志，推理 37–44 t/s，MTP 接受率 0.74–0.88。
- 系统日志仅两类无害告警：gnome-shell dock 布局噪音、Canonical Livepatch 联网检查失败（自动重试中，不影响运行）。
2.3 结论
- 温度控制：优秀 —— 零热节流事件，CPU 39°C / GPU 62–74°C，HWP + powersave + 深度 C 状态全部生效，空闲降频正常。
- 待机功耗：正常但偏高（约 70–110 W） —— 主要构成是 CPU 包 ~32 W（265K 是 125W TDP 的桌面级芯片，基线功耗天然不低）+ GPU 23–56 W + 平台开销。由于 LLM 服务器 7×24 运行，机器永远达不到纯待机。
2.4 建议（仅供参考，未执行任何一项）
- 想测真实待机功耗：临时
systemctl stop qwen38后再用turbostat采样，可看到纯平台基线（预计 CPU 包降到 ~20–25 W，整机 ~40–60 W）。测完systemctl start qwen38恢复。 - GPU 功耗模式：当前是
BOOTUP_DEFAULT。若主要跑推理，可考虑COMPUTE档，对计算负载的功耗/性能调度更优；混合用途则保持现状即可（详见报告三）。 - 显存温度：推理满载时 82–91°C 属规格内但偏高，建议留意机箱风道；R9700 是涡轮卡，确保进风口无遮挡。
- 加监控：llama-server 启动参数加
--metrics，之后/metrics端点可出 Prometheus 指标，配合现有 sysstat 定时任务做长期追踪。 - Livepatch 告警：livepatch.canonical.com 连接失败在反复重试，若不用 Livepatch 可忽略；在意日志干净可考虑停用该服务。
- 内存功耗不可测：turbostat 的 RAMWatt 为 0（该平台无 PMT 计数器），如需精确整机功耗，最可靠的方法是用外置功率计（插排计量插座）实测墙端功耗。
三、GPU 功耗模式（COMPUTE 档）详细建议
3.1 关键发现：AMD 卡是"纯计算卡"
GPU 型号 显示输出 角色 card0 Intel 核显 (Arrow Lake-U) HDMI-A-1 已连接，4K 3840×2160 负责所有显示/办公/学习画面 card1 AMD Radeon AI PRO R9700 无任何显示器连接 纯计算，只跑 LLM 推理 办公、学习、看网页、写文档时，AMD 卡完全空闲，画面全由 Intel 核显 + CPU 承担。AMD 卡唯一的活儿就是给 llama-server 做推理。对一块"只干计算、不碰显示"的卡，COMPUTE 档就是为它量身定做的。
3.2 各档位差异（基于该卡实际 DPM 参数）
档位 最低核心频率 功耗上限 加速 (Boost) 定位 BOOTUP_DEFAULT（当前） ~500 MHz 800（较保守） 自动 通用均衡，偏省电 COMPUTE 600 MHz（固定下限） 16384（高，放开） 解除限制 持续计算优化 POWER_SAVING ~500 MHz 0 受限(3) 最省电，牺牲性能 3D_FULL_SCREEN / WINDOW_3D ~500 MHz 0 满加速(1) 游戏，瞬时高帧 VIDEO ~500 MHz 500 自动 视频播放省电 VR 600 MHz 16384 解除 与 COMPUTE 几乎相同 核心差异两点：
- COMPUTE 把核心频率下限抬到 600 MHz（默认约 500），空闲时略高一点点；
- COMPUTE 放开了功耗上限（16384 vs 800）并解除加速限制——长时间推理时 GPU 能维持更高、更稳定的频率，不容易被功耗墙压频。
3.3 建议：切到 COMPUTE 档
理由（针对"学习 + 办公 + 7×24 推理"场景）：
- 负载性质完全匹配：AMD 卡 100% 的负载是推理（持续计算），COMPUTE 正是为这种"长时间、稳定、吃算力和显存带宽"的负载调的。
- 减少长推理压频：单次任务动辄 2–4 万 token、跑十几秒，属持续负载。默认档的保守功耗墙（800）更易触发降频；COMPUTE 放开功耗墙后，长任务的 tokens/s 更稳、峰值更高。
- 没有"显示"副作用：显示器接在 Intel 核显上，COMPUTE 抬高的频率下限不会让办公画面变卡或更耗电——那块卡办公时根本闲着。
- 代价极小：600 vs 500 MHz 的下限差，空闲功耗只多 ~1–2 W，可忽略；温度方面 GPU 现在才 62–74°C，余量充足。
什么情况下不建议切（供权衡）：
- 若把"极致省电"排在"推理速度"前面，且能接受推理略慢/略不稳，保持
BOOTUP_DEFAULT也完全没问题——它本就是安全的均衡档。 - 但就"卡只干推理"的用法看，COMPUTE 的收益（更稳更快的推理）明显大于代价（多 1–2 W 空闲功耗）。
一句话结论：建议切 COMPUTE。 它和这块纯计算卡的用法是最佳匹配，收益实在、代价可忽略。
3.4 如何验证（A/B 测试，建议先测再定）
-
记录基线（当前 BOOTUP_DEFAULT）：跑一个固定 prompt 的推理，记下 tokens/s、
rocm-smi --showpower、GPU 温度。 -
临时切档（立即生效，重启即还原，不改任何文件）：
echo 5 | sudo tee /sys/class/drm/card1/device/pp_power_profile_mode（5 = COMPUTE；改完用
cat同一文件确认，*号会移到 COMPUTE 上） -
重复同样的推理，对比 tokens/s、功耗、温度。
-
满意就保留，不满意
echo 0 | sudo tee ...切回默认。
注意：
pp_power_profile_mode是运行时设置，重启后会回到BOOTUP_DEFAULT。3.5 若决定长期用 COMPUTE，如何持久化（三选一）
- systemd 覆盖 qwen38.service（最贴合，随推理服务一起生效）：加一个
ExecStartPre在启动 llama-server 前写入档位。 - udev 规则：在 amdgpu 设备就绪时自动写入，开机即生效，与具体服务解耦。
- 独立 oneshot systemd 服务：开机跑一次
echo 5 > .../pp_power_profile_mode。
三者都能做到"开机自动 COMPUTE"，选 1 最省事（和推理服务绑定）。
3.6 补充提醒
- 切档后留意一次满载温度：显存峰值到过 82–91°C，COMPUTE 放开功耗墙后满载会略热，确认机箱风道没问题即可（R9700 是涡轮卡，别堵进风口）。
- 这个改动只影响 AMD 计算卡，对办公/学习的 Intel 核显显示路径零影响。
- 按用户要求，本次未做任何修改，以上全部是查看 + 建议。
本报告由只读检查生成，所有数据均为实测值。检查过程中未对系统、服务或配置做任何修改。生成工具：weasyprint（HTML → PDF），字体：Noto Sans CJK SC。
刚学会用.md文件，后期是用.md文件复制过来的，请包含，版面有点乱。小白积极参与请大家多多包涵
刚拍了张照片测试下
-
Qwen3.8-27B 本地服务器部署与验收报告（AMD Radeon AI PRO R9700 32GB ｜ llama.cpp HIP ｜ 128K 上下文 ｜ 多模态 ｜ MTP 投机解码）请参考指正，谢谢！一、部署
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 -j20build/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 80802、参数作用对照表
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: onllama-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十、先到这吧……
-
小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻 -
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。@williamlouis 我换成Ubuntu24.04以后，Token一般可以稳定在35-45之间。除非上下文用到100K后会下降到32左右。处理一般任务足够了，短上下文可以在43左右。
-
小白熬夜瞎折腾、瞎写，后期补齐验收报告，请各位大神指正。同时感谢特哥提供的交流平台🙏🏻🙏🏻🙏🏻一、部署
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、快照
-
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。 -
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。 -
本人小白，希望得到论坛大神指点，在win系统和Ubuntu系统里部署本地大模型运行验证资料。这几天一直在看特哥的视频，真的收获很大，先特此表达一下感谢
。同时也想借此机会请教一个问题。最近我入手了一张 AMD AI Pro R9700 显卡，并在 AI 助手的帮助下，在本地部署了 Qwen3.8-27B 模型，主要用于日常实验和办公学习。我本人算是纯小白，不太懂底层技术，基本是靠 AI 一步步指导完成的。
使用几天后，我注意到一个现象：在上下文长度设为 256K 的情况下，token 生成速度从原来的 30+ 降到了 20+ Tokens/s，性能有一定回落。
由于在特哥的视频里经常听到，在 Ubuntu 系统下部署模型，性能和稳定性会更有优势，所以我特意让帮我部署的 AI 查了相关资料，并尝试验证这个说法是否成立。不过得到的反馈是“提升空间不大，没必要再折腾”。
考虑到自己经验有限，还是想把这几天的部署和测试资料整理出来，发到论坛里供大家参考，也真心希望能听听各位有经验的大佬的看法和建议。
提前谢谢各位了～！
llama-cpp-局域网AI服务器-完整部署手册.pdf llama-cpp-模型服务启动与使用指南.pdf llama-cpp-Qwen3.8-部署与测试报告.pdf llama-server修改规划与验证结果-2026-09-02.pdf
