Вообще, самое смешное, что сейчас есть вполне интересные варианты для запуска сравнительно больших моделей локально на CPU
Сейчас весьма недорого (по цене видеокарты уровня 4060ti с 16 Гб VRAM) можно купить X99 платформу с двумя сокетами и, условно, 72 потоками+256 Гб RAM в 8 потоков.
Такая связка позволяет запускать даже большой DeepSeek на 400 миллиардов параметров в квантизации 4b и при этом получать хоть какие целые значения токенов в секунду :)
Это, само собой, все ещё очень медленно, но ЗНАЧИТЕЛЬНО быстрее потребительской платформы с RTX 4090, которая точно будет вынуждена использовать swap и будет выдавать токен за 10-15 секунд.
Предполагаю, что даже RTX 5090 + 9950x3d + ddr5 на 7000 MTs с GEN 4 NVME SSD в Raid0 будет все ещё медленнее, и при этом будет стоить на порядок дороже.
Так что если вам нужен инференс моделей для целей какой-нибудь автоматизации, где нет потребности в огромной скорости, но важно высокое качество... Подобный сервер может быть очень кстати :)
Вообще, подход в статье - замечательный, с тачки зрения игнорирования привычных рамок по использованию инструментов.
Мы вот, например, пришли к тому, что постгрес - замечательная шина данных, если у тебя ограничено количество потребителей :)
Однако, постановка с работой с GPU - кривенькая в силу одной единственной причины: работа через gpu нужна, чтобы потом использовать ответы не выгружая их с GPU. Например, для обучения или инференса нейросети на известном кусочке данных.
Тут же, получается, мы выигрываем только за счёт того, что промежуточные операции с ключом перед чтением/записью делаются в рамках более быстрой памяти. Но после этого добавляем дополнительный шаг чтения/записи RAM-VRAM. А это, вообще говоря, дорогая операция
Мне кажется, в статье происходит смешение теплого с мягким :)
Что не есть плохо, но нужно тогда уже доводить до конца реализацию получающегося тепло-мягкого :)
SOLID - это ведь не догмы, и не аксиомы "как правильно", это набор идей призывающий к упрощению контекста разработки :)
И поэтому приведенный пример с нарушением принципа разделения интерфейсов - далеко не всегда является нарушением. Причем, как на уровне цели упрощения контекста, так и на уровне буквы.
Будем ли мы думать про аспект авторизации во время работы над интерфейсом и реализацией профиля? Очень вероятно, что да. И нам придется вводить часть нашего кода, посвященную авторизации, в контекст в котором мы работаем над профилем.
При этом, честное разделение двух этих интерфейсов - не создаёт для нас никаких дополнительных проблем, кроме того, что для обнаружения смысловой связи между его частями (если она есть) - нам придётся дойти до точки, где эти элементы используются вместе.
При этом, нужно понимать, что аналогичная проблема, в целом, есть и у миксинов, и с какой-то точки зрения, она даже страшнее, ведь миксины не создают явного наследования, но при этом все ещё создают зависимость.
В общем, не совсем понятно: а главное зачем? Потому что в данном примере нам или не нужны ни миксины, ни наследование, если контекст профиля и авторизации не может быть полностью изолирован. Или мы можем честно разделить интерфейсы не имея ВООБЩЕ НИКАКИХ ПРОБЛЕМ, потому что нам никогда не нужно будет думать о них в одном контексте :)
P.S. буду рад, если меня кто-то поправит, я много лет уже пытаюсь понять в чем преимущество миксинов :D
И в том, что даже среди крупных компаний есть такие, где нет ни контроля доступов, ни управления зависимостями, ни построенного процесса ревью - вообще не сомневаюсь :)
Хотя, конечно, вся история звучит прохладно и репутацию всех участников попортит капитально :)
Ryzen 9 7900X - тоже 12 ядерный процессор, как и 9900X.
Со старшими чипами Интел конкурируют Ryzen 9 7950X и 9950X - там по 16 ядер и 32 потока.
В большинстве задач Ryzen показывает себя очень близко к соответствующим процессорами Intel по производительности, за поправкой на энергопотребление и тепловыделение.
Сегодня основная проблема Intel - их почти невозможно эффективно охлаждать. Со стандартным теплораспределителем они греются в максимальном бусте до предельной температуры вне зависимости от используемой системы охлаждения.
Из-за этого ситуация та же, что тянется уже несколько лет: Intel лучше в однопоточных задачах и там, где нужно за 10-20 секунд выдать максимум производительности.
AMD лучше ведёт себя в многопотоке и лучше сохраняет производительность при длительных нагрузках.
В России - выбор фактически зависит от твоих нагрузок. За рубежом Intel проигрывает весьма серьезно, т.к. процессор стоимостью в 500 евро обходится тебе ещё в дополнительные 50 евро в стоимости электроэнергии каждый год :) ну и охлаждение для 5950X, который больше греется, чем новые 7950 и 9950, стоит за 4 тысячи рублей и не греется больше, чем до 75 градусов.
А в моем домашнем ПК стоит 13600K и Arctic Cooling Freezr II 280 за 15 тысяч рублей. И под нагрузкой ниже 80 градусов процессор не бывает :)
Товарищи разработчики, я вам сугубо рекомендую меньше задаваться вопросом "а как эту задачу решить наиболее оптимально в сферическом коне в вакууме", и чуть больше задаваться вопросом "а зачем мы ее решаем?" :)
Вы этим сэкономите и себе, и окружающим много времени и нервных клеток :)
В данном случае ожидался конкретный ответ, но в реальности подобные "странные" запросы ранжируются от "один раз запустить, чтобы принять конкретное управленческое решение" - и тогда подходит лучше всего то решение, которое вы быстрее накидаете.
До "мы будем строить 150 реалтайм дашбордов по такого рода запросам, которые будут выводиться на 1,5 миллионах клиентов от Сиднея, до Москвы и Вашингтона" :) и вот в таком случае то как именно стоить запрос... Будет проблемой к которой вы перейдете не на первом часу общения с заказчиком :D
В реальной жизни, к сожалению или счастью, нет правильных ответов :) Мы вечно ищем компромисс, который больше всего подходит к конкретной ситуации :) помните об этом :)
Кроме того, что унитарные ветки должны предоставлять тебе простоту слияния и изоляцию кода по назначению, их смысл в том числе в их коротком сроке жизни и изоляции контекста при разработке.
Т.е. задача не в том, чтобы у тебя отдельно в ветке лежал код subsystem, а отдельно subsystem_ui.
А в том, чтобы ты начал разрабатывать классы ядра, разработал первую версию за день и к вечеру уже слил ее.
Потом на основе этих классов ты создал subsystem и также сделал первую версию за максимально короткое время.
И, главное, за исключением ситуации с фиксом багов в том коде, который ты активно используешь, в один момент времени ты работаешь над одним компонентом. А значит - упрощаешь себе не только синхронизацию с main, но и накладываешь на себя системные ограничения by design, что, как мы знаем, есть едва ли не единственный путь к снижению нагрузки на разработчика :)
Меня сейчас, возможно, закидают всяким, но, блин, все эти выплаты - очень позитивные новости.
Я как-то, когда думаю о детях и около них, рассчитываю на то, что я с ними буду "один на один" и как платить за все самостоятельно.
А если есть опция, что хоть какие-то расходы покроет государство - так это вообще восторг :) А тут прямо столько всего перечислили, что я даже про половину не знал :)
Привести визуализацию к абсолютным значениям, чтобы можно было объем транзакций оценить глядя на график
Добавить, например, в виде "толщины" колбасы - количество транзакций :)
В этом случае получится оценить и объем, и число транзакций в категории
Если разделить категории на "кучи"(node heaps) и в качестве ребра к1->к2 использовать транзакцию в к2 следующую за транзакцией в к1, и уложить граф с помощью метода укладки вроде Force Plot - можно будет показать динамику перехода расходов :)
Я очень активный пользователь такси, у меня больше тысячи поездок в год. Из аэропортов, в аэропорты, в довольно отдаленные районы и из них, а также в часы, когда "хороший хозяин собаку из дома не выгонит".
И ситуации, которые вы описываете, когда водитель делает фигню, конечно, есть. Но случаются они архирекдко. Потому что значительную их часть Яндекс находит сам. И даже когда одна из ситуаций случается, то по итогу пишется в поддержку, и воитель-причина неприятной ситуации больше на маршруте не появляется. А вам возвращают деньги, если их вообще спишут.
История с детскими креслами, конечно, так легко не решится. Но у меня вопрос - вы пробовали заказать Лидер или Максим с детским креслом до того как это появилось в Я.Такси?:) не знаю, как в вашем городе, но в Новосибирске детские кресла в такси вообще появились только когда пришел Яндекс. Ну и во всех крупных городах заказать такси с одним детским креслом сейчас проблемой не является, а с двумя... Вы демографию страны видели? Два детских кресла в такси, вне зависимости от Яндекса, маловероятно. Просто потому, что пользы для водителя от второго очень мало, а сложностей изрядно.
То же касается и "поездок, когда скоро будет повышенный спрос": году так в 2010 в Новосибирске уехать из аэропорта просто всегда стоило от тысячи рублей. Иногда сильно дороже, но дешевле - не было. Сейчас я уезжаю на правый берег (25км), а то и в академгородок (50км) в среднем за 1000-1600 рублей, и не на экономе. При этом, иногда, если я прилетаю в разрыв между рейсами, то получается уехать и за 600-700 рублей. То есть, в целом, для меня стоимость такси с учётом инфляции упала раза в два, а иногда я вообще можно сказать бесплатно уезжаю.
И, нет, Яндекс.Такси не идеальный сервис. Да, они иногда очень жёстко косячат. И, да, с их монополией связано очень много потенциальных рисков. Вот только то, о чем пишите вы - или не связано с Яндекс.Такси, или легко в рамках экосистемы решается.
Во-первых, привет коллегам от ML-команды Евраза =) Во-вторых, классный рассказ про нюансы, мы что-то подобное регулярно рассказываем заказчикам "почему это так дорого" =) В-третьих, что таки у вас по экосистемным решениям? =)
В этом и история, что данных, в целом, много =) А ещё больше данных - которых нет и не будет =) Например, в печи может иметься дырка (это не шутка, не в этом конкретно кейсе, но ситуация реальная =)), через которую будет отходить тепло и часть газов/взвеси. И это будет нелинейно влиять на традиционную физическую формулу. Теоретически, построить физ.мат. модель с учетом всех дополнительных нюансов тех.процесса можно... Но как правило это проект стоимостью в десятки, а то и в сотни миллионов рублей =)
Применение ML в таких задачах - это как раз попытка по косвенным признакам вывести зависимости от "скрытых" данных и восстановить ту самую аппроксимационную функцию на основе данных и сделать это дешевле и быстрее, чем при попытке честного моделирования. При этом "наивная модель" по нескольким точкам (обычно её зовут baseline) - является первым шагом для построения статистической модели =) И если он уже даёт результат - статистическую модель обычно уже не строят.
Очень жаль, что большая часть комментаторов так однобоко смотрит на ситуацию.)
Минцифры нужно отдать должное, они сделали невероятно много хорошего для ИТ специалистов работающих на российские компании. Более того, в определенные моменты показали высочайший уровень квалификации и понимания ситуации, например, когда началась мобилизация.
От себя, как от руководителя довольно крупного ИТ подразделения могу сказать разве что спасибо всем сотрудникам минцифры и лично Максуту Игоревичу :) Мои специалисты благодаря их действиям чувствуют себя существенно лучше и спокойнее, благодаря их усилиям.
Если получится создать конкурента ASML в любом смысле этого слова - никто не будет говорить про "выпуск только для армии". Экспорт начнется в тот же момент, когда за рубежом появится спрос, скорее всего :)
Но создать конкурента ASML... В мире это прямо сейчас никому не нужно настолько, чтобы в это инвестировать действительно серьезные средства, т.е. много триллионов долларов :)
Теоретически, в современной России может сложиться единственная точка на земле в обозримом будущем, где подобное может стать оправданным и осмысленным :) не более того
Хотя история с безмасочной фотолитографией и звучит действительно очень перспективно, но подводных камней на этом пути - умопомрачительное количество. А потому ни одной оценке "за столько лет и денег - мы сделаем" я бы не верил :)
Любой кто хоть раз умудрился спроектировать и реализовать что-то более сложное, чем ножка для стула, понимает, что в серьезных разработках разброс затрат и сроков начинается от двухкратного х)
А не в курсе кто именно такие заявления делает? Я тут давече у коллег спрашивал, но первоисточника подобных высказываний мне так и не сдали :) а я бы посотрудничал :)
Теория - даёт тебе точную и строгую формулу с парой констант, которые работают "условно всегда" При этом в формуле есть множество значений, которые на предприятии ТОЧНО измерить невозможно =) И если подставлять неточные значения - получается неточный результат: Garbage in - garbage out =)
Дооборудовать более точными измерительными средствами обычно капец как дорого =) В итоге, как правило, для тех значений, которые не могут точно измерить, подбирают "поправочные коэффициенты", которые дают похожий на правду результат в большинстве случаев =) А остальную формулу используют "как есть" =)
Вообще, самое смешное, что сейчас есть вполне интересные варианты для запуска сравнительно больших моделей локально на CPU
Сейчас весьма недорого (по цене видеокарты уровня 4060ti с 16 Гб VRAM) можно купить X99 платформу с двумя сокетами и, условно, 72 потоками+256 Гб RAM в 8 потоков.
Такая связка позволяет запускать даже большой DeepSeek на 400 миллиардов параметров в квантизации 4b и при этом получать хоть какие целые значения токенов в секунду :)
Это, само собой, все ещё очень медленно, но ЗНАЧИТЕЛЬНО быстрее потребительской платформы с RTX 4090, которая точно будет вынуждена использовать swap и будет выдавать токен за 10-15 секунд.
Предполагаю, что даже RTX 5090 + 9950x3d + ddr5 на 7000 MTs с GEN 4 NVME SSD в Raid0 будет все ещё медленнее, и при этом будет стоить на порядок дороже.
Так что если вам нужен инференс моделей для целей какой-нибудь автоматизации, где нет потребности в огромной скорости, но важно высокое качество... Подобный сервер может быть очень кстати :)
Вообще, подход в статье - замечательный, с тачки зрения игнорирования привычных рамок по использованию инструментов.
Мы вот, например, пришли к тому, что постгрес - замечательная шина данных, если у тебя ограничено количество потребителей :)
Однако, постановка с работой с GPU - кривенькая в силу одной единственной причины: работа через gpu нужна, чтобы потом использовать ответы не выгружая их с GPU. Например, для обучения или инференса нейросети на известном кусочке данных.
Тут же, получается, мы выигрываем только за счёт того, что промежуточные операции с ключом перед чтением/записью делаются в рамках более быстрой памяти. Но после этого добавляем дополнительный шаг чтения/записи RAM-VRAM. А это, вообще говоря, дорогая операция
"Напрямую на WSL" это не "напрямую" на самом деле :)
WSL использует те же механизмы виртуализации, что и докер :)
В целом, влияние контейнеризации в случае абсолютного большинства приложений - не критично.
Однако кэширование - ровно тот класс задач, где влияние становится как минимум заметным.
Мне кажется, в статье происходит смешение теплого с мягким :)
Что не есть плохо, но нужно тогда уже доводить до конца реализацию получающегося тепло-мягкого :)
SOLID - это ведь не догмы, и не аксиомы "как правильно", это набор идей призывающий к упрощению контекста разработки :)
И поэтому приведенный пример с нарушением принципа разделения интерфейсов - далеко не всегда является нарушением. Причем, как на уровне цели упрощения контекста, так и на уровне буквы.
Будем ли мы думать про аспект авторизации во время работы над интерфейсом и реализацией профиля? Очень вероятно, что да. И нам придется вводить часть нашего кода, посвященную авторизации, в контекст в котором мы работаем над профилем.
При этом, честное разделение двух этих интерфейсов - не создаёт для нас никаких дополнительных проблем, кроме того, что для обнаружения смысловой связи между его частями (если она есть) - нам придётся дойти до точки, где эти элементы используются вместе.
При этом, нужно понимать, что аналогичная проблема, в целом, есть и у миксинов, и с какой-то точки зрения, она даже страшнее, ведь миксины не создают явного наследования, но при этом все ещё создают зависимость.
В общем, не совсем понятно: а главное зачем? Потому что в данном примере нам или не нужны ни миксины, ни наследование, если контекст профиля и авторизации не может быть полностью изолирован. Или мы можем честно разделить интерфейсы не имея ВООБЩЕ НИКАКИХ ПРОБЛЕМ, потому что нам никогда не нужно будет думать о них в одном контексте :)
P.S. буду рад, если меня кто-то поправит, я много лет уже пытаюсь понять в чем преимущество миксинов :D
Я верю в человеческий идиотизм :D
И в том, что даже среди крупных компаний есть такие, где нет ни контроля доступов, ни управления зависимостями, ни построенного процесса ревью - вообще не сомневаюсь :)
Хотя, конечно, вся история звучит прохладно и репутацию всех участников попортит капитально :)
Товарищ, учите мат.часть.
Ryzen 9 7900X - тоже 12 ядерный процессор, как и 9900X.
Со старшими чипами Интел конкурируют Ryzen 9 7950X и 9950X - там по 16 ядер и 32 потока.
В большинстве задач Ryzen показывает себя очень близко к соответствующим процессорами Intel по производительности, за поправкой на энергопотребление и тепловыделение.
Сегодня основная проблема Intel - их почти невозможно эффективно охлаждать. Со стандартным теплораспределителем они греются в максимальном бусте до предельной температуры вне зависимости от используемой системы охлаждения.
Из-за этого ситуация та же, что тянется уже несколько лет: Intel лучше в однопоточных задачах и там, где нужно за 10-20 секунд выдать максимум производительности.
AMD лучше ведёт себя в многопотоке и лучше сохраняет производительность при длительных нагрузках.
В России - выбор фактически зависит от твоих нагрузок. За рубежом Intel проигрывает весьма серьезно, т.к. процессор стоимостью в 500 евро обходится тебе ещё в дополнительные 50 евро в стоимости электроэнергии каждый год :) ну и охлаждение для 5950X, который больше греется, чем новые 7950 и 9950, стоит за 4 тысячи рублей и не греется больше, чем до 75 градусов.
А в моем домашнем ПК стоит 13600K и Arctic Cooling Freezr II 280 за 15 тысяч рублей. И под нагрузкой ниже 80 градусов процессор не бывает :)
А как можно было в сравнение не включить YDB?)
Это тот случай, когда переход на неё я бы рассматривал в отдельных случаях даже при отсутствии каких-либо проблем с MS SQL и Oracle :)
Товарищи разработчики, я вам сугубо рекомендую меньше задаваться вопросом "а как эту задачу решить наиболее оптимально в сферическом коне в вакууме", и чуть больше задаваться вопросом "а зачем мы ее решаем?" :)
Вы этим сэкономите и себе, и окружающим много времени и нервных клеток :)
В данном случае ожидался конкретный ответ, но в реальности подобные "странные" запросы ранжируются от "один раз запустить, чтобы принять конкретное управленческое решение" - и тогда подходит лучше всего то решение, которое вы быстрее накидаете.
До "мы будем строить 150 реалтайм дашбордов по такого рода запросам, которые будут выводиться на 1,5 миллионах клиентов от Сиднея, до Москвы и Вашингтона" :) и вот в таком случае то как именно стоить запрос... Будет проблемой к которой вы перейдете не на первом часу общения с заказчиком :D
В реальной жизни, к сожалению или счастью, нет правильных ответов :) Мы вечно ищем компромисс, который больше всего подходит к конкретной ситуации :) помните об этом :)
В очередной раз происходит потеря смысла :)
Кроме того, что унитарные ветки должны предоставлять тебе простоту слияния и изоляцию кода по назначению, их смысл в том числе в их коротком сроке жизни и изоляции контекста при разработке.
Т.е. задача не в том, чтобы у тебя отдельно в ветке лежал код subsystem, а отдельно subsystem_ui.
А в том, чтобы ты начал разрабатывать классы ядра, разработал первую версию за день и к вечеру уже слил ее.
Потом на основе этих классов ты создал subsystem и также сделал первую версию за максимально короткое время.
И, главное, за исключением ситуации с фиксом багов в том коде, который ты активно используешь, в один момент времени ты работаешь над одним компонентом. А значит - упрощаешь себе не только синхронизацию с main, но и накладываешь на себя системные ограничения by design, что, как мы знаем, есть едва ли не единственный путь к снижению нагрузки на разработчика :)
Это не является коммерческой тайной. Данные о доходах могут проходить как персональные данные, и тем самым подпадать под статью 88 ТК РФ.
Меня сейчас, возможно, закидают всяким, но, блин, все эти выплаты - очень позитивные новости.
Я как-то, когда думаю о детях и около них, рассчитываю на то, что я с ними буду "один на один" и как платить за все самостоятельно.
А если есть опция, что хоть какие-то расходы покроет государство - так это вообще восторг :) А тут прямо столько всего перечислили, что я даже про половину не знал :)
Предложение для развития:
Привести визуализацию к абсолютным значениям, чтобы можно было объем транзакций оценить глядя на график
Добавить, например, в виде "толщины" колбасы - количество транзакций :)
В этом случае получится оценить и объем, и число транзакций в категории
Если разделить категории на "кучи"(node heaps) и в качестве ребра к1->к2 использовать транзакцию в к2 следующую за транзакцией в к1, и уложить граф с помощью метода укладки вроде Force Plot - можно будет показать динамику перехода расходов :)
Я сейчас один умный вещь скажу, вы только не обижайтесь.
В отношениях с работодателем есть два первичных документа: трудовой договор (со всеми дополнительными соглашениями) и должностная инструкция.
По сути, если прочитать их и те документы на которые они ссылаются, то уже будет на 99% понятно как в непонятной ситуации себя вести с работодателем.
А оставшийся процент - это истории завязанные на трудовой кодекс, относительно которых как правило и нужны консультации.
Ну, а дальше есть простых правила:
Все должно быть записано: разговоры и взаимодействия с работодателем, результаты работы и так далее. Если не записано - считай не было.
Если что-то не прописано в документах явно - надо идти копать в трудовой кодекс.
А вы пробовали что-то делать с этим?
Я очень активный пользователь такси, у меня больше тысячи поездок в год. Из аэропортов, в аэропорты, в довольно отдаленные районы и из них, а также в часы, когда "хороший хозяин собаку из дома не выгонит".
И ситуации, которые вы описываете, когда водитель делает фигню, конечно, есть. Но случаются они архирекдко. Потому что значительную их часть Яндекс находит сам. И даже когда одна из ситуаций случается, то по итогу пишется в поддержку, и воитель-причина неприятной ситуации больше на маршруте не появляется. А вам возвращают деньги, если их вообще спишут.
История с детскими креслами, конечно, так легко не решится. Но у меня вопрос - вы пробовали заказать Лидер или Максим с детским креслом до того как это появилось в Я.Такси?:) не знаю, как в вашем городе, но в Новосибирске детские кресла в такси вообще появились только когда пришел Яндекс. Ну и во всех крупных городах заказать такси с одним детским креслом сейчас проблемой не является, а с двумя... Вы демографию страны видели? Два детских кресла в такси, вне зависимости от Яндекса, маловероятно. Просто потому, что пользы для водителя от второго очень мало, а сложностей изрядно.
То же касается и "поездок, когда скоро будет повышенный спрос": году так в 2010 в Новосибирске уехать из аэропорта просто всегда стоило от тысячи рублей. Иногда сильно дороже, но дешевле - не было. Сейчас я уезжаю на правый берег (25км), а то и в академгородок (50км) в среднем за 1000-1600 рублей, и не на экономе. При этом, иногда, если я прилетаю в разрыв между рейсами, то получается уехать и за 600-700 рублей. То есть, в целом, для меня стоимость такси с учётом инфляции упала раза в два, а иногда я вообще можно сказать бесплатно уезжаю.
И, нет, Яндекс.Такси не идеальный сервис. Да, они иногда очень жёстко косячат. И, да, с их монополией связано очень много потенциальных рисков. Вот только то, о чем пишите вы - или не связано с Яндекс.Такси, или легко в рамках экосистемы решается.
You can do better.
Во-первых, привет коллегам от ML-команды Евраза =)
Во-вторых, классный рассказ про нюансы, мы что-то подобное регулярно рассказываем заказчикам "почему это так дорого" =)
В-третьих, что таки у вас по экосистемным решениям? =)
В этом и история, что данных, в целом, много =)
А ещё больше данных - которых нет и не будет =) Например, в печи может иметься дырка (это не шутка, не в этом конкретно кейсе, но ситуация реальная =)), через которую будет отходить тепло и часть газов/взвеси. И это будет нелинейно влиять на традиционную физическую формулу.
Теоретически, построить физ.мат. модель с учетом всех дополнительных нюансов тех.процесса можно... Но как правило это проект стоимостью в десятки, а то и в сотни миллионов рублей =)
Применение ML в таких задачах - это как раз попытка по косвенным признакам вывести зависимости от "скрытых" данных и восстановить ту самую аппроксимационную функцию на основе данных и сделать это дешевле и быстрее, чем при попытке честного моделирования.
При этом "наивная модель" по нескольким точкам (обычно её зовут baseline) - является первым шагом для построения статистической модели =) И если он уже даёт результат - статистическую модель обычно уже не строят.
Очень жаль, что большая часть комментаторов так однобоко смотрит на ситуацию.)
Минцифры нужно отдать должное, они сделали невероятно много хорошего для ИТ специалистов работающих на российские компании. Более того, в определенные моменты показали высочайший уровень квалификации и понимания ситуации, например, когда началась мобилизация.
От себя, как от руководителя довольно крупного ИТ подразделения могу сказать разве что спасибо всем сотрудникам минцифры и лично Максуту Игоревичу :) Мои специалисты благодаря их действиям чувствуют себя существенно лучше и спокойнее, благодаря их усилиям.
Если получится создать конкурента ASML в любом смысле этого слова - никто не будет говорить про "выпуск только для армии". Экспорт начнется в тот же момент, когда за рубежом появится спрос, скорее всего :)
Но создать конкурента ASML... В мире это прямо сейчас никому не нужно настолько, чтобы в это инвестировать действительно серьезные средства, т.е. много триллионов долларов :)
Теоретически, в современной России может сложиться единственная точка на земле в обозримом будущем, где подобное может стать оправданным и осмысленным :) не более того
Обещания и реальность - штука сильно разная :)
Хотя история с безмасочной фотолитографией и звучит действительно очень перспективно, но подводных камней на этом пути - умопомрачительное количество. А потому ни одной оценке "за столько лет и денег - мы сделаем" я бы не верил :)
Любой кто хоть раз умудрился спроектировать и реализовать что-то более сложное, чем ножка для стула, понимает, что в серьезных разработках разброс затрат и сроков начинается от двухкратного х)
А не в курсе кто именно такие заявления делает? Я тут давече у коллег спрашивал, но первоисточника подобных высказываний мне так и не сдали :) а я бы посотрудничал :)
Я чуть-чуть перефразировал бы =)
Теория - даёт тебе точную и строгую формулу с парой констант, которые работают "условно всегда"
При этом в формуле есть множество значений, которые на предприятии ТОЧНО измерить невозможно =)
И если подставлять неточные значения - получается неточный результат: Garbage in - garbage out =)
Дооборудовать более точными измерительными средствами обычно капец как дорого =)
В итоге, как правило, для тех значений, которые не могут точно измерить, подбирают "поправочные коэффициенты", которые дают похожий на правду результат в большинстве случаев =)
А остальную формулу используют "как есть" =)