На днях мне понадобилась локальная среда c Kubernetes для запуска GPU задач и тестирования сервисов с ИИ. Мой рабочий компьютер — это ноутбук Lenovo Legion следующей конфигурации:

• Процессор 13th Gen Intel(R) Core(TM) i7-13650HX (2.60 GHz)
• Оперативная память 32 GB
• Видеокарта NVIDIA GeForce RTX 5070 Laptop GPU
• Диск 1 TB SSD

Каждый раз арендовать облако и временно развертывать K8s-окружение, чтобы экономить на стоимости — не очень удобно. Поэтому я решил попробовать сконфигурировать локальную среду. Оказалось, что Kubernetes с доступом к GPU внутри WSL2 — это реально. Но есть несколько неочевидных нюансов, которые ломают рантайм.

TL;DR

Итоговый стек:

• Windows 11 + NVIDIA driver (с поддержкой WSL)
• Podman
• WSL2 (Ubuntu 24.04)
• K3s (containerd)
• NVIDIA Container Toolkit
• NVIDIA device plugin
• фикс: runtimeClassName: nvidia для device plugin

Что хотелось получить

По сути — мини-кластер на ноутбуке, который работает по следующей схеме:

Pod → Kubernetes → containerd → NVIDIA runtime → WSL GPU → Windows driver → RTX GPU

С возможностью делать:

• локальный инференс
• эксперименты с AI-инфраструктурой и GPU

Шаг 1: Проверка GPU в WSL

Если после установки WSL2 у вас работает Nvidia System Management:

nvidia-smi

— двигаемся дальше.

Шаг 2: Linux-драйверы

WSL — особенная штука. Драйвер для GPU живет в Windows, Linux просто проксирует доступ через /usr/lib/wsl

Если nvidia-smi не находится:

echo 'export PATH=$PATH:/usr/lib/wsl/lib' >> ~/.bashrc
source ~/.bashrc

Чего не стоит делать:

apt install nvidia-utils-*

Такая установка системных пакетов внутри Linux почти гарантированно все сломает.

Шаг 3: Проверка GPU в контейнерах

Перед установкой Kubernetes важно убедиться, что GPU работает в контейнерах.

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
podman run --rm --device=nvidia.com/gpu=all ubuntu nvidia-smi

Если последняя команда выполняется успешно, то runtime настроен правильно.

Шаг 4: Установка K3s

curl -sfL https://get.k3s.io | sh -

Настраиваем kubeconfig:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
export KUBECONFIG=~/.kube/config

Проверяем доступна ли наша единственная Kubernetes нода:

kubectl get nodes

Шаг 5: Подключение NVIDIA runtime

sudo nvidia-ctk runtime configure --runtime=containerd
sudo systemctl restart k3s

После перезапуска K3s убеждаемся, что поддержка GPU есть в конфиге:

sudo grep nvidia /var/lib/rancher/k3s/agent/etc/containerd/config.toml

Шаг 6: Установка device plugin

kubectl apply -f \
https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.1/deployments/static/nvidia-device-plugin.yml

NVIDIA runtime и device plugin

После выполнения шага 6 я столкнулся со следующей ситуацией вокруг device plugin — он запускается и не падает, но не видит GPU. В логах можно увидеть:

No devices found. Waiting indefinitely.
Incompatible strategy detected auto

Причина такого поведения кроется в том, что device plugin запускается под обычным runtime (runc), а не под NVIDIA runtime. Т. е.:

• внутри pod’а нет CUDA / NVML
• GPU не может быть обнаружен
• nvidia.com/gpu не регистрируется

Нужно заставить сам device plugin использовать NVIDIA runtime:

kubectl patch daemonset nvidia-device-plugin-daemonset \
  -n kube-system \
  --type='merge' \
  -p '{"spec":{"template":{"spec":{"runtimeClassName":"nvidia"}}}}'

Перезапускаем pod:

kubectl delete pod -n kube-system -l name=nvidia-device-plugin-ds

и проверяем доступные GPU:

kubectl get node -o jsonpath='{.status.capacity.nvidia\.com/gpu}'

Команда должна вернуть 1.

Финальная проверка

Для тестирования работы GPU внутри WSL2 можно запустить следующий pod:

cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: cuda-smoke-test
spec:
  restartPolicy: Never
  runtimeClassName: nvidia
  containers:
  - name: cuda
    image: nvcr.io/nvidia/k8s/cuda-sample:nbody
    args: ["nbody", "-gpu", "-benchmark"]
    resources:
      limits:
        nvidia.com/gpu: 1
EOF

и проверить его состояние и логи:

kubectl get pod cuda-smoke-test -w
kubectl logs cuda-smoke-test

Что в итоге получилось

• локальный Kubernetes на ноутбуке с Nvidia RTX 5070 (8GB vRAM)
• с возможность GPU scheduling
• тестирования задач с CUDA и LLM

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

В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами. Технологические компании, банки и даже обычный enterprise поняли, куда движется индустрия, и начали срочно внедрять ИИ в продукты и внутренние процессы.

Если открыть hh.ru, LinkedIn или Telegram-каналы с вакансиями, легко увидеть набор ролей, которые постоянно пересекаются по описанию и требованиям:

• LLM Engineer
• ML Engineer
• AI Engineer
• AI Architect
• иногда еще что-то вроде «AI Automation Engineer»

Особенно часто встречается вакансия LLM Engineer. И вот тут начинается путаница.

Например, в одной вакансии Senior LLM Engineer требуют:

• 2+ года коммерческой разработки на Python
• практический опыт с LangChain, LlamaIndex, prompt engineering, RAG
• подтвержденный опыт разработки и внедрения AI-решений

Смотришь другую вакансию — уже Team Lead LLM Engineer. А там:

• создание и развитие RAG-систем, включая Agentic RAG
• observability для агентов
• сервисы обработки документов
• организация разметки данных
• дообучение мультимодальных моделей
• LLM-as-a-Judge и quality pipelines
• вывод моделей и сервисов в production

Проблема в том, что под одним и тем же названием компании часто описывают совершенно разные роли.

Где-то под LLM Engineer реально подразумевается человек, который работает с моделями как с объектом исследования и улучшения: оценка (evals), промптинг, fine-tuning, data curation, quality loops, иногда даже инференс и serving.

А где-то под тем же названием ищут обычного сильного прикладного инженера, который должен собирать AI-функции в продукте: RAG, агенты, интеграции, пайплайны, наблюдаемость (observability), безопасность, продакшен-уровень.

А иногда компания просто ищет единорога, который одновременно умеет:

• тренировать и дообучать модели
• строить RAG и агентные системы
• делать evals
• поднимать production-инфраструктуру
• выстраивать MLOps
• а в идеале еще и оптимизировать инференс

Естественно, когда бэкенд- или фуллстэк-разработчик, который хочет перейти в прикладной ИИ (applied AI), читает такую вакансию, у него быстро появляется мысль: «я вообще не подхожу».

И это часто ложное ощущение.

Где проходит граница

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

LLM Engineer

Это роль ближе к работе с самими моделями и качеством их поведения.

Обычно сюда попадает:

• выбор и сравнение моделей
• построение evals (оценки)
• prompt engineering как системная дисциплина, а не просто подбор промптов
• эксперименты с quality loops
• работа с fine-tuning или post-training
• участие в проектировании AI-архитектуры на уровне поведения модели и ее качества

Для такой роли действительно полезны:

• хороший кругозор в NLP и LLM
• понимание того, как устроены современные модели
• умение читать статьи, документацию и разбирать бенчмарки
• привычка много экспериментировать и валидировать гипотезы

AI Engineer / Applied AI Engineer

Это прикладная разработка: создание ценности для продукта с помощью уже существующих моделей и инструментов.

Обычно сюда относится:

• AI-функции внутри продукта
• tool calling
• RAG
• агенты и их оркестрация
• интеграции с внешними системами
• оценка (eval) и наблюдаемость (observability) на уровне приложения
• надежный продакшен-код вокруг моделей

Здесь важнее другое:

• умение строить сервисы
• понимать ограничения LLM и не ломать продукт об эти ограничения
• уметь отлаживать качество: проблема в данных, retrieval, prompt, tool use или модели
• уметь доводить систему до продакшена, а не просто собирать демо

И вот здесь важный тезис: во многих вакансиях под названием LLM Engineer на самом деле ищут именно AI Engineer. То есть разработчика с сильной бэкенд- или фуллстэк-базой, который умеет применять LLM в реальных системах.

Как могут выглядеть вменяемые требования к AI Engineer

Например, так:

• уверенное владение Python или TypeScript
• умение писать чистый код, тесты и поддерживаемые сервисы
• базовое понимание LLM: токены, контекст, temperature, top-p, ограничения по длине контекста
• опыт промптинга моделей: шаблоны, few-shot, structured output, tool/function calling
• опыт разработки RAG-систем и работы с векторными хранилищами
• опыт интеграции LLM в сервисы
• понимание Docker и контейнеризации
• навыки диагностики качества и производительности AI-сервисов
• базовое понимание безопасности и ограничений при работе с LLM

Как видно, тут нет обязательного требования знать Transformer на уровне LLM-инженера/исследователя, заниматься fine-tuning, строить MLOps-платформу или разбираться в CUDA.

И это нормально.

Что с этим делать

У меня здесь два простых совета.

Рекрутерам и нанимающим менеджерам

Если вам нужен прикладной инженер, который будет встраивать ИИ в продукт, так и пишите.

Не называйте вакансию LLM Engineer только потому, что это звучит модно. Чем точнее вы обозначите границы роли, тем лучше будет воронка:

• меньше нерелевантных откликов
• меньше самоотсечения хороших кандидатов
• выше шанс быстрее закрыть позицию

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

Разработчикам, которые хотят перейти в Applied AI

Не отбрасывайте вакансию только потому, что в ней в одну кучу свалены RAG, агенты, evals, дообучение, observability и MLOps.

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

Поэтому:

• уточняйте на первом же созвоне, что реально входит в зону ответственности
• показывайте пет-проекты и рабочие кейсы
• рассказывайте не только про «я пробовал ChatGPT», а про реальные инженерные задачи
• не думайте, что без опыта в ML/LLM вам закрыт путь в ИИ разработку

Для входа в прикладной ИИ (applied AI) не обязательно быть исследователем. Во многих случаях достаточно хорошей инженерной базы и нормального понимания того, как LLM ведут себя в реальных системах.

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

За последние несколько месяцев мне довелось пообщаться с тремя компаниями по поводу роли руководителя кросс-функциональной команды или CTO в зрелом бизнесе. У каждой были свои ожидания от роли и свои цели на год. Но одна задача повторялась почти у всех: внедрить ИИ в команды разработки и за счет этого повысить их эффективность.

Контекст обычно был примерно такой. Есть устоявшаяся команда, есть зрелый продукт, но, по мнению менеджмента, разработка идет слишком медленно. ИИ-инструменты и кодинговые агенты внутри команды либо почти не используются, либо используются точечно, каждым по-своему, без общего подхода. Иногда их уже пробовали, но результат оказался слабее ожиданий. А на рынке в это время появляются истории о том, как CEO или CPO за ночь собирают прототипы с помощью Codex или Claude Code.

Выслушав такой запрос, я начинал задавать не вопросы про модели и инструменты, а совсем другие:

• как сейчас выглядит delivery-процесс от появления идеи до релиза
• как команда оформляет бизнес- и системные требования
• как работает с макетами и передает контекст между участниками
• как разработчики превращают требования сначала в архитектуру, а потом в код
• как команда контролирует качество на разных этапах

На этом месте можно возразить: «А какое вообще отношение процессы разработки имеют к внедрению ИИ?» На мой взгляд — самое прямое. Чтобы объяснить почему, представим себе две команды.

Первая команда

У первой команды процессы более-менее выстроены. Люди умеют фиксировать мысли в текстовом и визуальном виде и передавать контекст друг другу. Типичная цепочка выглядит так:

идея → бизнес-требования и макеты → системные требования → архитектура → задачи на разработку

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

Обычно такие команды неплохо умеют работать асинхронно. Люди пишут документы, оставляют после себя след в виде решений, описаний и ревью-комментариев. Это помогает не только людям, но и ИИ.

Вторая команда

Во второй команде тоже может быть формальный Scrumban, но по факту работа устроена иначе. Задачи сразу падают в таск-трекер. Требования, если и пишутся, то вперемешку: бизнес-логика, технические детали и допущения лежат в одном месте. Критерии приемки толком не продуманы. Архитектура рождается уже после того, как задачу взяли в работу. О рисках вспоминают позже. Фичи выкатываются быстро, а инциденты тушатся ситуативно.

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

В какой команде ИИ взлетит быстрее

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

Допустим, разработчику выдали доступ к ChatGPT, Claude Code или другому ассистенту. Внутри такого инструмента — большая языковая модель. Она генерирует ответ, опираясь на тот контекст, который ей передали.

И вот здесь возникает ключевой вопрос: какая из двух команд быстрее получит реальную пользу от ИИ?

Очевидно, первая.

Почему? Потому что у нее уже есть зафиксированный контекст: требования, ограничения, архитектурные решения, стандарты разработки, критерии приемки. Разработчик может взять эти артефакты, явно обозначить границы задачи и начать работать с агентом почти сразу.

Пример запроса может выглядеть так:

Ты — опытный backend-разработчик. В приложенном документе описаны бизнес- и системные требования для фичи обработки банковских выписок. В RFC-123 зафиксирована текущая архитектура. Предложи вариант реализации нового метода API GET /bank-statements/. Также учти наши стандарты разработки: стиль кода, подход к REST API и требования к автотестам. Сначала предложи план реализации, затем список изменений по слоям системы и набор тест-кейсов.

То есть разработчик из первой команды за несколько минут собрал хороший контекст и получил шанс на действительно полезный результат.

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

Вывод

Из этого следует простой вывод: внедрение ИИ зависит не только от интереса к технологии, но и от зрелости производственных процессов.

Context is king — и в общении с людьми, и в работе с ИИ.

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

Поэтому, когда меня спрашивают про внедрение ИИ в продуктовой команде, мой ответ обычно один и тот же: сначала выровняйте delivery-процесс, а потом уже системно внедряйте ИИ.

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