На 410чанѣ съ начала апрѣля 2021 года и по вторую половину января 2022 года совершалося цѣнное обсужденіе многихъ вопросовъ о томъ, какъ умѣстно сохранять изображенія въ графическихъ файлахъ. Его архивъ https://410chan.org/b/arch/res/158687.html донынѣ хранитъ и наглядные примѣры сильнаго сжатія изображеній, и подробные списки достоинствъ нѣкоторыхъ форматовъ графическихъ файловъ, и образцы иллюстрацій, способныхъ помѣщаться на 410чанъ только послѣ переужатія, а не механическаго копированія ихъ изъ первоисточника. Не мало тамъ было сказано и словъ о томъ, слѣдуетъ ли для сохраненія кадровъ видео прибѣгнуть къ формату, предусматривающему сжатіе съ потерями (какъ JPEG или lossy WebP), или же умѣстно потратить большій объёмъ файла (въ форматѣ PNG или въ lossless WebP), но той цѣною достигнуть неизмѣнности пикселовъ. Желая возобновить тутъ обсужденіе графическихъ файловъ, я радъ видѣть для того вѣскій поводъ: въ FFmpeg въ нынѣшнемъ мѣсяцѣ появилась возможность сохранять какой угодно ключевой кадръ из видео AV1 въ файлѣ AVIF, но при этомъ зря не тратится объёмъ файла (какъ было бы при перекодированіи въ форматъ безъ потерь), зря не тратится качество кадровъ (какъ было бы при перекодированіи съ потерями), зря не тратится и то время, которое уходило бы на перекодированіе, а вмѣсто того всѣ свѣдѣнія о пикселахъ ключевого кадра сохраняются «какъ есть» безъ перекодированія, то есть точно въ томъ же прежде сжатомъ видѣ, какой онѣ ужé имѣли въ видеопотокѣ AV1, и снабжаются только новымъ заголовкомъ, приличествующимъ файлу AVIF. Сохранить ключевой кадръ этимъ способомъ можно одною командою: ffmpeg -hide_banner -i имяФайлаAV1 -ss времяКадра -frames:v 1 -c:v copy кадръ.avif Въ сообщеніи по адресу https://t.me/ReadMithgol/491 (растровую копію котораго я прилагаю и тутъ для наглядности) и затѣмъ ещё по адресу https://t.me/ReadMithgol/492 я поподробнѣе разсмотрѣлъ то мѣсто и значеніе, которое эта новинка FFmpeg получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
Ещё одна новость хранения файлов состоит в том, что теперь libavif поддерживает цвѣтовое пространство YCgCo-Re, которое обеспечивает рост экономии при сжатии файлов, совершаемом без внесения потерь в изображение, так что в командную строку «avifenc --jobs 8 --ignore-exif --ignore-xmp --codec aom --speed 0 --lossless исходный.png безПотерь.avif» теперь можно добавить параметр «--cicp 1/13/16» (или какой-нибудь другой, но также с шестнадцатыми матричными коэффициентами) и немедленно получить около 12% экономии объёма файла (больше или меньше в зависимости от содержимого — экономию 12,12% я получил на контурной карте, которую прилагаю). Неприятная изнанка этой новости состоит в том, что к кодировщику нужен и декодировщик, а без него всѣ просмотрщики и всѣ браузеры прежних версий (а Файерфокс под Windows 7 скоро перестанут обновлять, напримѣръ) будут показывать такие AVIF с некорректною цвѣтностью. Значение же этой новости умаляется тѣмъ, что файл AVIF был больше файла PNG в случае прилагаемой карты на 72,17%, так что даже экономия 12,12% ещё не способна одолѣть собою чудовищную неэффективность того варианта сжатия AVIF, который без внесения потерь в изображения.
>>210240 Я где-то читал, что AVIF таки способен превзойти и превосходит PNG по сжатию, но только при большей цветовой глубине. Если так, интересно, в связи с чем они не стали делать оптимизацию lossless для 8bpc. Самая распространённая цветоглубина же. Сделали бы, можно было бы WebP записать в obsolete. Или не совсем. С lossless WebP жмётся в редких случаях даже чуть-чуть лучше, чем JPEG XL-ем. Досадно, что обнаруженное в прошлом году RCE оказалось именно в lossless части кодировщика.
Мелкософт запилил JPEG XL дополнение для Винды 10/11. Может, прогнут Гугл всё-таки.
Возможно ли, что >>210338 изрядно давно не новость? — спрашиваю оттого, что по адресу https://apps.microsoft.com/detail/9mzprth5c0tb годом релиза назван позапрошлый (2023) год. (Скриншот прилагаю.)
Мысли сообщений >>210190 〜 >>210240 я развил по адресу https://t.me/readMithgol/1131 в Телеграме. Скриншот прилагаю.
А можно сжать щёчки Мицу-гяру в графическом файле, и показать нам? Чтоб мы, так сказать, проверили уровень и качество сжатия. Всё в порядке, мы же тут все девочки! Мицу-тян, не стесняйся!!
https://bulochka.org/b/ там →
Чтиво интересное, но почему ж в телеграмме-то? Хоть бы сайт девочковый с RSS поднял...
>>210895 С каких это пор Мицгола интересует анонимность? На "девочковом" сайте рекорды собирать не интересно.
>>210896 > славчпок Прочитал как slavпок.
>https://t.me/s/ReadMithgol >Нынешние отаку забывают о своём долге посвятить жизнь идеалам и поклонению совершенной недостижимой красоте. Они влюбляются в живых людей, создают семьи и даже заводят детей, забывая, что половой инстинкт был дан им лишь для того, чтобы повышать доходы японских корпораций.
>>210898 Могёт, чё.
>>210898 За это мы его и любим! Даёшь Мицу-тян на свободной платформе!
>... события в так называемом реальномъ мірѣ отвращают меня от просмотра не одних только произведений о вымышленных боевых дѣйствіяхъ (как я о том сообщал 20 апрѣля 2023 г.), но и, напротив того, о жизни чрезмѣрно мирной и милой. ... Пришлите к нему участкового уже, а то глупостей ещё наделает.
> Пришлите к нему участкового Участковую суккубу.
Автор сообщения >>210898 цитирует репост.
>>210902 Так как это тред Мицу-тян, то правильнее будет написать не "суккубу", а "семенную демонетку"!
>>210907 Демонетка-то тоже слово не совсем русское. Может, Соус знает, как правильно по-старославянски будет.
Что произойдёт с форматом AVIF опосля появления видео AV2 (>>211793)? — доподлинно это не извѣстно, но по адресу https://t.me/ReadMithgol/1236 я изложил нѣкоторыя гадательныя разсужденія, а здѣсь прилагаю скриншот их.
Если в непримечательном на вид буквосочетании WebP, как мы помним, зашифровано словосочетание «оргазм кончающего веба», то AVIF — это очевидным образом Adult Video Intercourse Frame. Что же будет с AVIF после выхода Adult Video 2? Чтобы сиквел оказался на уровне соответствия ожиданиям, скорее всего, потребуется усложнение структуры процесса и добавление новых, неожиданных поворотов сюжета. Отчего явною становится мысль, что AVIF по выходу AV2 будет расшифровываться не иначе как Anal-Vaginal Intracranial Fisting!
Когда я обновил систему Windows до десятой версіи ея (>>212201), тогда появилась возможность использовать новыя версіи средств работы с графическими файлами, ужé не способныя дѣйствовать в Windows 7. По адресу https://t.me/ReadMithgol/1285 (скриншот сообщения прилагаю) я сообщил об улучшениях результата, достигаемого одним из таких средств, а именно oxipng.
По адресу https://t.me/ReadMithgol/1330 я сообщил, что думаю о том, что во Chromium вдругорядь добавили поддержку формата JPEG XL. Скриншот прилагаю.
(Видеоцитату, к сообщению >>212713 прилагавшуюся в Телеграме, я также прилагаю и здѣсь.)
>>212714 Поспрашивал Google про AV2. Говорит, что AV2 будет поддерживать прозрачность! VP9 поддерживает, AV1 нет. В AVIF сейчас прозрачность grayscale кадром кодируют. Говорит, что время кодирования старались сделать не хуже, чем в 2 раза. Будем надеяться. Интересена размерность tile'а, как спатиально-независимо кодируемой единицы. Насколько я понимаю, у JPEG'а это блок 8x8, у PNG текущая линия зависит только от предыдущей, у AVIF максимальный размер тайла по ширине 4096 пикселей. Интересно в контексте оптимизации по памяти создания уменьшенных копий: если попробовать запостить 24000x24000 картинку, VPSочка может надорваться. Увы, в imagemagic для AVIF такой оптимизации нет, хотя вроде есть возмость вызвать libheiff/libavif с shrink-on-load (которое не декодирует всю оригинальную картинку в память?). Но это AVIF. А что насчёт JPEG XL? Чем делать уменьшенные копии, чтобы поддерживало современные форматы и memory usage не улетало в космос?
>>212716 Я так скажу: пусть об этом думают создатели декодировщиков, а не мы. И даже создатели декодировщиков могут об этом не сильно думать, а полагаться на способность операционной системы среагировать на нехватку оперативной памяти и использовать виртуальную память (что на нынѣшнихъ дисках NVMe бывает не так медленно, как до их появления; напримѣръ, устройство https://www.dns-shop.ru/product/1809fac309e1d582 обѣщаетъ возможность записи тринадцати тыщщ мегабайтов в секунду при работе через интерфейс PCIe 5.0 ×4). Напоминаю два обстоятельства: ① При кодировании файла AVIF можно дѣлить картинку на независимо декодируемыя части двумя способами: тайлами и гридами. (Здѣсь слово tile означает, что видеокадр AV1 состоит из независимо декодируемых прямоугольных кусков; слово grid означает, что файл AVIF содержит нѣсколько независимо декодируемых видеокадров AV1, результаты декодирования которых затѣмъ формируют прямоугольную сѣтку.) Но второй из этих двух способов до сих пор не поддерживается (и оттого предотвращает декодирование AVIF) во браузере Mozilla Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1696090 ② При кодировании файла AVIF можно не только воздержаться от создания тайлов, но и подзабить на ограничения по размѣрамъ, свойственныя даже сáмому снисходительному из профилей («Professional»). Напримѣръ, файл https://pomf2.lain.la/f/3anes1z.avif содержит 5000×8000 пикселов (сóрок мегапикселов, из изображения https://danbooru.donmai.us/posts/5560557 взятых) без тайлов и без гридов, однако невозбранно декодируется (однако, может быть, декодируется непремѣнно софтовым декодировщиком и в обход аппаратного, если тот ограничен требованиями профилей). Скриншот прилагаю.
>>212722 Спасибо за разъяснения по AVIF. Подумываю о реализации поддержки AVIF/JXL, тут или на форке, да и в целом про реформу системы приложения файлов. Один из вопросов, кого убьёт OoM killer, если картинка не влезет в память, и корректно ли код движка обработает такую ситуацию. Сейчас проверок на максимальное width×height или setrlimit нет, но вроде есть свои лимиты и у FFmpeg, и, помнится, у gd. Впрочем, не у картинкомагии. И желающий вызвать DoS может спамить PNG-бомбы. Или AVIF-бомбы. Насколько страшно? Dunno. Но есть желание максимизировать допустимую размерность картинки, минимизировав количество ресурсов и проблем. > полагаться на способность операционной системы среагировать на нехватку оперативной памяти и использовать виртуальную память Под это понадобится держать swap-файл или раздел. Место на диске! У imagemagic'а вроде есть некая опция, позволяющая держать pixel cache в файле, но, думаю, это не то. Например, libwebp, помнится, не позволяет передать custom allocator. И если так, разве можно ему скормить mmap'ленный файл в качестве места под пиксели и их обработку? > обѣщаетъ возможность записи тринадцати тыщщ мегабайтов Шустро. Но это sequential write. Насколько локализованы у декодировщика запросы к памяти при обработке? I wonder. Надо протестировать. > Запись случайных блоков 4 Кбайт > 1650000 IOPS Больше, чем при чтении? Но sequential read быстрее sequential write? Wut.
> И если так, разве можно ему скормить mmap'ленный файл в качестве места под пиксели и их обработку? Можно попробовать подменить libc'шные функции, конечно, но я сомневаюсь, что оно работает так.
>>212724 Давно и не мною было замѣчено (>>/d/2649), что изображение 16K×16K пикселов не пролезет на 410чан. Если хочется провѣрить это утверждение ещё и в формате «бомбы» (то есть графического файла не только большого размѣра, но и мáлого объёма), то тогда сгодится файл https://www.bamsoftware.com/hacks/16384.webp (28 байтов).
>>212724 > Подумываю о реализации поддержки AVIF Да чё там подумывать, достаточно https://codeberg.org/FBE410/fbe-410/pulls/38 мёрджить, как в сообщении >>/dev/28037 предложено.
Во браузерах начинает вдругорядь появляться поддержка формата JPEG XL, на сей раз сочинённая на языке Rust: ① о появлении поддержки JPEG XL во Хроме можно прочесть по адресу https://www.opennet.ru/opennews/art.shtml?num=64639#:~:text=В%20Chrome%20Canary,Rust%2E ② ≈одиннадцать часов назад произошло и появление поддержки JPEG XL во браузере Mozilla Firefox, причём по комментарию https://bugzilla.mozilla.org/show_bug.cgi?id=1986393#c47 можно увидать, что рѣчь идёт о будущем Firefox 149. Та и другая поддержка формата JPEG XL пока ещё не включена по умолчанию, однако может быть включена вручную в настройках браузера.
Пользуясь >>212757 в качестве повода, я разсказалъ по адресу https://t.me/ReadMithgol/1373 о том, что думаю про дальнѣйшія перспективы формата JPEG XL. Скриншот прилагаю.
Так как окончательный выпуск браузера Firefox 149, упомянутого в сообщении >>212757, должен состояться сегодня, то я дополняю его упоминание сообщением о том, что радоваться рано: поддержка формата JPEG XL в этой версии ограничивается тестовыми сборками, не достигая ни окончательной (релизной) версии браузера, ни даже бета-версии. В комментариях на странице https://bugzilla.mozilla.org/show_bug.cgi?id=2016688 сказано (≈7 часов назад), что так всё это и будет продолжаться до тѣхъ поръ, пока не окажется сочинённою новая обёртка декодировщика исходным кодом, служащим для постепенного отображения иллюстраций, и затѣмъ ещё не пройдёт автоматическое тестирование (fuzzing). В то же время браузер Google Chrome 145 ужé содержит и в релизах своих поддержку формата JPEG XL, однако не по умолчанию, а за флагом в настройках. Если этот флаг включить, то тогда иллюстрации в формате JPEG XL начинают в WWW отображаться (скриншот Хрома прилагаю).
Где взять свежую сборку овермикса? На линуксе я уже давно потерял надежду его собрать, но хотя бы чтоб через wine можно было запустить...
>>212990 Ей неоткуда взяться свѣжею: на Гитхабе послѣдній коммитъ былъ въ маѣ 2024 года. Притом мнѣ не нравится поведение версии v0.4.0-alpha3, так что рекомендую v0.4.0-alpha2: https://github.com/spillerrec/Overmix/releases/tag/v0.4.0-alpha2
>>212991 Я психонувши смиксил только что через фотошлёп. Поскольку он очень хорошо поддерживается программным обеспечением «wine», чтобы экспортировать картинку, мне пришлось копировать её в буфер обмена, иначе эта программа просто крашилась при какой бы то ни было попытке собственно экспорта. Ну результат вроде ничё, показывать не буду! За ссылку благодарю.
Около половины суток назад по адресу https://github.com/AOMediaCodec/libavif/releases/tag/v1.4.2 выложили новую версию (v1.4.2) кодировщика libavif, основанную на сáмой новой версии (v3.14.1) кодировщика libaom-av1. Прежний челлендж по сжатию картинки «NICE BOAT» для достижения объёма не болѣе 20 260 байтов новая версия проходит при значениях cq-level на единицу больше, чѣмъ необходимыя в сообщении >>210190 в прошлом году для libavif v1.2.0: • с параметрами «--advanced color:qm-min=0 --advanced color:qm-max=6 --advanced cq-level=43» получается файл https://uploadbay.net/uploads/EhaEoyhWm.avif объёмом 20 210 байтов; • с параметрами «--advanced deltaq-mode=6 --advanced color:qm-min=0 --advanced color:qm-max=5 --advanced cq-level=48» получается файл https://uploadbay.net/uploads/J7IjRtCmg.avif объёмом 20 222 байтов. Основные выводы: ① Как и прежде, при настолько сильном сжатии параметр «--advanced deltaq-mode=6» перестаёт оправдывать себя (наращивает качество изображения въ глубокихъ тѣняхъ за счёт принуждения к наращиванию cq-level и оттого к ухудшению качества во всём остальном изображении при равномъ объёмѣ). ② Продолжается тренд на рост объёма файла, выдаваемого кодировщиком при сохранении прежних значениях квантизатора. В результате для сохранения объёма файла пришлось нарастить cq-level на единицу, что не могло не привести к росту потерь квантования, однако общее качество изображения всё же выглядит подросшим, то есть эти потери компенсируются дополнительным объёмом данных, сберегаемых кодировщиком. ③ Новая версия кодировщика ещё менѣе склонна размазывать артефакты, остающиеся от сжатия изображения, и это идёт изображению на пользу («хѣрня > размазня») пока что, потому что это пока ещё не доходит до такого раздражающего изобилия мусора на ровномъ мѣстѣ, которое было у JPEG, напримѣръ.
>>213186 Мне будет интреснее читать про твои тесты, если ты будешь приводить не только значения CQ и результаты сравнения на глаз, но и результаты SSIM/PSNR/Butteraugli метрик.
В связи с появлением видеоформата AV2 я разсуждалъ по адресу https://t.me/ReadMithgol/1500 о том, чтó ещё не ясно насчёт будущности AV2-в-AVIF. Скриншот сообщения прилагаю.
На скриншоте в сообщении >>213191 видна опечатка: написано «стенографически», а слѣдуетъ читать «стеганографически». (Разница между этими понятиями мнѣ извѣстна, но я машинально пропустил слог второпях.)
Сегодня (16 іюня) вышла новая версия (152) браузера Mozilla Firefox. Эта первая такая (именно релизная) версия, в которой можно пойти в настройки (въ подраздѣлъ Firefox Labs) и включить там поддержку графическаго формата файлов JPEG XL. Официальный скриншот настроек прилагаю. Ажиотаж по этому поводу достиг такой силы, что на сайте Phoronix днём ранѣе по адресу https://www.phoronix.com/news/Firefox-152-Download ужé предлагали заходить на FTP Фонда Мозиллы и забирать оттудова установочные файлы браузера, полагаясь на их ≈окончательность перед выпуском. Вы можете провѣрить работоспособность просмотра файлов JPEG XL на примѣрѣ, приведённом в сообщении >>199642, однако запаситеся терпением: так как там 35 мегапикселов в 16⅔-мегабайтовом файле, то отображение его (и даже простое скачивание с сайта Catbox) занимает не одну секунду и не двѣ (и не три).
Переводя разсужденія о будущности гипотетическаго формата AV2-в-AVIF (>>213191) в практическую плоскость, давайте посмотрим на то, как видеокадр AV2 справляется со сжатием информации из того PNG «NICE BOAT» на ровномъ бѣломъ фонѣ, который здѣсь прилагаю.
Результат провѣрки >>213339 оказывается вот каким: не превосходя 20 260 байтов (то есть не превосходя объёма шакальнаго JPEG, в сообщении https://410chan.org/b/arch/res/158687.html#158719 обнаруживаемаго), видеокадр AV2 по адресу https://uploadbay.net/uploads/mU8kxWWuN.ivf занимает всего лишь 20 165 байтов. Этот итог достигнут кодированием с параметрами «--bit-depth=8 --lag-in-frames=35 --enable-keyframe-filtering=0 --enable-tpl-model=1 --kf-min-dist=240 --kf-max-dist=480 --end-usage=q --qp=139 --enable-qm=1 --qm-min=0 --qm-max=11 --cpu-used=0 --tile-rows=0 --tile-columns=0 --threads=4 --ivf», нѣкоторыя изъ которыхъ, впрочем, никак не способны дѣйствовать на единственный видеокадр. Обратите поэтому внимание только на восьмибитную глубину цвѣта (то есть двадцатичетырёхбитные пикселы), на величину квантизатора (139) и на диапазон матриц квантизации (от 0 до 11). Результат обратнаго декодирования прилагаю. Пикселы не тридцатибитны оттого, что я не разобрался, как заставить FFmpeg родить такой видеокадр с десятибитною глубиною цвѣта, который принял бы кодировщик. (Спросил совѣта у нейросѣтевыхъ совѣтчиковъ, но они совѣтъ нагаллюцинировали, подлецы.) Сравнение с результатами >>213186 показывает явный рост качества AV2 по сравнению с AV1-в-AVIF. Оговорюсь, что сравнение слегка искажено не одной только разницею глубин цвѣта: внедрение в AVIF поддержки AV2 потребовало бы поставить перед видеокадром и заголовок той длины, которая в AVIF (а не той, которая в IVF).
Но какое значение эксперимент >>213339 + >>213340 может имѣть для понимания будущаго? — будет ли вообще в будущем такой формат, который был бы аналогом AVIF, основанным на AV2 вмѣсто AV1? Да: по адресу https://github.com/AOMediaCodec/av1-avif/issues/332 наконец объявлено, что он будет.
Не слишком замѣченнымъ осталось то обстоятельство, что компания Apple в начале мая объявила о создании собственнаго нейрокодека для сжатия изображений, причём для сжатия весьма сильнаго (с приведением примѣровъ изображеній, сжатых до удѣльнаго объёма от 0,095 до 0,507 бита на пиксел в среднем). Назвали его PICO, что происходит от сокращения слов «Perceptual Image Codec». Статья о PICO выложена на сайте arXiv по адресу https://arxiv.org/pdf/2605.05148 Исходный код выложен на сайте GitHub по адресу https://github.com/apple/ml-pico Примѣры работы выложены на Гитхабе же — по адресу https://apple.github.io/ml-pico/ Обращает на себя внимание утверждение о небольшой величине кодировщика и декодировщика (30,4 и 19,4 мегабайта), и неясность перспектив внѣэппловскаго употребленія (в частности, лицензия исходнаго кода не содержит отказа от патентных отчислений), и не слишком аккуратное сравнение с возможностями других кодировщиков — напримѣръ, для AV1 вызов кодировщика совершался без попытки придать параметру «tune» значение «butteraugli» или «iq» (каждое из которых при не слишком сильном сжатии, в районе полубита на пиксел уж точно, способно повысить качество изображения-результата по сравнению с настройками по умолчанию, рассчитанными скорѣе на сжатие видеозаписей, а не статических изображений), да и для AV2 значение этого параметра тоже не перемѣняли. Сильно раздражает, что при придумывании имени вообще никто не думал о поисковой находимости, так что по слову «pico» можно найти что угодно, кромѣ самогó эппловского формата и его кодека — и плату Raspberry Pi Pico, и гомосексуальное аниме «Boku no Pico», и гарнитуры виртуальной реальности Pico (от компании, дочерней по отношению к ByteDance), и португальское слово с основным значением «пик» («вершина горы»), и проч. (Викисловарь про это португальское слово содержит по адресу https://en.wiktionary.org/wiki/pico#Portuguese упоминание о неосновном значении его «гомосек», понимаемом как краткий синоним к слову «picolho». Возможно, как раз это и было источником вдохновения и для авторов названия гомосексуальнаго аниме «Boku no Pico», и для авторов названия кодека PICO компании Apple, управляемой открытым гомосеком Тимом Куком.)
>>213449 >Тим Кук >deep learning codec
>>213449 Премного извиняюсь, но позвольте мне встрять всего на один момент. Мне хотелось бы внести одно крайне важное уточнение: на самом деле аниме сие не только гомосексуальное, но также специфически педерастическое. Знание этой разницы может когда-нибудь в будущем спасти вам жизнь!
Боку но Пико аниме отоконокошное. Когда надо, чтобы мальчики были похожи на девочек, это очень лайтовый гомосексуализм.
>>213455 Справедливо. Но стоит вспомнить, что всякие заигрывания с элементами "того" пола: макияж, ногти, голос и манеризмы - дело обычное. Впрочем это устаревшие сведения.
>>213455 Как я представляю образ типичного субъекта с гордо несимыми проблемами с культуркой, он скорее назвал бы >>213455 и всякое моэ вроде кирары №;%ским. А "образ мужика" >>213454 ему бы мог понравиться, до пересечения некоторой грани, когда станет понятно, что это. Наверно ироничность этого и выражена в классической обзывалке про латентность.
>>213457 Кстати, о моэ. MoE-модельки иногда неплохо себя проявляют. Компромисный интеллект Gemma-4-26B-A4B-it сопровождается троекратным ускорением, относительно 31B. Вынужден лелеять надежды на выгодное применение на длинной дистанции для анализа текстов.
