Transcription
[музыка] ИИ стремительно развивается, выполняя повторяющиеся и рутинные задачи быстрее, чем когда-либо. При правильном использовании он способен значительно повысить вашу продуктивность. Он способен с молниеносной скоростью создавать конвейеры Terraform, манифесты Kubernetes, файлы Docker и многое другое. Поскольку ландшафт ИИ развивается так быстро, важно, чтобы инженеры DevOps S и платформенные инженеры оставались впереди. ИИ повлияет на ваш повседневный рабочий процесс. Будь то ваши конвейеры развертывания, люди, желающие развернуть компоненты ИИ, такие как модели и серверы MCP, ваша инфраструктура, хостинг таких вещей, как модели, агенты и серверы MCP, безопасность, поскольку ИИ неизбежно расширит поверхность атаки ваших платформ. Есть больше вещей, которые нужно обезопасить, или будь то производительность. В среде микросервисов или монолитов, где вы имеете дело с большим количеством запросов в секунду, ИИ естественным образом замедлит работу, а также увеличит расходы. ИИ довольно дорог. Это идеальная возможность для облачных провайдеров выставить вам больше счетов. Вот почему сегодня мы рассмотрим важные термины ИИ для инженеров DevOps S и платформенных инженеров. наиболее влиятельные термины, что они все означают, и это поможет вам начать ваш путь с ИИ и направить ваше внимание на то, как ИИ будет применяться к DevOps, S и инжинирингу платформ, когда дело доходит до облака, CI/CD и инфраструктуры. Но сначала большинство из вас не подписаны. Так что, если вам понравилось видео, обязательно нажмите кнопку подписки. И без дальнейших церемоний, давайте начнем. [музыка] Теперь первое, что важно узнать, это модель, также известная как большая языковая модель или LLM. Я бы хотел думать о большой языковой модели как о массивной многомерной базе данных только для чтения. [музыка] Она содержит статическое представление информации. Важным компонентом или аспектом LLM являются ее веса. Веса моделей ИИ — это числовые параметры в нейронной сети, которые определяют силу связей между нейронами, действуя как знания или память, полученные во время обучения. Теперь модель среднего размера может иметь около 7 миллиардов параметров. Массивная большая языковая модель может иметь около 80 миллиардов параметров. Вы увидите количество параметров иногда в названии модели, например 8B, что означает 8 миллиардов параметров. Это очень важно, когда вы пытаетесь разместить модель локально, потому что вам потребуется такое количество дискового пространства. Теперь больший вес модели не обязательно означает, что она лучше или точнее для конкретных задач. Маленькая хорошо обученная модель может быть намного точнее, чем массивная плохо обученная модель. Большая модель также не обязательно более правдива, так как галлюцинации могут возникать чаще. Теперь, как инженер, который может захотеть разместить эти модели, важно понимать, что этим моделям требуется оборудование, такое как VRAM, ЦП или дисковое пространство. VRAM часто требует графических процессоров, таких как видеокарты, для функционирования. VRAM — это специализированное оборудование, такое как видеокарта или графический процессор. Так что, если вам нужна виртуальная машина в облаке, контейнер Docker или кластер Kubernetes, вам понадобится такое оборудование для размещения моделей. Также важно знать, что контейнеризация, такая как Docker, действительно полезна, потому что вы можете запускать эти модели в контейнерах. Существуют технологии, такие как OALMA, которые помогают вам это сделать. И с помощью команды Docker run просто запустить эти модели в контейнерах. Это означает, что вы можете запускать их в облаке, в Kubernetes, на собственной инфраструктуре. Если вы обратите внимание на эту команду docker run, вы увидите, что я монтирую GPU в контейнер. Вам нужно предоставить правильные устройства. Это связано с тем, что этим моделям потребуются такие вещи, как GPU, а также том. Так что думайте об этом как о stateful set в Kubernetes. Вот почему изучение таких вещей, как контейнеризация и Kubernetes, очень важно для инженеров DevOps S и платформенных инженеров и играет роль в ИИ. Итак, что я могу сделать, это сказать docker run и смонтировать GPU в контейнер, указать порт для доступа к моим моделям, и я могу запустить lama в Linux-контейнере. Затем я могу сказать lama-help. Это позволяет мне запустить lama, показать мои модели, остановить, запустить, загрузить модели, перечислить их, удалить их и многое другое. Я могу перечислить все мои модели. Вы можете видеть, что у меня есть модель Gwen 3 coder. Я могу сказать Olama run, а затем название модели, чтобы запустить модель. И когда модель запущена, я могу задать ей вопрос, и она даст мне ответ. Важно знать, что эта модель также доступна через порт. Так что у меня могут быть такие вещи, как агенты и другие приложения, которые запрашивают модель. Теперь это все популярные модели с открытым исходным кодом, которые вы можете запустить сами, как я это сделал. Но есть также некоторые очень популярные модели с закрытым исходным кодом, с которыми вам следует ознакомиться, такие как модели Claude, OpenAI, Google и другие. ИИ и модели — это высококонкурентная область. За многие модели приходится платить, но их также можно размещать в облаке, например, в Azure и AWS. Теперь ключевой вывод здесь для платформенных инженеров — это понимание того, что такое модель. Знайте, что вы можете размещать их на собственной инфраструктуре. Понимайте их основные вычислительные требования. Такие вещи, как сеть, вычисления, GPU, хранилище и т. д. Также понимайте, что популярные модели имеют закрытый исходный код и обычно платные, и вам нужны учетные записи или подписки для доступа к ним. Популярные облачные провайдеры, такие как AWS, Azure и Google Cloud, позволяют вам размещать эти модели. Теперь, как вы можете видеть, когда вы запускаете модель, у вас есть открытый порт. Это позволяет контейнеру ожидать HTTP-запросы и передавать их модели. Это означает, что мы можем запрашивать нашу модель через порт. И эти запросы называются промптами. Теперь это приводит нас к следующему важному термину, который называется промпты. Теперь промпт — это просто набор инструкций, отправляемых модели для вызова ответа. Это вопрос, который мы вводим в модель, чтобы получить ответ. Теперь промпты могут показаться очень простой вещью на поверхности, но они идут очень глубоко. То, как вы составляете промпт, будет определять ответы, которые вы получите от модели. В наши дни вы даже можете получить сертификат инженера по промптам. И мы немного поговорим о том, почему это так важно. Эти промпты, а также ответы формируют то, что я бы назвал дискуссией. Эта дискуссия может расти, а размер этой дискуссии, которую модель может запомнить, называется контекстным окном. Это работает по принципу "первым пришел — первым ушел". Таким образом, самое старое сообщение удаляется из контекста, чтобы освободить место для новых сообщений, поступающих в контекстное окно. Это означает, что если вы начинаете дискуссию с важного момента, а затем дискуссия затягивается, если вы не поддерживаете этот важный момент, он будет потерян в контекстном окне. Важно знать, что каждая модель имеет разный размер контекстного окна. Это контекстное окно очень важно для таких вещей, как ИИ-агенты, чат-боты или помощники по кодированию. Допустим, вы создаете ИИ-агента, который помогает вам управлять манифестами Kubernetes для вашего кластера, и у вас есть набор стандартов, например, каждый развертывание должно иметь health probe или определенное количество реплик. Эти вещи могут быть потеряны из контекстного окна, когда ваша дискуссия растет, и вам приходится постоянно повторяться. Вот где такие вещи, как системные промпты и инструкции, появляются, когда вы создаете агентов. Эта тема относится к тому, что называется контекстной инженерией. Теперь, что здорово, так это то, что эти системные промпты просто живут в файлах. Файлы на вашей машине, которые вы можете зафиксировать в репозиториях git. Если вы знакомы с такими вещами, как Claude, Claude использует claude.md. Gemini использует Gemini.md. Существует открытый стандарт для агентов, использующих файл под названием agents.md. GitHub Copilot использует instructions.mmd с определенными соглашениями об именовании файлов. В конечном итоге все это одно и то же. Это просто системные промпты, которые вы можете хранить в файлах. Вы можете иметь их в своем пользовательском каталоге. Так что вы можете иметь пользовательские файлы для себя, для ваших личных стандартов. Вы можете обучать ИИ, по сути, как вы хотите писать код, хотите ли вы использовать строчные буквы или camel case, каковы бы ни были ваши предпочтения или стандарты. По сути, эти файлы инструкций передаются модели и оцениваются во время нашей дискуссии. Это здорово, потому что, как я уже упоминал, вы можете иметь свои собственные личные файлы инструкций, чтобы управлять тем, как вы хотите, чтобы ИИ вел себя на вашей машине при выполнении таких задач, как помощь в кодировании, или вы можете разместить эти инструкции на уровне компании в репозитории git, таком как GitHub, где вы можете контролировать общекорпоративные шаблоны, соглашения и стандарты. И это помогает решить проблемы с контекстным окном, как я упоминал ранее. Теперь иногда эти инструкции не всегда доступны локально. Возможно, у вас есть некоторая документация по чему-то вроде Google Drive или в облаке. Возможно, у вас есть файлы на S3 или записи в базе данных, или вы храните свои стандарты где-то еще, и вы хотите динамически извлекать их во время вашей дискуссии. Вот где появляется концепция rag. Rag — это retrieval augmented generation, которая позволяет нам извлекать внешние данные и вставлять их в контекстное окно. Так что rag — это, по сути, метод, с помощью которого мы можем извлекать данные из внешних источников, которые недоступны рядом с агентом. Так что это позволяет нам извлекать внешние данные. Важно знать, что это не функция самой модели, а, как правило, чат-бот или инструмент ИИ или ИИ-агент, который вы запускаете и который может выполнять функции rag. По сути, позволяя нам извлекать данные откуда-то извне. Следующий важный термин, и это, вероятно, один из тех, с которыми вы больше всего взаимодействовали, называется агенты. Когда ИИ начал становиться популярным, чат-боты были всем. Агенты — это, по сути, чат-боты следующего поколения. Это, по сути, просто приложения. Они могут работать в браузере. Они могут работать в контейнерах, в вашем кластере Kubernetes, в облаке. Они могут работать в вашем мобильном приложении. Это, по сути, просто процесс, ничего особенного, но они используют функции ИИ, такие как модель, и другие концепции, которые мы рассмотрим в этом видео. Агенты, по сути, управляют контекстом. Они извлекают такие вещи, как системные промпты, которые мы рассматривали ранее. Они выполняют такие вещи, как rag и другие функции. Важно знать, что агенты могут работать где угодно. И причина, по которой они так важны для инженеров DevOps, S и платформенных инженеров, заключается в том, что вы можете запускать их локально для помощи в кодировании. Разработчики также могут запускать их. Вы можете запускать их внутри вашего кластера Kubernetes. Ваша компания может захотеть разместить агентов, агентов, ориентированных на клиентов, которые предоставляют поддержку, внутренних агентов, которые помогают сделать бизнес более гибким, и по другим причинам. Как инженер, вы также можете создавать своих собственных агентов, чтобы повысить эффективность своей работы. Теперь вместо того, чтобы пользовательский интерфейс взаимодействовал с моделью во время дискуссии, пользователь будет взаимодействовать с агентом. И агент — это просто приложение, которое выполняет всю тяжелую работу за кулисами. Таким образом, агент облегчает дискуссию, передавая промпты и ответы между пользователем и моделью. Он извлекает инструкции, по сути, заполняя контекст, который охватывает наши системные промпты, и выполняет rag. Так что он может извлекать данные из внешних источников. Теперь все основные игроки в сфере ИИ имеют агентов, и вы, вероятно, знакомы с большинством из них. У GitHub есть Copilot. Затем у вас есть один из самых популярных игроков Claude от Anthropic. Затем у вас есть Grock от XAI. Затем у вас есть Google Gemini. Затем у вас есть Codeex от OpenAI. Затем у вас есть популярный агент для кодирования ИИ с открытым исходным кодом под названием Open Code. и один из новичков, Open Claw. Ключевой вывод здесь для инженеров S sur DevOps и платформенных инженеров заключается в том, что ИИ-агент — это просто приложение. Он может работать где угодно: в браузере, на вашем телефоне, в Linux-контейнере, внутри вашего кластера Kubernetes, в облаке. Здесь я создаю и запускаю Docker-контейнер, содержащий Clawude. Это CLI Clawude, где я могу войти в свою подписку Clawude, и у меня также есть CLI GitHub Copilot, работающий в контейнере. Оба этих имеют возможности / agent, где я могу настроить пользовательские агенты. Это означает, что я могу поговорить с ним и сказать что-то вроде "сгенерировать YAML-файл для веб-сервера nginx с одной репликой в развертывании Kubernetes". Этот агент затем будет иметь доступ к моим локальным файлам репозитория git, где я могу давать ему задачи для выполнения, и он взаимодействует с моделями, используя эти промпты. Таким образом, он берет эти промпты и взаимодействует с моделью. В данном случае вы можете видеть, что CLI Copilot использует модель Claude Sonnet 4.6. Я также могу взаимодействовать с агентами в моей IDE, такой как VS Code. Это означает, что я могу задавать вопросы в окне чата прямо в моей IDE. Так что это не обязательно должно быть в терминале. Теперь вот где начинается самое интересное. Следующий важный термин — это тот, который больше всего влияет на инженеров DevOps, платформенных инженеров и S sur, и это MCP. Почему это так? Это потому, что MCP работают как серверы, как и веб-серверы, которые могут работать в контейнерах на Linux, в Kubernetes или в облаке. Они также открывают порт, который может принимать запросы. С инженерной точки зрения они требуют контроля доступа к безопасности. У них есть публичные конечные точки. Поэтому аутентификация важна, и они составляют очень важную основную функцию ИИ. Но что такое MCP? Это означает Model Context Protocol. По сути, сервер MCP — это просто процесс, как и веб-сервер, который работает. По сути, концепция MCP позволяет ИИ-агентам или ИИ-приложениям принимать действия, выполнять задачи и, по сути, отделяет логику задач от самого ИИ-агента. Так, например, если вы хотите перезапустить pod Kubernetes, ИИ-агенту не нужно разбираться в командах cubectl или YAML-файле и напрямую взаимодействовать с кластером. Он может просто проверить сервер MCP, найти инструмент Kubernetes и выполнить его. Если вам нужен ИИ-агент для перезагрузки виртуальной машины в облаке, вам не нужно, чтобы ИИ-агент имел логику и разбирался, как получить доступ к облачной среде, как общаться с ее API, перезагрузить эту виртуальную машину. Он может просто связаться с сервером MCP, чтобы выполнить работу. Думайте о MCP как о дополнительных руках для ИИ-агента для выполнения инструментов. ИИ-агент просто передает параметры серверу MCP, и пусть он выполнит работу. И логика выполнения работы частично находится на стороне MCP. Инструмент Kubernetes MCP может знать, как взаимодействовать с Kubernetes и выполнять команды. Инструмент EC2 AWS может знать, как общаться с EC2 и работать с виртуальными машинами. И существует тысячи серверов MCP, доступных онлайн с официальной поддержкой. Агенты от различных облачных провайдеров, системы управления проектами, такие как Azure DevOps, AWS, Cloudflare, по всему инженерному пространству. Если вы запускаете Kubernetes на Azure, вы можете использовать Azure AKS MCP и выполнять такие действия, как "список моих кластеров AKS в моей подписке", "список пулов узлов для моего кластера AKS". Если вы используете сервер Kubernetes MCP, вы можете выполнять всевозможные операции Kubernetes, такие как применение манифестов YAML, получение журналов и многое другое, включая операции Helm. Это означает, что вы можете расширить ИИ-агентов для выполнения расширенных задач. И это становится довольно мощным. Это означает, что вы можете использовать MCP, чтобы позволить вашему ИИ-агенту делать довольно крутые вещи, такие как доступ и управление ресурсами Kubernetes, управление облачными ресурсами, а также вещи, связанные с наблюдаемостью, такие как метрики Prometheus. Таким образом, вы можете создать ИИ-агента S sur, который выполняет действия по наблюдаемости. Таким образом, вы можете видеть, как MCP расширяет наши возможности ИИ-агентов. Итак, у нас есть дискуссии, системные промпты, rag для внешних данных и MCP для выполнения расширенных возможностей. Теперь вот где начинается сложная часть, и это стоимость. Большая часть, если не вся, стоимость ИИ основана на токенах. Так что же такое токен? Вы можете, по сути, думать о токене как о способе, которым ИИ разбивает слова для обработки. Промпты, которые мы отправляем в LLM, по сути, разбиваются на то, что называется токенами. И сложная часть заключается в том, что все взаимодействия, такие как дискуссии, включая промпты, ответы, инструкции или системные промпты, внешние данные, извлекаемые через rag, MCP, все, что проходит через контекстное окно, обычно токенизируется. Так что все это становится частью стоимости. Теперь токены могут быть довольно продвинутыми и сложными, когда дело доходит до машинного обучения, но, по сути, токен — это примерно 0,75 слова, и вам обычно выставляют счет на основе потребления токенов. Вот где вы хотите стать супероптимальным в использовании ИИ. Лучшие промпты, лучшее планирование перед тем, как вы поручите агентам выполнять работу, и лучшие файлы инструкций. Все это часть оптимизации контекста и контекстной инженерии. Теперь, последнее, но не менее важное, но это очень важно, и это то, что пока не очень популярно, но станет очень популярным в будущем для инженеров S sur DevOps и платформенных инженеров, и это ИИ-шлюзы. И это станет более популярным в инфраструктурной части и таких вещах, как платформы Kubernetes. По мере того, как компании расширяют свои агенты, свои MCP, свои модели, они начнут требовать такие вещи, как ИИ-шлюзы. ИИ-шлюз — это, по сути, API-шлюз, который взаимодействует с агентами, моделями и серверами MCP. Занимается такими вещами, как балансировка нагрузки, сессии, безопасность и многое другое. Так что представьте себе что-то вроде API-шлюза Kubernetes. Но вместо взаимодействия с микросервисами или HTTP, gRPC и вещами, к которым мы привыкли, мы теперь можем интегрироваться с этой вещью под названием ИИ-шлюз. Это означает, что мы можем начать балансировать нагрузку на различные модели LLM. Таким образом, вы можете маршрутизировать трафик либо на локальные модели, либо на модели, размещенные в облаке, либо вы можете балансировать нагрузку на различные агенты. Это включает в себя такие вещи, как взаимодействие между агентами, или вы можете балансировать нагрузку на серверы MCP. Это обеспечивает высокую доступность, балансировку нагрузки, такие вещи, как аутентификация, сохранение сеансов и многое другое. Если вы следили за моей серией по API-шлюзу Kubernetes, вы могли видеть, что мы рассматривали продукт под названием K Gateway, который является реализацией API-шлюза, работающего на Kubernetes. Но что делает его особенным, так это то, что это продвинутый ингресс-контроллер и API-шлюз следующего поколения, поддерживающий маршрутизацию LLM и такие вещи, как шлюзы между агентами. Он нативно интегрируется с ИИ-шлюзами, такими как Agent Gateway. Agent Gateway — это распределенная система с открытым исходным кодом, построенная на ИИ-нативных протоколах, таких как взаимодействие между агентами, а также MCP. И это позволяет нам подключать, защищать и наблюдать различные типы коммуникаций для сред ИИ. Надеюсь, это видео дало вам хорошее представление о том, как начать свой путь, когда дело доходит до ИИ [музыка] с точки зрения инжиниринга платформ S sur и DevOps. Дайте мне знать в комментариях ниже, как проходит ваш путь с ИИ и какие инструменты вы используете в настоящее время. Помните, если вам понравилось видео, поставьте лайк, подпишитесь, нажмите на колокольчик, и если вы хотите следовать окончательной дорожной карте DevOps, вы можете сделать это по ссылке ниже в Instagram. И если вы хотите [музыка] еще больше поддержать канал, нажмите кнопку "Присоединиться" ниже, чтобы стать участником YouTube. И, как всегда, спасибо за просмотр, и до следующего раза, мир.