рано или поздно всё заканчивается, и им придётся снова завоёвывать расположение аудитории
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.
Внимание к деталям плавно ушло вместе со Стивом Джобсом. Тим Кук — он, в первую очередь, про зарабатывание здесь и сейчас, а не про инновации и сверхдолгосрочные вложения (например, когда внимание к деталям создаёт имидж и окупается десятилетия). 20% усилий даёт 80% прибыли и вот это всё.
Даже анимация поворота экрана у современной техники Apple значительно упростилась. Меньше фишек с разной массой у разных элементов экрана, с размытием движения, с тем, что частота опроса сенсора выше частоты экрана в N раз, с тем, что анимации считаются почти в реальном времени. Пропорции не соблюдаются, GUI всё реже продумывают как целостную композицию, а не просто утилитарную картинку.
Одновременно с этим подтянулось качество конкурирующих продуктов — Android и Windows. Речь и о технических аспектах, и внимании к деталям, и внимании к дизайну и удобству. В начале 2010 годов даже топовый андройд по сравнению с айфоном был тормозным лагающим недоразумением. Сейчас «андройд» почти уже не лагает, а «айфон» начал всё больше лагать. Эстетика наконец‑то проросла в Android, Windows, Linux. А с айфоноайпадов постепенно слезает лоск. Оно просто сделано добротно, но не больше.
Есть и другой аспект: все эти электронные побрекушки из чего‑то вау стали не то чтобы обыденностью, они стали инфраструктурой. Типа батарей отопления, электрических розеток и унитазов. В начале жизненного цикла батареи и унитазы тоже были с вниманием к деталям, и тоже были круто‑дорого. Сейчас унитазы и розетки это само собой разумеющееся. Так и тут. Ноут толщиной 9 мм и смартфон сейчас это как электрическая лампочка, а не «ого у тебя целый комп в кармане, да еще и с 320 ядерным процессором 100 ГГц, как же это круто, а через год будет 101 ГГц это вообще мир перевернёт, инфа 100»
Более того, я подозреваю, что сейчас внимание к деталям постепенно будет уходить из многих сфер, в том числе, оно будет теряться у предметов премиального класса. Вместо этого будет имитация внимания к деталям. AI‑дженирейтед слоп воплощённый в 3D/4D печати и всё такое. И в софте, разумеется, в софте.
Мир меняется, становится нестабильным, обрастает войнами и кризисами (не только финансовыми), связи рвутся. Система ценностей, заточенная под спокойную размеренную жизнь, уходит, вместе с ней уходят мечты, цели и подходы, заточенные под неё. А новые пока ещё не родились. Но, мне кажется, так или иначе, в новом мире правило 80/20 будет применяться гораздо шире и мощнее. Военная утилитарность будет плавно проникать в быт и моду.
То, что происходит с Apple — это плавная адаптация ко всем этим фундаментальным изменениям. Им как раз сейчас нужен именно кто‑то вроде Тима Кука, а не Стива Джобса, просто потому что сейчас не 2010е.
Помимо полной поддержки AVX512 есть ещё поддержка на логическом уровне — формально инструкция поддерживается, но реально процессор выполняет её как две 256-битных. Я столкнулся с этим на своём CPU пока писал управление светодиодными лентами. CPU по документации вроде AVX512 поддерживает, но скорость от AVX2 по факту не отличается. Сначала я думал, что виноват C#, и по‑нормальному надо для таких задач использовать C++. Однако, раскопав документацию процессора поглубже, я понял, что регистры AVX512 вроде как есть, а вот обработчиков нет — вместо этого срабатывают AVX2 в два этапа. Полноценный AVX512 — это к ксеонам/тредрипперам/эпикам.
А ещё у AVX512 гораздо более удобный shuffle, который может переносить любые байты в любое место. У AVX256 насколько мне известно две половинки по 128 бит, которые между собой перемешивать не получится. Но могу ошибаться.
Приходилось писать реалтаймовое автоматическое выравнивание камер глубины между собой (RealSense D415), то есть вычислять относительно одной камеры положение всех остальных. Нужно это было для реалтаймового 3D сканирования с текстурой — строим несколько поверхностей и сшиваем.
Выравнивание сделал так: ищем общие точки на цветных 2D картинках, через канал глубины вытаскиваем расстояние до них и рассчитываем их 3D координаты в локальной системе отсчёта конкретной камеры, дальше уже простая триангуляция. Ну то есть вот треугольник видит одна камера, вот другой треугольник видит другая камера. Мы знаем, что это в реале эти два треугольника на самом деле один и тот же треугольник, поэтому можем посчитать матрицу трансформации.
D415 шумит конечно, но точек много, комбинаций по 3 точки ещё больше, поэтому немного медианной фильтрации, усреднения и кое‑какой магии — и вот уже точность +‑ приемлемая. Камеры, в основном, стояли на месте, их иногда могли перенести куда‑нибудь или просто случайно сместить. Поэтому я мог позволить себе оооочень долгое интегрирование по времени :)
Так вот, есть мысли что подобный подход применим и тут, и высоковероятно, что ресурсов жрать оно будет меньше, чем нейросетка, даже в случае с монокулярной камерой. Фактически при движении дрона мы получаем новые ракурсы, и нам нужно просто узнать координаты нового местоположения в системе координат предыдущего (или нескольких), и просто интегрировать путь.
А ещё это довольно несложно (относительно) впихнуть в ASIC и производить по 50 000 штук в месяц.
Смотря сколько лент надо контролировать, сколько диодов на них и с какой частотой их переключать. Если их несколько тысяч, простые контроллеры могут не переварить.
максимальной задержкой около 6 мкс, а реализовать это - нетривиальная задача, и такой подход даёт большую загрузку микроконтроллера обработкой этих прерываний
Более чем. Делал протокол WS2812b руками на nopах, забил всю память STM32 Discovery. На таймерах/SPI получилось бы сильно проще и меньше.
Системный промпт «Отвечай на русском» без кавычек, Flash Attenuation вкл, пул потоков 16 (было 12, но вряд ли это влияет на результат), остальное по дефолту.
Эти промпты лишены человеческого смысла, но они внутренне когерентны, и их форма резонирует с паттернами модели. И LLM будет на них отвечать.
Вполне себе оно засекает, что тут что-то не то.
Остальные
Но в целом рекомендации довольно интересные, неплохо протестировать на разных моделях. В частности, есть ли разница в применении этих методологий при работе с обычными и рассуждающими LLM, и что будет, если миксовать их с другими подходами, например, игрой с температурой.
А ещё интересно, есть ли аналогичные трюки для VLM. Например, подгружать дополнительно картинку с какой‑нибудь бессмыслицей, которая по факту улучшит выдачу.
Потому что поддержка у этого свойства в css только с 25 года только в новейших браузерах.
А что мешает сделать микросервис, который на вход жрёт шрифт, а на выходе дает всю нужную инфу о его размерах и прочих ТТХ? В конце концов это можно сделать на бекенде с кешированием. В общем, может я опять перегибаю оверинжиниринг, но для меня подобные проблемы выглядят как‑то диковато.
В WPF для десктопа 2008 года всё это было из коробки. Там только рендеринг шрифтов в самом начале был размытый из‑за игонра хинтинга, но это быстро починили. Почему эти сверхтехнологии инопланетных цивилизаций дошли до веба в 2025 году, большая загадка. И это при том, что сейчас на WebKit делают буквально почти всё.
Это я чего так: приходится бывает на другом проекте что-то делать, а там бардак - дизайнер ни тему не сделал, так ещё и сам по себе решил это обрезание подрубить. Ему говорим исправь - ему пофиг. В итоге все паддинги и тд приходилось вручную подбирать.
Ну имхо это уже организационная проблема, а не техническая. Работали бы нормально паддинги, что‑нибудь другое бы дизайнер забыл бы сделать.
Странно что Фигма по умолчанию не включает эту штуку.
Приходилось писать быстрый рендеринг многострочного текста вдоль кривой Безье, поседел от количества нюансов и того, насколько на самом деле у шрифтов много заморочек и нюансов. У них туча разных вспомогательных линий и размеров.
И выравнивание текста в простейшем случае должно опираться на размер строчной латинской буквы «x», а не на фактический размер букв. В крайнем случае — на размер кегля.
Даже без VR на больших разрешениях типа 11520×2160 или 23040×4320 нужно много VRAM, иначе в играх будет 1 fps. А ещё можно рендерить в 3D пакетах всякое 16K на GPU и тут тоже будет нужно много VRAM.
Но тут речь про LLM, а не графику. У меня OSS 120b выдает 11–16 токенов в секунду в зависимости от настроек, при этом карта забита под 0 и ничего другого в неё уже не влезет.
А описанный в статье способ, фактически, позволяет если не ускорить, то хотя бы одновременно загрузить дополнительно несколько моделей и переключаться между ними, не делая полной выгрузки и повторной загрузки. Например, комбинировать OSS120b с каким‑нибудь VLLM и SDXL.
И, если это делается по слоям, то наверно можно делать какие‑нибудь довольно хитрые конструкции из очень большого числа соединений, типа «одеяла» из десятков тысяч маленьких плат соединенных между собой десятками тысяч микрошлейфов. Вручную/роботами такое сделать почти нереально.
Но это мои фантазии, тут интересно было бы получить информацию о производстве «из первых рук» :)
Вы правы, я взял как пример пароль только из латинских букв одного регистра. Поправил текст. Однако год — это вполне ещё осязаемое время.
Тут есть тонкость: часто пароли из букв и цифр начинаются на буквы и заканчиваются цифрами, то есть цифры стоят только в конце. И перебор можно начинать именно с этих, наиболее вероятных вариантов. И если пароль имеет цифры только в конце, то тогда мы найдём его гораздо быстрее (предположительно, в среднем где‑то за 1 месяц).
Вообще тема глубокая. Можно найти где‑нибудь большие каталоги утекших паролей, статистически проанализировать и найти корреляции и паттерны, по которым пароли делают наиболее часто, и в первую очередь перебирать те варианты, которые соответствуют наиболее частым паттернам.
Там же вроде написано, что RTX 5090 считает ~27 гигахэшей в секунду. И тогда получается, что пароль длиной 10 латинских букв одного регистра на домашнем компе за полтора часа.
Если пароль из 10 заглавных и строчных букв + цифр (26 * 2 + 10) — то уже нужно около года (в среднем 6 месяцев).
Если добавляем спецсимволы — тогда у нас алфавит из, условно говоря, 128 символов, и тогда 1 такая карта будет работать до 1400 лет (а 1400 видеокарт 1 год:3 )
Если говорим про весь ASCII (то есть 256 символов), то до полутора миллионов лет, а 100 000 видеокарт — всего 10 лет
Остаётся выяснить, что дороже: аренда кластера из видеокарт на год или проведение разведывательной операции (которая может длиться от 10 секунд до 10 лет и больше).
Хорошо что никто пока не придумал какую‑нибудь движуху, неявно мотивирующую помогать взламывать пароли. Ну типа помогаешь перебирать хэши и тебе за это капает вознаграждение. Типа блокч...
Жаль, имхо такое сохранять надо. Я с DOS не работал, в детстве когда начинал кодить уже застал эпоху Win98 с окнами и GDI (но не GDI+).
В DOS это вообще же жесть наверное, там вручную надо было графический режим включать и писать оконный стек вообще с нуля, и только потом писать на нем софт. То есть Вы практически мини‑Windows 3.1 туда впихнули. Уважуха.
ИМХО можно просто взять оригинальную Википедию, взять каждую статью, и по каждому суждению устроить «прозвон источников», то есть не просто выяснить, откуда инфа, а проследить всю цепочку источников. И у каждого источника так же прозвонить цепочку финансирования — откуда у источника берутся ресурсы на существования. И не просто в статике, а с привязкой ко времени — когда где всплывала инфа, по какой закономерности. Как раз задача для ИИ.
Интересно, найдутся ли статьи, которые, на первый взгляд, ссылаются на множество источников, а при детальном анализе оказывается, что это какой‑то один центр.
Но почему‑то мне кажется, что публично так делать никто не будет :)
Интересно. Правильно ли я понимаю, что если я захочу запустить рой (например, 1000) таких дронов, то они должны воспринимать друг друга как препятствие, и сложность вычислений пути взлетит по экспоненте? И тут надо прикручивать что‑то типа растровой 3D сетки (ну или октодерева для навигации, но это перебор имхо)?
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.
Внимание к деталям плавно ушло вместе со Стивом Джобсом. Тим Кук — он, в первую очередь, про зарабатывание здесь и сейчас, а не про инновации и сверхдолгосрочные вложения (например, когда внимание к деталям создаёт имидж и окупается десятилетия). 20% усилий даёт 80% прибыли и вот это всё.
Даже анимация поворота экрана у современной техники Apple значительно упростилась. Меньше фишек с разной массой у разных элементов экрана, с размытием движения, с тем, что частота опроса сенсора выше частоты экрана в N раз, с тем, что анимации считаются почти в реальном времени. Пропорции не соблюдаются, GUI всё реже продумывают как целостную композицию, а не просто утилитарную картинку.
Одновременно с этим подтянулось качество конкурирующих продуктов — Android и Windows. Речь и о технических аспектах, и внимании к деталям, и внимании к дизайну и удобству. В начале 2010 годов даже топовый андройд по сравнению с айфоном был тормозным лагающим недоразумением. Сейчас «андройд» почти уже не лагает, а «айфон» начал всё больше лагать. Эстетика наконец‑то проросла в Android, Windows, Linux. А с айфоноайпадов постепенно слезает лоск. Оно просто сделано добротно, но не больше.
Есть и другой аспект: все эти электронные побрекушки из чего‑то вау стали не то чтобы обыденностью, они стали инфраструктурой. Типа батарей отопления, электрических розеток и унитазов. В начале жизненного цикла батареи и унитазы тоже были с вниманием к деталям, и тоже были круто‑дорого. Сейчас унитазы и розетки это само собой разумеющееся. Так и тут. Ноут толщиной 9 мм и смартфон сейчас это как электрическая лампочка, а не «ого у тебя целый комп в кармане, да еще и с 320 ядерным процессором 100 ГГц, как же это круто, а через год будет 101 ГГц это вообще мир перевернёт, инфа 100»
Более того, я подозреваю, что сейчас внимание к деталям постепенно будет уходить из многих сфер, в том числе, оно будет теряться у предметов премиального класса. Вместо этого будет имитация внимания к деталям. AI‑дженирейтед слоп воплощённый в 3D/4D печати и всё такое. И в софте, разумеется, в софте.
Мир меняется, становится нестабильным, обрастает войнами и кризисами (не только финансовыми), связи рвутся. Система ценностей, заточенная под спокойную размеренную жизнь, уходит, вместе с ней уходят мечты, цели и подходы, заточенные под неё. А новые пока ещё не родились. Но, мне кажется, так или иначе, в новом мире правило 80/20 будет применяться гораздо шире и мощнее. Военная утилитарность будет плавно проникать в быт и моду.
То, что происходит с Apple — это плавная адаптация ко всем этим фундаментальным изменениям. Им как раз сейчас нужен именно кто‑то вроде Тима Кука, а не Стива Джобса, просто потому что сейчас не 2010е.
Помимо полной поддержки AVX512 есть ещё поддержка на логическом уровне — формально инструкция поддерживается, но реально процессор выполняет её как две 256-битных. Я столкнулся с этим на своём CPU пока писал управление светодиодными лентами. CPU по документации вроде AVX512 поддерживает, но скорость от AVX2 по факту не отличается. Сначала я думал, что виноват C#, и по‑нормальному надо для таких задач использовать C++. Однако, раскопав документацию процессора поглубже, я понял, что регистры AVX512 вроде как есть, а вот обработчиков нет — вместо этого срабатывают AVX2 в два этапа. Полноценный AVX512 — это к ксеонам/тредрипперам/эпикам.
А ещё у AVX512 гораздо более удобный shuffle, который может переносить любые байты в любое место. У AVX256 насколько мне известно две половинки по 128 бит, которые между собой перемешивать не получится. Но могу ошибаться.
Приходилось писать реалтаймовое автоматическое выравнивание камер глубины между собой (RealSense D415), то есть вычислять относительно одной камеры положение всех остальных. Нужно это было для реалтаймового 3D сканирования с текстурой — строим несколько поверхностей и сшиваем.
Выравнивание сделал так: ищем общие точки на цветных 2D картинках, через канал глубины вытаскиваем расстояние до них и рассчитываем их 3D координаты в локальной системе отсчёта конкретной камеры, дальше уже простая триангуляция. Ну то есть вот треугольник видит одна камера, вот другой треугольник видит другая камера. Мы знаем, что это в реале эти два треугольника на самом деле один и тот же треугольник, поэтому можем посчитать матрицу трансформации.
D415 шумит конечно, но точек много, комбинаций по 3 точки ещё больше, поэтому немного медианной фильтрации, усреднения и кое‑какой магии — и вот уже точность +‑ приемлемая. Камеры, в основном, стояли на месте, их иногда могли перенести куда‑нибудь или просто случайно сместить. Поэтому я мог позволить себе оооочень долгое интегрирование по времени :)
Так вот, есть мысли что подобный подход применим и тут, и высоковероятно, что ресурсов жрать оно будет меньше, чем нейросетка, даже в случае с монокулярной камерой. Фактически при движении дрона мы получаем новые ракурсы, и нам нужно просто узнать координаты нового местоположения в системе координат предыдущего (или нескольких), и просто интегрировать путь.
А ещё это довольно несложно (относительно) впихнуть в ASIC и производить по 50 000 штук в месяц.
Смотря сколько лент надо контролировать, сколько диодов на них и с какой частотой их переключать. Если их несколько тысяч, простые контроллеры могут не переварить.
Более чем. Делал протокол WS2812b руками на nopах, забил всю память STM32 Discovery. На таймерах/SPI получилось бы сильно проще и меньше.
Системный промпт «Отвечай на русском» без кавычек, Flash Attenuation вкл, пул потоков 16 (было 12, но вряд ли это влияет на результат), остальное по дефолту.
Скрытый текст
Хм, любопытненько.
Uncensored
Vanilla
Вполне себе оно засекает, что тут что-то не то.
Остальные
Но в целом рекомендации довольно интересные, неплохо протестировать на разных моделях. В частности, есть ли разница в применении этих методологий при работе с обычными и рассуждающими LLM, и что будет, если миксовать их с другими подходами, например, игрой с температурой.
А ещё интересно, есть ли аналогичные трюки для VLM. Например, подгружать дополнительно картинку с какой‑нибудь бессмыслицей, которая по факту улучшит выдачу.
А что мешает сделать микросервис, который на вход жрёт шрифт, а на выходе дает всю нужную инфу о его размерах и прочих ТТХ? В конце концов это можно сделать на бекенде с кешированием. В общем, может я опять перегибаю оверинжиниринг, но для меня подобные проблемы выглядят как‑то диковато.
В WPF для десктопа 2008 года всё это было из коробки. Там только рендеринг шрифтов в самом начале был размытый из‑за игонра хинтинга, но это быстро починили. Почему эти сверхтехнологии инопланетных цивилизаций дошли до веба в 2025 году, большая загадка. И это при том, что сейчас на WebKit делают буквально почти всё.
Ну имхо это уже организационная проблема, а не техническая. Работали бы нормально паддинги, что‑нибудь другое бы дизайнер забыл бы сделать.
Странно что Фигма по умолчанию не включает эту штуку.
Приходилось писать быстрый рендеринг многострочного текста вдоль кривой Безье, поседел от количества нюансов и того, насколько на самом деле у шрифтов много заморочек и нюансов. У них туча разных вспомогательных линий и размеров.
И выравнивание текста в простейшем случае должно опираться на размер строчной латинской буквы «x», а не на фактический размер букв. В крайнем случае — на размер кегля.
Даже без VR на больших разрешениях типа 11520×2160 или 23040×4320 нужно много VRAM, иначе в играх будет 1 fps. А ещё можно рендерить в 3D пакетах всякое 16K на GPU и тут тоже будет нужно много VRAM.
Но тут речь про LLM, а не графику. У меня OSS 120b выдает 11–16 токенов в секунду в зависимости от настроек, при этом карта забита под 0 и ничего другого в неё уже не влезет.
А описанный в статье способ, фактически, позволяет если не ускорить, то хотя бы одновременно загрузить дополнительно несколько моделей и переключаться между ними, не делая полной выгрузки и повторной загрузки. Например, комбинировать OSS120b с каким‑нибудь VLLM и SDXL.
Отсутствует разъём, который занимает место.
И, если это делается по слоям, то наверно можно делать какие‑нибудь довольно хитрые конструкции из очень большого числа соединений, типа «одеяла» из десятков тысяч маленьких плат соединенных между собой десятками тысяч микрошлейфов. Вручную/роботами такое сделать почти нереально.
Но это мои фантазии, тут интересно было бы получить информацию о производстве «из первых рук» :)
Мне кажется, что из
не следует что
Это может быть так, а может и нет. Скорее всего нет.
Вы правы, я взял как пример пароль только из латинских букв одного регистра. Поправил текст. Однако год — это вполне ещё осязаемое время.
Тут есть тонкость: часто пароли из букв и цифр начинаются на буквы и заканчиваются цифрами, то есть цифры стоят только в конце. И перебор можно начинать именно с этих, наиболее вероятных вариантов. И если пароль имеет цифры только в конце, то тогда мы найдём его гораздо быстрее (предположительно, в среднем где‑то за 1 месяц).
Вообще тема глубокая. Можно найти где‑нибудь большие каталоги утекших паролей, статистически проанализировать и найти корреляции и паттерны, по которым пароли делают наиболее часто, и в первую очередь перебирать те варианты, которые соответствуют наиболее частым паттернам.
Там же вроде написано, что RTX 5090 считает ~27 гигахэшей в секунду. И тогда получается, что пароль длиной 10 латинских букв одного регистра на домашнем компе за полтора часа.
Если пароль из 10 заглавных и строчных букв + цифр (26 * 2 + 10) — то уже нужно около года (в среднем 6 месяцев).
Если добавляем спецсимволы — тогда у нас алфавит из, условно говоря, 128 символов, и тогда 1 такая карта будет работать до 1400 лет (а 1400 видеокарт 1 год:3 )
Если говорим про весь ASCII (то есть 256 символов), то до полутора миллионов лет, а 100 000 видеокарт — всего 10 лет
Остаётся выяснить, что дороже: аренда кластера из видеокарт на год или проведение разведывательной операции (которая может длиться от 10 секунд до 10 лет и больше).
Хорошо что никто пока не придумал какую‑нибудь движуху, неявно мотивирующую помогать взламывать пароли. Ну типа помогаешь перебирать хэши и тебе за это капает вознаграждение. Типа блокч...
Ой :)
Жаль, имхо такое сохранять надо. Я с DOS не работал, в детстве когда начинал кодить уже застал эпоху Win98 с окнами и GDI (но не GDI+).
В DOS это вообще же жесть наверное, там вручную надо было графический режим включать и писать оконный стек вообще с нуля, и только потом писать на нем софт. То есть Вы практически мини‑Windows 3.1 туда впихнули. Уважуха.
ИМХО можно просто взять оригинальную Википедию, взять каждую статью, и по каждому суждению устроить «прозвон источников», то есть не просто выяснить, откуда инфа, а проследить всю цепочку источников. И у каждого источника так же прозвонить цепочку финансирования — откуда у источника берутся ресурсы на существования. И не просто в статике, а с привязкой ко времени — когда где всплывала инфа, по какой закономерности. Как раз задача для ИИ.
Интересно, найдутся ли статьи, которые, на первый взгляд, ссылаются на множество источников, а при детальном анализе оказывается, что это какой‑то один центр.
Но почему‑то мне кажется, что публично так делать никто не будет :)
Интересно. Правильно ли я понимаю, что если я захочу запустить рой (например, 1000) таких дронов, то они должны воспринимать друг друга как препятствие, и сложность вычислений пути взлетит по экспоненте? И тут надо прикручивать что‑то типа растровой 3D сетки (ну или октодерева для навигации, но это перебор имхо)?