Несколько раз перечитал условие задачи. Чем тут банальная дихотомия не подходит? Сложность O(log N), код от “Случайного” варианта одной строчкой отличается. Зачем сложные варианты, когда есть простой и быстрый?
Свой вирутуальный сервер с VPN может быть легко скомпрометирован, если вы запустите Max не выключив VPN. Запрос от Max уйдёт через ваш сервер и выдаст РКНу его IP.
"всегда используй PreparedStatement" — этот совет основан на предположении, что кэшировать план запроса всегда хорошо. Это не так. В большой доле сценариев использование PreparedStatement с параметрами — будет мешать планировщику базы построить оптимальный план с учётом конкретного значения параметра. Планировщик вынужден строить план под более универсальный случай и терять в производительности.
А какая разница, микросервисы или нет? Или будем держаться на надежде, что если один микросервис будет перегружен, то остальным база не будет нужна? Тут это скорее выглядит как признание того, что в случае с микросервисами становится сложнее планировать нагрузку.
Открою вам старашный "секрет" про пулы соединений: никогда не используйте на проде динамическое измнение числа соединений (или подобных ресурсов). Всегда используйте фиксированный размер, если у вас ресурс сам по себе не скейлится автоматически и вы хотите, чтобы в целом система работала как можно более стабильно и предсказуемо.
Число соединений к базе? min == max
Память JVM процсса? Xms == Xmx (и ещё -XX:+AlwaysPreTouch вдогонку)
Если только у вас база сама по себе не скейлится автоматически под нагрузкой, то причин начинать с маленького числа соединений в пуле — примерно ноль.
Угу. А потом новости в духе "компания X уволила N программистов", "сервисы компании X не работали M часов", "компания X понесла K убытков", "компания X подала на банкротство".
Я вполне понимаю, что у какой-то компании Y всё получается и большого факапа не случается и она финансово обходит конкурентов. И таких немало. Вот только сам факт того, что ставка на ИИ — это большой риск для бизнеса почему-то вайб-кодеры замалчивают.
Какой-то идиотизм. Рейтрейсинг не прижился, так как до сих пор нет массово доступых по цене видеокарт для него (и не предвидится ещё несколько лет как минимум). Но новая технология, которая требует ещё более мощное железо уж точно "взлетит"! /s
Тут существенный момент: что чтобы на перепродаже потерять всего 10%, а не 99% - нужно покупать что-то, что само по себе востребовано. А значит инвестиция будет попадать куда нужно.
В чём смысл "статьи"? Поделиться кодом? Можно было ограничиться ссылкой и парой абзецев описания общей архитектуры (которого по факту нет) и описать собственно функционал бота (чего опять же нет). Не очень понятно, кому могут быть интересны куски совершенно типичного кода.
Ещё раз. 10 инстансов одной модели, с одинаковыми параметрами (но разным seed).
Это вполне достаточно, чтобы увидеть, что, возможно, на самом деле не модели по-разному умные, а что им по-разному везёт и сама статья выше — совершенно непоказательна.
Всё остальное что вы написали — это уже относится к поиску лучшего портфеля и совершенно не относится к существу той проблемы, на которую я указал.
PS: Мне про торги можно не рассказывать, я работаю непосредственно в финтехе.
Так ваше "на грани случайностей" — это просто статистический разброс. Подбрасывайте 1000 независимых монеток и некоторые монетки вам покажут отличный рост. Только это не значит, что какие-то из монеток как-то "умнее" других. Им просто повезло.
Несколько раз перечитал условие задачи. Чем тут банальная дихотомия не подходит? Сложность O(log N), код от “Случайного” варианта одной строчкой отличается. Зачем сложные варианты, когда есть простой и быстрый?
И кварки, и Фаэтон (планета), и динозавры, и библия… Жаль нет объяснения Бермудского треугольника, очень нехватает /s
Там уже этот алогоритм во всю адаптируют под llama.cpp и не только.
Ну не TCP/IP же… Он эту проблему не решит.
Свой вирутуальный сервер с VPN может быть легко скомпрометирован, если вы запустите Max не выключив VPN. Запрос от Max уйдёт через ваш сервер и выдаст РКНу его IP.
"всегда используй PreparedStatement" — этот совет основан на предположении, что кэшировать план запроса всегда хорошо. Это не так. В большой доле сценариев использование PreparedStatement с параметрами — будет мешать планировщику базы построить оптимальный план с учётом конкретного значения параметра. Планировщик вынужден строить план под более универсальный случай и терять в производительности.
А какая разница, микросервисы или нет? Или будем держаться на надежде, что если один микросервис будет перегружен, то остальным база не будет нужна?
Тут это скорее выглядит как признание того, что в случае с микросервисами становится сложнее планировать нагрузку.
Открою вам старашный "секрет" про пулы соединений: никогда не используйте на проде динамическое измнение числа соединений (или подобных ресурсов). Всегда используйте фиксированный размер, если у вас ресурс сам по себе не скейлится автоматически и вы хотите, чтобы в целом система работала как можно более стабильно и предсказуемо.
Число соединений к базе? min == max
Память JVM процсса? Xms == Xmx (и ещё
-XX:+AlwaysPreTouchвдогонку)Если только у вас база сама по себе не скейлится автоматически под нагрузкой, то причин начинать с маленького числа соединений в пуле — примерно ноль.
Угадайте, откуда нейросеть знает про то, как написать "собственную" реализацию.
Угу. А потом новости в духе "компания X уволила N программистов", "сервисы компании X не работали M часов", "компания X понесла K убытков", "компания X подала на банкротство".
Я вполне понимаю, что у какой-то компании Y всё получается и большого факапа не случается и она финансово обходит конкурентов. И таких немало. Вот только сам факт того, что ставка на ИИ — это большой риск для бизнеса почему-то вайб-кодеры замалчивают.
Какой-то идиотизм. Рейтрейсинг не прижился, так как до сих пор нет массово доступых по цене видеокарт для него (и не предвидится ещё несколько лет как минимум). Но новая технология, которая требует ещё более мощное железо уж точно "взлетит"! /s
Тут существенный момент: что чтобы на перепродаже потерять всего 10%, а не 99% - нужно покупать что-то, что само по себе востребовано. А значит инвестиция будет попадать куда нужно.
В чём смысл "статьи"? Поделиться кодом? Можно было ограничиться ссылкой и парой абзецев описания общей архитектуры (которого по факту нет) и описать собственно функционал бота (чего опять же нет).
Не очень понятно, кому могут быть интересны куски совершенно типичного кода.
А ничего, что эти рекомендации имеют смысл только для конеретной модели?
Вы в крупном городе небо вообще видели? Местами из-за засветки можно разве что за луной и солнцем наблюдать :(
"Да, вы совершенно правы! На фото пять ящериц."
Кто будет нести ответственность за неверное толкование договора ИИ-помошником?
Там, где можно смеяться.
Ещё раз. 10 инстансов одной модели, с одинаковыми параметрами (но разным seed).
Это вполне достаточно, чтобы увидеть, что, возможно, на самом деле не модели по-разному умные, а что им по-разному везёт и сама статья выше — совершенно непоказательна.
Всё остальное что вы написали — это уже относится к поиску лучшего портфеля и совершенно не относится к существу той проблемы, на которую я указал.
PS: Мне про торги можно не рассказывать, я работаю непосредственно в финтехе.
Так ваше "на грани случайностей" — это просто статистический разброс. Подбрасывайте 1000 независимых монеток и некоторые монетки вам покажут отличный рост. Только это не значит, что какие-то из монеток как-то "умнее" других. Им просто повезло.