Hacker News Digest

Qwen3.8-Flash-Next — это мультимодальная MoE-модель с 125B параметрами и 51B N-gram-встраиваний, активирующая всего 6B параметров на токен. Она служит ранним превью архитектуры Qwen4 и улучшает эффективность за счёт четырёх ключевых нововведений: гибридного внимания GDN + QSA, гейтованного остатка (GR) с четырьмя ветвями, N-gram-встраиваний, выгружаемых в хост-память с асинхронной префетчкой, и оптимизатора Muon, настроенного под новую архитектуру. Благодаря этим изменениям модель достигает превосходных результатов в кодинге и офисных задачах при обучении, требующем лишь 1/9 ресурсов по сравнению с Qwen3.7-Plus.

Модель поддерживает контекст до 262 144 токенов нативно и масштабируется до 1 000 000 токенов с YaRN. Qwen Sparse Attention (QSA) использует лёгкий индексатор для выбора важного контекста на уровне микроблоков, резко снижая стоимость внимания на длинных последовательностях. Gated DeltaNet (GDN) эффективно сжимает историю, а гейтованный остаток улучшает межслойный поток информации и стабильность обучения. N-gram-встраи позволяют увеличить ёмкость модели с минимальными вычислительными издержками благодаря табличному поиску по локальному контексту. Все компоненты работают совместно для достижения максимальной стоимостной эффективности без потери качества.

Тред дополняет статью практикой локального запуска: подтверждает жизнеспособность модели на 128GB-системах (Strix Halo, Mac, DGX Spark), уточняет реальные размеры и проблемы N-gram сайдкара, даёт конкретные цифры скорости и стоимости, и фиксирует нерешённые вопросы по длинному контексту и совместимости с llama.cpp/vLLM/LM Studio.

• Совет: @xlayn слил llama.cpp с поддержкой дискового кэша N-gram: ~23.54 tok/s на IQ4_XS; @hedgehog на Ryzen 395 / Strix Halo получает ~22 tok/s, качество лучше 3.8 27B и достаточно хорошее, чтобы уйти с 3.6 35B, хотя 35B всё ещё быстрее.

• Совет: @cmrdporcupine выложил отдельный движок инференса под DGX Spark: ~80 tok/s prefill, 12 tok/s decode, ~80 GiB в RAM, N-gram-таблицы подгружаются с SSD.

• Совет: @pram отмечает: релиз Unsloth Desktop весит 73GB, то есть влезает в 128GB Mac и Strix Halo; @jedisct1 опубликовал MLX-кванты oQ4e-128k для Apple M5 128 GiB.

• Спор: @potus_kushner vs @pbmonster о N-gram сайдкаре: @pbmonster считает, что горячие N-gram держатся в RAM, остальные тянутся с SSD, @potus_kushner возражает — Unsloth показывает 50GB при заявленных 4 битах, что ломает сценарий «64GB RAM с 2–3 битным квантом» и делает модель фактически недоступной для обычных пользователей.

• Совет: @andy99 сомневается, что 176B суммарных параметров влезут в 4-битный квант под 100GB; @pbmonster уточняет — N-gram параметры могут жить на SSD с кэшем горячих в памяти.

• Совет: @monster_truck делится опытом в QwenCloud за $18: склеил форки, сделал чистый merge, bisect регрессии и фикс через проектные тулы; 90M входных/400k выходных токенов за $0.45, потрачено менее 10% недельного лимита.

• Несколько участников (@martinald, @tristor, @garo-pro) подтверждают: в mainline llama.cpp, vLLM и LM Studio модель пока не запускается; Unsloth уже отправил патчи в llama.cpp.

• Спор: @simonw: на DGX Spark с UD-IQ1_S результаты хуже, чем у Qwen 3.8 27B; @hedgehog на IQ-квантах в llama.cpp и @freakynit, @whwhyb — напротив, качество выше 27B и лучше DeepSeek V4 Flash. Различие списывают на агрессивность кванта у Simon.

• Совет: @armcat поднимает вопрос входной вербозности: GLM 5.2 на их бизнес-нагрузках накапливал много thinking-токенов, Qwen3.8-27B удваивал это; просит данные о token efficiency именно у Flash-Next.

• Совет: @anon373839 ищет инфу о поведении на DGX Spark на длинных контекстах: при 273 GB/s пропускной способности результаты противоречивы и неполны.

• Участники (@tosh, @lucabytheway, @Imustaskforhelp, @garo-pro) считают релиз значимым: новая архитектура (предвестник Qwen 4), обучение в 1/9 стоимости Qwen3.7-Plus при лучших результатах; N-gram-встраивания уже использовались в DeepSeek, Gemma и Longcat.

• Совет: @amclennon и @respectattentio: модель дешевле DeepSeek Flash по API и подчёркивает разницу стратегий — китайские лаборатории выпускают веса с первого дня, американские держат модели под замком.

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).