LLM — только имитация интеллекта. Нейросети не имеют «опыта», не совершают действий и не получают обратной связи от реальности
Какое самоуверенное утверждение! Чат гпт каждый день ведёт столько диалогов, сколько ни один человек за всю жизнь не может. Да, архитектура не предполагает, что каждый диалог тотчас же пересчитает веса, но где уверенность, что все эти миллиарды диалогов не пойдут в обучающую модель новой версии?
Agoda is a digital travel platform that helps travelers see the world for less with its great value deals on a global network of over 4.5M hotels and holiday properties worldwide, plus flights, activities, and more. They’re now testing Imagen and Veo on Vertex AI to create visuals, allowing Agoda teams to generate unique images of travel destinations which would then be used to generate videos.
Это ж прямое описание мошеннической схемы. Туристам рекламируют места, которые 100% будут выглядеть НЕ, как на картинке
Verizon, the largest U.S. wireless carrier, is using AI-powered enterprise search to help teams in network operations and customer experience get the answers they need faster.
Никакой конкретики ни о том, какой масштаб внедрения, ни какие технологии. Может, там вообще стажер с почтой @verizon.com себе собрал с говна и палок на n8n прототип...
Кстати, не смешно. Серьёзные люди, оперирующие транзакциями в десятки и сотни тысяч раз большими, чем стоимость компьютера, практикуют использование отдельных устройств для финансов и критичных переписок. И, логично, что, у такого человека вполне может стоять рядом комп для игр, укомплектованный самой дорогой мышкой (ибо, нет времени вникать, какая мышка/видеокарта/клавиатура мне нужна, - куплю самую дорогую, чтобы наверняка).
Там есть еще один интересный прикол. Что объем мошенничества имеет взрывную зависимость с тем, выше, или ниже у тебя защита по сравнению с рынком. Мошеннические транзакции, в отличии от радиационных частиц, бомбардируют бизнесы не случайно, а, пропорционально успешности прошлых. Когда появляется новый денежный мешок (казик с большими бонусами, финтех с возможностью брать в долг, новый криптопроект с потенциальной возможностью пихнуть туда грязные монеты etc), команды работающих на потоке фродеров его обязательно рано или поздно прощупают и сравнят объем гемора с их текущими темами (разведка боем). И, если там окажется сильно проще, чем у других, то произойдет взрыв фрода, ибо разведчики приведут армию (команду с отработанными и регламентированными процессами и большим количеством рядовых исполнителей, работающих с 9 до 6).
Это работает и в другую сторону. При усилении борьбы с фродом у сильно зафроженного проекта наступает момент, когда он выходит из топа доходности у крупных команд, и они уходят к другим, сразу снижая фрод в разы, и оставляя фродить только разведчиков крупных команд и мелкое жулье, не обладающее целостной картиной, и фродящее где придется
Скрытый текст
Чукча и геолог собирают камушки на берегу океана. Вдруг видят направляющегося к ним голодного белого медведя. Ружья нет. Чукча хватает лыжи и начинает их надевать. Геолог: - Бесполезно. Все равно ты не сможешь бежать быстрее медведя. - А мне и не надо бежать быстрее медведя. Мне надо бежать быстрее тебя!
А продавать в одном магазине сети одно печенье, а в другом другое - смысла никакого нет.
Хоть это и не отменяет тезис о том, что маленькие производства не интересны для СТМ, но своими глазами видел, как на упаковке написано "если партия начинается на 1, то производитель А, если 2, то В, если 3, то С", и указано 3 адреса и 3 юрлица. В этом же и суть. Раз сеть взяла на себя ответственность за качество продукции своего бренда, то, и миксовать производителей соседних одинаковых пачек товара могут, пока способны контролировать качество
Хорошая аналогия. Но, с другой стороны, а, может, в случае с телевизорами, суть не в сложности техпроцесса, а в том, что +1 маленький и несчастный магазин телевизоров даёт ценность (вчера надо было километр ехать за телевизором, а сейчас в соседнем доме), а +1 гараж, собирающий телевизоры, не даёт ценности вообще (ибо по цене-качеству он никак не сравнится с гигантами)?
Есть же другой пример, где производителей дохрена, а продавцов мало. Игры для ПК. Сделать +1 магазин игр сильно проще, чем AAA игру. Но, за счёт того, что +1 игра даёт ценность, а +1 магазин нет, и нету 100500 стимов
Особенно коммерческий транспорт, где лишние километры пробега без зарядки – это прям золото.
Вопрос в том, готовы ли они к непредсказуемости. Условно, если почтовый грузовичек будет развозить 250 посылок в солнечный день и 200 в пасмурный (ибо заряд кончается раньше конца смены), то бизнес станет сильно нестабильным, и придётся все равно иметь запас грузовиков и водителей.
Или иметь аккумуляторы с запасом, чтобы грузовик дожил до конца смены даже в случае абсолютной облачности весь день, но, тогда, возникает вопрос, а зачем эти солнечные батареи размещать именно на грузовиках? Ну, объективно, не самое удобное место для обслуживания и ремонта. На поле или крыше склада проще и надёжнее, и КПД выше за счёт оптимального угла
Подумал, что такой трекер более полезен даже тем, у кого кота нет, чтобы принять осознанное решение, нужен ли котенок (щенок). Такая, по сути, как сейчас модно говорить, распаковка владения котом.
Могу ошибаться, но, насколько помню, сила cdn в способности навесить на 1 ip адрес много железок по всему миру. Что позволяет иметь стабильно низкий пинг до эджа с любого места. В теории то любой владелец сайта может заморочиться и сделать это, но это гемор и в плане взаимодействия с хостерами и в плане компетенций команды.
Без этой киллер фичи, даже, имея много ориджинов, все решения сомнительны. К примеру, попытки заставить dns отдавать разные ориджины сомнительны из-за того, что какой именно днс сервер будет спрашивать посетитель, и как тот сервер ответит - вещи неподконтрольные. Редиректы типа eu.mysite.com/us.mysite.com с прибиванием гвоздями поддоменов с ориджинами норм тема, если это аппка вроде таск трекера, но сомнительная тема, если это SEO история, ибо поисковик будет это видеть разными страницами. Ок, можно заморочиться, и апи коллы делать на ближайшие ориджин, если это SPA, но, все равно, статика будет тормозить.
Приведу реальный пример, где очень хотели уйти от CF, но не смогли. Есть сетка SEO сайтов с миллионами страниц в индексе гугла. Трафик примерно поровну идёт с Африки (реальные посетители), и с США (бот гугла, обновляющий свой индекс). Принципиально важно быстро отдать и там и там (тормоза на гугле -> пессимизация в выдаче. Тормоза в Африке -> посетители не дожидаются открытия страницы и идут дальше по выдаче). Страницы SSR (так лучше для SEO). Манипуляции с редиректами хз, как себя покажут для SEO. Итого, держат 2 ориджина (1 Европа ради Африки, второй - США ради гугла), CF дополнительно гарантирует, что
Наверное, правильнее говорить "рекрутеру". Все же, HR это по работе с уже нанятыми.
Если речь о фрилансере или агентстве, то что-то вроде 50% вознаграждения при выходе на работу кандидата, 50% после закрытия ИС (критерием закрытия потребности всегда считают окончание ИС).
Если о штатном, то это всегда ставка + бонус за каждого нанятого кандидата, либо план на их количество
По наблюдению за своим айфоном как через съемку экрана камерой, так и просто, шатая пальцем, выглядит, будто бы он диммит где-то до процентов 10 без мерцания, после чего димминг уже не даёт дальше снижать, и дальнейший путь вниз ищет через шим. Видимо, этот переключатель, по сути, ограничит диапазон яркости до вот этой точки переключения
Странно вообще. Самые жирные киты типа Bank of America и подобных очень поведены на контроле над своими данными. Доходит до требований к аутсорсным галлерам иметь отдельный офис со своим контролем доступа. туалетом, и кухней для сотрудников проекта, чтобы не разболтали за чаем или у писсуара случайно чего. Выглядит, как добровольный отказ от топ 0.1% клиентов, каждый из которых приносит, как 10000 лохов
Давайте на это шире посмотрим. Живой разработчик это тот же LLM. Без кодовой базы под рукой, IDE с автокомплитом и возможности глянуть в доку тоже напишет некомпилируемую хрень.
Принципиальное отличие оно в том, что разработчик сам понимает, когда надо дернуть внешние данные, а RAGом пытаются напичкать до выполнения задачи. Примерно, как если закрыть программиста в комнате без интернета и заставить писать программу в блокноте, но перед этим дать ему десяток вырванных страниц с учебника по питону, и пару файлов с проекта. Повезет - ему этих данных хватит. Не повезёт, - штош, придется додумать, как могла б выглядеть функция, с которой раньше дела не имел, и, которая в эти страницы не попала
Вангую, что все начнёт нормально работать, когда модель сама будет запрашивать доп данные в процессе генерации, и понимать, когда неспособна выдать надёжный ответ. Условно, не вырывать страницы с учебника до задачи, а листать учебник в процессе выполнения
Поддержу. Как будто бы, слишком уж обобщенная сущность. С одной стороны, вроде и круто: написал один раз софтину, принимающую имя файла на входе, и вообще не паришься, просто запускай и запускай, меняя аргумент, и подставляя туда что хочешь.
А, с другой, как будто бы, такой подход побуждает появление неочевидных ошибок где-то в глубине стека. Например, запустили сервис, подставив адрес фтп, как путь к файлу для логирования (при том, что автор сервиса вообще держал в голове только текстовый файл и stdout при написании). Работать будет, ибо ничего ж криминального не сделано. Но однажды процесс начнёт получать абсолютно непредсказуемые ошибки, которые при этом ещё и никто никогда не сможет прочесть, потому, что они не залоггируются
Есть хотя бы график доходности его инвестиций по годам?
Хотя бы? Да такого графика даже у Дина лично нет. Там доли в стартапах, оценить которые можно только при наличии покупателя в моменте (чем-то квантовые штуки напоминает). Ну есть у тебя 3% в каком-то ИИ стартапе, который генерирует ежемесячный операционный убыток в $250K. Сколько он стоит? Через ебидту по классике не оценишь никак. Если по последнему раунду брать, будет Х (но то было 6 месяцев назад, и именно такая сделка больше никода не повторится). С момента последнего раунда там могло как остаться 0.01X (если идея не выстрелила, и, максимум, можно пару патентов да десяток херманмиллеров продать), так и 100Х, если вот, прямо сейчас, идут переговоры о новом раунде по 100Х.
А что не так?) Объективно, узнать, на что поставил свой кошелек такой человек, интересно Понятно, что, его портфель не повторить, ибо это не публичные компании, но это ж удивительная возможность узнать во что человек с таким мозгом И информацией реально верит (а не говорит/пишет где-то)
Сравнивать эти две метрики, а не показатель использования CPU.
Автор предлагает решение. Но, оно тоже довольно сомнительное. Объем работы в рамках 1й единицы редко константен. Условно, если в чёрную пятницу х10 заказов, то надо не только сделать х10 актов процессинга, но и каждый из них будет чуть тяжелее, чем обычно (где-то алгоритм не О(1), а O от уже сделанных заказов сегодня, где-то кеш начал быстрее протухать из-за того, что объем RAM на кеш-сервере кончается быстрее, чем ttl, база отвечает медленно, сетевые интерфейсы перегружены, и так далее). Можно легко попасть в ситуацию, когда сервер делает 1/2 от своей нормальной работы, все зелёное в мониторинге, но, по факту, целостная система на пределе
Как будто бы, как раз тот случай, что надо тот же ML (или стат таблицы) использовать, и, оценивая текущую частоту, температуру, и загрузку каждого ядра, оценивать, сколько ещё можно с этой системы выжать
Из реального опыта подкину ещё неочевидных парадоксов:
1) из-за энергоэкономии на сервере СУБД падал потоковый процессинг в неннагруженное время. Система состоит из очереди сообщений, сотен воркеров, и сервера СУБД на что-то типа 128 логических ядер. В моменты низкой нагрузки очередь необработанных сообщений летит в космос, но к вечеру, под нагрузкой, возвращается к риалтайму. То есть, утром, в моменты нагрузки до 10% на всем процессорах всех серверов, растут задержки. Оказалось, что ядра на сервере СУБД под общей нагрузкой сервера в 5-10% начинали работать где-то на частоте 0.6 ГГц, из-за чего череда последовательных запросов к СУБД взлетала по времени в разы, и время на обработку одного сообщения становилось несовместимым с потоком сообщений, и воркеры сидели на ожидании СУБД, а СУБД не получала достаточной нагрузки, чтобы поднять частоту. К вечеру нагрузка от других сервисов выводила камни из спячки на их базовую частоту, и сразу все становилось на свои места. Поменяв настройки энергопитания, проблема рассосалась, и более не вернулась
2) Обновление процессоров положило систему. Кластер блейд серверов с двумя xeon e5 в каждом (не помню уже, точно какой, но что-то с очень большой базовой частотой, как для северного железа, типа 3.6 и по 6 ядер в каждом) обслуживает довольно крупный сайт. Каждый отдельный воркер это многопоточный процесс на делфи под x86 с ограничением в 2 ГБ из-за архитектуры. В какой-то момент происходит перевооружение с заменой камней на другие E5 с совместимым сокетом, и все ещё допустимым TDP, хоть и на пределе, но с сильно большим количеством ядер и меньшей частотой. Как результат, время выполнения каждого отдельного запроса на апи с фронта выростает, и в конфигурации того же количества воркеров и потоков система падает под привычной нагрузкой. Девопсы поднимают количество воркеров на каждом блейде, и после этого падает СУБД, к который они ходят за обновлением кеша. Возвращают назад количество воркеров, поднимают количество потоков, и воркера начинают падать по out of memory (привет 2ГБ). В итоге в срочном порядке старые камни ставят назад.
3) Имел дело с уникальной системой, вмещающей 4 видеокарты 1080Ti/Titan X + 2 ксеона в 1U корпус. Отдельная история, как с ее глубиной ее впихнуть в стойку. Но, впихнув, видим, что камни упорно не хотят разгоняться выше 0.6 ГГц. Как уже не танцевали с бубном вокруг биоса, пока производитель не сказал, что с одного блока питания оно нормально работать не будет. С двух блоков таки зарабатало как надо. Реально, одного БП не хватает, и система работает, но с тротлингом
Талант распределен неравномерно, и, как правило, в любой компании есть те, на ком все завязано, и, как-то так выходит, что они же эффективнее всех могут разобраться в ИИ. Выходит, что у этих людей, скорее всего, тупо не будет возможности выделить это время (да, право имеют, но к ним и так стоит очередь), а те, кто могут, не сильно то и разберутся.
В моей практике был случай, когда в компании предложили всем собрать команду, и придумать внутренний стартап, чтобы потом запустить 3 лучших. Я сразу ванговал, что идея не взлетит потому, что способны на такое те, кто и так уже где-то чем-то руководит и много на себе завязал, а их внимание необходимо на критических путях процессов, сильно более важных, чем весь проект внутренних стартапов вместе взятых. Так и вышло. Идеологи топ3 проектов, которые должны были идти на запуск, оказались все трое завязаны на критичных процессах. Им предложили что-то типа 2 часа в день, и после этого судьба стала ясна
Какое самоуверенное утверждение! Чат гпт каждый день ведёт столько диалогов, сколько ни один человек за всю жизнь не может. Да, архитектура не предполагает, что каждый диалог тотчас же пересчитает веса, но где уверенность, что все эти миллиарды диалогов не пойдут в обучающую модель новой версии?
Если бы...
Там ещё и откровенно вредоносные применения есть
Это ж прямое описание мошеннической схемы. Туристам рекламируют места, которые 100% будут выглядеть НЕ, как на картинке
К слову, там ниочем по ссылке. 1001 абзац типа
Никакой конкретики ни о том, какой масштаб внедрения, ни какие технологии. Может, там вообще стажер с почтой @verizon.com себе собрал с говна и палок на n8n прототип...
Кстати, не смешно. Серьёзные люди, оперирующие транзакциями в десятки и сотни тысяч раз большими, чем стоимость компьютера, практикуют использование отдельных устройств для финансов и критичных переписок. И, логично, что, у такого человека вполне может стоять рядом комп для игр, укомплектованный самой дорогой мышкой (ибо, нет времени вникать, какая мышка/видеокарта/клавиатура мне нужна, - куплю самую дорогую, чтобы наверняка).
Там есть еще один интересный прикол. Что объем мошенничества имеет взрывную зависимость с тем, выше, или ниже у тебя защита по сравнению с рынком. Мошеннические транзакции, в отличии от радиационных частиц, бомбардируют бизнесы не случайно, а, пропорционально успешности прошлых. Когда появляется новый денежный мешок (казик с большими бонусами, финтех с возможностью брать в долг, новый криптопроект с потенциальной возможностью пихнуть туда грязные монеты etc), команды работающих на потоке фродеров его обязательно рано или поздно прощупают и сравнят объем гемора с их текущими темами (разведка боем). И, если там окажется сильно проще, чем у других, то произойдет взрыв фрода, ибо разведчики приведут армию (команду с отработанными и регламентированными процессами и большим количеством рядовых исполнителей, работающих с 9 до 6).
Это работает и в другую сторону. При усилении борьбы с фродом у сильно зафроженного проекта наступает момент, когда он выходит из топа доходности у крупных команд, и они уходят к другим, сразу снижая фрод в разы, и оставляя фродить только разведчиков крупных команд и мелкое жулье, не обладающее целостной картиной, и фродящее где придется
Скрытый текст
Чукча и геолог собирают камушки на берегу океана. Вдруг видят направляющегося к ним голодного белого медведя. Ружья нет. Чукча хватает лыжи и начинает их надевать. Геолог:
- Бесполезно. Все равно ты не сможешь бежать быстрее медведя.
- А мне и не надо бежать быстрее медведя. Мне надо бежать быстрее тебя!
Хоть это и не отменяет тезис о том, что маленькие производства не интересны для СТМ, но своими глазами видел, как на упаковке написано "если партия начинается на 1, то производитель А, если 2, то В, если 3, то С", и указано 3 адреса и 3 юрлица. В этом же и суть. Раз сеть взяла на себя ответственность за качество продукции своего бренда, то, и миксовать производителей соседних одинаковых пачек товара могут, пока способны контролировать качество
Хорошая аналогия. Но, с другой стороны, а, может, в случае с телевизорами, суть не в сложности техпроцесса, а в том, что +1 маленький и несчастный магазин телевизоров даёт ценность (вчера надо было километр ехать за телевизором, а сейчас в соседнем доме), а +1 гараж, собирающий телевизоры, не даёт ценности вообще (ибо по цене-качеству он никак не сравнится с гигантами)?
Есть же другой пример, где производителей дохрена, а продавцов мало. Игры для ПК. Сделать +1 магазин игр сильно проще, чем AAA игру. Но, за счёт того, что +1 игра даёт ценность, а +1 магазин нет, и нету 100500 стимов
Вопрос в том, готовы ли они к непредсказуемости. Условно, если почтовый грузовичек будет развозить 250 посылок в солнечный день и 200 в пасмурный (ибо заряд кончается раньше конца смены), то бизнес станет сильно нестабильным, и придётся все равно иметь запас грузовиков и водителей.
Или иметь аккумуляторы с запасом, чтобы грузовик дожил до конца смены даже в случае абсолютной облачности весь день, но, тогда, возникает вопрос, а зачем эти солнечные батареи размещать именно на грузовиках? Ну, объективно, не самое удобное место для обслуживания и ремонта. На поле или крыше склада проще и надёжнее, и КПД выше за счёт оптимального угла
Подумал, что такой трекер более полезен даже тем, у кого кота нет, чтобы принять осознанное решение, нужен ли котенок (щенок). Такая, по сути, как сейчас модно говорить, распаковка владения котом.
Могу ошибаться, но, насколько помню, сила cdn в способности навесить на 1 ip адрес много железок по всему миру. Что позволяет иметь стабильно низкий пинг до эджа с любого места. В теории то любой владелец сайта может заморочиться и сделать это, но это гемор и в плане взаимодействия с хостерами и в плане компетенций команды.
Без этой киллер фичи, даже, имея много ориджинов, все решения сомнительны. К примеру, попытки заставить dns отдавать разные ориджины сомнительны из-за того, что какой именно днс сервер будет спрашивать посетитель, и как тот сервер ответит - вещи неподконтрольные. Редиректы типа eu.mysite.com/us.mysite.com с прибиванием гвоздями поддоменов с ориджинами норм тема, если это аппка вроде таск трекера, но сомнительная тема, если это SEO история, ибо поисковик будет это видеть разными страницами. Ок, можно заморочиться, и апи коллы делать на ближайшие ориджин, если это SPA, но, все равно, статика будет тормозить.
Приведу реальный пример, где очень хотели уйти от CF, но не смогли. Есть сетка SEO сайтов с миллионами страниц в индексе гугла. Трафик примерно поровну идёт с Африки (реальные посетители), и с США (бот гугла, обновляющий свой индекс). Принципиально важно быстро отдать и там и там (тормоза на гугле -> пессимизация в выдаче. Тормоза в Африке -> посетители не дожидаются открытия страницы и идут дальше по выдаче). Страницы SSR (так лучше для SEO). Манипуляции с редиректами хз, как себя покажут для SEO. Итого, держат 2 ориджина (1 Европа ради Африки, второй - США ради гугла), CF дополнительно гарантирует, что
1) статика будет отдана с эджа
2) кеш мисс не приведёт к пересечению океана
Наверное, правильнее говорить "рекрутеру". Все же, HR это по работе с уже нанятыми.
Если речь о фрилансере или агентстве, то что-то вроде 50% вознаграждения при выходе на работу кандидата, 50% после закрытия ИС (критерием закрытия потребности всегда считают окончание ИС).
Если о штатном, то это всегда ставка + бонус за каждого нанятого кандидата, либо план на их количество
По наблюдению за своим айфоном как через съемку экрана камерой, так и просто, шатая пальцем, выглядит, будто бы он диммит где-то до процентов 10 без мерцания, после чего димминг уже не даёт дальше снижать, и дальнейший путь вниз ищет через шим. Видимо, этот переключатель, по сути, ограничит диапазон яркости до вот этой точки переключения
Странно вообще. Самые жирные киты типа Bank of America и подобных очень поведены на контроле над своими данными. Доходит до требований к аутсорсным галлерам иметь отдельный офис со своим контролем доступа. туалетом, и кухней для сотрудников проекта, чтобы не разболтали за чаем или у писсуара случайно чего. Выглядит, как добровольный отказ от топ 0.1% клиентов, каждый из которых приносит, как 10000 лохов
Давайте на это шире посмотрим. Живой разработчик это тот же LLM. Без кодовой базы под рукой, IDE с автокомплитом и возможности глянуть в доку тоже напишет некомпилируемую хрень.
Принципиальное отличие оно в том, что разработчик сам понимает, когда надо дернуть внешние данные, а RAGом пытаются напичкать до выполнения задачи. Примерно, как если закрыть программиста в комнате без интернета и заставить писать программу в блокноте, но перед этим дать ему десяток вырванных страниц с учебника по питону, и пару файлов с проекта. Повезет - ему этих данных хватит. Не повезёт, - штош, придется додумать, как могла б выглядеть функция, с которой раньше дела не имел, и, которая в эти страницы не попала
Вангую, что все начнёт нормально работать, когда модель сама будет запрашивать доп данные в процессе генерации, и понимать, когда неспособна выдать надёжный ответ. Условно, не вырывать страницы с учебника до задачи, а листать учебник в процессе выполнения
Поддержу. Как будто бы, слишком уж обобщенная сущность. С одной стороны, вроде и круто: написал один раз софтину, принимающую имя файла на входе, и вообще не паришься, просто запускай и запускай, меняя аргумент, и подставляя туда что хочешь.
А, с другой, как будто бы, такой подход побуждает появление неочевидных ошибок где-то в глубине стека. Например, запустили сервис, подставив адрес фтп, как путь к файлу для логирования (при том, что автор сервиса вообще держал в голове только текстовый файл и stdout при написании). Работать будет, ибо ничего ж криминального не сделано. Но однажды процесс начнёт получать абсолютно непредсказуемые ошибки, которые при этом ещё и никто никогда не сможет прочесть, потому, что они не залоггируются
Хотя бы? Да такого графика даже у Дина лично нет. Там доли в стартапах, оценить которые можно только при наличии покупателя в моменте (чем-то квантовые штуки напоминает). Ну есть у тебя 3% в каком-то ИИ стартапе, который генерирует ежемесячный операционный убыток в $250K. Сколько он стоит? Через ебидту по классике не оценишь никак. Если по последнему раунду брать, будет Х (но то было 6 месяцев назад, и именно такая сделка больше никода не повторится). С момента последнего раунда там могло как остаться 0.01X (если идея не выстрелила, и, максимум, можно пару патентов да десяток херманмиллеров продать), так и 100Х, если вот, прямо сейчас, идут переговоры о новом раунде по 100Х.
А что не так?)
Объективно, узнать, на что поставил свой кошелек такой человек, интересно
Понятно, что, его портфель не повторить, ибо это не публичные компании, но это ж удивительная возможность узнать во что человек с таким мозгом И информацией реально верит (а не говорит/пишет где-то)
Автор предлагает решение. Но, оно тоже довольно сомнительное. Объем работы в рамках 1й единицы редко константен. Условно, если в чёрную пятницу х10 заказов, то надо не только сделать х10 актов процессинга, но и каждый из них будет чуть тяжелее, чем обычно (где-то алгоритм не О(1), а O от уже сделанных заказов сегодня, где-то кеш начал быстрее протухать из-за того, что объем RAM на кеш-сервере кончается быстрее, чем ttl, база отвечает медленно, сетевые интерфейсы перегружены, и так далее). Можно легко попасть в ситуацию, когда сервер делает 1/2 от своей нормальной работы, все зелёное в мониторинге, но, по факту, целостная система на пределе
Как будто бы, как раз тот случай, что надо тот же ML (или стат таблицы) использовать, и, оценивая текущую частоту, температуру, и загрузку каждого ядра, оценивать, сколько ещё можно с этой системы выжать
Ох... И, вправду, неприятная тема
Из реального опыта подкину ещё неочевидных парадоксов:
1) из-за энергоэкономии на сервере СУБД падал потоковый процессинг в неннагруженное время. Система состоит из очереди сообщений, сотен воркеров, и сервера СУБД на что-то типа 128 логических ядер. В моменты низкой нагрузки очередь необработанных сообщений летит в космос, но к вечеру, под нагрузкой, возвращается к риалтайму. То есть, утром, в моменты нагрузки до 10% на всем процессорах всех серверов, растут задержки. Оказалось, что ядра на сервере СУБД под общей нагрузкой сервера в 5-10% начинали работать где-то на частоте 0.6 ГГц, из-за чего череда последовательных запросов к СУБД взлетала по времени в разы, и время на обработку одного сообщения становилось несовместимым с потоком сообщений, и воркеры сидели на ожидании СУБД, а СУБД не получала достаточной нагрузки, чтобы поднять частоту. К вечеру нагрузка от других сервисов выводила камни из спячки на их базовую частоту, и сразу все становилось на свои места. Поменяв настройки энергопитания, проблема рассосалась, и более не вернулась
2) Обновление процессоров положило систему. Кластер блейд серверов с двумя xeon e5 в каждом (не помню уже, точно какой, но что-то с очень большой базовой частотой, как для северного железа, типа 3.6 и по 6 ядер в каждом) обслуживает довольно крупный сайт. Каждый отдельный воркер это многопоточный процесс на делфи под x86 с ограничением в 2 ГБ из-за архитектуры. В какой-то момент происходит перевооружение с заменой камней на другие E5 с совместимым сокетом, и все ещё допустимым TDP, хоть и на пределе, но с сильно большим количеством ядер и меньшей частотой. Как результат, время выполнения каждого отдельного запроса на апи с фронта выростает, и в конфигурации того же количества воркеров и потоков система падает под привычной нагрузкой. Девопсы поднимают количество воркеров на каждом блейде, и после этого падает СУБД, к который они ходят за обновлением кеша. Возвращают назад количество воркеров, поднимают количество потоков, и воркера начинают падать по out of memory (привет 2ГБ). В итоге в срочном порядке старые камни ставят назад.
3) Имел дело с уникальной системой, вмещающей 4 видеокарты 1080Ti/Titan X + 2 ксеона в 1U корпус. Отдельная история, как с ее глубиной ее впихнуть в стойку. Но, впихнув, видим, что камни упорно не хотят разгоняться выше 0.6 ГГц. Как уже не танцевали с бубном вокруг биоса, пока производитель не сказал, что с одного блока питания оно нормально работать не будет. С двух блоков таки зарабатало как надо. Реально, одного БП не хватает, и система работает, но с тротлингом
Вот, посыл понятен, но есть проблема
Талант распределен неравномерно, и, как правило, в любой компании есть те, на ком все завязано, и, как-то так выходит, что они же эффективнее всех могут разобраться в ИИ. Выходит, что у этих людей, скорее всего, тупо не будет возможности выделить это время (да, право имеют, но к ним и так стоит очередь), а те, кто могут, не сильно то и разберутся.
В моей практике был случай, когда в компании предложили всем собрать команду, и придумать внутренний стартап, чтобы потом запустить 3 лучших. Я сразу ванговал, что идея не взлетит потому, что способны на такое те, кто и так уже где-то чем-то руководит и много на себе завязал, а их внимание необходимо на критических путях процессов, сильно более важных, чем весь проект внутренних стартапов вместе взятых. Так и вышло. Идеологи топ3 проектов, которые должны были идти на запуск, оказались все трое завязаны на критичных процессах. Им предложили что-то типа 2 часа в день, и после этого судьба стала ясна