Удивительный прогресс всего за несколько месяцев в развитии моделей и llama.cpp. До этого я тестировал модель Qwen3.6-27B, она не влезала в мои 16 гигабайт видеопамяти, работала довольно медленно, генерация была 12-18 токенов в секунду.

С моим тестовым заданием (маркдаун редактор на Rust и GTK под Linux) она справилась за примерно 20 часов.

Как эксперимент было интересно, но с практической точки зрения бесполезно. Слишком долго.

И вот за это время и вышла модель Qwen3.6-35B-A3B на архитектуре MoE - 35B параметров всего, но на каждый токен активируется только ~3B (8 routed-экспертов + 1 shared из 256). За счёт этого модель работает как значительно более лёгкая по вычислениям, сохраняя при этом качество, близкое к куда более крупным моделям того же класса. В llama.cpp появилась и поддержка этой архитектуры, и куча улучшений производительности, и MTP (Multi-Token Prediction) — дополнительная "голова" предсказания нескольких токенов вперёд, обученная вместе с моделью. MTP даёт ~1.4-2.2x ускорение генерации без потери точности, хотя для MoE-моделей прирост обычно скромнее (~1.15-1.25x).

Так вот, сегодня я решил этой модели скормить своё тестовое задание. Предварительно Claude Code погонял разные тесты и нашёл оптимальные настройки для этой модели.

Сказать, что я удивлён, ничего не сказать. Во-первых, модель целиком влезает в видеопамять. Во-вторых, я получил размер контекста 256k, чего ранее с другими моделями не бывало (даже с небольшими моделями были проблемы).

Скорость обработки промпта примерно 260-400 токенов в секунду. Скорость генерации на пустом контексте была под 100 токенов в секунду, по мере заполнения контекста скорость снизилась до 62-65 токенов в секунду. Но это всё равно чертовски быстро.

От первого промпта до запуска приложения, в котором был кривой и неработающий UI, модель 27B у меня добралась часов за 10. Модель 35B сегодня добралась за 50 минут!

Я воодушевился скоростью, начал говорить модели что исправить и всего за 4 часа получил приложение, которое работает и в котором исправлены все огрехи, даже мелочи.

Интересно будет теперь погонять эту модель на своих реальных проектах. Кто знает, может мечта о годной локальной модели для кода не так уж и далека от осуществления.

Перепробовал за последние месяцы много разных локальных моделей. У меня есть свой тест для них — файл с подробным заданием для редактора заметок под Linux на Rust. Подсветка синтаксиса (несложно, есть из коробки в системном компоненте) и панель предварительного просмотра, которая должна показывать отформатированный текст. В целом, довольно похоже на моё приложение Swifty Notes, но на Rust.

Так вот, Qwen3.6-27B пока что единственная модель, которая добралась до финиша. Работала она в течение 3 дней (не круглосуточно, а только когда я был у компа и мог её направить). Редко, но всё-таки модель испытывала проблемы с вызовом инструментов. Иногда не могла отредактировать файл и останавливалась — приходилось просить её попробовать ещё раз. В целом эту часть я бы оценил на 4 из 5.

Самое главное — модель не ходила кругами. Rust здесь очень удачный выбор: если есть ошибка, то проект просто не компилируется. А в сочетании с тем, что техническое задание требует сначала писать тесты, а потом код (Test Driven Development), очень много проблем находится и исправляется на самых ранних стадиях. И тут модель себя показала неплохо. Достаточно быстро исправляла ошибки, следовала инструкциям из ТЗ и изучала документацию, если вдруг использовала несуществующий API или просто нужно было проверить, что доступно. Тут твёрдая 4 из 5.

Размер модели — 17.5 гигабайт. Я скачал её через LM Studio, но запускал через llama.cpp — на удивление, скорость работы моделей там гораздо выше, хотя вроде бы LM Studio её же и использует. Возможно, более свежие версии llama.cpp просто уже более оптимизированы.

В видеопамять модель не влезает целиком (у меня 16 ГБ), поэтому частично работала на CPU, что очень сказалось на скорости. 15.94 ГБ видеопамяти и ещё около 12 ГБ оперативной памяти занимало всё это чудо в пике (когда контекст уже был близок к заполнению). Размер контекста я выставил 64k — поначалу хватало неплохо, но ближе к концу, когда объём кода вырос, модель довольно часто делала сжатие контекста. Хотя в целом с задачей такого размера модель справилась.

Скорость работы я бы оценил на 2 из 5.

Когда модель отрапортовала, что всё готово, я запустил приложение и увидел, что в панели просмотра у меня просто текстом HTML вместо рендера. Пришлось попросить модель это исправить, и спустя ещё часа полтора-два я получил приемлемый результат. Но стоит упомянуть, что с флагманскими моделями тоже такое сплошь и рядом — с первого раза большие задачи, как правило, не получаются, требуются правки и уточнения.

Итого: Claude Code сделал бы это задание минут за 20–30, и, скорее всего, ещё минут 20–30 я бы потратил на доделывание. Округлим до 1 часа. С Qwen3.6-27B на это понадобилось в сумме около 20 часов работы без остановки, то есть примерно 3 полноценных рабочих дня. Конечно, большую часть времени ты просто сидишь и смотришь, как модель работает. Скорость генерации на предварительных тестах, которые мне помог провести Claude, на моём железе была 12–18 токенов в секунду.

Разница в скорости огромная. Результат удовлетворительный. Многое из требуемого функционала просто не работает, но я виню в этом размер контекста — модели тяжело держать столько кода в памяти.

Тем не менее результатом я доволен. Это вселяет веру в то, что программирование с помощью локальных моделей на обычном железе возможно. А ведь ещё год назад даже облачные модели косячили похожим образом, а локальные модели такого размера и вовсе для программирования не годились. Возможно, через год прогресс приведёт к тому, что для небольших проектов подписки станут не нужны. Да и тенденция к тому, что открытые бесплатные модели уже догнали флагманов от OpenAI и Anthropic, мне нравится.

После релиза 1.1.0 у библиотеки swift-adwaita вышло семь релизов подряд. Пока я продолжаю разрабатывать первое реальное приложение на этой обёртке, всплывают вещи, которые в синтетических тестах не видны — и почти каждая правка отсюда. Главная история этого цикла: swift-adwaita теперь собирается и запускается на macOS, а заодно я наступил на красивые грабли со Swift Concurrency внутри GLib main-loop и аккуратно с них слез.

История одного бага: async, который никогда не выполняется

В 1.2.0 я схлопнул все диалоги (FileDialog, ColorDialog, FontDialog) на async throws и убрал колбэк-варианты — казалось, так чище. Через сутки выяснилось, что внутри запущенного GTK-приложения (g_application_run) код вида Task { @MainActor in await dialog.open(...) } просто никогда не выполняется. Дефолтный исполнитель главного актора в Swift — это DispatchQueue.main, а GLib main-loop его не крутит. Процесс выглядит живым, ошибок нет, кнопка нажимается — но файловый диалог не появляется.

1.2.1 экстренно вернул колбэк-варианты для FileDialog, 1.2.2 закрыл эту дыру окончательно: колбэк-перегрузки добавлены для всех async-API (Clipboard, ColorDialog, FontDialog, UriLauncher, Texture.load). Async-варианты остались — они нужны для тестов и не-GTK контекста, — но из обработчиков сигналов GTK теперь по умолчанию рекомендуется колбэк-форма. Долгосрочное решение (свой SerialExecutor поверх GLib) отложено как отдельная задача.

1.2.0: что появилось в API

• Асинхронная загрузка изображений. Texture.load(from:) декодирует всё, что умеет GdkPixbuf — PNG, JPEG, GIF, WebP, TIFF, BMP — вне главного актора. Это шире, чем умеет нативный gdk_texture_new_from_filename.
• Воспроизведение анимированных изображений. AnimatedImagePlayer крутит кадры из GdkPixbufAnimation в виджете Picture с методами start / stop / advanceFrame.
• Application.onOpen и Application.run(arguments:) — обработка активации по файлам для приложений с флагом G_APPLICATION_HANDLES_OPEN.
• Runtime-проверки типов виджетов. Widget.gtkType, isInstance(of:), и более строгий tryCast, который теперь действительно сужает тип, а не «успешно» приводит любой виджет к чему угодно.
• Изолированные deinit на GObjectRef, GVariant и других обёртках — освобождение GObject теперь всегда происходит на главном акторе явно, а не на случайном потоке, который дропнул последнюю ссылку.
• Минимальный тулчейн поднят до Swift 6.2 — isolated deinit в 6.1 экспериментальный, релизный тулчейн отказывался его включать.

1.2.3–1.2.5: удобства и буфер обмена

Три небольших релиза о том, чтобы реже импортировать CAdwaita ради рутинных вещей:

• RGBA(hex:) — парсинг CSS-цветов: #RGB, #RGBA, #RRGGBB, #RRGGBBAA.
• IconTheme — обёртка над gtk_icon_theme_get_for_display с addSearchPath(_:) для локальных иконок приложения.
• ApplicationFlags как OptionSet: Application(id: "...", flags: [.handlesOpen, .nonUnique]) вместо сырых битовых масок.
• MainContext.drainPending() и pump(for:) — однострочные замены для while g_main_context_pending { g_main_context_iteration }, которые в каждом тестовом наборе писались заново.
• Перехват вставки. Widget.onPasteClipboard, синхронные пробы Clipboard.containsImage / containsFiles, асинхронные readTexture / readFiles, и Texture.encodedPNGData() — теперь можно перехватить вставку картинки в редактор и пропустить её через свой импорт, а не позволять GTK воткнуть её как текст.
• Silencing GTK-CRITICAL спама от GtkScrolledWindow и неверно настроенных GtkDropTarget — опциональный фильтр + правильные сигнатуры сигналов ::enter / ::motion.

1.3.0: macOS как платформа для разработки

Главная новость цикла. swift-adwaita теперь собирается и работает на macOS 13+ на Apple Silicon. Linux остаётся главной целевой платформой, но локально разрабатывать и тестировать можно прямо на маке, не поднимая виртуалку.

• Установка через Homebrew: brew install libadwaita gtksourceview5 pkgconf adwaita-icon-theme. Без adwaita-icon-theme кнопки в HeaderBar и баннеры рендерятся пустыми — Homebrew не подтягивает её транзитивно.
• Обязательная переменная окружения: XDG_DATA_DIRS=/opt/homebrew/share, иначе libadwaita не находит свои GSettings-схемы и падает при старте.
• DemoAppLib — все 78 примеров галереи теперь живут в отдельной библиотеке, которую можно слинковать с внешним приложением. Исполняемый DemoApp стал трёхстрочной обёрткой.
• Xcode-пример в examples/macos/DemoApp/ — минимальный Xcode 16+ проект, который оборачивает галерею в обычный .app-бандл. Cmd+R и работает.
• Параллельный набор тестов на XCTest для macOS. swift-testing на Apple-платформах вставляет autorelease-pool переходы между тестами, которые конфликтуют с Cocoa CFRunLoop источниками от gtk_init — на втором тесте всё падает. XCTest этого не делает, и тот же набор там проходит. Linux продолжает гонять swift-testing. Результат: 1181 тест / 0 падений на macOS.
• Три специфичных для Apple бага, которые Linux/glibc маскировал: Variant.stringValue возвращал nil для валидных строк (висячий указатель на g_variant_type_checked_); хелперы локализации (localized, nlocalized) возвращали мусор без перевода (gettext возвращает входной указатель untouched, а Swift→C bridge уже освободил его); MediaStream.timestamp не компилировался, потому что gint64 — это long на Linux x86_64 и long long на Apple arm64.
• macOS CI job на macos-26 с Xcode 26.4.1 (Swift 6.3). Только сборка, без прогона тестов: GitHub runner-ы headless, GTK4-Quartz падает без WindowServer-сессии.
• REUSE 3.3 метаданные лицензий — SPDX-заголовки в каждом файле, reuse lint зелёный.

1.3.1: уборка

Maintenance-релиз без изменений API. Подтянул документацию по перехвату вставки в README, добавил adwaita-icon-theme во все инструкции по установке для macOS (наступили — записали), поднял в Xcode-примере deployment target до macOS 26, чтобы он совпадал с тем, на чём Homebrew собирает GTK4 — иначе линкер ругается на каждый dylib.

Что дальше

Главная незакрытая проблема — это всё ещё интеграция Swift Concurrency с GLib main-loop. Сейчас в GTK-приложении нельзя писать Task { @MainActor in ... } из обработчика клика, и это огорчает. Долгосрочный план — собственный SerialExecutor, который вместо DispatchQueue.main прокидывает работу через g_idle_add_full. Пока что callback-API закрывают все практические сценарии, но писать настоящий исполнитель когда-то всё-таки придётся.

Проект открытый, под MIT-лицензией. Исходники — на GitHub, документация с гайдами — здесь.

Star Fork

Несколько месяцев назад @belbous рассказывал мне про видеокодек AV1 — какой он классный. Недавно я решил поэкспериментировать с ним. Обнаружил, что у меня на ноутбуке с Ubuntu есть нужное железо — видеокарта NVIDIA с поддержкой аппаратного кодирования AV1 через NVENC. Эта возможность появилась только в RTX 40-й серии: на 30-й и старше NVENC умеет AV1 только декодировать, а для кодирования остаётся софт на процессоре. К счастью, всё это интегрировано в ffmpeg, бери и пользуйся.

С помощью Claude Code я на примере нескольких видеофайлов подобрал подходящие настройки. Цель была — сохранить качество, но уменьшить размер файла. В итоге в настройках даже не фигурирует битрейт. На выходе получился bash-скрипт, который анализирует видеофайл через ffprobe и, в зависимости от разрешения и цветовой схемы, выставляет CQ и прочие настройки.

Claude Code не просто подобрал значения наугад: он сделал несколько прогонов на куске видео, сравнил входной и выходной файл, повырезал кадры и сам оценил качество, даже описывая сцены, которые сравнивал — след на снегу, пейзаж с деревьями, лицо Декстера 😁.

Изначально Claude Code исходил из сравнения трёх кодеков — H.264, H.265 (он же HEVC) и AV1. Базовый расчёт был такой: H.264 → H.265 даёт сжатие около 50%, а H.265 → AV1 — ещё около 30% при том же качестве. Правда, эти 30% относятся к софтовым кодировщикам (libaom, SVT-AV1) — аппаратный AV1 в NVENC работает в разы быстрее, но при том же битрейте проигрывает им в качестве. Я хотел сэкономить место на диске, так что такой компромисс меня устроил.

Звук попутно я пережимал в стерео кодеком Opus, так как смотреть всё равно собираюсь на телевизоре с обычным (и довольно средним) стереозвуком, а запускать планировал с iPad, который почему-то исторически не умеет выводить звук 5.1 через HDMI (вместо звука — шипение).

Результат впечатляющий. Серия «Основания» — 4K, HEVC, HDR — ужалась с 10,2 ГБ до 2 ГБ. В пять раз! При визуально том же качестве картинки. Правда, надо честно оговориться: пятикратное сжатие здесь — это не столько чистая эффективность AV1, сколько следствие очень высокого битрейта у исходника (рипы обычно делают с большим запасом). На файлах, изначально сжатых плотнее, выигрыш будет скромнее.

Одна 45-минутная серия перекодировалась около 15 минут. Для видео в 4K это очень быстро. А одна 50-минутная серия «Декстера» в 1080p в SDR и вовсе перекодируется за пять минут. Красота.

Но есть и минусы — из коробки NVENC не поддерживает HDR10+ и Dolby Vision, так что эти динамические метаданные при перекодировании теряются. Обычный HDR10 со статическими метаданными пробрасывается нормально, то есть базовый HDR на месте — проблемы только с расширенными форматами. Есть какой-то обходной путь: эту часть конвертировать отдельно и потом склеивать, но я решил не заморачиваться — телевизор у меня не такой уж крутой, HDR10+ и Dolby Vision он всё равно бы не показал. Можно ещё использовать другой кодек, который всё сделает на процессоре — там и качество выше, и метаданные сохраняются, — но тогда эта же серия в 4K конвертировалась бы не 15 минут, а много часов. Так что у меня, похоже, получилось идеальное соотношение качество/время.

Сегодня расхваливал товарищу из айти-завтрака Video Player — видеопроигрыватель из GNOME, который раньше назывался Showtime. Насколько я понимаю, в какой-то момент он стал проигрывателем по умолчанию, в том числе и в последней версии Ubuntu.

Мне нравится его минимализм, нужные мне файлы он воспроизводит, и приятно, что при выборе аудиодорожки показывает название перевода (студии озвучки) — почему-то не все проигрыватели это умеют.

Пришёл домой, решил сравнить его с другими проигрывателями, открыл файл с HDR и Dolby Vision — кажется, зря я его так хвалил. На снимке экрана сверху вниз: Video Player (Showtime), Cine и VLC.

Все три отличаются по цветам. Пожалуй, перейду на Cine. Судя по репозиторию, это довольно молодой видеопроигрыватель. Он тоже основан на MPV и тоже написан на Python, как и Showtime. Только развивается активнее, обновления выходят чаще, и, главное, цвета показывает корректно. У Showtime, насколько я помню, почему-то проблемы с HDR уже не первый год, а обновления выходят раз в три-шесть месяцев.

VLC, конечно, легенда, способная проиграть всё, что вообще возможно проиграть, но интерфейс, на мой взгляд, изрядно устарел. Дорогу молодым.

После выпуска swift-adwaita я сосредоточился на создании своего первого приложения с его использованием. Что-то простое, но полезное для меня самого. И вот, первое приложение готово к использованию.

Swifty Notes — это нативное приложение для заметок в формате Markdown под Linux, использующее GTK/libadwaita и написанное на языке Swift.

Основной интерфейс — десктопное приложение: пишите, организуйте и просматривайте Markdown-заметки с помощью нативных виджетов GTK, функции автосохранения, сохранения состояния рабочего пространства и настраиваемых параметров редактора (размер шрифта, перенос строк, отступы и внешний вид).

В комплекте идет CLI (интерфейс командной строки), который работает с теми же файлами, поэтому shell-скрипты, инструменты автоматизации и AI-агенты могут безопасно просматривать или обновлять заметки без необходимости использования отдельной базы данных или фоновых служб.

• Создание, переименование, дублирование, экспорт и удаление Markdown-заметок.
• Автосохранение изменений, сохранение состояния рабочего пространства и хранение локальных изображений прямо вместе с каждой заметкой.
• Настройка размера шрифта и других параметров редактора под разные экраны и рабочие процессы.
• Выбор места хранения заметок, включая папки с облачной синхронизацией, что позволяет поддерживать актуальность одних и тех же файлов на разных устройствах.
• Импорт изображений простым перетаскиванием (drag and drop) и рендеринг Markdown через нативный виджет GTK вместо использования веб-представления (web view).
• Использование CLI для удобной автоматизации заметок в формате JSON с помощью скриптов, конвейеров оболочки (shell pipelines) и AI-агентов.

Swifty Notes для Linux — это проект с открытым исходным кодом, исходный код доступен на GitHub.

Star Fork

Вышел релиз Swift Adwaita 1.1.0. Поскольку я работаю над первым приложением, созданным с использованием этой библиотеки, я расширил её возможности и исправил некоторые баги.

Основные изменения

• Добавлена интеграция с GtkSourceView с использованием типизированных оберток на Swift для редактирования кода, подсветки синтаксиса, поддержки языков и схем стилей.
• Расширен API виджетов в части работы с поповерами (popovers), окнами, совместимостью с календарем и обработкой жизненного цикла во время выполнения (runtime lifecycle).
• Повышена стабильность релиза благодаря улучшенной интеграции с основным циклом GLib (main-loop), расширению покрытия CI и добавлению новых регрессионных тестов.

Добавлено

• SourceView, SourceBuffer, SourceLanguage, SourceLanguageManager, SourceStyleScheme и SourceStyleSchemeManager.
• Типизированные идентификаторы для языков и схем стилей GtkSource.
• Новый демонстрационный пример редактора кода.
• MainContext.task { ... }, task(after:) и task(every:) как отменяемые дескрипторы (handles) задач в основном цикле GLib.
• Асинхронные помощники Async MainContext.run, yield и sleep(for:) для безопасного соединения конкурентности Swift (Swift concurrency) с циклом GLib.
• Widget.unparent() и PopoverMenu.unparent().
• Удобные помощники для работы с Popover и PopoverMenu.
• Дополнительные регрессионные тесты для поиска родителя в цепочке виджетов/окон, а также расширенное покрытие для функций редактирования кода и поведения медиафайлов.

Изменено

• GtkWindow.present() теперь удерживает окна открытыми до их закрытия, что делает использование временных или локально ограниченных окон более безопасным.
• Widget.window теперь находит содержащее окно через цепочку родителей виджета, вместо того чтобы предполагать, что GTK root всегда является окном.
• Обработка дат в календаре теперь использует прослойку (shim) для совместимости с GTK, что позволяет чисто собирать пакет как на старых, так и на новых версиях GTK.
• Обновлены конфигурация генерации документации и хостинга документации.
• В CI теперь выполняется установка и тестирование с системными зависимостями GtkSourceView 5.

Исправлено

• Исправлена отложенная очистка сигналов/пользовательских данных (user-data): теперь она освобождает захваченные замыкания через основной цикл GLib, а не через задачи Swift main-queue, что позволяет избежать проблем с жизненным циклом в GTK-приложениях.
• Исправлена распространенная ошибка планирования (scheduling pitfall) в GTK путем предложения API в стиле Task, который работает в основном цикле GLib вместо DispatchQueue.main.
• Исправлены проблемы с видимостью сериализованного набора функций в Swift 6.1 в тестовом наборе.
• Исправлены регрессионные тесты для popover/window, чтобы избежать путей падения (crash paths) GTK в CI при сохранении проверки ожидаемого поведения.
• Обновлена документация по релизу и инструкции по установке: теперь они включают пакеты разработки GtkSourceView 5.

Документация и CI

• В README добавлена ссылка на API-документацию.
• Обновлены инструкции по установке для Ubuntu/Debian и Fedora.
• Улучшена согласованность встроенной документации во всем API обертки.
• Расширено покрытие CI для документации, форматирования и тестовых прогонов на Swift 6.1 / 6.2 / 6.3.

Это проект с открытым исходным кодом под лицензией MIT. Исходный код доступен на GitHub. Документация с руководствами доступна здесь.

Star Fork