从 41 到 56 tok/s:我修好了 DFlash 官方 benchmark 的 bug,顺手在 7900 XTX 上搭了全套联网大模型
-
27B 不能联网 搜索的问题。很多人提问。提供一个解决方案吧。在不借用 hermes的情况下如何实现。安装后测试完全可用。建议 32G显存。24G可用但是不能太复杂。
全程使用 kimi k3 1M max 配置
实施时长:1小时。主要原因是网速。网速慢的时候得1.5小时Qwen3.6-27B 本地部署方案与测试报告
一、环境
项 配置 CPU / 内存 i7-4790K(4C/8T)/ 32 GiB DDR3 GPU RX 7900 XTX 24 GiB(gfx1100),驱动 amdgpu 6.16.13,ROCm 7.2.0 系统 Ubuntu 24.04,kernel 6.14,磁盘余量 637G 网络 局域网固定 IP 192.168.8.247(路由器锁定)
二、总体架构
浏览器 → Open WebUI (:8080, venv) → dflash_server (:8000, C++/HIP) → 7900 XTX │ Q4_K_M 主模型 16G + Q8_0 DFlash 草稿 1.8G(DDTree 树验证)- 推理引擎:Lucebox DFlash(lucebox-hub 源码编译),块扩散草稿 + DDTree 树验证投机解码
- 隔离原则:venv 只隔离 Python 工具链(下载/前端);模型即 GGUF 文件,多模型切换零隔离成本;未用 Docker
- 启动命令:
dflash(模型 API)、dflash-ui(网页前端),GPU 高性能模式随服务启停自动切换(解决空载风扇噪音)
三、安装步骤(可复现)
# 1. 依赖 apt-get install -y git cmake build-essential hipblas-dev hipcub-dev \ rocblas-dev rocprim-dev rocwmma-dev python3-venv # 2. 源码 git clone --recurse-submodules https://github.com/Luce-Org/lucebox-hub cd lucebox-hub/server # 3. 编译(gfx1100,含 rocWMMA Phase2 prefill kernel) cmake -B build -S . -DCMAKE_BUILD_TYPE=Release -DDFLASH27B_GPU_BACKEND=hip \ -DDFLASH27B_HIP_ARCHITECTURES=gfx1100 -DDFLASH27B_HIP_SM80_EQUIV=ON cmake --build build --target test_dflash dflash_server test_flashprefill_kernels -j4 ./build/test_flashprefill_kernels # 数值验证 # 4. Python 工具(venv) python3 -m venv ~/venvs/dflash && ~/venvs/dflash/bin/pip install huggingface_hub transformers open-webui # 5. 模型 hf download unsloth/Qwen3.6-27B-GGUF Qwen3.6-27B-Q4_K_M.gguf --local-dir ~/models/ hf download Lucebox/Qwen3.6-27B-DFlash-GGUF dflash-draft-3.6-q8_0.gguf --local-dir ~/models/draft/
四、关键调优与踩坑记录
坑 根因 解法 官方 bench 速度虚低(41 t/s) bench_he.py只传--ddtree-budget不传--ddtree,源码里预算不启用树模式直接驱动 test_dflash补--ddtreebudget≥16 速度腰斩 verify token 数 >16 触发 TILE kernel(gfx1100 上的慢/不稳路径) 实测甜点 budget=12(VEC 路径内 AL 平台期上限)Q8_0 草稿必需环境变量 滑窗正确性 DFLASH27B_DRAFT_SWA=2048运行中 OOM 崩溃 64K 上下文 KV 全量预分配 + 前缀缓存 32 槽不限量 MAX_CTX=32768+--prefix-cache-slots 8前端报超上下文 Open WebUI 发 max_tokens=32768服务端 --default-max-tokens 8192(§4.4 钳制,日志已验证)风扇空载狂转 DPM 常驻 high 启动脚本内 high,退出 trap 回 auto
五、测试报告
测试项 结果 rocWMMA kernel 数值验证 全部 PASS(S=8192:18.3 ms/iter) AR 基线( test_generate)25.87 tok/s 投机链模式(缺 --ddtree)41.4 tok/s DDTree budget=12(10-prompt 均值) 44.46 tok/s,AL 4.65,接受率 29.5%,1.72× AR API 实测:英文代码 53.9 tok/s(接受率 34%) API 实测:中文对话 19.8 tok/s(草稿为代码优化,中文收益低,属预期) 显存占用(稳定运行) 19.6 / 24 GiB,余量 4+ GiB 注:参考文章的 81 tok/s 未复现,原因有二——其使用 6 月旧版引擎(现行版在 gfx1100 有性能回退),且其 CPU 为双路 E5;本文数据为本机多次实测均值。
六、Web 支持(Open WebUI)
pip install open-webui装入同一 venv;启动脚本dflash-ui注入:OPENAI_API_BASE_URL(S)=http://127.0.0.1:8000/v1ENABLE_OLLAMA_API=false
- 访问
http://192.168.8.247:8080,首个注册账号自动成为管理员(数据全在本机)
七、网页搜索实现
原理:模型本身不联网。Open WebUI 中间件在调用模型前先用 DuckDuckGo(
ddgs,免 API key,本机直连已验证)检索,把结果注入提示词,模型基于注入内容作答并附引用。配置落地(两个教训)
- 该版本配置键为
ENABLE_WEB_SEARCH/WEB_SEARCH_ENGINE(而非旧版ENABLE_RAG_WEB_SEARCH); - 首次启动会把默认值持久化进 SQLite(
…/site-packages/open_webui/data/webui.db),之后 env 改不动——最终直接改库:web.search.enable=trueweb.search.engine="duckduckgo"result_count=3
使用方式
全局开关只是放行;每个对话需在输入框点 地球图标(代码依据
middleware.py:2456,仅当features.web_search=true才执行搜索)。闲聊勿开,免得拖慢首 token。
八、运维速查
dflash # 启模型 API(:8000) Ctrl+C 停 dflash-ui # 启网页前端(:8080) Ctrl+C 停 MAX_CTX=65536 PC_SLOTS=2 MAX_TOKENS=16384 dflash # 长文本临时配置 MODEL=/root/models/xxx.gguf dflash # 换模型 # 日志:/root/dflash-server.log /root/webui.log全部组件已在运行状态,重启机器后按顺序执行
dflash、dflash-ui即可恢复。总结:在保证速度的情况下。让模型能够执行网络搜集工作。这个信息时代里,这个功能更加重要。
希望此文能帮助到大家。 -
,
T terry 固定了此主题
-
7900XTX 质量上下文 并能联网搜索 接入不了 Hermes。上下文长度不够。
-
7900XTX 质量上下文 并能联网搜索 接入不了 Hermes。上下文长度不够。
-
可以联网是开展工作流的基础。这样7900XTX就有了实战能力了。
-
联网+Qwen3.6-27B+ ltxv-13b-0.9.8-distilled-fp8(14.6G) 可以实现一个 自动产出的工作流了。
实测 老同学 2B的小模型和没有没什么区别。这个 2B是用来搞笑的生产力! -
7900XTX 质量上下文 并能联网搜索 接入不了 Hermes。上下文长度不够。
@williamlouis
配合OpenWebUI看来不是搞代码的需求,这种情况下可以考虑27B的iQ3系列,日用和正常的Q4没什么区别。以前用5070ti的时候用这个效果很棒,又快又稳,简单的脚本之类的也没有问题。
下面这个实测不错,但是不要用xs和s版本那两个会崩,因为这些作者他们量化完了以后不会自己运行实际跑,所以要跑几个不同的版本精挑细选一下。
https://huggingface.co/mradermacher/Huihui-Qwen3.6-27B-abliterated-i1-GGUF?show_file_info=Huihui-Qwen3.6-27B-abliterated.i1-IQ3_XXS.gguf -
我一直 用的 adspower.
补充下进展 联网+Qwen3.6-27B+cpu 纯编码 .sh .py .js 最终实现了视频工作流生产。
结论:在课件类视频中 实现指定逻辑是第一位的。 wan ltx 自身运行中的想象力不可控因素过多。不能实现无人程序化产出。 -
任何模型能工作才是最重要的。网络中的各种测试都是一个参考。只能作为你没安装前的考量参数。
输出速度再快。不能24小时无人值守运行程序也是一个展示型玩物。
这篇帖子的精华是给大家一个低门槛能链接互联网的 Qwen 27B。没有这个基础模块各种项目无法开展。
没上更复杂的链接方式是讲清楚让所有人都能安装太墨迹了。这套操作的适用行最强。安装最简单。
