LINUX.ORG.RU

Anthropic использует Nix в продакшене!

 , ,


0

1

Anthropic уменьшил время запуска продакшена с минут до субсекунд с помощью многоуровневой иерархии репликации кэша. nix-sidecar — инструмент для замены Docker, заменяющий медленные извлечения образов высокопараллельными нативными загрузками Nix, кэшируемыми на каждом узле.

Предыстория такова: Anthropic довел модель контейнеров до предела, используя в производстве образы размером 25 ГБ и более. Команда постоянно сталкивались с неизбежными узкими местами в рабочих процессах контейнеров: задержками последовательных извлечений, накладными расходами на развертывание больших контейнерных артефактов и т. д.

Поэтому они приняли решение полностью перейти на Nix, создав специальный инструмент под названием nix-sidecar, который взял на себя роль Docker в их рабочем процессе.

Теперь Anthropic полагается на Nix для определения, построения и распространения своих сред выполнения в виде замыканий, при этом nix-sidecar извлекает необходимые пути хранения непосредственно из многоуровневой иерархии реплицированного бинарного кэша. Это позволяет полностью избежать узких мест, присущих извлечению и распаковке больших контейнерных образов.

Anthropic по-прежнему полагается на Kubernetes для оркестрации производственных рабочих нагрузок, но использует nix-sidecar для предоставления необходимых закрытий непосредственно на узлах Kubernetes, чтобы их можно было смонтировать в поды или получить к ним доступ. Другими словами, вместо того, чтобы полагаться на среду выполнения контейнеров (такую как Docker или containerd) для извлечения и распаковки образа, рабочие нагрузки внутри поды выполняются с использованием закрытий, предоставленных nix-sidecar.

Источники: https://www.socallinuxexpo.org/scale/22x/presentations/docker-was-too-slow-so-we-replaced-it-nix-production/

https://flox.dev/blog/gonna-be-at-scale-22x-beam-onto-planet-nix/

P.S. перевел через DeepL, ибо вручную лень.

★★★

Последнее исправление: the_real_kinik (всего исправлений: 3)

используя в производстве образы размером 25 ГБ и более.

Эту фразу лучше было перевести как «т.к. они идиоты»

Что в итоге наколхозили, тоже непонятно. Зато nixos %)

router ★★★★★
()

Так много букв, но ни слова о том, кто или что такое Anthropic…

Сэкономлю время на гугление остальным, кто так же не в курсе, ибо сам загуглил:

Американская технологическая компания в сфере искусственного интеллекта (ИИ), основанная бывшими сотрудниками OpenAI. Создатель семейства больших языковых моделей под общим названием Claude.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)

Nix

Насколько оно вообще стабильное? Там есть какие-то релизы или так же как в Раче: пердолингом и молитвами поддерживается система?

MoldAndLimeHoney ★★
()
Ответ на: комментарий от MoldAndLimeHoney

Если я понял, все немного проще

Раньше они пихали в свои контейнеры вообще все (не понимали разницу между контейнером и виртуалкой). Потом догадались выкинуть преферанс и поэтесс в sidecar контейнер

router ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

Релизы есть, примерно раз в шесть месяцев выходят, в мае и ноябре, насчёт сроков поддержки не знаю. Но в случае каких-то сложных проблем разбираться даже хуже, чем с арчем, т. к. тут non-FHS и куча местечковых костылей поверх линуксовых.

SeTSeR
()

А для чего кричать? Типа, компания, проектирующая электронных болванов - это вершина достижений цивилизации?

По поводу Nix: сам я не пробовал, но много лет наблюдаю за людьми, использующими Nix. Начальный энтузиазм через несколько лет проходит, и все рано или поздно уходят, т.к. работа в Nix требует много нетривиальных движений руками.

Хотя сам подход мне интересен, хочу его попробовать, но руки всё никак не дойдут…

Как раз для сборки контйенеров он мне кажется гораздо более перспективным, удобным и эффективным, нежели императивный подход с Dockerfile.

Chiffchaff
()
Ответ на: комментарий от MoldAndLimeHoney

так же как в Раче: пердолингом и молитвами поддерживается система

4.2, в Раче достаточно одних молитв.

thesis ★★★★★
()
Ответ на: комментарий от user_undefined

А можете объяснить отчего так? Обычно образ содержит нужные библиотеки, чтобы процесс мог запуститься. А конфиги, секреты, данные для работы уже подключаются к контейнеру из внешних источников. Отчего у нейронок делают по другому?

ugoday ★★★★★
()
Ответ на: комментарий от cobold

а вот хз, у ребят свой выделенный кластер которым они занимаются, видимо им норм. я просто вижу дикого размера образы в локальном регистри, когда пошел спрашивать нафига сказали про в том числе жирный пайторч

user_undefined ★★
()
Ответ на: комментарий от router

не понимали разницу между контейнером и виртуалкой

Есть ещё вариант что всю эту контейнерную агитацию они читали, но решили послать её нафиг и сделать так как удобнее.

А тему надо в толксы.

firkax ★★★★★
()
Ответ на: комментарий от firkax

контейнерную агитацию они читали,

… но ничего не поняли :)

но решили послать её нафиг и сделать так как удобнее.

не, судя по топику, они как раз собрали контейнер. Но запихали в него вообще все, что захотели

router ★★★★★
()
Ответ на: комментарий от ugoday

к сожалению не скажу, я не сильно погружен их процесс. Ну тот же торч как раз и относится к нужным библиотекам, знаю наши еще что-то кладут, что по их словам не получилось нормально брать из s3. Я не говорю что это нормально и нельзя сделать иначе, но видел уже в разных компаниях, возможно какие-то причины есть

user_undefined ★★
()
Ответ на: комментарий от Chiffchaff

А для чего кричать? Типа, компания, проектирующая электронных болванов - это вершина достижений цивилизации?

Типа это настоящий хайлоад.

Как раз для сборки контйенеров он мне кажется гораздо более перспективным, удобным и эффективным, нежели императивный подход с Dockerfile.

Тоже хочется попробовать, но пока некогда.

the_real_kinik ★★★
() автор топика

Прикольно. Но для подавляющего большинства проектов нет нужды выкатывать 25-гигабайтные образы за доли секунды, так что такой опыт интересен немногим.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

для нормального софта они вообще не нужны. и ничего не надо «выкатывать».

сначала создали грабли, теперь их оптимизируют - вся суть современного говнософта.

Iron_Bug ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

По ощущениям один из самых стабильных дистров, если не самый стабильный вообще. На своих локалхостах обновляюсь ежедневно в автоматическом режиме уже несколько лет, брат жив. Т.к. всё версионируется, в случае поломки за минуту можно дефектный софт откатить назад, или наоборот, взять из анстейбла, но такое приходится делать очень редко.

Gary ★★★★★
()
Ответ на: комментарий от user_undefined

когда там один pytorch будет занимать по 10 гигов

Да не весит столько пайторч.

James_Holden ★★★★★
()
Ответ на: комментарий от Gary

На своих локалхостах обновляюсь ежедневно в автоматическом режиме

В случае того же Арча проблемы появлялись, если долго не обновляться, а потом обновиться.

Bad_ptr ★★★★★
()
Ответ на: комментарий от Gary

… можно дефектный софт откатить назад …

Появился какой-то удобный способ это сделать, не откатывая всю систему целиком?

altwazar ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

Насколько оно вообще стабильное? Там есть какие-то релизы или так же как в Раче: пердолингом и молитвами поддерживается система?

Ты тут перый день? Годами мистер @t184256 проповедовал nix с остервенением фанатика.

mamina_radost
()
Ответ на: комментарий от MoldAndLimeHoney

Насколько оно вообще стабильное? Там есть какие-то релизы или так же как в Раче: пердолингом и молитвами поддерживается система?

Есть обычные релизы и роллинг, со всеми вытекающими.

Но надо понимать одно принципиальное отличие никса от привычных линукс дистрибутивов. Nix предлагает декларативно определять состояние пакетов в системе и их настроек, а достигается это за счет создания конфига файла-функции на функциональном языке программирования, и вызов этой функции готовит тебе окружение.

Это создаёт ситуацию, когда в Nix можно довольно точно повторить состав пакетов и /etc для конкретной версии никса/среза пакетов. Что практически невозможно сделать с классическими дистрибутивами. Но в плане использования системы как роллинг дистрибутива эта прослойка в виде применения конфиг-функции - дополнительная переменная, которая создаёт еще одну непредсказуемость при обновлении.

Так же подход никс хорошо сочетается с подходом кубернетес/контейнеров, когда стейт (состояние) системы определяется при её запуске. Но вот менять что-то налету становится сложнее и опаснее, чем в классических линукс дистрибутивах.

Например, хочешь ты подключить своп в файле. В классическом дистрибутиве это простая и безопасная операция:

  1. Создал файл любым удобным методом, хоть через dd.

  2. Сказал что это своп, сделал swapon.

  3. Добавил в /etc/fstab.

В никсе ты говоришь, что у тебя должен быть такой то своп файл и применяешь конфигурацию. А прослойка должна сама определить и проделать необходимые действия. И вся система может встать комом (было дело).

Или аналогично при добавлении диска. В классическом дистрибутиве ты создал раздел, отформатировал, прописал в fstab, сделал mount по пути и убедился что всё правильно. Если допустил ошибку в fstab, то ничего страшного, mount ругнётся и поправишь. В никсе у тебя в дело вступает прослойка и простая опечатка может нагнуть рабочую систему.

Поэтому «стабильность» зависит от твоих ожиданий и методов использования. Никс направлен на встроенную в концепт ос возможность повторить состояние системы и держать пакеты для нескольких состояний на диске одновременно. Но жертвует удобством и предсказуемостью в других местах.

altwazar ★★★★★
()
Ответ на: комментарий от altwazar

Появился какой-то удобный способ это сделать, не откатывая всю систему целиком?

Зависит от того что считать удобным способом, вообще это делается прописыванием ещё одного nixpkgs, или через channels или через inputs. В nix нет понятия версий пакетов, что немного усложняет восприятие проблемы.

Gary ★★★★★
()
Ответ на: комментарий от altwazar

Было б интересно почитать про баги с «нагибанием рабочей системы», ну и если система пришла совсем в негодность, это лечится обычной перезагрузкой и выбором прошлой версии, хотя по идее если rebuild не отработал то и сломанная система не должна добавиться в загрузчик.

Gary ★★★★★
()
Ответ на: комментарий от Gary

Было б интересно почитать про баги с «нагибанием рабочей системы»

Ну, например. Надо было подключить диск и в названии fs я перепутал местами два символа. При переключении конфигурации графический сеанс был убит и выкинуло в консоль с нерабочей системой.

… лечится обычной перезагрузкой …

Вот про это я и пишу. Концепт никса хорошо сочетается с загрузкой нужного окружения в духе кубера с контейнерами. Но в случае с классическими серверами и десктопами есть потребность менять состояние на лету и основные риски связаны именно с процессом изменения этого состояния. Не потерять управление, обеспечить непрерывность работы сервиса при изменениях, чтобы рабочее пользовательское приложение не закрылось и т.п. Вот тут подход nix-ос работает отвратительно, простейшие и безопасные вещи превращаются в неудобную русскую рулетку.

altwazar ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.