OpenCode के साथ Qwen3.8-Flash-Next को लोकली कोडिंग एजेंट की तरह कैसे चलाएँ

Qwen3.8-Flash-Next की आर्किटेक्चर

यह 125B-पैरामीटर का मुख्य MoE मॉडल है, लेकिन प्रति टोकन केवल लगभग 6B पैरामीटर सक्रिय होते हैं। इसमें n-gram एम्बेडिंग्स में अतिरिक्त 51B पैरामीटर भी शामिल हैं।

यह आर्किटेक्चर कई ऐसे विचार पेश करता है जिनकी Qwen, Qwen4 के लिए खोज कर रहा है:

• Gated DeltaNet + Qwen Sparse Attention (QSA) ज़्यादा कुशल लॉन्ग-कॉन्टेक्स्ट प्रोसेसिंग के लिए
• Gated Residual connections लेयर्स के बीच सूचना प्रवाह सुधारने के लिए
• N-gram embeddings जो मॉडल क्षमता बढ़ाती हैं बिना सभी पैरामीटर्स को सक्रिय रूप से कंप्यूट किए

स्रोत: Qwen 

मॉडल का नैटिव कॉन्टेक्स्ट विंडो लंबाई 262,144 टोकन है और सैद्धांतिक रूप से YaRN का उपयोग करके 1 मिलियन टोकन तक बढ़ाई जा सकती है।

कोडिंग में Qwen3.8-Flash-Next कैसा प्रदर्शन करता है?

यह कोडिंग में भी आश्चर्यजनक रूप से मजबूत है। ये Qwen के अपने रिपोर्ट किए गए कुछ नतीजे हैं, Qwen3.8-27B की तुलना में:

ये Qwen के अपने मूल्यांकन हैं, इसलिए मैं इन्हें अब भी विक्रेता-रिपोर्टेड नतीजों की तरह ही लूँगा, लेकिन ये मॉडल को कोडिंग में इस्तेमाल करने के मेरे अनुभव से काफ़ी मेल खाते हैं।

Qwen3.8-Flash-Next के लिए GPU सर्वर तैयार करना

मैंने 96GB VRAM वाले RTX PRO 6000 का उपयोग किया, लेकिन आपको ज़रूरी नहीं कि इतनी VRAM चाहिए ही।

यह असल में Qwen3.8-Flash-Next की दिलचस्प बातों में से एक है। क्योंकि llama.cpp मॉडल के हिस्सों को सिस्टम RAM में ऑफ़लोड कर सकता है, आप कम VRAM वाले GPU का उपयोग कर सकते हैं, बशर्ते आपके पास पर्याप्त RAM हो।

हम जिस Unsloth UD-Q4_K_XL क्वांटाइज़ेशन का उपयोग कर रहे हैं, वह लगभग 111GB का है और चार GGUF फाइलों में बँटा हुआ है।

मेरी सेटअप के लिए, मैं कम से कम 140GB उपयोगी संयुक्त RAM और VRAM रखने की सिफारिश करूँगा, ताकि मॉडल, कॉन्टेक्स्ट, 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 अब वैसे भी डिप्रीकेटेड है, क्योंकि 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

पूरा 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 को सोर्स फाइल्स, टूल आउटपुट्स, टर्मिनल लॉग्स और लंबी बातचीत के लिए भरपूर जगह देता है—बिना उस अतिरिक्त मेमोरी को कॉन्टेक्स्ट पर खर्च किए जिसका शायद मैं उपयोग न करूँ।

यहाँ महत्वपूर्ण सेटिंग्स हैं:

1. --fit on से llama.cpp अपने-आप तय करता है कि मॉडल का कितना हिस्सा GPU पर रखा जाए।

2. --fit-target 4096 उसे लगभग 4GB GPU मेमोरी खाली छोड़ने को कहता है, जिससे रनटाइम को VRAM लिमिट तक सीधे पहुँचने के बजाय कुछ स्पेस मिलता है। llama.cpp आधिकारिक तौर पर ऑटो-फिटिंग और कॉन्फ़िगरेबल टार्गेट मेमोरी मार्जिन दोनों सपोर्ट करता है।

3. सैंपलिंग सेटिंग्स भी यूँ ही नहीं हैं। Qwen, मॉडल को थिंकिंग मोड में इस्तेमाल करते समय temperature=1.0, top_p=0.95, top_k=20, और min_p=0.0 की सिफ़ारिश करता है।

पूरा मॉडल लोड होने के बाद भी मेरे पास पर्याप्त मेमोरी बची थी—लगभग 13GB VRAM कॉन्टेक्स्ट विंडो, 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."
      }
    ]
  }'

यदि आपको वैध रिस्पॉन्स मिलता है, तो लोकल सर्वर तैयार है।

मेरी सेटअप पर, शुरू में मुझे लगभग 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 को जोड़ना बहुत आसान हो जाता है।

मैंने OpenCode को 65K वर्किंग कॉन्टेक्स्ट पर सेट किया, भले ही llama.cpp सर्वर के पास 131K उपलब्ध है।

इससे लंबे आउटपुट्स के लिए पर्याप्त हेडरूम बचता है और एजेंट सेशंस सर्वर कॉन्टेक्स्ट को बहुत आक्रामक तरीके से भरने से बचते हैं।

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 से स्पष्ट रूप से एक कदम आगे है। सबसे बड़ा फर्क यह है कि यह प्रोजेक्ट्स को कैसे अप्रोच करता है। यह केवल कोड जेनरेट करने के बजाय संरचना, डिटेल्स और व्यावहारिक इम्प्लीमेंटेशन पर ज़्यादा ध्यान देता है। यदि आप इस मोडel को लोकली चलाने में रुचि रखते हैं, तो हमारा Qwen3.8-27B ट्यूटोरियल पढ़ें।

मुझे यह भी अच्छा लगा कि यह अक्सर अनावश्यक फ़्रेमवर्क और डिपेंडेंसीज़ जोड़ने के बजाय साधारण HTML, CSS, JavaScript और Python पर निर्भर करता था।

मुख्य कमी आकार है। UD-Q4_K_XL GGUF लगभग 111GB का है, और मॉडल खासकर डिबगिंग के दौरान काफ़ी रीज़निंग और आउटपुट टोकन का उपयोग कर सकता है।

इसके अलावा, सेटअप आश्चर्यजनक रूप से सीधा-सादा था। यदि आपके पास पर्याप्त RAM और VRAM है, तो Qwen3.8-Flash-Next अब तक मेरे द्वारा टेस्ट किए गए सबसे मजबूत लोकल कोडिंग मॉडलों में से एक है।