Hacker News Digest

DeepSeek открыла исходный код DeepInfer — высокопроизводительного фреймворка вывода, на котором работают её крупномасштабные продакшен-сервисы. Релиз ориентирован на офлайн-вывод и включает ключевые возможности для обслуживания под нагрузкой. Поддерживается пока одна модель — DeepSeek-V4.1-Flash. Среди заявленных функций: оптимизированные ядра (FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect и собственные ядра на TileLang), параллелизм Attention DP и MoE EP с балансировкой EPLB, механизм DSpark с проверкой по оценке уверенности, асинхронное планирование батчей без накладных расходов, инвариантность к составу батча и детерминированная генерация.

Отдельно стоит отметить ограниченный реплей SWA: для модели V4.1 по умолчанию сохраняются лишь 140 токенов суффикса, что сокращает работу на этапе prefill. Структурированный вывод поддерживает регулярные выражения, JSON-схемы и грамматики EBNF. Аппаратно фреймворк работает на GPU NVIDIA SM100 и NPU Huawei Ascend 950. Для полного сервиса вывода потребуются система KV-кэша, разделение этапов VE/Prefill/Decode и балансировка нагрузки между репликами — эти компоненты в релиз не вошли. Код распространяется под лицензией Apache 2.0, а за основу изначально был взят проект vLLM.

Обсуждение сместилось с технических деталей на геополитику и экономику: DeepSeek может подорвать монополию Nvidia, поддерживая чипы Huawei Ascend. Релиз DeepInfer расценивают как тактический ответ на запрет продуктов DeepSeek в правительстве США (DHS Order #2026-01) для обхода ограничений. Открытый код для NPU Huawei Ascend может ослабить позиции Nvidia, если стек станет массовым в малых лабораториях. Однако @seamossfet считает, что регуляции и таможенный контроль в США и ЕС нивелируют эту угрозу. Мнения о влиянии релиза разделились: одни видят удар по капитализации OpenAI и Anthropic из-за снижения стоимости вывода, другие (@ryno364) не считают это переломным моментом, так как веса уже были открыты. Появление DeepInfer может снизить цены на API у мелких хостинг-провайдеров (например, OpenRouter) за счет снижения порога входа в высокопроизводительный хостинг. Технические данные: — Пропускная способность одного кластера — 155 трлн токенов в день, выручка вне пика — $38 на карту в час (@schneehertz, @GreenWatermelon). — В релизе нет полноценной системы KV-кэширования (_aavaa_, @dangoodmanUT). — По опыту @VonLuderitz, модель V4.1 Flash работает быстрее и эффективнее Claude Max, имея меньше ограничений.

Intel представила GPU D270 — ускоритель для дата-центров, оптимизированный под инференс, а не обучение. Ключевая идея: агентные ИИ-нагрузки читают гораздо больше, чем пишут, порождая длинные контексты, многошаговые рабочие процессы и доминирование этапа prefill. D270 рассчитан именно на это: до 480 ГБ памяти LPDDR5X на карту, 32 ядра Xᵉ3P, 256 матричных движков XMX и энергопотребление 350 Вт с воздушным охлаждением. Память здесь заменяет дорогую HBM, позволяя держать больше модели и контекста резидентно.

Плата построена на стандартном PCIe 5.0 и пассивном охлаждении — без проприетарных сетей и переделки стоек под жидкостное охлаждение. Площадь кристалла перераспределена с графики и трассировки лучей на матричные вычисления, что повышает эффективность инференса. Заявлена поддержка открытых моделей «в день ноль» на фреймворках vLLM и PyTorch. Целевые сценарии — агентный ИИ, RAG с длинным контекстом, ассистенты, работа с документами, мультимодальность и высоконагруженная выдача токенов. Сравнения производительности с RTX Pro 6000 основаны на публичных данных и внутреннем анализе Intel по состоянию на февраль 2026 года.

Обсуждение смещает фокус с технических характеристик на доступность железа для локального запуска LLM, подчеркивая критическую важность объема памяти для MoE-моделей и агентных систем. Основным барьером для локального запуска мощных моделей остается стоимость и объем видеопамяти, а не только вычислительная мощность. Спор о роли ИИ-агентов как нового интерфейса: @K0balt считает их будущим, @hypfer указывает на отсутствие детерминизма и риск случайного удаления данных в продакшене. По опыту @unrented7977, локальные модели (например, Qwen 27b на Blackwell 96GB) уже могут превосходить проприетарные решения вроде Codex в некоторых задачах. Пользователи критикуют страницу продукта Intel за наличие «заглушек» и шаблонного текста, который забыли заменить перед публикацией. По мнению @ismailmaj, D270 больше напоминает потребительскую карту, чем серверную, из-за отсутствия эффективных механизмов multi-GPU, что ограничит её использование при большом количестве одновременных пользователей. По опыту @K0balt, при запуске модели 180b на потребительском железе (2x 3090 + 128GB RAM) скорость падает по мере заполнения контекста, что подтверждает актуальность архитектуры D270 для агентных нагрузок. Считается, что агрессивное снижение цен OpenAI на модель Luna может быть признаком страха перед развитием локальных моделей. По оценке @faragon, если стоимость памяти будет стандартной, итоговая цена устройства может составить менее 3000 USD при массовом производстве.

Kolibri — это открытая модель с весами от Aleph Alpha, выпущенная 3 октября 2026 года в День немецкого воссоединения. Это Mixture-of-Experts Transformer с 78 млрд общего числа параметров, из которых активны только 3 млрд, поддерживающий контекст до 1 млн токенов. Модель обучена на английском и немецком языках, специализирована для использования в регулируемых секторах: государственное управление, промышленность и авиация. Доступна на Hugging Face под лицензией Apache 2.0.

Kolibri превосходит свою предшественницу — Kolibri Origin (30B общих, 3B активных параметров, 65k токенов контекста) — благодаря улучшенному пайплайну обучения, включающему автоматическое восстановление после сбоев, сотни ablation-экспериментов и стандартизированный мониторинг. В тестах Kolibri показывает высокие результаты: в HumanEval+ — 94.7%, в LiveCodeBench v6 — 93.8%, в среднем по коду — 94.2%, а в Instruction Following (IFBench) — 81.9%. Для немецкого языка достигнуты сильные показатели, например, 75.0% в CL v4 (web search). Модель оптимизирована для локального развертывания, снижая зависимость от внешних API и обеспечивая суверенитет данных через полную прозрачность цепочки поставок и защиту интеллектуальной собственности. Для запуска требуется пакет aleph-alpha-inference и vLLM с поддержкой fp8 кэша, reasoning и tool-calling. Рекомендуемые параметры сэмплинга: temperature=1.0, top_p=0.97, top_k=128. Для контекстов свыше 262k токенов нужно указать --max-model-len 1048576.

Обсуждение характеризует Kolibri как попытку создать контролируемый инструмент ЕС для регулируемых секторов. Беспрецедентной для коммерческих LLM признана открытость Aleph Alpha в описании датасета и методов обучения, включая протокол Merlin-Arthur для борьбы с галлюцинациями. Конкурентоспособность модели вызывает споры: Qwen3.8 27B превосходит Kolibri в немецком языке (79.9 против 70.8), а отсутствие сравнения с Qwen3.8 Flash может быть умышленным. При этом Kolibri эффективна в кодировании и агентных задачах, работает быстро (170 токенов/с на fp8 на RTX Pro 6000), но склонна к избыточному «размышлению». Вопрос «суверенности» остается дискуссионным. Поглощение канадской Cohere одни считают подрывом суверенитета, другие — логичным объединением ресурсов. Сомнения вызывает и использование LLM для перевода текстов в энциклопедический стиль. Для реального суверенитета в госсекторе необходим полный стек (эмбеддинги, ретривер, память), а также открытые, управляемые сообществом тренировочные запуски по аналогии с Debian. Технические особенности: — Ограничение немецким и английским языками может мешать интеграции знаний из других языков. — Собственный токенизатор Aleph Alpha многообещающ, но его эффективность не оценена. — Для локального развертывания 78 млрд параметров требуют значительной памяти; рекомендуется квантование 4/8 бит, так как fp16 не помещается на обычных машинах и Mac. Критическими остаются вопросы соответствия GDPR при обработке данных и общая оценка Aleph Alpha: от обвинений в отсутствии таланта до признания новаторами в создании ИИ-экосистемы ЕС.

Языковая модель с 4 миллиардами параметров была дообучена с помощью supervised fine-tuning и agentic reinforcement learning для генерации планов выполнения SQL-запросов в PostgreSQL, которые работают быстрее, чем планы, выбранные стандартным оптимизатором. На этапе SFT модель научилась генерировать корректные планы для 14 из 113 ранее неразрешимых запросов, а после RL — для всех 113. В результате среднее время выполнения запросов сократилось на 44,7% по сравнению с планами PostgreSQL, а в лучших случаях — до 81%. Для устранения шума измерений был создан специальный стенд с изолированными контейнерами и минимизацией влияния кэша страниц Linux. Для обучения в шумной среде разработана модификация алгоритма GRPO, а обучение распределено между арендованным узлом с двумя H100 (для vLLM и тренера) и локальными четырьмя контейнерами PostgreSQL. Кроме того, использовано off-policy дистиллирование из 500 траекторий агента GPT-6 Astra для стабилизации обучения. Подход подтверждает, что даже небольшие открытые модели могут обучаться превосходить традиционные оптимизаторы в задачах с однозначной метрикой качества — временем выполнения запроса.

Обсуждение ставит под сомнение практическую ценность LLM‐оптимизатора: заявленные 81 % ускорения получены на небольшом наборе (8 ГБ, полностью в памяти), их масштабируемость и экономическая эффективность не доказаны, а риски галлюцинаций и повышенных затрат могут превзойти выгоду. Большинство участников советуют более простые и проверенные подходы: правильное индексирование, классическое ML, гибридные решения и ускорение самого PostgreSQL. Некоторые считают LLM‐подход слишком грубым и ресурсоёмким, предлагая целенаправленные нейросетевые эвристики (похожие на AlphaGo) или видя потенциал LLM в генерации планов. Критики отмечают, что 81 % ускорения не сравнимо с более чем 3‐кратным выигрышем без модели, а затраты на H100 и API могут превысить выгоду. Важно проверять планы, сгенерированные LLM, в изолированной копии продакшн‐БД, чтобы убедиться в ускорении типичных запросов и отсутствии регрессий. Для снижения риска галлюцинаций рекомендуется запускать LLM несколько раз и выбирать лучший план, либо использовать его как подсказку традиционному оптимизатору. Гибридный подход — выбор между традиционным оптимизатором и LLM‐моделью с последующим взятием лучшего плана — рассматривается как более практичный. Также советуют включать опцию RECOMPILE в хранимых процедурах для решения регрессий без LLM. Время планирования является критическим фактором: улучшения планов должны учитывать суммарное время планирование + выполнение. Классические методы ML (модели предсказания стоимости планов) считаются более подходящими, чем крупные языковые модели, для оптимизации запросов. Некоторые предлагают ускорять сам PostgreSQL через CUDA для более прямого прироста производительности. Простое, но часто забываемое правило — правильно индексировать данные; без этого любые улучшения планов будут ограничены.

GLM-5.3 — это открытая модель с теми же весами, что и GLM-5.2, но с существенным улучшением благодаря пост-обучению. Она демонстрирует 50% рост в внутреннем тесте Z.ai Code Bench по сравнению с GLM-5.2 и достигает SOTA среди открытых моделей на публичных бенчмарках, включая Terminal Bench 3.0 (28.3 vs 4.6 у GLM-5.2) и Agents' Last Exam (28.5 vs 23.8). Особенно выделяется её способность к долгосрочному планированию и сложному коду.

В области кибербезопасности GLM-5.3 показывает неожиданно быстрый рост способностей: на CyberGym она лидирует с 84.5% (против 77.2 у GLM-5.2), а на этапах эксплуатации уязвимостей более чем удваивает результаты предшественницы — например, на ExploitGym (2h/6h) достигает 105/130 против 29/39 у GLM-5.2, а на ExploitBench — 54.4% против 24.4%. Модель поддерживает гибкое управление объёмом рассуждений через параметр reasoning_effort (low/high/max, по умолчанию max) и требует явного указания clear_thinking=true в шаблоне чата для корректной работы. Развёртывание возможно через SGLang, vLLM, Transformers и другие фреймворки, включая поддержку Ascend NPU.

GLM-5.3 и его Flash-версия показали значительный рост производительности благодаря пост-обучению, а не увеличению размера, и конкурируют с проприетарными моделями при более низкой стоимости и возможности локального запуска. GLM-5.3 прибавил 50% в Z.ai Code Bench относительно GLM-5.2 и достиг SOTA среди открытых моделей на Terminal Bench 3.0 и Agents' Last Exam. GLM-5.3-Flash отвечает быстрее DeepSeek-V4-Flash (108 с против 154 с) при сопоставимой цене за задачу, что делает его предпочтительным для латенси-чувствительных сценариев. Улучшения достигнуты на той же базе весов, что и GLM-5.2, — за счёт качества тренировочных сред и валидаторов. GLM-5.3-Flash также демонстрирует лучшее соотношение токенов к точности, снижая избыточное «переразмышление» по сравнению с Qwen3.8 и GLM-5.2. В Q3-квантовании он уже превосходит многие модели 100B–200B по глубине мышления и внутренним тестам, а в задачах кодирования считается лучшим выбором, обходя DS4Flash и Stealth Ox-Alpha. Локальный запуск GLM-5.3 возможен на 512 ГБ RAM (Mac M5 Ultra или сервер с Epyc) и окупается: модели на старом железе показывают заметный рост, например с AA-счёта 24 до 57. Отмечается спор: часть пользователей считает вложения в дорогое локальное железо неоправданными из-за быстрого удешевления облачных API, другие — что локальная инфраструктура становится выгоднее со временем. Также обсуждается, что GLM-5.3 слаб в прозаических ответах и трудно настраивается на естественный стиль, но превосходит другие модели в рутинных задачах и кодировании. Практические советы: для длительной обработки выгоднее сервер с двойными Xeon и 512 ГБ RAM — он дешевле Mac M5 Ultra, хотя медленнее, и может работать в гараже из-за шума. GLM-5.3-Flash лучше использовать как исполнителя, а Kimi или другие модели — как планировщик. Для специализированных задач (например, поиск сделок) GLM-5.3 подходит как база для fine-tuning или LoRA-адаптации. Протестировать Flash-версию можно на OpenRouter через DeepInfra. Ограничения: GLM-5.3-Flash не поддерживает изображения, что не критично для текстовых и кодовых задач. Несмотря на более высокую цену по сравнению с GLM-5.2, переход на Flash-версию считается оправданным из-за значительного превосходства.

Qwen3.8-27B — новая модель из семейства Qwen с 27 млрд параметров, оптимизированная под FP8-квантование с блоком 128, сохраняющая почти полную точность оригинала. Она сочетает мощь в кодировании, научных задачах и агентных сценариях с поддержкой видеопонимания и гибким контролем рассуждений через параметры reasoning_effort и preserve_thinking. Модель нативно обрабатывает изображения и видео до часа длиной, а контекст поддерживается до 1 млн токенов — в развернутой версии на Qwen Cloud.

Технически, архитектура включает 64 слоя с гейтед DeltaNet и Gated Attention, а также MTP для многотокенного предсказания. В бенчмарках она превосходит предшественников: 73% на Terminal Bench 2.1 (против 63,4% у Qwen3.6) и 61,7% на SWE-bench Pro. Для длинных контекстов рекомендуется настраивать rope_parameters с фактором 2.0 при 524K токенов, а для видео — увеличить longest_edge до 469M для высокой частоты кадров. Модель совместима с vLLM, SGLang и другими фреймворками, а готовая облачная версия с инструментами и 1M контекстом выйдет вскоре.

Qwen 3.8 27B демонстрирует качество, сопоставимое с Opus 4.6, в кодировании и генерации SVG (подтверждено @CMay, @simonw, @swalsh на Mac M5, RTX 3090/4090), но страдает от низкой эффективности: высокое потребление VRAM, медленная генерация и склонность к «переосмыслению» — тратит в 10 раз больше токенов, чем Gemma 4, часто зацикливаясь в режиме xhigh reasoning. @RandyOrion и @c7b утверждают, что качество напрямую зависит от усилий размышления, тогда как @Casteil и @dofm считают это избыточным. Для контроля поведения рекомендуют явно задавать `--chat-template-kwargs '{"preserve_thinking":true,"reasoning_effort":"medium"}'` или использовать шаблоны Jinja от @froggeric. Для ускорения инференса: на RTX 5090 — ninfer (~138 tok/s), на RTX 4090 — оптимизированный llama.cpp с MTP и flash-attn (@hypfer). VRAM-потребление неэффективно: 32K контекста — 2.5 ГБ, 128K не загружается даже при Q4_0 (в отличие от Gemma 4/Muse Glimmer). Квантованные версии от Unsloth (Q8kxl) зацикливаются — стабильнее версии от bartowski в llama.cpp. В немецком языке прогресс минимальный, с регрессиями, уступает Gemini Flash Lite (@scirob). Для бюджетного запуска — Intel B70 с 32 ГБ VRAM за $1500 (@Almondsetat). Модель корректно генерирует JS-приложения и минимизирует ошибки при портировании на Rust/Tauri (@dexterlagan). 1-битное квантование позволяет запустить на 16 ГБ Mac Mini, но требует перезапуска сессии при смене режимов plan/act (@jedbrooke).

Qwen3.8 — новый флагман открытой модели, построенный на архитектуре Qwen3.5 с 2,4 трлн параметров, из которых 95 млрд активно используется. Ключевые новшества: улучшенное кодирование, поддержка агентов с длительным планированием, гибкое управление «мышлением» через параметр reasoning_effort и сохранение контекста рассуждений между сообщениями. В отличие от закрытых аналогов, модель доступна в открытом доступе и может быть развернута через vLLM, SGLang или TokenSpeed, а также использована через официальный API Qwen Cloud.

Особое внимание уделено надёжности завершения многократных задач: модель лучше справляется с агентными сценариями, где требуется последовательное взаимодействие с окружением, и демонстрирует стабильные результаты на бенчмарках вроде SWE‑bench Pro (67,7 %) и PaperBench (93 %). Для оптимального использования рекомендуется sampling‑настройка temperature=1.0, top_p=0.95, top_k=20 и выделение до 262 144 токенов на рассуждения и 131 072 — на финальный ответ. Эти параметры позволяют моделировать сложные цепочки выводов без потери качества.

Qwen3.8 — модель с 2,4 трлн параметров (95 млрд активных), поддерживает reasoning_effort для регулирования глубины рассуждений и сохраняет контекст рассуждений между сообщениями. Полная версия занимает 5 ТБ, quant-версия — 397 ГБ. Ограничения: нет поддержки зрения в открытой версии, контекст до 250K (можно попытаться расширить через сторонние решения). Для локального запуска требуются мощные ресурсы (например, RTX 5090 + 64 ГБ ОЗУ), но даже этого может не хватить. Сравнивается с Kimi K3, Opus 4.8 и Fable 5: некоторые считают, что у Qwen3.8 нет значительных преимуществ из-за ограничений и размера. Используется для OCR, кодирования и других задач — пользователи делятся результатами экспериментов.

• В день выхода открытой модели вроде gpt-oss-120b мы сразу ускоряем её для клиентов, как партнёры запуска OpenAI. К концу дня запуска стали лидерами на NVIDIA по латентности и пропускной способности по данным OpenRouter.

• Быстрая оптимизация обеспечена гибким стеком инференса и экспертизой команды; за время написания поста прибавили ещё ~100 ток/с при 100% аптайме.

• Работы включали:

  • Тесты и бенчмарки в TensorRT-LLM, vLLM и SGLang.
  • Совместимость с архитектурами Hopper и Blackwell.
  • Интеграцию с нашим стеком (в т. ч. NVIDIA Dynamo).
  • Оптимизации: маршрутизация с учётом KV-кэша, спекулятивная генерация с Eagle.

Шаг 1: Первый инференс

• Запускаем базовый инференс в любом доступном фреймворке и на нужных GPU/серверных уровнях.
• Параллелим работу: одни пробуют vLLM и SGLang, другие — TensorRT-LLM; быстрее всего взлетел TensorRT-LLM.
• Важно обслуживать модель и на Hopper (H100), и на Blackwell (B200) для широкой доступности и максимальной скорости.
• Гибкость рантайма позволяет быстро переключать инструменты и обновлять матрицу поддержки.

Шаг 2: Исправление багов совместимости

• Новые архитектуры приводят к тонким несовместимостям; GPT OSS добавил, например, Harmony — новый формат ответов.
• Итеративно чиним и валидируем на скорость и корректность; по возможности контрибутим обратно в open source.
• Благодаря сообществу есть несколько отличных путей запуска GPT OSS, проблемы быстро выявляются и чинятся.

Шаг 3: Оптимизация конфигурации

• Хотя GPT OSS 120B можно запустить на одном H100, оптимально масштабировать на 4–8 GPU для лучшей латентности/throughput.
• Рассмотрены два подхода параллелизма для MoE: тензорный и экспертный. Тензорный даёт меньшую задержку, экспертный — выше системную пропускную способность. Мы выбрали тензорный, так как приоритет — латентность.
• Приняли MoE Backend в TensorRT-LLM (поддерживается на Blackwell, не на Hopper), который добавляет более быстрые CUDA-ядра и превосходит предыдущие решения.

• Обсуждение крутится вокруг запуска и производительности GPT-OSS (20B/120B) на разном железе: от MacBook M-серии и RTX 4090/3050 до датацентровых H100/Blackwell и даже CPU.
• Многие отмечают, что скорость хороша при малых контекстах; при >10k токенов начинается существенная деградация скорости и рост задержек, особенно без MCP/веб-доступа.
• TensorRT-LLM часто даёт лучшую латентность/пропускную способность, но сложен в настройке; альтернативы вроде vLLM/SGLang проще, Llama/Оllama позволяют быстро поднять 20B локально и даже распределить по старым GPU.
• Идут споры о “доступности” H100: купить дорого, но аренда широко доступна и выгоднее для нерегулярных нагрузок; при этом Blackwell с FP4 обещает ещё больший буст, в экосистеме Rust добавляют FP8/FP4.
• Пользователи спрашивают про требования к VRAM, практичную локальную агентную разработку на потребительских GPU, и оптимальные настройки на Mac (например, iogpu.wired_limit_mb).
• Обсуждают техники ускорения (спекулятивное декодирование — вызывающее вопросы пользы), причины падения токен/с при длинных диалогах, и различие prefill vs decode по узким местам.
• Наряду с похвалами скорости есть критика: сложность стеков, неточности/галлюцинации ответов, «извиняльный» контент, и вопрос — зачем OpenAI выпускает OSS-модели и как это соотносится с доступностью железа.