单卡7900XTX 24GB + 64GB DDR4 Avalon (Qwen3.8-Flash-Next) Windows 部署文档

mmiker

Avalon (Qwen3.8-Flash-Next) Windows 部署文档

日期：2026-11-07
硬件：AMD RX 7900 XTX 24GB / Ryzen 5 5600G / DDR4 双通道（系统实际识别 63.4 GB）
项目：https://github.com/freriadoc/Avalon （llama.cpp 分支，专为 Qwen3.8-Flash-Next 125B MoE 优化）
成果：Windows 下从零编译部署成功，实测生成 54–58 t/s（MTP，512 token）

一、最终部署布局

项	路径 / 值
源码	`C:\AI\Avalon`（git clone，main 分支）
可执行文件	`C:\AI\Avalon\build\bin\llama-server.exe`
启动脚本	`C:\AI\Avalon\avalon-server.bat`
模型	`C:\AI\models\Avalon-GGUF`（91 GiB，33 分片 IQ3_KS + MTP + moe-cache-ranking.bin）
HIP SDK	`C:\Program Files\AMD\ROCm\7.2`
编译脚本	`C:\AI\Avalon\build_windows.bat`（首次）/ `build_only.bat`（增量）
服务地址	`http://0.0.0.0:8080`（OpenAI 兼容 `/v1/chat/completions`）

️ 模型必须放在 NVMe SSD。放机械硬盘时生成仅 3–6 t/s，挪到 NVMe 后 49–58 t/s。模型里有个 36 GB 的 per-layer token embedding 张量每个 token 都要访问，HDD 随机读直接把速度打死。

二、环境准备

Visual Studio 2026 Community（含 MSVC 14.51、CMake、Ninja）——VS 自带 CMake 路径：
C:\Program Files\Microsoft Visual Studio\18\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\{CMake\bin\cmake.exe, Ninja}
AMD HIP SDK 7.2：官网下载页 → Windows 11 / 7.2，实际直链（1.6 GB）：
https://download.amd.com/developer/eula/rocm-hub/AMD-Software-PRO-Edition-26.Q3-Win11-For-HIP.exe
静默安装：Start-Process <exe> -ArgumentList '-install','-log','C:\AI\hip_install.log' -Verb RunAs -Wait（会弹 UAC）
git，python 3.14 + huggingface_hub（pip install huggingface_hub，下载用 hf.exe，位于 %APPDATA%\Python\Python314\Scripts）
网络代理：本机 127.0.0.1:7890 可用（git/curl 走 -x http://127.0.0.1:7890；GitHub 直连超时）

三、编译（关键坑与解法）

配置命令（在 build_windows.bat 内完成，需 vcvars64 环境）：

call "...\VC\Auxiliary\Build\vcvars64.bat"
set HIP_PATH=C:\Program Files\AMD\ROCm\7.2
set CXXFLAGS=-isystem C:\AI\Avalon\hip_compat
cmake -B build -G Ninja -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1100 ^
  -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
cmake --build build --target llama-server -j 8

坑 1：MSVC 14.51 `<cmath>` 与 HIP clang 冲突（必须修）

错误形态：

error: __device__ function 'isgreater' cannot overload __host__ __device__ function 'isgreater'
  （引用 MSVC 14.51 cmath 的 _CLANG_BUILTIN2(isgreater)）

原因：MSVC 14.51 起把 isgreater/isless 等声明为 constexpr（clang 下隐含 __host__ __device__），与 ROCm clang 的 __device__ 声明冲突。上游修复见 LLVM PR #201563、Strata PR #373。

解法（同 Strata 方案）：建垫片目录，并把 CXXFLAGS=-isystem <垫片目录> 加进环境：

// C:\AI\Avalon\hip_compat\cmath
#if defined(__HIP__)
#include <__clang_cuda_math_forward_declares.h>
#endif
#include_next <cmath>

注意：.bat 里不要写中文注释（GBK 代码页下 UTF-8 中文会破坏 cmd 解析）。

坑 2：`moe-cache.cu` POSIX `close()`（必须修）

ggml/src/ggml-cuda/moe-cache.cu 约 3647 行 close(f.second) 在 Windows 无此符号。修法：文件头部 _WIN32 块加 #include <io.h>，该处改为：

#if defined(_WIN32)
    _close(f.second);
#else
    close(f.second);
#endif

其他

Ninja 不在 PATH：把上面 VS 的 Ninja 目录加进 PATH。
直接 clang 链接失败（oldnames.lib 找不到）：必须在 vcvars64 环境里跑 CMake。
编译时长约 25 分钟（iGPU 6 核，283 个目标）。

四、模型下载

# 国内走 hf-mirror 更快；HuggingFace 官方源经代理实测会掉到 ~100KB/s
export HF_ENDPOINT=https://hf-mirror.com
hf download freriadoc/Qwen3.8-Flash-Next-Avalon-GGUF --local-dir C:\AI\models\Avalon-GGUF

39 个文件共 91 GiB，镜像实测 ~200MB/s、21 分钟下完；官方源经代理 3 小时仅 3 GB。
校验目录：33 个 Qwen3.8-Flash-Next-Avalon-IQ3KS-000xx-of-00033.gguf + MTP\mtp-...FR65k.gguf + moe-cache-ranking.bin。
与 Strata 的 IQ3_S 模型不通用（Avalon 用自有 IQ3_KS 混合量化 + 专属张量布局），必须单独下载。

五、启动脚本 `avalon-server.bat`

@echo off
set HIP_PATH=C:\Program Files\AMD\ROCm\7.2
set PATH=C:\AI\Avalon\build\bin;%HIP_PATH%\bin;%PATH%
set MODEL_DIR=C:\AI\models\Avalon-GGUF
set GGML_CUDA_MOE_ARENA_MB=46000

C:\AI\Avalon\build\bin\llama-server.exe ^
  -m "%MODEL_DIR%\Qwen3.8-Flash-Next-Avalon-IQ3KS-00001-of-00033.gguf" ^
  -c 262144 -b 9536 -ub 9536 -fa on -ctk q8_0 -ctv q4_0 --jinja --parallel 1 ^
  -md "%MODEL_DIR%\MTP\mtp-Qwen3.8-Flash-Next-shared-IQ3K-IQ4NL-FR65k.gguf" ^
  --spec-type draft-mtp --spec-draft-n-max 2 -ubd 256 -ctkd q8_0 -ctvd q8_0 ^
  --host 0.0.0.0 --port 8080 %*

要点：

GGML_CUDA_MOE_ARENA_MB=46000 是 Windows 上的必开项：Avalon 的 RAM 专家 arena 在 Windows 默认关闭（页缓存模式）。46 GB ≈ 专家总量 49 GiB 略留余量；内存紧张可降 40000。
--fit 默认开：稠密权重进 GPU，专家进内存，GPU 专家缓存自动吃剩余显存（本机约 12.5 GB，来自 moe-cache-ranking.bin 热度排序）。
KV 缓存 q8_0/q4_0，262k 上下文 + MTP 全装得下 24 GB 显存。

六、性能实测（RX 7900 XTX / 5600G / 63.4GB 可用内存）

配置	生成 512 token (MTP)	短 prompt 预填充	启动加载
模型在 HDD（HGST 2TB）	3.3 – 6.0 t/s	1.3 – 7.7 t/s	~9.5 分钟
模型 → NVMe SSD	49.4 t/s	~21 t/s	53 秒
+ 46GB 内存 arena	54 – 58 t/s	~26 t/s	—
作者参考（7900XT/64G/32k ctx）	98.4 t/s	~1700 t/s	—

按作者口径复测（32k ctx、贪心、MTP、3 轮平均）：57.7 t/s ≈ 标称 59%。差距主要来自：系统实际可用内存 63.4 GB（arena 装不满专家，部分走页缓存/SSD）+ CPU 6 核比作者 8 核慢。MTP 草稿接受率 0.58–0.73 正常，tail-skip 生效（[moe-cache] tail skip (rank >= 7) 日志可确认）。

排障速查

症状	原因	处置
速度个位数 t/s	模型在机械盘	挪 NVMe（robocopy /E /MT:8）
50 t/s 上不去 90+	内存 arena 未开或装不满	设 `GGML_CUDA_MOE_ARENA_MB`；检查系统实际可用内存
日志 `pin: 0 expert tensors registered`	内存不足/驱动注册上限	正常现象（Windows 报 KFD 上限），靠 arena 解决
首轮请求极慢	GPU 专家缓存冷	热身 1–2 轮后再测
API 报 ill-formed UTF-8	git-bash 里 curl 传中文被转码	测试用英文 payload

七、经验总结

磁盘 > 一切：本项目对存储延迟极敏感，模型必须在 NVMe；HDD 上速度差 10 倍。
Windows arena 默认关：README 的 GGML_CUDA_MOE_ARENA_MB=0 注释容易误读——"on Windows it is still the default" 指的是旧行为在 Windows 是默认，想要 RAM arena 必须显式设值。
VS 2026 (MSVC 14.51) + HIP SDK 7.2 的 cmath 冲突是必踩的坑，垫片头是官方认可解法；不想折腾可改装 VS 2022 的 MSVC 14.4x。
镜像下载：国内环境 HF_ENDPOINT=https://hf-mirror.com 比"官方源+代理"快百倍。
内存识别：装机内存 ≠ 系统可用内存，部署前先看 llama-server 日志里的 CPU: ... (64893 MiB, ...) 一行确认可用量。
与 Strata 模型不通用，别指望复用 IQ3_S 文件。

八、优化实验记录（作者口径：32k ctx、短 prompt、贪心、MTP、512 token ×3 轮）

实验	改动	结果 (t/s)	结论
基线	arena 46000, ub 9536, 32k ctx	57.7 平均	最优配置
① arena 拉满	51000MB	启动崩溃；50000MB 稳态 5-7	49.8G arena + 36G PLE > 63.4G 可用，页缓存风暴；图捕获还会崩 (`MUL_MAT_ID ... hosted MoE`)
② 专家缓存限显存	`--moe-cache 10000`（固定预算、禁用 weight repacking）	6.7	此 build 该模式走无 repack 慢路径（参数名是 `--moe-cache N`，不是 README 里的 `--moe-gpu-expert-cache-budget`，且 `-lmhead` 不存在）
③ README 7900 XTX 行配方	`ub 19072 + GGML_SCHED_PREFETCH_EXPERTS=6 + --moe-cache-cpu-overlap 2`	~43 收敛	该配方为 5900X/PCIe4/Linux 调的，5600G 上为负优化

与作者逐项对比（作者 98.4 t/s 标称）：

项	作者 (98.4)	本机 (57.7)	差异影响
GPU	7900 XT 20 GB	7900 XTX 24 GB	本机占优
CPU	3800XT 8C16T / 32MB L3	5600G 6C12T / 16MB L3	主差距（CPU 专家计算 + 图内 CPU 行）
GPU 链路	B450: PCIe 3.0 x16	Cezanne: PCIe 3.0 x16（13.6 GB/s）	同级
内存	DDR4-3200 DR	DDR4-3600	本机略优
OS	Linux（O_DIRECT，实测 64GB 全可用 99.1 t/s）	Windows（arena 上限约 46GB，PLE 36G 与专家 49G 不能同驻）	次差距
Windows 参照	—	ppkrol Windows 移植：XTX+5800X3D+64GB 实测 83.6–92.2 t/s	证明差距几乎全在 CPU（X3D 大 L3）

与 Strata 对比（README 作者同机）：Avalon 66.1 / 98.4（无MTP/MTP）vs Strata v0.2.9 HIP 51.1 / 68.4（+44% MTP）。本机：Strata 实测 49 t/s → Avalon 57.7（+18%）——CPU 越弱 Avalon 的架构优势越被掩盖。质量：Avalon IQ3KS 三篇文本困惑度全面优于 Strata 服务的 ISTA IQ3_S。

剩余优化空间（按性价比）：AM4 免换主板直上 5700X3D/5800X3D（预期 75–90 t/s，ppkrol 数据背书）＞其余参数已探到本平台上限。

九、256k 上下文性能实测（2026-11-08）

服务配置：262144 ctx、arena 46000、ub 9536、KV q8_0/q4_0、MTP 2 draft tokens。长文本 payload 用不同主题文本生成，避免前缀缓存干扰预填充计时。

场景	实测	作者同场景（README）
短 prompt @ 262k 配置	68.2 t/s	—
32k ctx 短 prompt（对照）	57.7 t/s	66.1 / 98.4 t/s
~112k token 填充	生成 75.4 t/s，预填充 598 t/s（194 s）	32k filled：62.3 / 88.0
~177k token 填充	生成 77.3 t/s，预填充 770 t/s	—
~234k token 填充	生成 70.5 t/s，预填充 774 t/s（310 s）	250k filled：57.3 / 81.1（预填充 1,491 / 1,342）

结论：

长上下文反而更快：填充 234k 后生成 70.5 t/s > 32k 短 prompt 的 57.7。长上下文激活更多热门专家 → GPU 显存专家缓存（12.5 GB，按 moe-cache-ranking.bin 热度）命中率大幅上升，CPU 读专家减少。
生成达到作者同场景的 87%（70.5 vs 81.1 @250k filled），比短 prompt 场景（59%）差距小得多——CPU 劣势被缓存高命中摊薄。
预填充约为作者一半（774 vs ~1,500 t/s），但填满 256k 上下文仅需 5–6 分钟，可用。
262k 全量配置可直接日用：三场景 70±7 t/s，无需为速度回退 32k。
payload 生成时按实测 ~5.1 字符/token 校准（英文正文），中文约 1.5–1.8 字符/token，需自行换算。

Xiaote

版主审定：本帖设为优秀，作者 +3 积分奖励，继续加油！

奖励凭证：优秀 +3 分 · 编号 e2905-2225-1

terry

CPU的影响不该这么大，可以再详细检查下，最好对比下Strata的同机数据，补充一点图。

抡锤者