OpenCode로 Qwen3.8-Flash-Next를 로컬 코딩 에이전트로 실행하는 방법

RTX PRO 6000에서 llama.cpp로 Qwen3.8-Flash-Next GGUF를 로컬 실행하고 OpenCode에 연결해 완전 로컬 에이전틱 코딩 환경을 구성하는 방법을 배워보세요.

업데이트됨 2026년 8월 28일 · 8분 읽다

AI로 탐색하기

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 팀의 새로운 오픈 웨이트 Mixture-of-Experts(MoE) 모델로, Qwen4를 위해 개발 중인 아키텍처의 초기 미리보기 역할도 합니다.

전체 벤치마크와 기능 개요, 가격 및 가용성 정보, 경쟁 모델과의 비교 등 모델에 대한 심층 분석은 저희의 Qwen3.8-Flash-Next 가이드를 참고하세요.

Qwen3.8-Flash-Next 아키텍처

125B 파라미터의 메인 MoE 모델이지만, 토큰당 활성화되는 파라미터는 약 6B에 불과합니다. 또한 n-gram 임베딩으로 51B 파라미터가 추가됩니다.

이 아키텍처는 Qwen이 Qwen4를 위해 탐구 중인 여러 아이디어를 도입합니다.

Gated DeltaNet + Qwen Sparse Attention(QSA)으로 장문 컨텍스트 처리를 더 효율적으로
Gated Residual 연결로 레이어 간 정보 흐름 개선
N-gram 임베딩으로 모든 파라미터를 적극적으로 계산하지 않고도 모델 용량 확대

출처: Qwen

모델의 기본 컨텍스트 윈도우 길이는 262,144 토큰이며, 이론적으로 YaRN을 사용해 100만 토큰까지 확장할 수 있습니다.

Qwen3.8-Flash-Next의 코딩 성능은 어떤가요?

코딩에서도 놀라울 만큼 강력합니다. 아래는 Qwen3.8-27B와 비교한 Qwen 자체 보고 결과의 일부입니다.

벤치마크	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을 사용했지만, 반드시 그 정도 VRAM이 필요한 것은 아닙니다.

이 부분이 Qwen3.8-Flash-Next의 흥미로운 점 중 하나입니다. llama.cpp는 모델 일부를 시스템 RAM으로 오프로딩할 수 있어, RAM이 충분하다면 VRAM이 적은 GPU도 사용할 수 있습니다.

이번에 사용할 Unsloth UD-Q4_K_XL 양자화 모델은 약 111GB이며 네 개의 GGUF 파일로 분할되어 있습니다.

제 환경에서는 RAM과 VRAM을 합쳐 최소 140GB의 사용 가능 메모리를 확보할 것을 권장합니다. 모델, 컨텍스트, KV 캐시, 런타임 오버헤드를 위한 충분한 공간이 필요하기 때문입니다.

H200과 같은 장비가 있다면 사실상 거의 모든 것을 GPU에 올릴 수 있습니다. 저는 중간 지점을 택했습니다.

먼저 GPU를 확인하세요:

nvidia-smi

GPU, 드라이버 버전, CUDA 버전, 사용 가능한 VRAM을 확인할 수 있어야 합니다.

다음으로 필요한 패키지를 설치합니다:

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 모델을 로드하는 것과는 매우 다릅니다.

지원이 아직 매우 초기 단계이므로, 아키텍처를 인식하지 못할 수 있는 이전 버전의 llama.cpp 대신 Unsloth가 관리하는 Qwen3.8-Flash-Next 브랜치를 사용했습니다. 해당 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는 대규모 전송이 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

완전한 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

의도적으로 기본 262K 컨텍스트 대신 131,072 토큰 컨텍스트 윈도우를 사용했습니다.

코딩 에이전트에는 131K만으로도 충분히 크며, 소스 파일, 툴 출력, 터미널 로그, 긴 대화를 담기에 OpenCode에 넉넉한 공간을 제공하면서 사용하지 않을 가능성이 큰 컨텍스트에 메모리를 낭비하지 않습니다.

여기서 중요한 설정은 다음과 같습니다:

--fit on은 llama.cpp가 모델의 어느 정도를 GPU에 둘지 자동으로 결정하게 합니다.
--fit-target 4096은 GPU 메모리 4GB 정도를 여유로 남겨두도록 지시합니다. VRAM 한도를 빡빡하게 쓰지 않고 런타임에 여지를 주려는 설정입니다. llama.cpp는 자동 피팅과 여유 메모리 마진 설정을 공식 지원합니다.
샘플링 설정도 임의가 아닙니다. Qwen은 모델을 thinking 모드로 사용할 때 temperature=1.0, top_p=0.95, top_k=20, min_p=0.0를 권장합니다.

전체 모델을 로드한 뒤에도 컨텍스트 윈도우, KV 캐시, 기타 애플리케이션을 위한 VRAM이 약 13GB 정도 여전히 남았습니다.

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."
      }
    ]
  }'

유효한 응답이 오면 로컬 서버가 준비된 것입니다.

제 환경에서는 초기에 초당 약 80토큰이 나왔는데, 모델 일부가 시스템 RAM에 있었던 점을 고려하면 놀라웠습니다.

컨텍스트가 커지면서 속도는 초당 64토큰에 가까워졌습니다.

이 크기의 모델로서는 여전히 매우 쓸 만한 수준이며, 아키텍처가 그 이유를 설명해 줍니다. 모델이 125B 메인 파라미터를 갖고 있어도 토큰당 활성 파라미터는 약 6B에 불과하기 때문입니다.

llama.cpp WebUI로 Qwen3.8-Flash-Next 테스트

llama.cpp의 장점 중 하나는 llama-server가 이미 간단한 WebUI를 제공한다는 점입니다.

http://localhost:8080을 여세요. 모든 것이 제대로 실행 중이라면 모델이 바로 사용 가능해야 합니다.

첫 본격 테스트에서는 한 번에 완전한 정부 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,

상당히 큰 생성 작업이었습니다. 모델은 많은 토큰을 사용해 사고한 뒤, 단일 HTML 파일로 전체 웹사이트를 생성했습니다. 완료까지 약 13분이 걸렸고, 컨텍스트가 커질수록 생성 속도는 점차 느려졌습니다.

하지만 결과는 예상보다 훨씬 좋았습니다.

차트, 애니메이션, 탭, 다양한 섹션, 반응형 스타일, JavaScript 인터랙션, 그리고 놀라울 만큼 정돈된 전체 레이아웃이 포함되었습니다.

흥미로운 점은 사실상 원샷 생성에 가까웠다는 것입니다. 제가 많은 세부 요소를 명시적으로 요청하지 않았습니다.

이 지점에서, 이 모델이 모든 구현 세부를 일일이 지정하기보다는 어느 정도 자유를 줄 때 특히 코딩 작업에 강하겠다는 생각이 들었습니다.

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 연결이 매우 쉽습니다.

llama.cpp 서버가 131K 컨텍스트를 제공하더라도, OpenCode의 작업 컨텍스트는 65K로 설정했습니다.

이렇게 하면 긴 출력에 충분한 여지를 남기고, 에이전트 세션이 서버 컨텍스트 전체를 과도하게 채우는 것을 방지할 수 있습니다.

Qwen3.8-Flash-Next를 로컬 코딩 에이전트로 사용하기

프로젝트 디렉터리로 이동한 뒤 OpenCode를 시작합니다:

cd /workspace/my-project
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.

모델은 먼저 할 일 목록을 만들고 애플리케이션을 설계한 뒤, 구현을 시작했습니다.

몇 분 만에 첫 번째 동작하는 대시보드를 만들었습니다. 다만 초기 UI는 마음에 들지 않았습니다. 너무 넓게 퍼져 있고, 사용성 문제도 몇 가지 있었습니다.

그래서 마음에 들지 않는 점을 에이전트에게 그대로 전달하고, 더 컴팩트한 시스템 커맨드 센터 형태로 인터페이스를 다시 만들도록 요청했습니다.

두 번째 버전은 훨씬 나아졌습니다.

결국 CPU, RAM, VRAM, GPU 사용량, 스토리지, 네트워크 활동, 실행 중인 프로세스를 실시간으로 모니터링할 수 있는 컴팩트한 대시보드가 완성되었습니다. 캐시 삭제, 임시 파일 정리, 프로세스 관리 컨트롤도 추가되었습니다.

흥미로웠던 점은 Qwen의 구현 접근 방식입니다. 두 가지 다른 애플리케이션에서 테스트했는데, 종종 바닐라 HTML, CSS, JavaScript를 선호했고, React나 Node 패키지 같은 대형 프레임워크를 바로 설치하지 않았습니다.

저는 오히려 이 점이 마음에 들었습니다. 프레임워크를 지정하지 않으면, 불필요한 의존성을 추가하기보다 문제를 해결하는 가장 단순한 아키텍처를 찾으려 했습니다.

단점은 시간이 걸린다는 것입니다. 사고 과정이 많고, 생성되는 토큰이 많으며, 때로는 디버깅도 꽤 필요합니다. 모델이 문제를 곱씹으며 토큰을 쓰는 게 확실히 느껴집니다.

하지만 최종 결과물은 일반적으로 더 작은 로컬 모델에서 보통 얻는 것보다 훨씬 완성도가 높았습니다.

마무리 생각

웹사이트 생성과 에이전틱 코딩에서 Qwen3.8-Flash-Next를 테스트해 본 결과, Qwen3.8-27B에서 확실히 한 단계 도약했다고 느꼈습니다. 가장 큰 차이는 프로젝트 접근 방식입니다. 단순히 코드를 생성하는 데서 그치지 않고, 구조, 세부, 실용적 구현에 더 많은 주의를 기울입니다. 로컬에서 이 모델을 실행하는 데 관심이 있다면 Qwen3.8-27B 튜토리얼을 확인하세요.

또한 불필요한 프레임워크와 의존성을 추가하기보다, 종종 단순한 HTML, CSS, JavaScript, Python에 의존하는 점도 마음에 들었습니다.

주요 단점은 크기입니다. UD-Q4_K_XL GGUF는 약 111GB이며, 특히 디버깅 중에는 추론과 출력 토큰을 많이 사용할 수 있습니다.

그 외에는 설정이 놀라울 정도로 간단했습니다. RAM과 VRAM이 충분하다면, Qwen3.8-Flash-Next는 지금까지 테스트한 로컬 코딩 모델 중 가장 강력한 모델 중 하나입니다.