#poetry
Нашел старенький стих, даже не помню, чей.
"Ты думаешь, ты счастлив,
И проживаешь жизнь сполна?
Дурак! твой день ужасен,
Кругом идёт война.
Везде одна разруха
Не веришь мне?
А зря.
На улице так глухо,
И на ушах у всех лапша.
Мой мир.
Здесь каждый верит в Бога.
Бог не имеет столько сил.
Ты в нищете, твой дом - берлога,
Увы, не Бог твой господин.
Пустынная алея,
Холодная зима прошла.
Так чем же мы болеем?
Откуда столько зла?
Плечом к плечу встречаясь,
Друг друга посылаем на.
Ты сам всё понимаешь,
Холодная идёт война.
Счастливая улыбка,
Печальные глаза.
Наш мир - всего ошибка,
Пустой, как и душа."
Нашел старенький стих, даже не помню, чей.
"Ты думаешь, ты счастлив,
И проживаешь жизнь сполна?
Дурак! твой день ужасен,
Кругом идёт война.
Везде одна разруха
Не веришь мне?
А зря.
На улице так глухо,
И на ушах у всех лапша.
Мой мир.
Здесь каждый верит в Бога.
Бог не имеет столько сил.
Ты в нищете, твой дом - берлога,
Увы, не Бог твой господин.
Пустынная алея,
Холодная зима прошла.
Так чем же мы болеем?
Откуда столько зла?
Плечом к плечу встречаясь,
Друг друга посылаем на.
Ты сам всё понимаешь,
Холодная идёт война.
Счастливая улыбка,
Печальные глаза.
Наш мир - всего ошибка,
Пустой, как и душа."
😢1
#bigquery #primarykeys
Офигеваю с Гугла. Многие годами жаловались, что в BigQuery нет первичных и внешних ключей.
И вот гугл их добавил. Теперь можно указать таблице primary key(x,y) not enforced. Not enforced прописано во всех примерах доки. Думаю, к чему бы это?
Опытным путём выяснилось, что ключи указать ты можешь, но проверять база их целостность за тебя не будет. На кой хер тогда такое "добавление" нужно? С таким созданным первичным ключом в базу спокойно добавляются дубликаты. Отлично, гугл.
https://www.datadice.io/blog/how-comprehensive-are-the-new-primary-keys-and-foreign-keys-in-bigquery
Офигеваю с Гугла. Многие годами жаловались, что в BigQuery нет первичных и внешних ключей.
И вот гугл их добавил. Теперь можно указать таблице primary key(x,y) not enforced. Not enforced прописано во всех примерах доки. Думаю, к чему бы это?
Опытным путём выяснилось, что ключи указать ты можешь, но проверять база их целостность за тебя не будет. На кой хер тогда такое "добавление" нужно? С таким созданным первичным ключом в базу спокойно добавляются дубликаты. Отлично, гугл.
https://www.datadice.io/blog/how-comprehensive-are-the-new-primary-keys-and-foreign-keys-in-bigquery
www.datadice.io
How comprehensive are the new Primary Keys and Foreign Keys in BigQuery? - datadice - Customized Data-Warehouse Solutions
Google is starting to add features from systems like MySQL. By Alexander Junke
❤1
Forwarded from Борис опять
# Что выгоднее: ChatGPT API или инференс модели на Huggingface?
ChatGPT берет $2 за 1 миллион токенов. Переведем во что-то понятное: задача саммаризации имейлов. Пусть один имейл это 400 токенов промпта и 200 токенов выхода. Тогда обработка 100 имейлов будет стоить всего $0.08.
Сколько стоит сделать то же самое на Huggingface? Вот как берет деньги Huggingface за Inference endpoints:
1. По запросу поднимается эндпоинт с моделью. Можно выбрать одну из конфигураций, где чем мощнее тем дороже. Варьируется от $0.6 до $45 в час для GPU.
2. Считается сколько часов был задействован эндпоинт. За каждый час начисляется плата. Насколько я понимаю считается количество часов округленное вверх. То есть поднял инстанс на минуту == должен денег за час. Эндпоинты нужно удалять самостоятельно, иначе они будут тихо проедать ваши деньги.
3. В конце месяца все затраты суммируются и списываются с карты.
100 имейлов точно можно обработать в течение часа. Если используется самый простой GPU эндпоинт (куда влезает маленькая Alpaca модель, так что это реалистично), то это будет стоить $0.6, что почти в 10 раз дороже, чем ChatGPT.
Однако расклад сильно меняется, если вам нужно обработать более 100 имейлов. Например, 10 000 имейлов будет стоить уже $8 при использовании ChatGPT. Если вы можете обработать столько же в течение часа используя Huggingface, то будет почти в 10 раз дешевле.
Я замерил: inference api huggingface обрабатывает типичный имейл примерно за 3 секунды. Можно обработать 1200 имейлов в час. Обработка этих имейлов с помощью ChatGPT стоит $0.96 против $0.6 за час Huggingface инстанса. Huggingface побеждает.
Вывод: скорее всего при постоянном потоке задач использование Huggingface дешевле, а при редких запросах однозначно побеждает ChatGPT.
ChatGPT берет $2 за 1 миллион токенов. Переведем во что-то понятное: задача саммаризации имейлов. Пусть один имейл это 400 токенов промпта и 200 токенов выхода. Тогда обработка 100 имейлов будет стоить всего $0.08.
Сколько стоит сделать то же самое на Huggingface? Вот как берет деньги Huggingface за Inference endpoints:
1. По запросу поднимается эндпоинт с моделью. Можно выбрать одну из конфигураций, где чем мощнее тем дороже. Варьируется от $0.6 до $45 в час для GPU.
2. Считается сколько часов был задействован эндпоинт. За каждый час начисляется плата. Насколько я понимаю считается количество часов округленное вверх. То есть поднял инстанс на минуту == должен денег за час. Эндпоинты нужно удалять самостоятельно, иначе они будут тихо проедать ваши деньги.
3. В конце месяца все затраты суммируются и списываются с карты.
100 имейлов точно можно обработать в течение часа. Если используется самый простой GPU эндпоинт (куда влезает маленькая Alpaca модель, так что это реалистично), то это будет стоить $0.6, что почти в 10 раз дороже, чем ChatGPT.
Однако расклад сильно меняется, если вам нужно обработать более 100 имейлов. Например, 10 000 имейлов будет стоить уже $8 при использовании ChatGPT. Если вы можете обработать столько же в течение часа используя Huggingface, то будет почти в 10 раз дешевле.
Я замерил: inference api huggingface обрабатывает типичный имейл примерно за 3 секунды. Можно обработать 1200 имейлов в час. Обработка этих имейлов с помощью ChatGPT стоит $0.96 против $0.6 за час Huggingface инстанса. Huggingface побеждает.
Вывод: скорее всего при постоянном потоке задач использование Huggingface дешевле, а при редких запросах однозначно побеждает ChatGPT.
❤1
#google
Вот вам и сандаль пичаль. Пичаль пичалью, а 6 лямов баксов на свою охрану (?) у компании выкружил. Бункеры строил, чтоль, по примеру? Гонку с OpenAI просрал, но свои сотни миллионов получить не забыл.
https://3dnews.ru/1085544/glava-vinugdennoy-sokrashchat-personal-google-v-proshlom-godu-zarabotal-226-mln
Вот вам и сандаль пичаль. Пичаль пичалью, а 6 лямов баксов на свою охрану (?) у компании выкружил. Бункеры строил, чтоль, по примеру? Гонку с OpenAI просрал, но свои сотни миллионов получить не забыл.
https://3dnews.ru/1085544/glava-vinugdennoy-sokrashchat-personal-google-v-proshlom-godu-zarabotal-226-mln
3DNews - Daily Digital Digest
Глава Google в прошлом году заработал $226 млн — в 800 раз больше среднестатистического сотрудника
Вызванный пандемией бум интернет-технологий сменился спадом ещё в прошлом году, поэтому многие активно наращивавшие численность персонала корпорации вынуждены сейчас её сокращать.
#gpt #jokes
Недавно была Пасха. Мы смотрели с друзьями обзор фильма "Чужой. Завет". Придумай шутку для этой ситации.
Конечно! Вот небольшая шутка про "Чужой. Завет" и Пасху:
Знаешь, что у этих пришельцев из "Чужого. Завета" общего с Пасхой?
Нет, что?
Оба случаются только раз в году и оставляют за собой много ошметков!
Недавно была Пасха. Мы смотрели с друзьями обзор фильма "Чужой. Завет". Придумай шутку для этой ситации.
Конечно! Вот небольшая шутка про "Чужой. Завет" и Пасху:
Знаешь, что у этих пришельцев из "Чужого. Завета" общего с Пасхой?
Нет, что?
Оба случаются только раз в году и оставляют за собой много ошметков!
#trading #tradingpolicy #backtesting #optimization
Итак, продолжаем с трейдингом. В соответствии с предыдущим постом, я определился с несложной стратегией, которая открывает позицию на ожидании роста или падения цены актива, и закрывает её по стоп-лоссу или тейк-профиту. Согласно плану, надо её потестировать на истории (у нас есть 1 месяц срочного рынка ММВБ) без ML, и, если получится не сильно убыточно, попробовать внедрить, чтобы набить шишек, набраться опыта, и т.д.
У неё 3 параметра:
order_offset: float,
takeprofit_size: float,
stoploss_size: float.
Первый связан с открытием позиции (насколько далеко от прошлой сделки мы будем считать цену высокой или низкой), 2 остальных - с закрытием (по прибыли и убытку). Параметры могут быть заданы в единицах цены или ценовой волатильности (не знаю, что лучше, 2-е кажется более универсальным). Есть ещё размер заявки и максимальный риск позиции, но их мы будем считать фиксированными.
Для выбранного дня и инструмента каждое сочетание параметров в теории даёт свой поток сделок и, соответственно, свой профиль прибыли/риска. Причём эмпирически видно, что для определённого сочетания параметров за период профиль может варьироваться от крайне убыточного до достаточно прибыльного, но за следующий период смениться на полностью противоположный, Как же оценить жизнеспособность торговой стратегии в таких условиях?
Видимо, надо проверять некую связность параметров на последовательных интервалах. Если "лучшие" или "хорошие" параметры по инструменту изменяются от часа к часу достаточно плавно, есть надежда, что, подбирая "лучшие на текущий момент" параметры брутфорсом и применяя их следующий, скажем, час, мы приземлимся не очень далеко от "истинных лучших параметров" за этот будущий час, и имеем шансы заработать. (На самом деле, ещё более продвинута идея прогнозирования лучших будущих параметров, её продвигают ДеПрадо и Чан.)
На данный момент у меня есть отлаженный питоновский код, который для набора параметров и куска рыночных данных (цен) генерирует сделки и считает итоговые результаты торгов: прибыль(ность), просадку, число сделок. В Нумбу конвертнуть его на удивление не получилось (обычно со скрипом, но получается).
Попробую проверить результаты следующего подхода: каждый час по каждому инструменту находим "лучшие" (в терминах прибыли, просадки, устойчивости) параметры с начала торгового дня до текущего момента, следующий час торгуем по ним. Под устойчивостью понимается тот факт, что небольшое изменение параметра не должно приводить к резкому изменению целевой функции. Для этого целевую функцию думаю оценивать не только в заданной точке M-мерного пространства параметров (в нашем случае M=3), но и в K ближайших (в смысле некоторой метрики, к примеру, эвклидовой) точках. Как оценку набора параметров можно брать отношение среднего (mean) целевой функции в этой и K ближайших точек к её вариации (std).
Как это можно реализовать:
1) сделать низкоуровневые черновые расчёты:
разбить все дни/инструменты на куски фиксированного размера, например, каждый 1 час, или каждые 10_000 сделок.
выбрать подлежащее проверке число сочетаний, например, P=1_000_000. Сгенерировать P случайных (но валидных) комбинаций параметров.
для каждого куска данных отправить на кластер задачи бэктеста всех этих P комбинаций для этого куска.
как результат, централизованно сохранить день, час, инструмент, параметры, итоговые метрики (прибыль, просадку, и тд)
2) провести, собственно, метабэктест:
каждый час находим, не забывая K точек окрестности, сочетание с лучшей оценкой (что лучше - за прошлый час или за весь день?), в качестве результата просто берём из базы уже известный кусок для этого сочетания и следующего часа. суммируем по всем дням и инструментам. тем самым и получим искомую оценку пригодности торговой стратегии.
Единственная проблема пока в том, что если открыта позиция на весь лимит риска, пока она не закроется, сделки в следующий период совершить будет нельзя, и расчёт теряет практический смысл. Но, наверное, это можно обойти большим депозитом и установкой "лимита на час".
Итак, продолжаем с трейдингом. В соответствии с предыдущим постом, я определился с несложной стратегией, которая открывает позицию на ожидании роста или падения цены актива, и закрывает её по стоп-лоссу или тейк-профиту. Согласно плану, надо её потестировать на истории (у нас есть 1 месяц срочного рынка ММВБ) без ML, и, если получится не сильно убыточно, попробовать внедрить, чтобы набить шишек, набраться опыта, и т.д.
У неё 3 параметра:
order_offset: float,
takeprofit_size: float,
stoploss_size: float.
Первый связан с открытием позиции (насколько далеко от прошлой сделки мы будем считать цену высокой или низкой), 2 остальных - с закрытием (по прибыли и убытку). Параметры могут быть заданы в единицах цены или ценовой волатильности (не знаю, что лучше, 2-е кажется более универсальным). Есть ещё размер заявки и максимальный риск позиции, но их мы будем считать фиксированными.
Для выбранного дня и инструмента каждое сочетание параметров в теории даёт свой поток сделок и, соответственно, свой профиль прибыли/риска. Причём эмпирически видно, что для определённого сочетания параметров за период профиль может варьироваться от крайне убыточного до достаточно прибыльного, но за следующий период смениться на полностью противоположный, Как же оценить жизнеспособность торговой стратегии в таких условиях?
Видимо, надо проверять некую связность параметров на последовательных интервалах. Если "лучшие" или "хорошие" параметры по инструменту изменяются от часа к часу достаточно плавно, есть надежда, что, подбирая "лучшие на текущий момент" параметры брутфорсом и применяя их следующий, скажем, час, мы приземлимся не очень далеко от "истинных лучших параметров" за этот будущий час, и имеем шансы заработать. (На самом деле, ещё более продвинута идея прогнозирования лучших будущих параметров, её продвигают ДеПрадо и Чан.)
На данный момент у меня есть отлаженный питоновский код, который для набора параметров и куска рыночных данных (цен) генерирует сделки и считает итоговые результаты торгов: прибыль(ность), просадку, число сделок. В Нумбу конвертнуть его на удивление не получилось (обычно со скрипом, но получается).
Попробую проверить результаты следующего подхода: каждый час по каждому инструменту находим "лучшие" (в терминах прибыли, просадки, устойчивости) параметры с начала торгового дня до текущего момента, следующий час торгуем по ним. Под устойчивостью понимается тот факт, что небольшое изменение параметра не должно приводить к резкому изменению целевой функции. Для этого целевую функцию думаю оценивать не только в заданной точке M-мерного пространства параметров (в нашем случае M=3), но и в K ближайших (в смысле некоторой метрики, к примеру, эвклидовой) точках. Как оценку набора параметров можно брать отношение среднего (mean) целевой функции в этой и K ближайших точек к её вариации (std).
Как это можно реализовать:
1) сделать низкоуровневые черновые расчёты:
разбить все дни/инструменты на куски фиксированного размера, например, каждый 1 час, или каждые 10_000 сделок.
выбрать подлежащее проверке число сочетаний, например, P=1_000_000. Сгенерировать P случайных (но валидных) комбинаций параметров.
для каждого куска данных отправить на кластер задачи бэктеста всех этих P комбинаций для этого куска.
как результат, централизованно сохранить день, час, инструмент, параметры, итоговые метрики (прибыль, просадку, и тд)
2) провести, собственно, метабэктест:
каждый час находим, не забывая K точек окрестности, сочетание с лучшей оценкой (что лучше - за прошлый час или за весь день?), в качестве результата просто берём из базы уже известный кусок для этого сочетания и следующего часа. суммируем по всем дням и инструментам. тем самым и получим искомую оценку пригодности торговой стратегии.
Единственная проблема пока в том, что если открыта позиция на весь лимит риска, пока она не закроется, сделки в следующий период совершить будет нельзя, и расчёт теряет практический смысл. Но, наверное, это можно обойти большим депозитом и установкой "лимита на час".
Telegram
Aspiring Data Science
#trading #tradingpolicy
По части 2, торговая политика, есть пока что только смутная идея простой стратегии. Если получится предсказывать движение актива, то разумным выглядит открытие минимальной позиции в сторону движения наибольшей вероятности (большей…
По части 2, торговая политика, есть пока что только смутная идея простой стратегии. Если получится предсказывать движение актива, то разумным выглядит открытие минимальной позиции в сторону движения наибольшей вероятности (большей…
#energy
"В момент избытка электрической энергии 24-т блоки подаются к лифтам и поднимаются на высоту. В США сооружение будет достигать в высоту 140 м, а в Китае — 120 м. Когда выработка электрической энергии падает, что актуально в случае солнечной и ветряной энергетики, блоки спускаются на лифтах вниз, раскручивая роторы генераторов и вырабатывая электричество. За время спуска блока размерами 3,5 × 2,7 × 1,3 м со скоростью 2 м/с вырабатывается примерно 1 МВт электричества с КПД более 80 %. Здания гравитационного аккумулятора можно строить не только вверх, но и вширь, таким образом наращивая ёмкость хранения энергии. Например, хотя китайский аккумулятор будет ниже строящегося в США, за счёт большей площади сооружения он может хранить до 100 МВт·ч электричества, тогда как американский — всего 36 МВт·ч."
https://3dnews.ru/1085622/shveytsarskaya-kompaniya-stroit-gigantskie-gravitatsionnie-akkumulyatori-odin-v-ssha-a-vtoroy-v-kitae
"В момент избытка электрической энергии 24-т блоки подаются к лифтам и поднимаются на высоту. В США сооружение будет достигать в высоту 140 м, а в Китае — 120 м. Когда выработка электрической энергии падает, что актуально в случае солнечной и ветряной энергетики, блоки спускаются на лифтах вниз, раскручивая роторы генераторов и вырабатывая электричество. За время спуска блока размерами 3,5 × 2,7 × 1,3 м со скоростью 2 м/с вырабатывается примерно 1 МВт электричества с КПД более 80 %. Здания гравитационного аккумулятора можно строить не только вверх, но и вширь, таким образом наращивая ёмкость хранения энергии. Например, хотя китайский аккумулятор будет ниже строящегося в США, за счёт большей площади сооружения он может хранить до 100 МВт·ч электричества, тогда как американский — всего 36 МВт·ч."
https://3dnews.ru/1085622/shveytsarskaya-kompaniya-stroit-gigantskie-gravitatsionnie-akkumulyatori-odin-v-ssha-a-vtoroy-v-kitae
3DNews - Daily Digital Digest
Швейцарская компания построит гигантские гравитационные аккумуляторы в США и Китае
Швейцарская компания Energy Vault к лету завершит строительство самых масштабных в мире площадок по аккумулированию электрической энергии в гравитационных системах.
Forwarded from Kali Novskaya (Tatiana Shavrina)
#nlp #про_nlp
"Во-первых, это красиво..."
Все постят этот восхитительный гайд по архитектурам LLM. Очень люблю такие майндмэпы — легко запомнить, систематизировать, использовать в лекциях
"Во-первых, это красиво..."
Все постят этот восхитительный гайд по архитектурам LLM. Очень люблю такие майндмэпы — легко запомнить, систематизировать, использовать в лекциях
❤1
#games
Забавная идея )
https://3dnews.ru/1085881/datskiy-internet-provayder-zapustil-servis-love-squad-on-pozvolyaet-nanyat-virtualnogo-killera-dlya-zaigravsheysya-vtoroy-polovinki
Забавная идея )
https://3dnews.ru/1085881/datskiy-internet-provayder-zapustil-servis-love-squad-on-pozvolyaet-nanyat-virtualnogo-killera-dlya-zaigravsheysya-vtoroy-polovinki
3DNews - Daily Digital Digest
Датский интернет-провайдер запустил сервис Love Squad — он позволяет нанять виртуального киллера для заигравшейся второй половинки
Вторая половинка проводит больше времени за онлайн-играми, чем с вами, и огонь в отношениях начинает угасать? В Дании нашли решение — сервис Love Squad необычным способом отобьёт у заядлого геймера желание садиться за компьютер.
#astronomy
"Рождение квазара ведёт к фатальным последствиям для галактики-хозяина. Его активность выталкивает пыль и газ за пределы галактики и развеивает внутри неё. Это снижает активность звезообразования и может совсем остановить процесс появления новых звёзд в галактике. Нашу галактику Млечный Путь ждёт похожая судьба. Примерно через 5 млрд лет она столкнётся с галактикой Андромеда. Учёные не считали это угрозой для жизни на Земле, например, всё-таки звёзды находятся достаточно далеко друг от друга, но если в центре нашей галактики вспыхнет квазар, для чего теперь найдены все основания, всё может повернуться иначе."
https://3dnews.ru/1085918/nasha-galaktika-mlechniy-put-imeet-vse-shansi-porodit-kvazar-chemu-polucheni-ubeditelnie-dokazatelstva
"Рождение квазара ведёт к фатальным последствиям для галактики-хозяина. Его активность выталкивает пыль и газ за пределы галактики и развеивает внутри неё. Это снижает активность звезообразования и может совсем остановить процесс появления новых звёзд в галактике. Нашу галактику Млечный Путь ждёт похожая судьба. Примерно через 5 млрд лет она столкнётся с галактикой Андромеда. Учёные не считали это угрозой для жизни на Земле, например, всё-таки звёзды находятся достаточно далеко друг от друга, но если в центре нашей галактики вспыхнет квазар, для чего теперь найдены все основания, всё может повернуться иначе."
https://3dnews.ru/1085918/nasha-galaktika-mlechniy-put-imeet-vse-shansi-porodit-kvazar-chemu-polucheni-ubeditelnie-dokazatelstva
3DNews - Daily Digital Digest
Наша галактика Млечный Путь имеет все шансы породить квазар, чему получены убедительные доказательства
Около 60 лет назад астрономы обнаружили ярчайшие объекты во Вселенной, которые назвали квазарами.
#cloudcomputing #dask #business #opticloud
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
Облачные вычисления с Dask требуют знания цен (особенно на спотовые инстансы), думаю начать регулярный сбор цен основных провайдеров (AWS, GCP, Azure) в базу. Возможно, в последующем сделаю какой-то сервис поиска лучшей площадки и инстансов для заданной нагрузки (с учётом прогнозной доступности и цены на заданную длительность вычислений). Например, клиент делает сабмит 1 блока своей задачи, сервис прогоняет его на нескольких инстансах, с помощью ML рассчитывает время выполнения на всех возможных инстансах всех облачных провайдеров (они же отличаются по железу). Согласно указанному клиентом объёму блоков в день, датам начала/завершения работ, система рассчитывает, в каких именно облаках и на каких конкретно инстансах нужно создавать кластер, чтобы минимизировать стоимость/время расчётов.
Производительность железа распадается на несколько блоков: CPU, GPU, RAM, Storage (HDD/SSD), Network.
Также у клиента могут быть задачи разного типа: ML Training, ML inference, Finance/Physics/Bio simulations, Video Encoding.
В голове крутится прогон подобных бенчмарков на каждом уникальном по соответствующему железу типу инстанса (например: модель процессора, тип и частота памяти, тип СХД, пропускная способность сети).
Тогда пользователь сервиса (в первом приближении) говорит: мне надо обучать sklearn-овскую модель. минимум памяти на ядро 8Гб, где сейчас это лучше сделать? Сервис отвечает: в AWS, регион us-west-2, зона 2b, инстанс такой-то, спот цена такая-то., индекс производительности такой-то. А если клиент указывает фреймворк tensorflow, в сравнении участвуют уже и GPU, TPU, Trainium инстансы, и получается другой ответ, к примеру, GCP, регион такой-то, TPU v3 spot, цена такая-то, индекс производительности такой-то.
В идеале можно будет свою задачу на минималках отправить на тестирование, и тогда уже система точно рассчитает производительность на каждом инстансе. Но для начала можно будет ориентироваться хотя бы на какие-то общие бенчмарки.
#saas #startup
Find unsolved problems, poor customer experience, land & expand, build on your network, ride a fast growing ecosystem, build on existing user base, find where do you spend your money on a day job.
https://www.youtube.com/watch?v=z_EMDtbB2tA
Find unsolved problems, poor customer experience, land & expand, build on your network, ride a fast growing ecosystem, build on existing user base, find where do you spend your money on a day job.
https://www.youtube.com/watch?v=z_EMDtbB2tA
YouTube
7 Proven Ways to Create Profitable SaaS Ideas EVERY Time
Creating profitable SaaS ideas can be a challenging task. These 7 proven ways to validate your SaaS ideas will help ensure your SaaS business will be successful! In this video I discuss 7 ways to create profitable SaaS ideas every time...
Watch more videos…
Watch more videos…
#python #hettingner #pep #codegems #refactoring #codewrappers
P vs NP ) And the gorilla in the room.
https://www.youtube.com/watch?v=wf-BqAjZb8M
P vs NP ) And the gorilla in the room.
https://www.youtube.com/watch?v=wf-BqAjZb8M
YouTube
Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
"Speaker: Raymond Hettinger
Distillation of knowledge gained from a decade of Python consulting, Python training, code reviews, and serving as a core developer. Learn to avoid some of the hazards of the PEP 8 style guide and learn what really matters for…
Distillation of knowledge gained from a decade of Python consulting, Python training, code reviews, and serving as a core developer. Learn to avoid some of the hazards of the PEP 8 style guide and learn what really matters for…
#opticloud
Итак, первый шаг к сервису поиска оптимального облака под коротко- и среднесрочные расчёты сделан. Пока только для AWS, начат сбор спотовых цен на EC2 с высокой гранулярностью и для всех 27 публичных регионов. Уже, кстати, видно, что некоторые регионы проводят активное ценообразование, другие же спотовые цены почти не меняют. Сегодня добавляю сбор цен ondemand и заполнение таблицы "железных" характеристик инстансов. В будущем эта информация дополнится унифицированными листингами железа, снятыми непосредственно агентом внутри ВМ, и целым набором бенчмарков из разных областей. В течение недели поиск TOP N регионов/инстансов по соотношению производительность/цена на 1 vCore/Гб RAM/Тб HDD станет доступен в виде платного API.
Ещё планируются:
1) включение GCP и Azure
2) на более дорогом уровне: выдача не просто инстансов оптимальных СЕЙЧАС, а (с помощью ML) оптимальных в течение времени, нужного клиенту для вычислений. Например, банк проводит вычисления длительностью в 3 часа в 15-00 каждый день, где ему лучше запускаться сегодня, чтобы суммарная ожидаемая стоимость была минимальной? А завтра?
О ценообразовании:
Логичным кажется получение % от экономии, достигнутой с помощью сервиса, на какой-то стандартной нагрузке. Скажем, под фильтр клиента попадают N валидных комбинаций инстансов/регионов/зон. Тогда экономия составит mean(SportPrices(N))-min(SportPrices(N)) на инстанс в час.
Итак, первый шаг к сервису поиска оптимального облака под коротко- и среднесрочные расчёты сделан. Пока только для AWS, начат сбор спотовых цен на EC2 с высокой гранулярностью и для всех 27 публичных регионов. Уже, кстати, видно, что некоторые регионы проводят активное ценообразование, другие же спотовые цены почти не меняют. Сегодня добавляю сбор цен ondemand и заполнение таблицы "железных" характеристик инстансов. В будущем эта информация дополнится унифицированными листингами железа, снятыми непосредственно агентом внутри ВМ, и целым набором бенчмарков из разных областей. В течение недели поиск TOP N регионов/инстансов по соотношению производительность/цена на 1 vCore/Гб RAM/Тб HDD станет доступен в виде платного API.
Ещё планируются:
1) включение GCP и Azure
2) на более дорогом уровне: выдача не просто инстансов оптимальных СЕЙЧАС, а (с помощью ML) оптимальных в течение времени, нужного клиенту для вычислений. Например, банк проводит вычисления длительностью в 3 часа в 15-00 каждый день, где ему лучше запускаться сегодня, чтобы суммарная ожидаемая стоимость была минимальной? А завтра?
О ценообразовании:
Логичным кажется получение % от экономии, достигнутой с помощью сервиса, на какой-то стандартной нагрузке. Скажем, под фильтр клиента попадают N валидных комбинаций инстансов/регионов/зон. Тогда экономия составит mean(SportPrices(N))-min(SportPrices(N)) на инстанс в час.
👍2