LLM
Инструменты для вайбкода очень хороши для генерации манифестов.
Гитхаб заполнен примерами хороших манифестов, на которых модельки и обучались. А если еще скормить свой эталонный манифест то модель легко сгенерит то что ты хочешь.
Вчера этим и заинмался. Есть три репозитория, с разными компонентами система - бек, фронт, бот. И мне нужно было по сути разово их установить. Склонировал все три репы в одну директорию, открыл в курсоре ее и попросил набросать чарт. Потом просто заполнил вельюс с нужными переменками и образами и установил его в кластер. Ну и немного подебажил. Профит.
А вот года два назад мне понадобилось бы часа 2-3 что бы набросать этот чарт, что бы дойти до установки и дебага.
Инструменты для вайбкода очень хороши для генерации манифестов.
Гитхаб заполнен примерами хороших манифестов, на которых модельки и обучались. А если еще скормить свой эталонный манифест то модель легко сгенерит то что ты хочешь.
Вчера этим и заинмался. Есть три репозитория, с разными компонентами система - бек, фронт, бот. И мне нужно было по сути разово их установить. Склонировал все три репы в одну директорию, открыл в курсоре ее и попросил набросать чарт. Потом просто заполнил вельюс с нужными переменками и образами и установил его в кластер. Ну и немного подебажил. Профит.
А вот года два назад мне понадобилось бы часа 2-3 что бы набросать этот чарт, что бы дойти до установки и дебага.
👍2
RULES
Есть любители все усложнять. Например сделать флоу пайплайна из десятков стро рулзов.
Из разряда "если запуск с кнопки в вебе и на определенной ветке но нужно добавить эту переменную, иначе ничего не заработает".
Иногда, канеш, в этом прослеживается капелька логики. Но чаще все можно заменить несколькими only, except и env окружениями. И это даст сильно более прозрачный и читаемы процесс.
Есть любители все усложнять. Например сделать флоу пайплайна из десятков стро рулзов.
Из разряда "если запуск с кнопки в вебе и на определенной ветке но нужно добавить эту переменную, иначе ничего не заработает".
Иногда, канеш, в этом прослеживается капелька логики. Но чаще все можно заменить несколькими only, except и env окружениями. И это даст сильно более прозрачный и читаемы процесс.
👍1
PVC
Как в современных клаудах работают вольюмы в кубе:
- Запрос на создание pvc в апи куба
- Запрос на создание сетевого топа в клауде от куба
- Поднятие пода которому нужен pvc
- Создание сетевого тома
- Маунт тома к ноде кластера
- Маунт директории пода к этому тому
Профит, мы можем сохранять данные из нашего пода в клаудном томе)
Как в современных клаудах работают вольюмы в кубе:
- Запрос на создание pvc в апи куба
- Запрос на создание сетевого топа в клауде от куба
- Поднятие пода которому нужен pvc
- Создание сетевого тома
- Маунт тома к ноде кластера
- Маунт директории пода к этому тому
Профит, мы можем сохранять данные из нашего пода в клаудном томе)
👍1
FLOW
Сегодня немного погрумили релизный флоу разработки.
Пришли к чему то близкому к gitlab flow:
- main ветка как основная dev версия
- c main ветки катимся на dev стенд
- фича ветки берутся от main
- с main уходит релизную ветку
- с релизной ветки катим stage
- вливаем релизную ветку в prod ветку
- с prod ветки катимся в прод
- гасим релизную ветку
Главный принцип: минимум веток которые живут больше нескольких дней.
Да, выглядит замудренно, но если уложить это в голову то становится понятно и удобно)
Сегодня немного погрумили релизный флоу разработки.
Пришли к чему то близкому к gitlab flow:
- main ветка как основная dev версия
- c main ветки катимся на dev стенд
- фича ветки берутся от main
- с main уходит релизную ветку
- с релизной ветки катим stage
- вливаем релизную ветку в prod ветку
- с prod ветки катимся в прод
- гасим релизную ветку
Главный принцип: минимум веток которые живут больше нескольких дней.
Да, выглядит замудренно, но если уложить это в голову то становится понятно и удобно)
👍1
OS
Операционная система это по сути набор софта.
В юникс мире есть четкое разделение на ядро и дистрибутив, и под операционными системами подразумивается как раз дистрибутив.
Что в него входит?
- Загрузчик, который поднимает ядро при старте
- Инит система, какой ни будь systemd который запускает окружение на ядре
- Файловая система, инструменты по работе с диском
- DE, который поднимается инит системой
- Предустановленный пользовательский софт
И под эту картину подпадают очень разные системы, от линукса и макоси, заканчивая андроидом и авесом. Глобально тут только винда придумывает свой путь, отсюда и такое отличие в логике взаимодействия.
Операционная система это по сути набор софта.
В юникс мире есть четкое разделение на ядро и дистрибутив, и под операционными системами подразумивается как раз дистрибутив.
Что в него входит?
- Загрузчик, который поднимает ядро при старте
- Инит система, какой ни будь systemd который запускает окружение на ядре
- Файловая система, инструменты по работе с диском
- DE, который поднимается инит системой
- Предустановленный пользовательский софт
И под эту картину подпадают очень разные системы, от линукса и макоси, заканчивая андроидом и авесом. Глобально тут только винда придумывает свой путь, отсюда и такое отличие в логике взаимодействия.
👍1
CHIP
В современном железе часто есть сопроцесооры, например чипы безопасности.
Как система и софт с ними работают:
- Драйвер включатется в ядро
- В системе появлятеся апи для обращения в него
- По необходимости софт делает вызов этого апи
- Через драйвер запрос отправляется на чип и обрабатывается
- И в обратную сторону отдает ответ софту
Чип так же может обращаться в свою изолированную память, и просто отдавать True/False, например для авторизации для биометрии.
Плюс минус классическая клиент серверная архитектура, только на более низком уровне)
В современном железе часто есть сопроцесооры, например чипы безопасности.
Как система и софт с ними работают:
- Драйвер включатется в ядро
- В системе появлятеся апи для обращения в него
- По необходимости софт делает вызов этого апи
- Через драйвер запрос отправляется на чип и обрабатывается
- И в обратную сторону отдает ответ софту
Чип так же может обращаться в свою изолированную память, и просто отдавать True/False, например для авторизации для биометрии.
Плюс минус классическая клиент серверная архитектура, только на более низком уровне)
👍1
ASIC
Асики, по сути, это специализированные чипы, где на самом кремние выжжены алгоритмы обработки.
Это больше асоциируется с майнерами, так как массово такие чипы были как раз для майнинга крипты. По сути чипы которые умеют только обрабатывать хеши, но делать это очень быстро.
Но сейчас такие чипы становсят все более разнообразными. Например сопроцессоры безопасности, которые используют асики для шифрования. Или, в огромных корпорациях, есть сервера с асиками которые занимются только сжатием.
Зачем оно надо? Ради скорости. Потому что обычные процы могут все, но используют для этого стандартные транзисторы и команды, что по дефолту менее эффективно чем специалированные архитектуры.
Асики, по сути, это специализированные чипы, где на самом кремние выжжены алгоритмы обработки.
Это больше асоциируется с майнерами, так как массово такие чипы были как раз для майнинга крипты. По сути чипы которые умеют только обрабатывать хеши, но делать это очень быстро.
Но сейчас такие чипы становсят все более разнообразными. Например сопроцессоры безопасности, которые используют асики для шифрования. Или, в огромных корпорациях, есть сервера с асиками которые занимются только сжатием.
Зачем оно надо? Ради скорости. Потому что обычные процы могут все, но используют для этого стандартные транзисторы и команды, что по дефолту менее эффективно чем специалированные архитектуры.
👍1
CPU
Один такт это не всегда одна операция.
В ядре процессора есть множество блоков, и каждый блок в нескольких экземплярах. Основные логические вычисления происходят на арифметико логическом устройстве, которых в ядре может быть несколько штук. И при падаче напряжение на такт они все могут отрабатывать паралельно.
Это еще зависит от нашего алгоритма. Если он жестко последовательный и одна операция может пройти строго после другой то никакой паралельности не будет. Но чаще всего планировшик ядра может хотя бы минимально разбить задачу на несколько независимых операций и выполнить их за один такт на разных блоках.
Небльшой оффтоп. Тут nvidia и шмайкрасофт выпустили новые arm процы и винду оптимизированную под него. Очень жду осени что бы посмотреть что получилось)
Один такт это не всегда одна операция.
В ядре процессора есть множество блоков, и каждый блок в нескольких экземплярах. Основные логические вычисления происходят на арифметико логическом устройстве, которых в ядре может быть несколько штук. И при падаче напряжение на такт они все могут отрабатывать паралельно.
Это еще зависит от нашего алгоритма. Если он жестко последовательный и одна операция может пройти строго после другой то никакой паралельности не будет. Но чаще всего планировшик ядра может хотя бы минимально разбить задачу на несколько независимых операций и выполнить их за один такт на разных блоках.
Небльшой оффтоп. Тут nvidia и шмайкрасофт выпустили новые arm процы и винду оптимизированную под него. Очень жду осени что бы посмотреть что получилось)
👍1
SOC
Системы на чипе очень неплохо подходят для локальных маделей.
Прикол в том что основные вычесления там проходят на GPU ядрах, и когда этим ядрам доступна общая RAM всего чипа то это сильно повышает доступный размер моделей. Если брать стандартные GPU которые стоят не миллионы рублей то больше чем 24гб памяти сложно найти. И поднять там модель на 120 миллиардов параметров там не выйдет.
А вот современные M процы от эпла, и новые чипы от nvidia решают эту проблему. Там на одном чипе спокойно может быть хоть 128гб памяти, и можно поместить довольно большие модели.
Системы на чипе очень неплохо подходят для локальных маделей.
Прикол в том что основные вычесления там проходят на GPU ядрах, и когда этим ядрам доступна общая RAM всего чипа то это сильно повышает доступный размер моделей. Если брать стандартные GPU которые стоят не миллионы рублей то больше чем 24гб памяти сложно найти. И поднять там модель на 120 миллиардов параметров там не выйдет.
А вот современные M процы от эпла, и новые чипы от nvidia решают эту проблему. Там на одном чипе спокойно может быть хоть 128гб памяти, и можно поместить довольно большие модели.
👍1
FRONT
Одна из сложностей в фронтенде это енв.
Часто переменки с настройками можно задать только при билде. И если нам нужно, например, изменить бекенд урл то обычно приходится пересобирать весь фронт.
Это можно обойти. Например указать в entrypoint разные скрипты которые при старте будут подбирать енв и заменять значения во всей статики. Но это очень больно и костыльно.
Одна из сложностей в фронтенде это енв.
Часто переменки с настройками можно задать только при билде. И если нам нужно, например, изменить бекенд урл то обычно приходится пересобирать весь фронт.
Это можно обойти. Например указать в entrypoint разные скрипты которые при старте будут подбирать енв и заменять значения во всей статики. Но это очень больно и костыльно.
👍1
FLOW
Флоу разработки не говорит нам как и когда релизить.
Гит флоу, транк, гитлаб флоу и что угодно это по сути способ доставки изменений до прод вети или тега. В теории мы можем использовать любой флоу только с одним прод стендом и все. Ведь они не заставляют деплоить что либо.
Мы можем взять любой флоу и положить на него любой способ релизов и любые дев/тест стенды. Главное что бы было просто удобно)
Флоу разработки не говорит нам как и когда релизить.
Гит флоу, транк, гитлаб флоу и что угодно это по сути способ доставки изменений до прод вети или тега. В теории мы можем использовать любой флоу только с одним прод стендом и все. Ведь они не заставляют деплоить что либо.
Мы можем взять любой флоу и положить на него любой способ релизов и любые дев/тест стенды. Главное что бы было просто удобно)
👍1
ENV
Цепочка доступа до переменных.
Как переменка из хранилища доходит до приложения на стенде в классическом случае:
- Переменка лежит в ci системе или вольте
- При деплое она подставляется в манифест
- Прокидывается в окружение контейнера
- Приложение подтягивает ее из окружения
Все это точки доступа для компромитации, слишком много мест где нужно строго контролировать доступ.
Пока самое сесурити решение:
- Переменная в вольте рядом с приложением
- Доступ к нему только у одного человека
- Приложение при старте само обращается к вольту и подбирает переменные
- Только приложение по фингерпринту моджет прочесть переменки
Это сильно уменьшает поверхность атаки.
Цепочка доступа до переменных.
Как переменка из хранилища доходит до приложения на стенде в классическом случае:
- Переменка лежит в ci системе или вольте
- При деплое она подставляется в манифест
- Прокидывается в окружение контейнера
- Приложение подтягивает ее из окружения
Все это точки доступа для компромитации, слишком много мест где нужно строго контролировать доступ.
Пока самое сесурити решение:
- Переменная в вольте рядом с приложением
- Доступ к нему только у одного человека
- Приложение при старте само обращается к вольту и подбирает переменные
- Только приложение по фингерпринту моджет прочесть переменки
Это сильно уменьшает поверхность атаки.
👍1
Ну как уж не поделится работами фотограграфов которые пылятся у меня в скринах)
FAST
Допустим у нас есть средненький сайт, с фронтом, бекендом и базой данных. Ничего супер сложного, с нагрузкой до 1000 рпс.
На этом этапе, если не предвидится сильной нагрузки, нет смысла прям сильно усложнять инфру: добавлять кубер, кластеры баз, nosql базы и тд.
Но есть смысл чуть подтюнить текущую инфру:
- Сделать несколько реплик приложения даже в рамках одного сервера, и паралелить запросы
- Добавить кеш статики на nginx
- Проанализировать запросы к бд и навесить индексы
- Настроить сжатие на nginx
- Кеширование на клиенте
Это поможет сильно ускорить работу сайта и снизить нагрузку. И не придется усложнять себе жизнь с кубом и всей остальной сложной инфрой)
Допустим у нас есть средненький сайт, с фронтом, бекендом и базой данных. Ничего супер сложного, с нагрузкой до 1000 рпс.
На этом этапе, если не предвидится сильной нагрузки, нет смысла прям сильно усложнять инфру: добавлять кубер, кластеры баз, nosql базы и тд.
Но есть смысл чуть подтюнить текущую инфру:
- Сделать несколько реплик приложения даже в рамках одного сервера, и паралелить запросы
- Добавить кеш статики на nginx
- Проанализировать запросы к бд и навесить индексы
- Настроить сжатие на nginx
- Кеширование на клиенте
Это поможет сильно ускорить работу сайта и снизить нагрузку. И не придется усложнять себе жизнь с кубом и всей остальной сложной инфрой)
👍1
ARM
Сейчас есть тенденция оценивать датацентры не с точки зрения мощности и цены, а с точки зрения потребления энергии.
С современным нейросетями и облачными вычеслениями потребление датацентров ушло далеко за сотни мегават. А в перспективе перешагнет за гигават.
Это большая проблема. Во первых, эту энергию нужно откуда то брать. Во вторых, она почти полностью переходит в тепло которое нужно отводить.
И да, хоть бОльшую часть энергии будут потреблять GPU, ну и CPU все еще потребляет много энергии. Поэтому снижение расхода хотя бы на несколько процентов уже сильно снизит расходы на масштабе.
Тут на сцену выходит ARM архетектура чипов. В большенстве задач она дают такую же производительность на меншей потребляемой мощности. Это позволит датацентрам снизить расходы на миллионы долларов на энергии и охлаждении)
Сейчас есть тенденция оценивать датацентры не с точки зрения мощности и цены, а с точки зрения потребления энергии.
С современным нейросетями и облачными вычеслениями потребление датацентров ушло далеко за сотни мегават. А в перспективе перешагнет за гигават.
Это большая проблема. Во первых, эту энергию нужно откуда то брать. Во вторых, она почти полностью переходит в тепло которое нужно отводить.
И да, хоть бОльшую часть энергии будут потреблять GPU, ну и CPU все еще потребляет много энергии. Поэтому снижение расхода хотя бы на несколько процентов уже сильно снизит расходы на масштабе.
Тут на сцену выходит ARM архетектура чипов. В большенстве задач она дают такую же производительность на меншей потребляемой мощности. Это позволит датацентрам снизить расходы на миллионы долларов на энергии и охлаждении)
👍2