🎥 Лекция Microsoft об инженерном пути к квантовому компьютеру промышленного масштаба

Microsoft опубликовала лекцию образовательной серии «Building the Modern Quantum Architecture», посвящённой инженерному пути к квантовому компьютеру промышленного масштаба — способному решать задачи, недоступные классическим машинам.

Ведущий, технический сотрудник Microsoft доктор Маттиас Тройер, объясняет, почему наиболее перспективные применения лежат в области химии и материаловедения — от более совершенных аккумуляторов до экологичных хладагентов, — и как квантовые вычисления будут работать вместе с ИИ и высокопроизводительными вычислениями (HPC) для ускорения научных открытий.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Microsoft выпустила QDK 1.30 с ускорением компиляции квантовых программ

Microsoft выпустила версию 1.30 Quantum Development Kit (QDK) — платформы для разработки квантовых программ, которая компилирует код с языков Q#, OpenQASM и Qiskit в промышленный формат QIR. Главное нововведение — расширенные возможности профиля Adaptive: прямое выражение циклов без разворачивания, вызовы функций без инлайнинга и поддержка неограниченных циклов вроде «repeat-until-success». В отдельных случаях это на порядки сокращает время компиляции и размер программы. Также добавлены новые быстрые исправления в редакторе (автоимпорт и преобразование кубитов в массивы) и настраиваемые политики потери кубитов в моделях шума для двухкубитных операций. Всего релиз включает более 40 объединённых pull-запросов с улучшениями генерации QIR, поддержки компилятора Stim и системы типов.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ OpenAI снизила цены на модели GPT-5.6 Luna и Terra

OpenAI объявила о снижении цен на модели семейства GPT-5.6: самая быстрая и доступная Luna подешевела на 80%, а сбалансированная Terra — на 20%.

С 30 июля API-тарифы составляют $0,20 за миллион входных и $1,20 за миллион выходных токенов для Luna и $2 / $12 — для Terra; цена флагманской Sol не меняется.

По данным компании, Luna обеспечивает интеллект уровня прежних топовых моделей примерно за 6% стоимости задачи и почти в девять раз быстрее. Одновременно в API появился режим Fast mode, заменяющий Priority Processing: для GPT-5.6 Sol он даёт до 2,5× выше скорость за двойную цену без изменения качества.

Снижение цен также отражается в расходовании квот в Codex и ChatGPT Work и вскоре появится в AWS.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Haiqu применила квантовую оптимизацию к проектированию беспроводных сетей

Украинский стартап Haiqu, разрабатывающий квантовое ПО для эффективного использования существующих «шумных» квантовых процессоров, представил новый алгоритм DCA для оптимизации беспроводных сетей.

Алгоритм решает задачу связного доминирующего множества — найти наименьшее число устройств-ретрансляторов, через которые идёт трафик, чтобы вся mesh-, IoT- или ad-hoc-сеть оставалась связной. Вместо поиска идеального решения сразу алгоритм постепенно улучшает уже найденный вариант. Тест провели на 156-кубитном процессоре IBM Quantum Kingston на графе из 73 узлов: DCA стабильно превосходил стандартный LR-QAOA и находил компактнее «костяк» сети.

Оптимизация под особенности процессора почти втрое сократила число сложных операций и глубину вычислений. Алгоритм также переиспользует настроенные параметры от малых задач для больших. Результаты представят на конференции IEEE ICCCN.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Обзор языков и фреймворков квантового программирования в 2026 году

The Quantum Insider опубликовал обзор экосистемы квантового программирования в 2026 году. Квантовая разработка сегодня принципиально отличается от классической: алгоритмы вероятностны, измерение «схлопывает» состояние и не даёт свободно отлаживать код, а нынешние процессоры ограничены 50–300 кубитами.

В обзоре разобраны основные фреймворки — Qiskit от IBM как самый распространённый, Cirq от Google, PennyLane для квантового машинного обучения, Q# от Microsoft для Azure Quantum, CUDA-Q от NVIDIA, Amazon Braket SDK и другие.

Среди ключевых трендов — доминирование Python как общего языка, работа senior-разработчиков сразу с несколькими фреймворками, аппаратные слои абстракции и ускорение на GPU.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ 100 шагов GRPO на бесплатном Colab подняли structured output у 350M-модели на 7 пунктов

Hugging Face показала, как за 100 шагов GRPO в TRL научить LiquidAI/LFM2.5-350M отдавать валидный JSON: на бенчмарке IFStruct результат вырос с 22.6% до 29.7%, по JSON — с 18.0% до 31.9%. Всё на 16 GB GPU бесплатного Colab или Kaggle.

Данные — около 500 примеров из nvidia/Nemotron-RL-instruction_following-structured_outputs: к 40% добавлена инструкция «верни в fenced code block», ещё 20% превращены в задачи с top-level массивом. Награда из трёх функций на шкале [0, 1]: json_format_reward (1.0 за нужную форму, 0.2 за парсящуюся, но не ту), field_count_reward с линейным штрафом за промах по числу полей и schema_validation_reward по JSON Schema, веса 1.0 / 0.5 / 2.0. GRPO: 8 генераций на промпт, lr 5e-5, temperature 1.1, beta 0.01, LoRA r=16 — учится около 6M параметров, 1.66% модели.

Честная деталь: YAML почти не сдвинулся (27.2% → 27.5%), а Qwen3.5-2B всё равно выше с 33.15%. Но рецепт переносится: если маленькая модель на edge «почти» отдаёт JSON — три reward-функции и вечер на Colab дешевле, чем менять модель.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ PyTorch 2.14: NVGEMM, бэкенд nccl2 и отказоустойчивость внутри c10d

Вышел PyTorch 2.14 — 2 995 коммитов от 487 контрибьюторов. Главные темы: новый GEMM-бэкенд и распределённое обучение.

NVGEMM — бэкенд на CuTeDSL, который сам выбирает быстрейшее ядро для GEMM, с epilogue fusion и форматами вроде NVFP4 (только Blackwell). Включается через max_autotune_gemm_backends, требует nvidia-cutlass-dsl 4.6.0. nccl2 — новый in-tree бэкенд c10d из torchcomms: eager-only, one-sided RMA-окна, suspend/resume с offload памяти. Fault tolerance стала частью c10d: перенастройка process group без рестарта кластера, abort-хуки, Flight Recorder работает и с Gloo. В torch.compile — динамические формы через @dynamic_spec, torch.switch для MoE, compile-on-one-rank. На Apple Silicon Cholesky быстрее в 1.2–2.8x, lu_factor — более чем в 100x на мелких батчах. Overlap коммуникации и вычислений в Inductor включён по умолчанию.

Подвох: Python 3.15 поддержан только в eager, torch.compile бросает RuntimeError; ROCm 7.1 выброшен.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ funes: память для coding-агентов, собранная из их же сессионных трейсов

Hugging Face выложила funes — слой памяти для coding-агентов, который строится из сессий, уже лежащих у вас на диске. Поддержаны Claude Code, Codex, pi и Hermes.

Идея простая: агент во время работы уже пишет плотный отчёт о том, что он пробовал, где ошибся и почему передумал. Но грепом по десяти тысячам ходов вопрос «почему мы ушли от стримингового парсера» не решается. funes парсит трейсы в единую форму, чанкует, эмбеддит локальной моделью и пишет в датасет Lance. Запрос — это вектор плюс BM25, слияние рангов, реранкер на кросс-энкодере, перевзвешивание по свежести и добор соседних чанков. Ставится одним бинарником, подключается командой funes add claude, после чего у агента появляются инструменты recall и get, а каждый завершённый ход индексируется автоматически. recall возвращает исходный текст, а не пересказ, и показывает агента, сессию, ход и время.

Память можно привязать к приватному датасету на Hub, тогда она переезжает между машинами и агентами: решение, принятое в Claude Code, вспоминается в Codex. Credentials вырезаются при индексации и проверяются ещё раз при публикации.

На бенчмарке handoff-vs-recall выигрыш не только в удобстве: recall оказался в 8 и в 4 раза дешевле написанного вручную хэндоффа на двух задачах, а компакция на одной из них просто потеряла нужные находки при суммаризации. В комментариях к анонсу есть и независимый замер на 19 тысячах реальных сессий, там hit@1 составил 9 из 100 на дефолтах и 19 из 100 с отключённым 30-дневным half-life — стоит иметь в виду, если ваша история старше месяца.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Granite PatchTST-FM-r2: zero-shot прогноз временных рядов под Apache 2.0

IBM выпустила Granite Time Series PatchTST-FM-r2 — модель примерно на 385M параметров для zero-shot прогнозирования временных рядов, под двойной лицензией Apache 2.0 и OpenMDW 1.0.

На бенчмарке GIFT-Eval среди воспроизводимых zero-shot моделей она вторая по CRPS и MASE, 0.467 и 0.6846 по геометрическому среднему, и первая среди моделей с разрешительной лицензией по состоянию на 8 сентября. Если добавить в сравнение pretrained-модели, которым разрешено видеть тренировочные части оценочных датасетов, r2 остаётся третьей по CRPS и четвёртой по MASE, обходя Chronos-2, Timer-S1 и варианты Toto, хотя часть конкурентов заметно крупнее.

Что изменилось относительно r1: обычные трансформерные блоки заменены на conformer-блоки, где к multi-head attention добавлена темпоральная свёртка с чередующимися ядрами 5, 5, 3, 3. Свёртка забирает короткие зависимости, внимание концентрируется на дальних. Плюс патчи с 50-процентным перекрытием и окном Хэмминга, тридцать блоков вместо двадцати, контекст до 8192 шагов и 99 квантилей на выходе, то есть сразу и точечный прогноз, и интервалы.

Отдельно описан пре-тренировочный корпус: GiftEvalPretrain, синтетика на KernelSynth, TSMixup вне оценочных датасетов и около 500 тысяч последовательностей CauKer. Для enterprise такая прозрачность нередко важнее лишних пунктов в лидерборде. Ставится через pip install granite-tsfm, дальше pipeline на несколько строк, без дообучения.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Workflow1111: интерфейс AUTOMATIC1111 пересобран на 73 узлах gr.Workflow

Команда Gradio пересобрала большую часть функциональности AUTOMATIC1111 как один граф: одиннадцать медиапайплайнов, 73 узла и ни одной своей GPU.

Узлы бывают четырёх видов: fn — обычная функция на Python, model — вызов модели через InferenceClient, space — чужой Space на Hub, dataset — строка из датасета. Из них собраны txt2img с записью параметров генерации в PNG-метаданные, hi-res fix и img2img через FLUX.1-Kontext, генерация промпта на Qwen3-4B, интеррогейт картинки через Qwen2.5-VL и ViT, маска для inpaint из детекций DETR, prompt matrix, апскейл локальным Lanczos и через AuraSR, удаление фона через BRIA RMBG-2.0, PNG Info и image-to-video на Wan 2.2.

Интересна арифметика автономности: из 36 операторных узлов 32 — это fn, и 22 из них работают в процессе без сетевых вызовов. Две трети холста продолжают работать без интернета, а раз это обычные функции, их можно тестировать без канваса, сервера и GPU. Параллелизм получается бесплатно: узлы на одной глубине зависимостей стартуют одновременно, поэтому четыре варианта prompt matrix генерируются разом.

Главное отличие от ComfyUI даже не в этом. Каждый выходной узел автоматически становится типизированным REST-эндпоинтом, а при запуске с mcp_server=True — ещё и MCP-инструментом, который дёргает Claude Code или Cursor. Кастомный узел здесь просто функция на Python.

Если бы вы собирали такой пайплайн сегодня — ComfyUI или gr.Workflow?

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Transformers научился грузить GGUF-квантованные модели llama.cpp напрямую

Hugging Face встроил поддержку GGUF в Transformers: теперь квантованные под llama.cpp модели грузятся привычным from_pretrained, без отдельного рантайма — пока для Apple Silicon и архитектуры Qwen3.5 (dense и MoE). Под капотом — не своя реализация, а Metal-кернелы ggml через библиотеку kernels: отдельные кернелы под квантование (читают упакованные веса, не разворачивая их в полную матрицу), под нормализацию (слитый RMSNorm) и под attention (flash attention на prefill и decode), плюс оптимизации генерации — ранний сброс лишних attention mask и отложенная проверка условий остановки, чтобы реже синхронизировать CPU и GPU.

Цифры: Qwen3.5-4B в BF16 весит 8.42 ГБ, в Q4_K_M — 2.74 ГБ, Q5_K_M — 3.14 ГБ, Q6_K — 3.53 ГБ. На MacBook Pro M2 Max throughput на всех трёх чекпоинтах вышел близко к llama.cpp напрямую.

model = AutoModelForCausalLM.from_pretrained('unsloth/Qwen3.5-4B-GGUF', gguf_file='Qwen3.5-4B-Q4_K_M.gguf') — и модель, скачанная как GGUF-квант, гоняется через весь привычный API Transformers, а не через отдельный llama.cpp-биндинг. Нужны Apple Silicon, PyTorch 2.x (две последние версии) и свежие Transformers и kernels.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Shopify сжал провалы прод-агента в веса модели и срезал стоимость инференса на 96%

Shopify построил continual learning loop на PyTorch и vLLM: вместо того чтобы бесконечно раздувать промпт правилами на каждый новый провал агента в проде, команда компрессирует эти провалы прямо в веса модели через дообучение. Пайплайн — supervised fine-tuning на исправленных траекториях, GRPO reinforcement learning поверх этого и отдельно prompt compression, чтобы не тащить контекст, который SFT уже «зашил» в веса.

Результат — не просто дешевле: качество получилось выше, чем у моделей уровня frontier, при экономии 96% на инференсе. Смысл именно в цикле: провал → траектория с исправлением → дообучение → модель меньше и дешевле, но не наступает на те же грабли — а не в разовом файнтюне под конкретный релиз.

Практический вывод для тех, кто гоняет агентов в проде на дорогой frontier-модели просто потому что она реже ошибается: если ошибки воспроизводимы и их можно собрать в датасет, continual learning loop может оказаться дешевле, чем платить за reasoning на каждый запрос.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Ценовая война моделей: GPT-6 Luna вдвое дешевле прошлой Luna, Opus 5.5 — минус 20%

На неделе почти одновременно вышли Claude Opus 5.5, GPT-6 Sol и GPT-6 Luna — и главное в них не reasoning-бенчмарки, а цены. GPT-6 Luna — $0.10/$0.50 за миллион токенов вход/выход, вдвое дешевле GPT-5.6 Luna. GPT-6 Sol — $2/$10, тоже вдвое дешевле предшественника. Opus 5.5 подешевел скромнее, на 20%, до $4/$20, но у кэшированного входа скидка сразу 60%. Саймон Уиллисон отдельно замечает: у GPT-5.6 в ноябре было запланировано повышение цены на 25% — то есть GPT-6 в реальности вдвое дешевле не текущей, а будущей цены предшественника.

При этом не всё однозначно с качеством: по его же тестам, Opus 5.5 на reasoning-уровне max в одной из задач ушёл в бесконечные раздумья, потратил впустую весь лимит выходных токенов и не выдал результата вообще — максимальный reasoning не значит «максимально надёжный результат», иногда это просто максимальный счёт.

Если гоняете модели через Microsoft Foundry (см. на этой неделе //azure, там ровно эти модели с прайсингом по регионам) — самое время пересчитать cost per task с новыми числами, а не полагаться на прошлые расчёты.

Вы уже пересчитывали свой стек под новые цены, или ждёте следующего раунда снижений?

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Polars 2.0: streaming-движок по умолчанию, спилл на диск с 80% RAM и быстрее DuckDB почти везде

Вышел Polars 2.0, и это мажор не ради красоты: collect() у LazyFrame теперь по умолчанию идёт через streaming-движок, а он не гарантирует порядок строк для join, group_by и unpivot без maintain_order=True. Если у вас тесты сравнивают датафреймы построчно — вот что сломается первым.

Out-of-core включён по умолчанию: при ~80% занятой памяти Polars начинает сбрасывать на диск, дефолтный бюджет 64 ГБ; работает для sort, оконных функций и большинства выражений, join и group_by вне памяти — в планах. Новый тип Map отображает Arrow MapType напрямую (раньше читался как List(Struct)), с выражениями map.get, map.contains_key, map.keys. Неявная подгонка типов стала opt-in, а collect_schema() ловит несоответствия схем без материализации — авторы прямо пишут, что это для агентов, которые быстро итерируют код.

Бенчмарки на TPC-H и TPC-DS против DuckDB 1.5.6, DuckDB 2.0 alpha и DataFusion 54 на c7a.4xlarge и c7a.metal: «Polars по умолчанию был быстрее на всех бенчмарках, кроме одного». Масштабирование с 16 до 192 vCPU на SF100 — 3.8x у Polars против 3.2x у DuckDB. Подвох указан честно: на малых данных 192 потока дают накладные расходы, и на SF10 DuckDB быстрее в 1.3–1.8 раза. Гайд по апгрейду — в документации, раздел releases/upgrade/2.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ ThinkingBox-Bench: 67% провалов агентов выглядят как успех — ни одной ошибки инструмента, но база неверна

Microsoft Copilot Studio выложил бенчмарк, где агента оценивают не по его отчёту, а по конечному состоянию бэкенда: 507 бизнес-процессов (ритейл, автострахование, тревел, необанк, консалтинг), каждый по 20 прогонов с чистой базы, изолированная MCP-сессия на попытку.

Главная цифра: из 79 853 провальных попыток 67.24% завершились «чисто» — с вызовом, меняющим состояние, и без единой ошибки инструмента. Агент сказал «готово», а в базе: неверные значения полей (77.6%), лишние побочные эффекты (43.3%), пропущенные обязательные действия (25.4%). pass@1 у лучших — Claude Opus 5.5 67.16%, Opus 5 66.50%, GPT-5.4 65.36%; лучший open-weight Kimi-K3 — 57.37%. Разрыв между «решил хоть раз» и «решил 20 из 20» огромен: Kimi-K3 решает 93.9% задач хотя бы однажды, но стабильно — только 13.4%; у Opus 5 — 79.1% против 47.5%. Автострахование — самый тяжёлый домен, 33.8% в среднем.

Стоимость за стабильно решённую задачу (20/20): GPT-5.4 $6.80, GPT-6 Astra $7.45, Opus 5.5 $7.80 — по списочным ценам OpenRouter на 20 сентября, задачи синтетические. Код MIT, данные CDLA-Permissive-2.0, есть OpenEnv-окружение; нужны Python 3.11+, uv, Docker и Typesense 30.1.

Практический вывод простой: eval, который читает финальный ответ агента, измеряет красноречие. Проверяйте состояние.

👉🏻 Канал | 💬 Чат | 📕 Каталог

⚡️ Python 3.15: lazy import, распаковка в comprehension и сэмплирующий профилировщик

Вышел Python 3.15, и три вещи в нём стоит попробовать на этой неделе. Первая — PEP 810: lazy import json и lazy from pathlib import Path загружают модуль при первом обращении. Мотивация у Саймона Уиллисона из его LLM CLI: плагины, импортирующие sentence_transformers, добавляли несколько секунд к каждому запуску — типичная боль любого Python-CLI с тяжёлым ML-стеком.

Вторая — PEP 798, распаковка внутри comprehension: [*L for L in lists], {*s for s in sets}, {**d for d in dicts}. Больше не нужен itertools.chain, чтобы сплющить список списков. Третья — профилирование: cProfile переименован в profiling.tracing, а рядом появился сэмплирующий профилировщик Tachyon в profiling.sampling с flame graph, heat map и экспортом в формат Firefox Profiler; к живому процессу он цепляется через python -m profiling.sampling attach PID (на macOS потребовался sudo).

По скорости, по замерам Мигеля Гринберга на rc3, 3.15 примерно равен 3.14; экспериментальный JIT дал 1.2x на Фибоначчи. Заодно 3.10 ушёл в EOL — библиотекам теперь можно опираться на tomllib, asyncio.TaskGroup и timeout(), datetime.UTC. Ставится через uv python install 3.15, и 3.15.0 уже есть в actions/python-versions.

👉🏻 Канал | 💬 Чат | 📕 Каталог