• Структура Strip занимает 8 байт, но автор утверждает, что 259×64+7296 ≈ 24 КБ, что вызывает сомнения в правильности подсчёта памяти.
• Участники обсуждения предполагают, что речь идёт о кэш-линии в 64 байта и false-sharing, а не о фактическом размере структуры.
• Появился вопрос о том, какие именно бенчмарки корректности используются, и как можно было бы проверить корректность рендеров.
• Также обсуждалось, что вывод рендерера является растровое изображение, что требует копирования на GPU, что может быть не нужно на UMA-системах.

Исследователи протестировали три ведущие AI-модели на способность решать Google reCAPTCHA v2. Claude Sonnet 4.5 показал лучший результат с 60% успешных решений, немного обогнав Gemini 2.5 Pro (56%). GPT-5 значительно отстал с результатом всего 28%, что связано с его долгим и медленным процессом рассуждений, приводящим к постоянным тайм-аутам. Тесты показали, что производительность сильно зависит от типа CAPTCHA: все модели лучше справлялись со статичными заданиями и хуже всего — с кросс-тайл задачами.

Анализ выявил, что GPT-5 страдал от избыточных и навязчивых рассуждений, генерируя больше "мыслительных" токенов и постоянно редактируя свои решения. Эта проблема усугублялась плохим планированием и верификацией. В отличие от этого, Claude и Gemini демонстрировали более сбалансированный подход. Исследование подчеркивает, что в агрессивных средах с реальным временем выполнения скорость принятия решений так же важна, как и глубина рассуждений — иногда переосмысление приводит к такому же провалу, как и недостаток анализа.

• Обсуждение показало, что современные модели всё ещё плохо справляются с задачами вроде cross-tile и reload, что подчеркивает ограничения текущих LLM в распознавании объектов и их границ.
• Участники отметили, что Google reCAPTCHA влияет на поведение пользователей, включая задержки в ответах, что может влиять на точность.
• Обсуждение подняло вопрос о том, что в будущем CAPTCHA может исчезнуть, если ИИ станет достаточно продвинутым, что ставит под вопросом саму необходимость CAPTCHA.
• Участники обсудили, что вместо CAPTCHA можно было бы использовать более дружественные к пользователю методы, такие как двухфакторная аутентификация или анализ поведения, которые были бы менее исключающими.

Исследование Оксфордского института интернета выявило серьезные недостатки в текущих методах оценки искусственного интеллекта. Ученые обнаружили, что существующие подходы к тестированию ИИ-систем часто не учитывают их поведение в реальных условиях, что приводит к переоценке их возможностей и безопасности. В работе подчеркивается, что текущие тесты слишком узко сфокусированы на конкретных задачах и не охватывают широкий спектра потенциальных рисков.

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

• Обсуждение показало, что бенчмарки для LLM находятся в состоянии «дикого Запада»: нет единого стандарта, исследователи не хотят заниматься этим полностью, а существующие тесты часто не отражают реальные способности моделей.
• Участники отметили, что бенчмарки часто используются в маркетинговых целях и не отражают реальные способности моделей, особенно когда речь идет о сложных задачах, которые не могут быть покрыты существующими тестами.
• Был

Ubuntu 25.10 представляет поддержку архитектурных вариантов, в частности amd64v3 (x86-64-v3), позволяя оптимизировать пакеты под современные процессоры без потери совместимости со старым оборудованием. Для этого были изменены dpkg, apt и Launchpad, чтобы создавать несколько версий пакетов для разных уровней архитектуры. В текущем релизе около 2000 пакетов в компоненте "main" уже пересобраны, но они не прошли полное тестирование, поэтому возможны ошибки. Бенчмарки показывают прирост производительности около 1% для большинства пакетов и больше для числовых приложений.

Большинство облачных экземпляров и машин за последние 10 лет поддерживают x86-64-v3, что можно проверить командой ld.so --help | grep '\-v[0-9]'. Чтобы включить amd64v3, нужно установить последнюю версию dpkg и добавить конфигурацию APT::Architecture-Variants "amd64v3"; в /etc/apt/apt.conf.d/99enable-amd64v3, затем обновить систему. Важно, что после установки amd64v3 версий пакетов перенос жесткого диска на старое оборудование без поддержки x86-64-v3 станет невозможен. В 26.04 LTS эта проблема будет решена, а все пакеты будут пересобраны и полноценно протестированы.

• Ubuntu 25.10 предлагает оптимизированные пакеты для x86-64-v3 (AVX2), но не делает акцент на этом в анонсе.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.
• Вопрос о том, стоит ли жертвовать совместимостью ради 1 %, остаётся открытым, особенно если учесть, что в будущем может появиться v4 или v5.
• Пользователи обеспокоены, что не смогут вынуть диск и загрузиться на старом ноутбуке в случае сбоя.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.

При оптимизации кастомной ограниченной приоритетной очереди автор столкнулся с парадоксальным случаем, когда уровень оптимизации O3 работал на 123% медленнее, чем O2. Этот результат был подтверждён на процессорах Intel Haswell и AMD Zen 3, что указывает на системную проблему, а не на специфичную для архитектуры. Бенчмарки проводились с использованием criterion, а результаты демонстрировали устойчивую регрессию производительности при повышении уровня оптимизации.

Реализация использует отсортированный Vec с бинарным поиском вместо бинарной кучи, что эффективнее для данного случая из-за требования уникальности id элементов. Ключевую роль играет функция сравнения, работающая с числами с плавающей запятой, которые известны своей сложностью в сравнении. Для анализа производительности автор использовал flamegraph, чтобы выявить разницу в поведении между уровнями оптимизации.

Nice read. Last week I wrote a blog post about two noteworthy cases of O3 being slower than O2 in C++: https://barish.me/blog/cpp-o3-slower/ In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the

Проект представляет собой набор реализаций бенчмарка "Are-we-fast-yet" на различных языках программирования, включая Oberon, C++, C, Pascal, Micron и Luon. Основная цель - сравнение производительности разных языков через единый тестовый набор. Реализации позволяют разработчикам оценить эффективность каждого языка в стандартных задачах и понять, как современные языки конкурируют с классическими.

Бенчмарк охватывает ключевые алгоритмические задачи, такие как сортировка, обработка строк и математические вычисления. Интересно, что даже в 2023 году некоторые классические языки, как C и Pascal, демонстрируют конкурентоспособную производительность, в то время как более современные языки предлагают разные компромиссы между скоростью и выразительностью кода. Проект предоставляет ценный ресурс для выбора языка программирования под конкретные требования производительности.

• Обсуждение в основном касается языков Oberon и их компиляторов, включая их производительность и репозиторий.
• Участники обсуждают, что репозиторий недавно добавил реализацию на C++, но она оказалась значительно медленнее.
• Также поднимается вопрос о названии Micron — участники считают его плохим выбором, так как может вводить в заблуждение.
• Появляется ссылка на недавно опубликованные результаты тестов производительности.
• Участник под ником «dead» отмечен как неактивный.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

Redis показал заметно лучшую производительность по сравнению с Postgres при использовании в качестве кэша. В тестах на чтение Redis обрабатывал больше запросов в секунду, при этом нагрузка на CPU у сервера с Redis была умеренной (~1280mCPU из доступных 2000mCPU), а потребление памяти стабильно держалось на уровне ~3800 МБ. Сервер HTTP стал узким местом в случае Redis, исчерпав свои CPU-ресурсы.

Для Postgres основным ограничением стал CPU самой базы данных, который постоянно работал на максимуме. Это подтверждает, что Redis эффективнее справляется с высоконагруженными сценариями кэширования, особенно когда требуется низкая задержка и высокая пропускная способность операций чтения.

• Критика методологии бенчмарка: сравнение ненастроенных Postgres и Redis считается некорректным, так как Postgres требует тонкой настройки под железо для серьёзных тестов.
• Сомнения в целесообразности использования Postgres как кэша: отсутствие встроенного TTL, нагрузка на основную БД и сложности с вакуумом делают Redis более надёжным решением.
• Подчёркивается важность контекста: для небольших нагрузок (<1000 RPS) и упрощения стека использование Postgres может быть оправдано.
• Замечания о специфике теста: сравнение ограниченного Postgres (2 ядра) с неограниченным Redis, малый размер данных и отсутствие пайплайнинга искажают результаты.
• Обсуждаются альтернативы: использование UNLOGGED таблиц, специализированных клиентов (rueidis) или встроенного кэша приложения вместо распределённого решения.

SWE-Bench Pro — это новый бенчмарк для оценки способности ИИ-агентов решать сложные и долгосрочные задачи в разработке ПО. Он включает реальные проблемы из открытых репозиториев, требующие анализа кода, поиска ошибок, написания тестов и внесения изменений. Это шаг вперёд по сравнению с предыдущими тестами, так как фокусируется на многошаговых задачах, имитирующих реальную работу инженера.

Проект демонстрирует, что современные модели, такие как GPT-4, справляются лишь с частью заданий, подчёркивая пробелы в понимании контекста и планировании действий. Это указывает на необходимость дальнейшего улучшения агентов для автономной работы над сложными проектами. Практический вывод: хотя ИИ уже полезен в рутине, до полной автономии в разработке ещё далеко.

• Критика названия "SWE-Bench Pro" как потенциально нарушающего чужой товарный знак и вводящего в заблуждение относительно превосходства.
• Сомнения в эффективности защиты тестового набора копилфт-лицензией для предотвращения обучения на нём ИИ-моделей, учитывая игнорирование лицензий в индустрии.
• Вопросы к репрезентативности бенчмарка: отсутствие в тестировании самых современных и крупных моделей, доверие к приватному датасету и проблема "загрязнения" публичного.
• Обсуждение ключевых проблем бенчмарков для ИИ-кодеров: сложность создания "чистых" задач, которые модель не видела ранее, и уязвимость к "читтингу" через анализ скрытых частей репозитория.
• Замечание о стиле README репозитория (обилие эмодзи) как возможном признаке генерации LLM, что подрывает доверие.

Современные ИИ-модели демонстрируют впечатляющие способности в генерации кода, но сталкиваются с серьёзными трудностями при работе с реальными задачами компиляции — устаревшими инструментами, зависимостями и кроссплатформенной сборкой. CompileBench протестировал 19 моделей на 15 практических заданиях, включая сборку проектов вроде curl и jq, компиляцию под Windows/ARM64 и даже оживление 22-летнего кода 2003 года. Некоторые агенты выполняли до 135 команд за 15 минут для получения рабочего бинарного файла.

Anthropic модели Claude Sonnet и Opus заняли лидирующие позиции по успешности сборки, подтверждая свою репутацию среди разработчиков. OpenAI модели, особенно GPT-5-mini, показали лучшую ценовую эффективность, балансируя между скоростью и качеством. Gemini от Google неожиданно провалился: модели часто игнорировали спецификации задач, например, создавали динамические вместо статических сборок, несмотря на чёткие требования.

• Сложность сборки и кросс-компиляции legacy-проектов (Chocolate Doom, curl) на современных системах, включая ARM64.
• Способность ИИ (особенно Claude Opus) автоматически исправлять ошибки сборки, хотя процесс может занимать много времени и команд.
• Предложения расширить бенчмарки более сложными проектами (FFmpeg, Chromium, Qt) и проверкой корректности через тесты и санитайзеры.
• Скептицизм относительно способности ИИ гарантировать корректность итогового бинарного кода после автоматических правок.
• Практическая ценность автоматизации рутинных задач по настройке toolchain и портированию старого кода.

Как переписывание промта повысило эффективность GPT-5-mini на 22%

Мы представляем результаты тестирования модели GPT-5-mini в рамках бенчмарка Tau², предназначенного для оценки языковых моделей. Оказалось, что простое переписывание промта повысило успешность небольшой модели более чем на 20%.

Тестирование LLM с Tau²

На летнем обновлении OpenAI заявили, что GPT-5 значительно улучшила агентские задачи. Для проверки использовали бенчмарк Tau², симулирующий реальные взаимодействия в телекоме, ритейле и авиалиниях. Однако улучшения GPT-5 были заметны только в телекоме, поэтому мы сосредоточились на этой области.

GPT-5-mini предлагает преимущества: вдвое меньше задержка, выше пропускная способность и в пять раз дешевле при 85–95% производительности полной GPT-5. Мы провели эксперимент, чтобы оценить, насколько хорошо GPT-5-mini справляется с бенчмарком и можно ли улучшить её результаты, изменяя политики агентов или описания задач.

Базовые результаты: 45% провалов

Мы запустили подмножество из 20 тестовых сценариев телекома. Результаты показали успешность всего 55%. GPT-5-mini с её ограниченными возможностями reasoning не приблизилась к флагманской GPT-5.

Бенчмарк также ввёл метрику pass^k, измеряющую надёжность агента при k попытках выполнения задачи, и выделил задачи, с которыми агент не справляется совсем.

Решение: переписывание промтов с помощью Claude

Мы поставили три цели: повысить общую успешность, "разблокировать" больше задач и улучшить надёжность агента. Используя генеративный ИИ, мы поручили Claude проанализировать политики агентов в телекоме и переписать их для упрощения понимания моделью GPT-5-mini.

Ключевые улучшения включали:

• Чёткие деревья решений и последовательные шаги
• Ясные условия и обработку ошибок
• Снижение когнитивной нагрузки через таблицы и шаблоны
• Действенные команды вместо описаний

После переписывания промтов успешность GPT-5-mini выросла до 77%, что на 22% выше исходного показателя. Это демонстрирует, что тонкая настройка промтов может значительно повысить эффективность небольших моделей без изменения их архитектуры.

• Оптимизация структуры промптов (деревья решений, нумерованные шаги, проверки зависимостей) значительно улучшает работу ИИ-агентов.
• Использование Claude для перезаписи промпта повысило эффективность GPT-5-mini в телеком-бенчмарке, но методология вызывает вопросы о возможной утечке данных.
• Подход перезаписи промптов затратен по времени и ресурсам, не универсален для разных доменов и может нивелировать преимущества небольших моделей.
• Сообщество выражает скептицизм относительно долгосрочной стабильности и воспроизводимости результатов, полученных с помощью подобных техник.
• Многие отмечают, что описанные практики уже представлены в более продвинутых фреймворках, таких как DSPy.
• Обсуждается этический аспект: оптимизация промпта под конкретный бенчмарк может искажать оценку истинных агентских способностей модели.
• Отсутствие исходных промптов и деталей перезаписи затрудняет независимую верификацию и воспроизведение результатов.

Разрабатывая CLI-утилиту, я хотел избежать тормозов при тестах из-за fstat, как это было в Bundler. Решил попробовать in-memory FS, как в Go-библиотеке Afero.

В Rust аналогов нет: спросишь — получишь лекцию «в Rust это не нужно». Нашёл два кандидата:

• vfs — поддерживает swap-бэкендов, но без симлинков и прав, а главное — нельзя создавать исполняемые файлы.
• rsfs — старый, почти заброшенный; требует параметризовать весь код типом rsfs::FS, превращая сигнатуры в кашу.

Провёл бенчмарк: vfs, rsfs, ramdisk и обычный SSD — всё показывает ~45 мс. Современные SSD + кеш ОС настолько быстры, что экономия на syscalls незаметна.

Вывод: тестируй прямо на файловой системе — проще и не медленнее.

• Позикс-семантика сложна, поэтому самописная in-memory реализация почти всегда хуже по качеству, чем готовые tmpfs/ramfs.
• Для быстрых тестов достаточно /tmp (часто tmpfs) или /dev/shm — это дёшево и использует проверенный ядром код.
• SSD и кэши ОС настолько быстры, что даже обычное файловое I/O редко становится узким местом; CPU и syscalls чаще ограничивают.
• Несколько участников пожелали стандартным traits для файловой системы, как в Go (fs.FS, afero), но признают, что в std Rust это уже трудно.
• Основная цель обсуждаемого vfs-крейта — встраивать файлы в бинарь, а не мокать диск; об этом автор плохо сообщил в README.

go-sqlite-bench — тесты скорости драйверов SQLite для Go.
Сравниваются:

• modernc.org/sqlite (cgo-free, pure Go)
• github.com/mattn/go-sqlite3 (cgo, libsqlite3)
• github.com/ncruces/go-sqlite3 (cgo-free, modernc fork)

Методика: 1 млн вставок, 1 млн чтений, 1 млн обновлений.
Результаты (Intel i7-12700H, SSD, Go 1.22):

драйвер	вставка	чтение	обновление
modernc	2.3 s	0.8 s	2.5 s
mattn	1.1 s	0.4 s	1.2 s
ncruces	1.9 s	0.7 s	2.1 s

Вывод: mattn/go-sqlite3 быстрее, но требует CGO; modernc и ncruces не требуют CGO и проще в кросс-компиляции.

• Участники обсуждают, как в Go шифровать SQLite: упомянули библиотеку sqinn, которая общается с SQLite через stdin/out и показывает высокую скорость.
• Некоторые разработчики хвалят SQLite за простоту и отсутствие накладных расходов, особенно в Python/Django.
• Возникли проблемы с CGO при кросс-компиляции под FreeBSD и Linux; предлагают использовать Zig-инструментарий или Docker-сборку.
• Есть сомнения в корректности бенчмарков, так как автор тестов совпадает с автором sqinn.
• Участники отмечают ограничения SQLite при многопроцессном доступе и обсуждают альтернативы вроде DuckDB.

OpenBSD быстрее Linux в 10 раз?
Тест Jann Horn: создаём поток, оба потока открывают по 256 сокетов.

Linux

elapsed: 0.017–0.026 s

OpenBSD

ulimit -n 1024
elapsed: 0.002–0.006 s

Машины примерно равны. Подсказка в коде (не в сетевом стеке).
Обычно OpenBSD проигрывает в странных тестах, а тут — наоборот.

• Обсуждение выросло из «патологического» теста, который на Linux показывает замедление из-за роста таблицы файловых дескрипторов и блокировок, а на OpenBSD — нет.
• Участники спорят, что считать «быстрым»: OpenBSD жертвует скоростью ради безопасности, тогда как Linux активно оптимизирует критические пути.
• Для микробенчмарков советуют использовать __rdtsc(), но предупреждают о проблемах синхронизации TSC между ядрами и на ARM.
• Несколько человек отвлеклись на «пасхалку» в статье — плавающие «пушки», стреляющие курсором.
• Общий вывод: измеряйте свою нагрузку на одинаковом железе; универсального «быстрее» не существует.

Qodo Command набрал 71,2 % на SWE-bench Verified — стандартном бенчмарке для оценки способности агентов решать реальные задачи из GitHub.

• SWE-bench Verified включает 500 задач из 12 популярных репозиториев (Django, scikit-learn, sympy и др.).
• Каждая задача: описание бага/фичи + тест, который должен проходить после исправления.
• Оценивается только успешность прохождения тестов; стиль и качество кода не учитываются.

Результаты

• 71,2 % — новый рекорд среди публичных решений.
• +18,2 п.п. от предыдущего лидера (CodeStory Aide).
• +31,2 п.п. от первого релиза SWE-bench (2023).

Ключевые инсайты

• Контекст важнее модели: использование 128k-токенного окна и RAG-поиска по 500+ файлам дало +12 %.
• Итерации решают: 3–5 попыток сборки/тестов повышают успех на 8 %.
• Маленькие PR легче: задачи <30 строк кода решаются в 84 % случаев, >200 — лишь 38 %.

Что дальше

• Публикация детального тех-отчёта и открытого датасета.
• Расширение до 1 000 задач и добавление новых языков (Go, Rust).

• Qodo показал 71,2 % на SWE-bench-verified — 5-е место, всего на 1 % уступая официальному Claude Sonnet 4.
• Участники сомневаются в честности результатов и просят независимую платформу с peer-review.
• Поднимаются вопросы о стоимости, эффективности, размере модели и специфике подготовки именно под тест.
• Обсуждают, что сам бенчмарк «закрыт» для Python-ошибок и не отражает реальную разработку.
• Некоторые уже отказались от Qodo в пользу BugBot и сомневаются в жизнеспособности «обёрток» над LLM.

• За 3 месяца мы масштабировали «мышление» Qwen3-4B: выше качество и глубина рассуждений. Представляем Qwen3-4B-Thinking-2507:

  • Существенно лучше на задачах логики, математики, науки, кода и академических бенчмарках.
  • Улучшены общие навыки: следование инструкциям, инструменты, генерация текста, согласование с предпочтениями.
  • Расширено понимание длинного контекста: 256K.
  • Версия с увеличенной длиной «мышления» — рекомендуем для сложных задач.

• Обзор модели:

  • Тип: Causal LM; Этапы: пре-/посттренировка.
  • Параметры: 4.0B (без эмбеддингов 3.6B); Слоёв: 36; GQA: 32 Q / 8 KV.
  • Контекст: 262 144 токенов.
  • Поддерживается только режим «thinking»; enable_thinking=True не нужен. Шаблон чата добавляет <think> автоматически; нормален вывод, содержащий только </think>.
  • Подробности: блог, GitHub, документация.

• Производительность (избранное):

  • Знания: MMLU-Pro 74.0; MMLU-Redux 86.1; GPQA 65.8.
  • Рассуждения: AIME25 81.3; HMMT25 55.5; LiveBench 71.8.
  • Код: LiveCodeBench v6 55.2; CFEval 1852; OJBench 17.9.
  • Алайнмент: IFEval 87.4; Arena-Hard v2 34.9; WritingBench 83.3.
  • Агенты: BFCL-v3 71.2; TAU1/2 — лучшие в ряде доменов.
  • Мультиязычность: MultiIF 77.3; PolyMATH 46.2.
  • Примечания: выигрыш на Arena — GPT-4.1; для сложных задач — вывод до 81 920 токенов, иначе 32 768.

• Быстрый старт:

  • Нужен свежий transformers (иначе KeyError: 'qwen3').
  • Пример кода: загрузить AutoTokenizer/AutoModelForCausalLM, применить chat template, сгенерировать до 32 768 новых токенов, выделить «thinking»-часть до токена </think> (ID 151668) и основное содержимое.
  • Для продакшна: sglang>=0.4.6.post1 или vllm>=0.8.5; можно поднять OpenAI-совместимый сервис.

• Обсуждают малый открытый модель Qwen3-4B (в т.ч. «Thinking/Instr»), её доступность в LM Studio и на Hugging Face, возможность запуска на ПК, Mac (mlx 4–8 бит) и даже на слабом железе; полный контекст 262k токенов может требовать десятки ГБ RAM.
• По отзывам: модель быстрая, компактная и по многим бенчмаркам заметно улучшена; в ряде метрик приближается к старой 30B MoE-версии при ~7,5× меньшем размере, но новая 30B-A3B всё же сильнее.
• Практический опыт: хороша в анализе задач, но встречаются галлюцинации в предложениях/советах.
• Идёт сравнение с Gemma 3n: на общих тестах (напр. AIME, LiveCodeBench) Qwen3-4B-Thinking показывает значительно более высокие результаты.
• Обсуждают надёжность метрик: многие бенчмарки оцениваются GPT‑4.1; возникают вопросы о возможной адаптации моделей под «угодные» ответы и нехватке ручного аудита.
• Для «народных» оценок советуют LM Arena, Artificial Analysis, OpenRouter stats и r/LocalLlama, но подчёркивают ограниченную надёжность толпы.
• Вопросы пользователей: как соотносится контекст и RAM; варианты для iPhone/Apple Silicon; ссылки на готовые gguf и mlx-сборки предоставлены.