跳至内容

如何在本地将 Qwen3.8-Flash-Next 与 OpenCode 搭配为编码代理运行

了解如何在一张 RTX PRO 6000 上使用 llama.cpp 本地运行 Qwen3.8-Flash-Next GGUF，并将其连接到 OpenCode，打造完全本地的代理式编码环境。
更新 2026年8月28日  · 8分钟 读

用 AI 探索

ChatGPTClaudePerplexity

Qwen3.8-Flash-Next 是我最近测试过的本地模型中较为有趣的一款，尤其在编码与代理式任务上表现突出。剧透一下：该模型的表现让我颇感惊喜。

在本指南中，我们将在一张 96GB VRAM 的 RTX PRO 6000 上运行 Unsloth 的 UD-Q4_K_XL GGUF 量化，使用 llama.cpp 在本地提供服务，通过内置 WebUI 进行测试，最后将其连接到 OpenCode，将其用作完全本地的编码代理。

什么是 Qwen3.8-Flash-Next？

Qwen3.8-Flash-Next 于 2026 年 8 月 26 日发布。它是 Qwen 团队推出的一款新的开源权重 专家混合（MoE） 模型，同时也是正在为 Qwen4 开发架构的早期预览。

若想深入了解该模型，包括完整的基准测试与功能概览、定价与可用性信息、以及与竞品模型的对比，建议阅读我们的 Qwen3.8-Flash-Next 指南。

Qwen3.8-Flash-Next 架构

它是一款 1250 亿参数的主 MoE 模型，但每个 token 实际激活的参数约为 60 亿。同时还包含额外 510 亿参数的 n-gram 嵌入。

该架构引入了 Qwen 为 Qwen4 探索的若干新思路：

  • Gated DeltaNet + Qwen Sparse Attention（QSA），用于更高效的长上下文处理
  • 门控残差连接（Gated Residual），以改善层间信息流
  • N-gram 嵌入，在无需对所有参数进行主动计算的情况下提升模型容量

Qwen3.8-Flash-Next 架构图

来源：Qwen 

该模型的原生上下文窗口长度为262,144 个 token，并可理论上通过 YaRN 扩展至 100 万个 token。

Qwen3.8-Flash-Next 的编码表现如何？

它在编码方面也出乎意料地强。这是 Qwen 自己报告的一些结果，与 Qwen3.8-27B 的对比：

基准

Qwen3.8-Flash-Next

Qwen3.8-27B

DeepSWE 1.1

58.7

42.2

SWE-bench Pro

62.5

61.7

SWE-bench Multilingual

81.0

73.8

Toolathlon Verified

73.5

67.1

这些都是 Qwen 的自评结果，因此仍应视作厂商报告，但它们与我实际用该模型编程的体验相当吻合。

为 Qwen3.8-Flash-Next 准备 GPU 服务器

我使用的是一张 96GB VRAM 的 RTX PRO 6000，但并不一定需要这么多显存。

在 RunPod 中部署 RTX Pro 6000 Pytorch pod

这其实是 Qwen3.8-Flash-Next 有趣之处之一。由于 llama.cpp 可以将模型的一部分卸载到系统内存，只要系统内存充足，显存较小的 GPU 也能使用。

我们使用的 Unsloth UD-Q4_K_XL 量化约为 111GB，并分为四个 GGUF 文件。

就我的环境而言，我建议至少具备 140GB 的可用 RAM 与 VRAM 总和，以确保模型、上下文、KV 缓存与运行时开销有足够空间。

如果您用的是 H200 之类的卡，几乎可以把所有内容都放在 GPU 上。我选择了折中方案。 

先检查您的 GPU：

nvidia-smi

RTX PRO 6000 GPU 概览

您应能看到 GPU、驱动版本、CUDA 版本与可用显存。

接着安装所需软件包：

sudo apt update

sudo apt install -y \
  git \
  cmake \
  build-essential \
  curl \
  libcurl4-openssl-dev \
  python3-pip

为 Qwen3.8-Flash-Next 构建带支持的 llama.cpp

Qwen3.8-Flash-Next 使用新的 qwen4_exp 架构，这与简单加载另一款 Qwen3.8 模型有很大不同。

相关支持仍非常新，因此我使用了 Unsloth 维护的 Qwen3.8-Flash-Next 分支，而非依赖可能无法识别该架构的旧版 llama.cpp。对应的 llama.cpp 变更新增了 qwen4exp 架构、QSA、n-gram 嵌入和其他与模型相关的组件。

进入工作目录：

cd /workspace

克隆 Unsloth 分支：

git clone \
  --branch qwen4exp/qwen3.8-flash-next \
  https://github.com/unslothai/llama.cpp.git

进入目录：

cd llama.cpp

使用 CUDA 构建 llama.cpp：

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  --config Release \
  -j"$(nproc)"

最后确认 llama-server 构建成功：

./build/bin/llama-server --version

我的构建返回：

version: 0.3.0-dev (build 10656, commit 035e22731)
built with GNU 13.3.0 for Linux x86_64

下载 Qwen3.8-Flash-Next GGUF 模型

下载模型其实是本次搭建中最让人头疼的部分之一。

我首先尝试了 ModelScope，但速度一般。在 Hugging Face 上，起初速度还不错，但随后突然跌到 KB/s 的水平。

Hugging Face 现在对大模型下载使用其 Xet 后端，通常会自动启用自适应并发。它也提供了 HF_HUB_DISABLE_XET，在出问题时可禁用 Xet。

在我的场景下，禁用 Xet并并行下载四个 GGUF 分片效果好得多。

安装 Hugging Face CLI：

pip install -U huggingface_hub

为本次下载禁用 Xet：

export HF_HUB_DISABLE_XET=1
unset HF_XET_HIGH_PERFORMANCE
unset HF_XET_NUM_CONCURRENT_RANGE_GETS
unset HF_HUB_ENABLE_HF_TRANSFER

HF_HUB_ENABLE_HF_TRANSFER 现已弃用，因为 Hugging Face 已将大文件传输迁移至 Xet。

创建模型目录：

cd /workspace
mkdir -p Qwen3.8-Flash-Next-GGUF

现在并行下载四个分片：

for i in 1 2 3 4; do
  shard=$(printf "%05d" "$i")

  hf download unsloth/Qwen3.8-Flash-Next-GGUF \
    "UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-${shard}-of-00004.gguf" \
    --local-dir Qwen3.8-Flash-Next-GGUF &
done

wait

Downloading the Qwen3.8-Flash-Next GGUF Model

完整的 UD-Q4_K_XL 量化约为 111GB。

使用 llama.cpp 运行 Qwen3.8-Flash-Next

回到 llama.cpp 目录：

cd /workspace/llama.cpp

启动服务器：

./build/bin/llama-server \
  -m /workspace/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
  --alias qwen3.8-flash-next \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 131072 \
  --parallel 1 \
  --flash-attn on \
  --fit on \
  --fit-target 4096 \
  --jinja \
  --batch-size 1024 \
  --ubatch-size 512 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 20 \
  --min-p 0.0

Running Qwen3.8-Flash-Next with llama.cpp

我特意选择了 131,072 个 token 的上下文窗口，而非完整的原生 262K 上下文。

对于编码代理而言，131K 已经非常大了，足够容纳 OpenCode 的源码文件、工具输出、终端日志和长对话，而无需为了可能用不到的上下文再额外消耗内存。

其中重要的设置包括：

  1. --fit on 让 llama.cpp 自动确定应将模型的多少部分保留在 GPU 上。

  2. --fit-target 4096 指示其预留约4GB 的 GPU 内存，给运行时留出余量，避免直接顶到显存上限。llama.cpp 官方同时支持自动适配与可配置的目标内存余量。

  3. 采样设置也并非随意。Qwen 建议在思考模式下使用 temperature=1.0、top_p=0.95、top_k=20 和 min_p=0.0。

将 Qwen3.8-Flash-Next 模型加载入 GPU 内存后的 GPU 概览

即便加载了完整模型，我仍有充足余量，大约还剩 13GB 显存可用于上下文窗口、KV 缓存和其他应用。

使用 CURL 测试 Qwen3.8-Flash-Next 服务器

llama-server 暴露的是 OpenAI 兼容的 API。

检查可用模型：

curl http://127.0.0.1:8080/v1/models

您应能看到 qwen3.8-flash-next。

现在来测试生成一个回答：

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-flash-next",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ]
  }'

如果得到有效响应，说明本地服务器已就绪。

Testing the Qwen3.8-Flash-Next using CURL

在我的环境中，起初大约能达到每秒 80 个 token，这让我有些惊讶，因为模型的一部分驻留在系统内存中。

随着上下文增大，速度降至每秒约 64 个 token。

对于这个体量的模型而言，这仍然非常可用，而架构也能解释其中原因。尽管模型主参数为 1250 亿，但每个 token 实际激活的仅约 60 亿。

使用 llama.cpp WebUI 测试 Qwen3.8-Flash-Next

我很喜欢 llama.cpp 的一点在于，llama-server 已经自带了一个简单的 WebUI。

打开 http://localhost:8080。如果一切正常，模型应已可用。

使用 llama.cpp WebUI 测试 Qwen3.8-Flash-Next

我的第一次正经测试，是让它一次性构建一个完整的政府 IT 部门网站：

Create a modern, professional government IT department portfolio website in a single index.html file.
Use HTML, CSS, and JavaScript featuring a clean official design and responsive layout with smooth animations, interactive elements, and accessible government-style navigation.
It should display department overview, key services, digital transformation projects, achievements, technology initiatives, statistics, leadership/team section, latest updates, contact information,

使用 llama.cpp WebUI 测试 Qwen3.8-Flash-Next

这次生成规模相当大。模型先花费大量 token 进行思考，然后在一个 HTML 文件中生成了完整网站。大约耗时 13 分钟，且随着上下文增长，生成速度逐渐下降。

但结果远超出我的预期。

image10.png

它包含图表、动画、选项卡、不同版块、响应式样式、JavaScript 交互，整体布局也意外地精致。

image6.png

有趣的是，这基本属于一次性生成。我并未明确要求它加入许多这些小细节。

这也是我第一次意识到，该模型或许特别适合那些给予其一定自由度、而非逐条规定实现细节的编码任务。

将 Qwen3.8-Flash-Next 连接到 OpenCode

聊天固然不错，但我主要想把 Qwen3.8-Flash-Next 当作代理式编码模型来测试。

为此我使用了 OpenCode。先安装：

curl -fsSL https://opencode.ai/install | bash

重启终端并检查安装：

opencode --version

我这里是 1.18.23 版本。

现在创建 OpenCode 配置：

mkdir -p ~/.config/opencode

加入我们先前构建的本地 llama.cpp 提供方：

printf '%s\n' '{"$schema":"https://opencode.ai/config.json","model":"llama.cpp/qwen3.8-flash-next","provider":{"llama.cpp":{"npm":"@ai-sdk/openai-compatible","name":"Qwen3.8 Flash Next Local","options":{"baseURL":"http://127.0.0.1:8080/v1"},"models":{"qwen3.8-flash-next":{"name":"Qwen3.8 Flash Next","limit":{"context":65536,"output":32768}}}}}}' > ~/.config/opencode/opencode.json

最重要的是 http://127.0.0.1:8080/v1。 

OpenCode 通过 @ai-sdk/openai-compatible 支持自定义 OpenAI 兼容提供方，使得连接 llama.cpp 十分容易。

我将 OpenCode 的工作上下文设为 65K，尽管 llama.cpp 服务器本身提供 131K。

这样能为长输出留出足够余量，也避免代理会话过快占满服务器的上下文。

将 Qwen3.8-Flash-Next 作为本地编码代理使用

进入某个项目目录并启动 OpenCode：

cd /workspace/my-project
opencode

Qwen3.8-Flash-Next 已集成到 OpenCode

现在您可以给模型正常的代理式编码任务。例如，我让 Qwen 构建一个分析型仪表盘：

Build a modern system analytics and task-management dashboard. 
It should monitor CPU, RAM, VRAM, GPU usage, temperatures, disk usage, running processes, and temporary files. 
Users should be able to safely terminate tasks, free unused RAM/VRAM, clear caches, and clean temporary files from one interface.

在 OpenCode 中测试 Qwen3.8-Flash-Next

模型先创建待办清单并规划应用结构，然后再开始编写。

在 OpenCode 中测试 Qwen3.8-Flash-Next

几分钟内，它就产出了第一个可用的仪表盘。我并不太喜欢第一版 UI，感觉过于松散，且有若干可用性问题。

于是我直接告诉代理我不喜欢的地方，并要求将界面重构为更紧凑的系统指挥中心。

第二版好得多。

由 Qwen3.8-Flash-Next 生成的仪表盘

最终我得到一个紧凑的仪表盘，能实时监控 CPU、RAM、VRAM、GPU 使用率、存储、网络活动与运行进程。它还加入了清理缓存、清理临时文件与管理进程的控制项。

有意思的是 Qwen 的实现路径。我在两个不同应用上测试，它经常倾向于使用原生的 HTML、CSS 与 JavaScript，而不是立刻安装 React、Node 包或其他大型框架。

我实际上很喜欢这种行为。如果我未指定框架，它会尝试寻找能解决问题的最简架构，而不是添加不必要的依赖。

不足之处在于它比较花时间。会有大量推理、生成大量 token，有时还需要不少调试。您能明显感觉到模型在用 token 思考问题。

但最终产物通常比我从体量更小的本地模型那里得到的要完整得多。

结语

在网站生成与代理式编码的测试之后，我认为 Qwen3.8-Flash-Next 相较 Qwen3.8-27B 有明显提升。最大差异在于其处理项目的方式：它更注重结构、细节与实际落地，而不仅是生成代码。如果您有兴趣在本地运行这款模型，欢迎阅读我们的 Qwen3.8-27B 教程。

我也很喜欢它常用简单的 HTML、CSS、JavaScript 与 Python，而非叠加不必要的框架与依赖。

主要不足是体量。UD-Q4_K_XL GGUF 约 111GB，且模型在调试阶段尤其会使用大量推理与输出 token。

除此之外，整体搭建出乎意料地顺利。如果您的 RAM 与 VRAM 充足，Qwen3.8-Flash-Next 是我目前测试过的最强本地编码模型之一。

常见问题

本地运行 Qwen3.8-Flash-Next 需要什么硬件？

Unsloth 的硬件表显示，最小的 1-bit 量化为 75GB，4-bit 为 112GB，按总内存（显存与系统内存之和，或 Mac 上的统一内存）计量。您不需要 96GB GPU：llama.cpp 会在显存与内存间切分模型，因此小显存但系统内存充足的卡也能运行，只是卸载到内存的部分会更慢。

应选择 Qwen3.8-Flash-Next 的哪种量化？

UD-Q4_K_XL 在 111.3GB 处是甜蜜点，能保留约 93% 的与全精度模型的一致性（top-token agreement）。若内存吃紧，UD-IQ4_XS（93.7GB）与 UD-Q3_K_XL（90GB）仍可保持 90% 以上，而 UD-IQ1_S 在 72.5GB 处也能维持 80%。请注意，对于 125B 模型，低比特量化的体积比您预期更大，因为 n-gram 嵌入层从不低于 4-bit 进行量化。

能否用 Claude Code 或 Codex 替代 OpenCode 搭配 Qwen3.8-Flash-Next？

对于任何支持自定义 OpenAI 兼容 base URL 的工具，答案都是可以。将工具指向 http://127.0.0.1:8080/v1，并使用您为服务器设置的 --alias 作为模型 ID。Claude Code 期望的是 Anthropic 格式请求，因此需要一个转换代理，而不是直接替换 base-URL。无论使用哪种代理，都请将会话的上下文上限显式设置在服务器 --ctx-size 之下，避免长会话越界。

如何减少 Qwen3.8-Flash-Next 在“思考”上消耗的 token？

推理强度默认是 xhigh。向 llama-server 传入 --chat-template-kwargs '{"reasoning_effort":"medium"}' 可将其调低，另有 low 与 none 可选。模型默认还会保留前几轮的思考痕迹（preserve thinking），将 preserve_thinking 设为 false 能在长时间的代理会话中进一步减少 token 消耗。

主题
人工智能
大语言模型

和 DataCamp 一起学习 AI！

Tracks

面向开发者的 AI 工程师助理

26小时
了解如何使用 API 和开源库将 AI 集成到软件应用程序中。 今天就开始你的 AI 工程师之旅吧！
查看详情Right Arrow
开始课程
查看更多Right Arrow