А в чём суть? Рассказали, как арендовать сервер (вообще не относится к теме запуска), потом зачем-то рассказали про сборку из исходников (вместо того чтобы готовый официальный докер использовать) и вкрячивание олламы сервисом в систему (зачем), потом высыпали на читателя кучу скриншотов и статья закончилась.
Реально от всей статьи какая-то польза может быть только от таблички с результатами, но с учётом того что ollama работает поверх той же самой llama.cpp, но устаревшей, цифры практически идентичные и смысла вообще немного. С таким же успехом можно произвести наблюдение, что отношение периметра муравейника к диаметру примерно равно трём.
Вдобавок скорость при parallel = 2 или 4 почти не растёт, потому что выбранная модель MoE и для неё параллельность эффекта почти не даёт (в отличие от dense модели типа gemma 12b или 31b, но в статье замеры только для одной модели без попытки какого-либо анализа). А читатель потом будет думать, что parallel не работает или что ему нужна видеокарта с 24Гб для запуска.
Вся статья - тупая рекалма, сервер нафиг не нужен, а автор не разбирается теме. Всё то же самое сделать локально и на более бюджетном железе. Модель gemma 26b с moe, её можно и на 8 Гб видеопамяти запустить с оффлоадом экспертов в RAM - будет почти так же.
P.s. Тем кто только вкатывается - лучше с lmstudio и unsloth studio начинать, там та же llama.cpp под капотом, но с удобным ui для настроек и использования.
Ага, так и хотелось сказать что это type class на минималках.
Я тоже пробовал свой язык дизайнить и кажется, что если есть типы-суммы с тегами и тайпклассы, то как будто можно построить адекватный язык без наследования. Отличия конечно будут, но мне понравилось что получилось, и штуки типа vtable и прочего если очень надо - можно эмулировать.
У вас в итоге получилась сортировка подсчётом по номеру локации (чтобы было за O(N) вместо О(NlogN) у обычной сортировки) и вспомогательная структура для быстрого поиска. Возможно это очевидно, но в статье ни слова про сортировку и хранение по порядку в финальном варианте. (По крайней мере мне такое описание кажется более интуитивно понятным)
В краткосроке да, в долгосроке читателей всё меньше становится и хабр окончательно умрёт. Туда ему и дорога.
Реальная проблема не в ИИ и не а нейросоопе, а в накрутках рейтинга статей и отсутствии системы рекомендаций. На платформах типа Ютуба можно выкладывать любой шлак, но если его не смотрят и не лайкают - особо никто его и не увидит. А на Хабре единственный критерий для ленты рейтинг (Окей, ещё хабы), и у любой копростатьи он легко шагает за +30.
И хабр не особо поощряет минусование статей (требуют указать причину, есть лимиты на минусование, для старых пользователей плюс даёт. +² или +3, а минус - только -1) - этот механизм усилиям администрации тоже скорее мёртв чем жив, даже нейрослоп особо не минусуют, а для корпоративных статей с админ ресурсом это вообще почти нереально - они в любой момент могут ещё плюсов досыпать.
А, про такое я знаю, но в идеале не надо на сотню километров от центра уходить. Тогда да, любая погрешность с углом умножается на расстояние и точность падает на пять порядков (если 1 это один метр, а если один сантиметр или миллиметр то ещё хуже). А вам даже точности double не хватало? Там точность 15 знаков и как будто их достаточно.
Для матрицы вращения 3х3 экспоненту можно вычислить в замкнутой формуле (и для кватернионов и моторов аналогично). Из минусов - там вылазят вычисления sin, cos и atan2, но для малых углов можно разложить формулы в ряд Тейлора и получить и точность и скорость вычислений. Вдобавок у чисел с плавающей запятой есть замечательное свойство - они умеют хранить очень маленькие или очень большие числа типа 1е-50 или 1е50, и точность не страдает. Я в остальном согласен, но именно интерполяция не самая проблемная часть.
Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
Исходная точка: физические ограничения против теории типов Мой подход исходит из физических ограничений целевого железа (8-битный МК и 2 КБ ОЗУ). Это не абстракция, а жесткая реальность. Каждая фича языка в vm5277 должна платить за свое существование байтами Flash/RAM и тактами процессора. Ваш подход, как я понял, идет от выразительности и корректности на уровне типов. Это прекрасно там, где есть гигабайты ОЗУ и JIT-компилятор, но избыточно для микроконтроллеров.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
не перепутали ли мы эстетическую проблему с гораздо более серьёзной — исчезновением редакционной ответственности?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
А в чём суть? Рассказали, как арендовать сервер (вообще не относится к теме запуска), потом зачем-то рассказали про сборку из исходников (вместо того чтобы готовый официальный докер использовать) и вкрячивание олламы сервисом в систему (зачем), потом высыпали на читателя кучу скриншотов и статья закончилась.
Реально от всей статьи какая-то польза может быть только от таблички с результатами, но с учётом того что ollama работает поверх той же самой llama.cpp, но устаревшей, цифры практически идентичные и смысла вообще немного. С таким же успехом можно произвести наблюдение, что отношение периметра муравейника к диаметру примерно равно трём.
Вдобавок скорость при parallel = 2 или 4 почти не растёт, потому что выбранная модель MoE и для неё параллельность эффекта почти не даёт (в отличие от dense модели типа gemma 12b или 31b, но в статье замеры только для одной модели без попытки какого-либо анализа). А читатель потом будет думать, что parallel не работает или что ему нужна видеокарта с 24Гб для запуска.
Вся статья - тупая рекалма, сервер нафиг не нужен, а автор не разбирается теме. Всё то же самое сделать локально и на более бюджетном железе. Модель gemma 26b с moe, её можно и на 8 Гб видеопамяти запустить с оффлоадом экспертов в RAM - будет почти так же.
P.s. Тем кто только вкатывается - лучше с lmstudio и unsloth studio начинать, там та же llama.cpp под капотом, но с удобным ui для настроек и использования.
Ага, так и хотелось сказать что это type class на минималках.
Я тоже пробовал свой язык дизайнить и кажется, что если есть типы-суммы с тегами и тайпклассы, то как будто можно построить адекватный язык без наследования. Отличия конечно будут, но мне понравилось что получилось, и штуки типа vtable и прочего если очень надо - можно эмулировать.
У вас в итоге получилась сортировка подсчётом по номеру локации (чтобы было за O(N) вместо О(NlogN) у обычной сортировки) и вспомогательная структура для быстрого поиска. Возможно это очевидно, но в статье ни слова про сортировку и хранение по порядку в финальном варианте. (По крайней мере мне такое описание кажется более интуитивно понятным)
В краткосроке да, в долгосроке читателей всё меньше становится и хабр окончательно умрёт. Туда ему и дорога.
Реальная проблема не в ИИ и не а нейросоопе, а в накрутках рейтинга статей и отсутствии системы рекомендаций. На платформах типа Ютуба можно выкладывать любой шлак, но если его не смотрят и не лайкают - особо никто его и не увидит. А на Хабре единственный критерий для ленты рейтинг (Окей, ещё хабы), и у любой копростатьи он легко шагает за +30.
И хабр не особо поощряет минусование статей (требуют указать причину, есть лимиты на минусование, для старых пользователей плюс даёт. +² или +3, а минус - только -1) - этот механизм усилиям администрации тоже скорее мёртв чем жив, даже нейрослоп особо не минусуют, а для корпоративных статей с админ ресурсом это вообще почти нереально - они в любой момент могут ещё плюсов досыпать.
А, про такое я знаю, но в идеале не надо на сотню километров от центра уходить. Тогда да, любая погрешность с углом умножается на расстояние и точность падает на пять порядков (если 1 это один метр, а если один сантиметр или миллиметр то ещё хуже). А вам даже точности double не хватало? Там точность 15 знаков и как будто их достаточно.
Для матрицы вращения 3х3 экспоненту можно вычислить в замкнутой формуле (и для кватернионов и моторов аналогично). Из минусов - там вылазят вычисления sin, cos и atan2, но для малых углов можно разложить формулы в ряд Тейлора и получить и точность и скорость вычислений. Вдобавок у чисел с плавающей запятой есть замечательное свойство - они умеют хранить очень маленькие или очень большие числа типа 1е-50 или 1е50, и точность не страдает. Я в остальном согласен, но именно интерполяция не самая проблемная часть.
Есть такое видео, но его сложновато слушать: https://www.youtube.com/watch?v=1iPWt1gvT_w
И ссылки на почитать. https://habr.com/ru/articles/1033328/ https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/135011
Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
P.p.s. какие-то мысли про язык и процесс разработки (сам язык сильно отличается, но надеюсь какие-то вещи могут пригодиться) : https://kright.me/2026/07/06/delaiu-svoi-iazyk-programmirovaniia/
Лол, а остальные статьи на Хабре вас не смущают, включая статьи самих редакторов?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Ага, и на мой взгляд будет круто, если у них всё получится. Выглядит очень смело и амбициозно.
Они и хотят и пытаются. К текстовому редактору намного проще делать плагины и изменения, чем к IDE с кучей внутренних взаимосвязей и ограничений.
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
То же самое хотелось сказать. Отвратительно написанная новость, только в заблуждение вводит, хотя по-факту ничего не изменилось.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.