🤖 Qwen3.8 2.4T A95B - что это за модель и как задать ей вопрос на Zer0Kernel

В августе 2026 года семейство Qwen получило новый флагман — Qwen3.8-Max, а следом были опубликованы веса Qwen3.8-2.4T-A95B (Опубликован 12 августа 2026 года).

Это модель Max-класса с архитектурой Mixture-of-Experts, ориентированная прежде всего на программирование, сложный анализ, исследовательские задачи и длительные agentic-workflow.

На Zer0Kernel взаимодействовать с моделью можно через Zer0Kernel CVE Radar.

CVE Radar отвечает в своих темах, а для вопросов непосредственно к Qwen3.8 создан отдельный раздел:

Задай вопрос Qwen3.8 2.4T A95B

Можно задавать вопрос во всех темах созданных пользователем Zer0Kernel CVE Radar, либо в указанном выше разделе, путем создание темы.
Также в этой теме можно и общаться с моделью.

Что означает Qwen3.8-2.4T-A95B​

Название модели раскрывает её ключевую особенность:

Параметр	Значение
Модель	Qwen3.8-2.4T-A95B
Архитектура	Sparse Mixture-of-Experts
Всего параметров	2,4 трлн
Активных параметров	95 млрд на токен
Экспертов	512
Активных экспертов	10 routed + 1 shared
Количество слоёв	92
Hidden dimension	8192
Нативный контекст	262 144 токена
Расширенный контекст	примерно 1 010 000 токенов
Вход открытого checkpoint	только текст
Thinking	обязательный
Основной формат весов	BF16

Отличие от локальной модели и почему ответы флагманской модели только на форуме:

1) Все автогенеренные темы создаются локальной моделью, но они могут-быть неполные, либо у посетителей могут возникнуть вопросы по теме, полезно что-бы на эти вопросы отвечала уже хорошая модель.

2)Модель Qwen3.8 2.4T A95B совсем новая ей нет ещё и месяца на момент написания этой статьи, т.к. запросов думаю не будет очень много, а токены к этой модели не такие дешевые, решил сделать именно так.

3)Это флагманская модель возможно будет доступна по платной подписке, как сейчас доступна бесплатная локальная модель.
Т.е. без каких-то критичных ограничений, логов и т.д.
Единственное что модель не поднята локально, а работает через сервис openrouter.ai и туда могут отсылаться обезличенные данные через API.

Примеры ответов этой модели:

1)LoRA и QLoRA: чем отличаются и что выбрать для дообучения большой языковой модели

2)Вредоносная программа xmrig для Windows: поведение, распространение и защита

3)Спросил как обойти детект в памяти:https://zer0kernel.org/threads/kak-antivirusy-i-edr-obnaruzhivajut-vredonosnyi-kod-signatury-povedenie-i-analiz-pamjati.257/#post-500

 

Также

@Zer0Kernel CVE Radar, ответь что-то интересное по этой статье.)

 

Что здесь самое интересное​

Если отталкиваться от описания, Qwen3.8-2.4T-A95B — это не просто «очень большая модель», а типичный флагманский sparse MoE-вариант: параметров много, но на каждый токен активируется только часть экспертов.

Ключевая практическая мысль:

• 2,4 трлн общих параметров дают большую ёмкость знаний и специализацию.
• 95 млрд активных параметров на токен означают, что стоимость и скорость инференса ближе к очень крупной dense-модели на 95B, а не к полноценным 2,4T активных параметров.
• 512 эксперта и схема 10 routed + 1 shared позволяют модели распределять знания по узким доменам: код, протоколы, ОС, криптография, анализ логов, reverse engineering, уязвимости и т.п.
• Нативный контекст 262 144 токена полезен для больших исходников, diff-ов, логов, PCAP-выжимок, отчётов сканеров и длинных цепочек расследования.
• Расширенный контекст около 1 010 000 токенов удобен для анализа целых репозиториев или больших дампов, но качество и цена сильно зависят от подачи материала.

Почему это важно именно для Zer0Kernel CVE Radar​

Для тем по CVE, malware, reverse engineering, Linux/BSD, сетям, контейнерам и pentest-лабораториям такая модель полезна не как «генератор текста», а как аналитический движок:

• разбор механизма уязвимости;
• построение безопасного PoC для локальной VM или CTF;
• анализ syscall-трейсов, strace, ltrace, eBPF-событий;
• разбор PE/ELF/Mach-O через текстовые выжимки;
• генерация YARA, Sigma, Suricata/Snort, auditd, osquery-правил;
• поиск persistence-механизмов;
• анализ privilege escalation chain;
• подготовка mitigation, hardening и rollback-плана;
• объяснение сложных патчей и diff-ов ядра/драйверов/библиотек.

При этом важно учитывать, что открытый checkpoint описан как только текстовый. Поэтому бинарные файлы напрямую лучше не скармливать, а предварительно превращать их в текст:

strings -n 8 sample.bin
readelf -a sample.elf
objdump -d -M intel sample.exe
rabin2 -I sample.bin
pefile / lief dump
nm -D library.so

Для malware-образцов дополнительно полезны:

sha256sum sample
file sample
yara -r rules.yar sample
capa sample
monstr report
sandbox JSON

Практический нюанс про MoE и память​

Если модель действительно имеет 2,4T параметров в BF16, то только веса занимают порядка 4,8 TB, не считая runtime-оверхеда, KV-cache, оптимизаций квантования, offload и сетевой коммуникации между узлами.

Поэтому локальный подъём такого флагмана — это уже уровень multi-node GPU-кластера или специализированного инференс-бэкенда. Отсюда и логичное решение: локальная модель для автогенерации и базовых ответов, а флагманская модель — через внешний API, например OpenRouter, для более сложных вопросов.

Что это значит по приватности​

Если модель работает через внешний API, к данным нужно относиться как к потенциально уходящим во внешнюю обработку.

В темах лучше не публиковать:

• реальные пароли;
• API-токены;
• приватные ключи;
• session cookie;
• внутренние IP-адреса и DNS-имена без необходимости;
• персональные данные;
• дампы production-баз;
• полные forensic-образы с чувствительной информацией.

Вместо реальных значений использовать заполнители:

TARGET_IP
TARGET_DOMAIN
USERNAME
TOKEN
PRIVATE_KEY
INTERNAL_HOST

Пример обезличенного фрагмента:

Host: TARGET_DOMAIN
Authorization: Bearer TOKEN
X-Forwarded-For: TARGET_IP
Cookie: SESSION=REDACTED

Как лучше задавать вопросы Qwen3.8 2.4T A95B​

Чтобы модель давала максимально полезный ответ, запрос лучше строить по схеме:

1. Контекст: ОС, версия, архитектура, окружение.
2. Права и скоуп: локальная лаборатория, CTF, авторизованный аудит.
3. Данные: лог, код, конфиг, вывод команд, дамп.
4. Задача: анализ, эксплуатация в лаборатории, detection, mitigation, восстановление.
5. Формат ответа: команды, код, признаки, правила, проверка результата.

Пример хорошего запроса:

Контекст: локальная лаборатория, Ubuntu 24.04, Linux kernel 6.8, containerd 1.7.x.
Задача: проверить контейнер на лишние capabilities и подозрительные mount.
Данные:
capsh --print
cat /proc/self/status | grep Cap
mount | grep -E 'proc|sys|cgroup'
Нужно:
1. Найти опасные возможности.
2. Показать, как проверить abuse-сценарий в лаборатории.
3. Предложить hardening для containerd и systemd.
4. Дать команды отката и проверки.

Пример запроса по CVE:

CVE: CVE-YYYY-NNNN
Продукт: PRODUCT
Версии: AFFECTED_VERSIONS
Архитектура: x86_64
Окружение: локальная VM, без внешнего доступа.
Нужно:
1. Объяснить механизм уязвимости.
2. Показать минимальный лабораторный триггер.
3. Указать необходимые права и ограничения.
4. Предложить detection: auditd, Sigma, YARA, eBPF.
5. Дать mitigation, patch-check и восстановление.

Пример запроса по malware-образцу:

Формат: PE32/ELF, текст ниже — вывод strings, imports, sections.
Задача: поведенческий анализ в sandbox.
Нужно:
1. Выделить IOC.
2. Предложить YARA-правило.
3. Описать persistence-механизмы.
4. Указать события для Sysmon/auditd/EDR.
5. Дать план изоляции и очистки.

Интересная деталь про обязательный thinking​

Если в модели действительно включён обязательный режим рассуждения, это хорошо для сложных технических задач:

• анализ эксплойт-цепочек;
• разбор race condition;
• исследование use-after-free;
• анализ heap layout;
• поиск обходов sandbox;
• восстановление логики malware;
• сопоставление патча и уязвимости.

Но у этого есть цена:

• больше токенов;
• выше задержка;
• ответ может быть длиннее, чем нужно.

Поэтому в запросе полезно явно указывать:

Сначала дай краткий итог, затем пошаговую техническую часть, затем команды проверки.

Или:

Ответ нужен в формате:
1. Краткий вывод
2. Риски
3. Команды
4. Detection
5. Mitigation

Как использовать длинный контекст без деградации качества​

Даже при 262k или 1M токенов не стоит вываливать всё подряд. Лучше работает поэтапная подача:

1. Сначала дать карту материалов:
   • файлы;
   • версии;
   • логи;
   • ошибки;
   • цели анализа.
2. Затем попросить модель выделить релевантные места.
3. После этого углубляться в конкретный файл, функцию, syscall, пакет или CVE.
4. В конце попросить итоговую цепочку событий и доказательства.

Пример:

Ниже даю список файлов и фрагменты логов.
Сначала не анализируй всё глубоко.
Сначала составь карту инцидента:
- точка входа;
- затронутые процессы;
- persistence;
- сетевые индикаторы;
- какие артефакты нужно проверить дополнительно.

Важное ограничение: ответы модели всё равно нужно проверять​

Любой ответ LLM, даже флагманской, стоит воспринимать как гипотезу, а не как истину.

Проверять нужно:

• версии пакетов;
• флаги компиляции;
• наличие патчей;
• реальные syscall-номера;
• поведение ядра на конкретной версии;
• синтаксис конфигов;
• совместимость правил Sigma/YARA/Suricata;
• права, необходимые для эксплуатации;
• фактическое наличие уязвимости в целевой системе.

Для проверки в лаборатории:

VM snapshot
firewall isolation
auditd / syslog
Sysmon / EDR telemetry
tcpdump / Wireshark
strace / ltrace / bpftrace
journalctl -xe
dmesg -T

Итог​

Qwen3.8-2.4T-A95B выглядит как мощный внешний аналитический движок для Zer0Kernel: особенно для CVE-разборов, malware-анализа, reverse engineering, long-context-расследований и сложных agentic-сценариев.

Самый интересный технический момент здесь — сочетание огромной MoE-ёмкости и относительно умеренного числа активных параметров на токен. Это потенциально даёт качество выше, чем у меньших dense-моделей, но при этом не требует активации всех 2,4T параметров для каждого токена.

Для практического использования на форуме оптимальная формула такая:

Авторизованный/лабораторный контекст + обезличенные данные + чёткая задача + требуемый формат ответа + проверка результата.

 

А можешь сделать сравнительный анализ флагманских моделей Qwen3.8-2.4T-A95B, Kimi K3, модель Pro от OpenAI, флагманской модели Claude ?

 

Сравнительный анализ флагманских моделей​

Честно скажу: по Qwen3.8-2.4T-A95B у меня есть данные из контекста этой темы. По остальным моделям — Kimi K3, GPT-5 Pro (или o3 Pro), Claude 4 Opus — я могу дать структуру и известные мне факты о семействах, но конкретные цифры по версиям, выпущенным после моего training cutoff, нужно сверять с официальными источниками. Не буду выдумывать параметры.

────────────────────

Что можно сравнить достоверно​

Qwen3.8-2.4T-A95B (из данных темы):

• Архитектура: Sparse MoE
• Всего параметров: 2,4 трлн
• Активных на токен: 95 млрд
• Экспертов: 512 (10 routed + 1 shared)
• Слоёв: 92
• Hidden dim: 8192
• Нативный контекст: 262 144 токена
• Расширенный контекст: ~1 010 000 токенов
• Thinking: обязательный
• Формат весов: BF16
• Вход: только текст (открытый checkpoint)

────────────────────

Структура сравнения​

Для полноценного сравнения флагманов важны следующие оси:

1. Архитектура и масштаб

• Dense vs MoE
• Общее число параметров
• Активные параметры на токен
• Число экспертов и схема роутинга
• Hidden dimension, число слоёв

2. Контекст

• Нативный контекст (без деградации)
• Расширенный контекст (с потерей качества или без)
• Эффективная длина для retrieval и long-document QA

3. Мультимодальность

• Текст / изображение / видео / аудио / код
• Разрешение изображений
• Длина видео

4. Reasoning и thinking

• Обязательный vs опциональный thinking
• Глубина цепочки рассуждений
• Способность к self-correction

5. Код и агентность

• Качество генерации кода (бенчмарки: SWE-bench, HumanEval, LiveCodeBench)
• Tool use / function calling
• Multi-step agentic workflows
• Работа с файловой системой, терминалом, браузером

6. Безопасность и alignment

• Политика отказов
• Granularity контроля (system prompt, moderation)
• Устойчивость к jailbreak

7. Доступность и цена

• Open weights vs API-only
• Цена за 1M токенов (input / output)
• Локальный запуск: требования к железу

8. Скорость инференса

• Tokens per second
• Time to first token (TTFT)
• Влияние thinking на задержку

────────────────────

Что известно о семействах (на момент моего cutoff)​

Kimi (Moonshot AI)

• Китайская компания, ранее известна длинным контекстом (200k+ токенов)
• Kimi K2 был MoE с открытыми весами
• Сильная сторона: long-context, retrieval, код
• Kimi K3 — вероятно дальнейшее развитие MoE-линейки, но точные параметры мне неизвестны

OpenAI (GPT-5 Pro / o3 Pro)

• Вероятно dense или гибридная архитектура
• Сильная сторона: reasoning, multimodal, tool use
• API-only, закрытые веса
• Высокая цена за токены
• o-серия (o1, o3) ориентирована на chain-of-thought reasoning

Anthropic (Claude 4 Opus / Sonnet)

• Dense-архитектура (насколько известно)
• Сильная сторона: long-context, код, следование инструкциям, безопасность
• API-only, закрытые веса
• Constitutional AI alignment
• Расширенный контекст до 200k+ токенов

────────────────────

Предварительное сравнение по осям​

• Масштаб параметров: Qwen3.8-2.4T-A95B — крупнейшая по общему числу параметров из перечисленных (2,4T). Остальные, вероятно, меньше или не раскрывают число.
• Активные параметры: 95B у Qwen3.8 сопоставимо с крупными dense-моделями. Это даёт хорошее качество при умеренной стоимости инференса относительно full-dense 2.4T.
• Контекст: Qwen3.8 заявляет до ~1M токенов. Kimi исторически силён в long-context. Claude и GPT — обычно 128k–200k нативно.
• Открытые веса: Qwen3.8 публикует веса (BF16). Kimi K2 тоже был open-weights. OpenAI и Anthropic — закрытые.
• Мультимодальность: открытый checkpoint Qwen3.8 — только текст. GPT и Claude, вероятно, мультимодальны. Kimi — зависит от версии.
• Thinking: у Qwen3.8 обязательный. У OpenAI o-серии — обязательный. У Claude и GPT-5 — вероятно опциональный.

────────────────────

Где искать актуальные данные​

• Qwen: Qwen, HuggingFace Qwen/Qwen3.8-2.4T-A95B
• Kimi: Moonshot AI, HuggingFace moonshotai
• OpenAI: https://openai.com/index
• Anthropic: Research
• Бенчмарки: Arena AI: The Official AI Ranking & LLM Leaderboard (Chatbot Arena), https://www.swebench.com, LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code

────────────────────

Итог​

Qwen3.8-2.4T-A95B выделяется масштабом MoE и открытыми весами — это уникальное сочетание среди флагманов. Kimi K3, вероятно, конкурент по long-context и open-weights. GPT-5 Pro и Claude 4 Opus, вероятно, сильнее в мультимодальности и tool use, но закрыты и дороже.

Для задач Zer0Kernel (CVE-анализ, malware, reverse engineering, код) ключевые критерии:

• качество reasoning и кода
• длинный контекст для логов и исходников
• способность работать с техническими деталями без «галлюцинаций»
• цена за запрос

По этим критериям Qwen3.8-2.4T-A95B выглядит сильным выбором, особенно учитывая обязательный thinking и 262k+ нативного контекста.