Вал Беркoвич, главный AI‑офицер WEKA — серия интервью

Вал Беркoвич, главный AI‑офицер WEKA, является руководителем в области ИИ и инфраструктуры данных, сосредоточенным на развитии технологий, лежащих в основе следующего поколения искусственного интеллекта. С момента присоединения к WEKA в качестве главного AI‑офицера в январе 2025 года он сосредоточил усилия на построении инфраструктуры AI‑агентов, ускорении задач обучения и вывода, а также улучшении экономики вычислений ИИ. Помимо работы в WEKA, Беркoвич является советником по ИИ в Home Dock, стратегическим советником FermiHDI и The Hive, а также председателем PencilDATA, где его деятельность охватывает ИИ, кибербезопасность, блокчейн, облачные вычисления и инфраструктуру данных. Его карьера отражает длительный фокус на разработке и консультировании по передовым технологиям, предназначенным поддерживать всё более требовательные к данным системы ИИ.

WEKA — компания, создающая AI‑родную инфраструктуру данных, разрабатывающая программно‑определяемую платформу для требовательных задач искусственного интеллекта, машинного обучения, высокопроизводительных вычислений и других ускоренных нагрузок. Платформа WEKA Data Platform предоставляет организациям единый архитектурный слой, работающий в локальных, облачных, гибридных и граничных средах, помогая устранять узкие места хранения, повышать эффективность использования GPU и ускорять обучение и вывод AI‑моделей. Компания всё активнее позиционирует свои технологии вокруг развивающейся экономики вывода и агентного ИИ, предлагая инфраструктуру с высокой пропускной способностью и низкой задержкой доступа к данным в огромных масштабах, упрощая сложные конвейеры данных ИИ. WEKA обслуживает предприятия, облачных провайдеров, исследовательские организации и разработчиков ИИ, работающих в самых производительно‑интенсивных вычислительных средах.

Ваша карьера привела вас от формирования ранней стратегии облака в NetApp и участия в учредительном совете Kubernetes до построения AI‑инфраструктуры в WEKA. Как это развитие повлияло на ваш взгляд на подготовку инфраструктуры к следующей фазе ИИ?

Каждая эпоха моей карьеры определялась одной и той же схемой: узкое место смещается, а отрасль замечает это только спустя годы. В ранние дни облака и Kubernetes мы наблюдали, как вычисления становятся эластичными, а оркестрация становится новым узким местом. После ухода из NetApp, где я был CTO после приобретения SolidFire, я думал, что знаю, как выглядит «быстро»: миллисекунды для действительно случайного чтения первого байта в производственных нагрузках.

Причина, по которой я присоединился к WEKA, действительно гиковская. Был один показатель: первое несохранённое случайное чтение байта занимает 70 микросекунд — это не цифра уровня хранилища. Я никогда не задумывался о микросекундных задержках в таком классе систем. И тогда прозрело: эта технология может обслуживать приложения памяти, приложения класса DRAM, такие как Redis и KV‑кеш, а не только хранилище. И как раз в тот момент вывод (inference) стал превосходить обучение, потому что отрасли пришлось монетизировать модели, а агенты пришли, сделав память центральным элементом.

Это и есть тот угол зрения, который я привношу в AI‑инфраструктуру. Мы уже видели такой сценарий. Cloud FinOps возник, когда компании разворачивали инфраструктуру без строгой экономической оценки, а потом получали счёт. AI находится на той же кривой, но движется быстрее. По мере того как бизнесы неизбежно отталкивались от «token‑maxxing» из‑за появления счетов за API, значительно превышающих запланированные токен‑бюджеты, мы наблюдаем рост AI FinOps. Это момент, когда организации перестают рассматривать вывод как дешёвую утилиту и начинают управлять эффективностью токенов как финансовой дисциплиной. AI FinOps начинается с токеномики: оптимизации каждого аппаратного и программного уровня стека вывода, влияющего на стоимость токена. Сейчас самая большая потеря в этом стеке — дорогие GPU и новые ASIC, простаивающие в ожидании памяти и данных (так называемого «decode»), а не вычислительных FLOPS («prefill»). Тот, кто решит эту проблему, получит контроль над следующей фазой ИИ.

Белый дом держит детали своей новой рамки безопасности ИИ в секрете. Как предприятия могут готовиться к регулятивным требованиям, когда они ещё не знают, что именно будет проверяться?

Компаниям не стоит ждать окончательного чек‑листа. Конкретные тесты будут меняться, но лежащая в их основе обязанность останется прежней: вам придётся продемонстрировать, что делала ваша модель, какие данные она использовала и как она вела себя в определённый момент времени. А ждать уже не вариант в глобальном масштабе. EU AI Act стал обязательным в этом месяце и классифицирует большую часть оркестрации агентов как высокорисковую.

Это значит, что подготовка — это работа над инфраструктурой. Прослеживаемость данных, наблюдаемость, воспроизводимость и возможность воссоздать состояние модели по запросу — всё это критически важно для предприятий. Кроме того, организации должны внедрять модели‑ограничители перед выводом, задавая соответствующие задержки и токен‑бюджеты для слоёв семантической защиты. Если вы построите эти возможности сейчас, любой будущий фреймворк превратится в простую задачу форматирования. Ожидание окончательных правил заставит вас «доделывать» подотчётность в системах, которые изначально не были спроектированы для объяснения своих действий. Такое доработы всегда дороже, чем построить всё с нуля.

В конечном счёте решение по построению безопасного ИИ — это больше ИИ, применённого оптимально и преднамеренно.

Какие новые требования к инфраструктуре могут возникнуть из‑за тестирования безопасности ИИ, и как такие нагрузки будут отличаться от традиционного обучения или вывода моделей?

Обучение — это шланг. Вы проталкиваете огромные объёмы данных через модель в устойчивом, предсказуемом режиме. Тестирование безопасности — противоположность: тысячи сценариев оценки, повторяющиеся пробы, сравнения поведения версии за версией и постоянные «red‑team»‑атаки, которые никогда не заканчиваются.

Этот профиль имеет значение. Обучение и тестирование безопасности характеризуются всплесками, интенсивным чтением и сравнительным анализом. Они генерируют и потребляют огромные объёмы промежуточного состояния. Модели‑ограничители должны быть по‑сути гетерогенными и многослойными, реализованными в жёстких лимитах задержки, усиливая оценки новым измерением критериев безопасности. Для таких продвинутых или кибер‑способных моделей профиль нагрузки будет 24/7 постоянным, а не эпизодическим. Вы не проводите тест один раз и фиксируете результат. Вы запускаете непрерывные «swarm‑workloads» агентов, которые конкурируют в продакшене за вычисления, память и пропускную способность данных для защищаемых ими критических приложений. После качества и скорости большинство современных инфраструктур не рассчитаны на этот третий принцип.

Существует также проблема измерения. Большинство современных AI‑бенчмарков работают с 8 000 токенов или меньше, один запрос — один ответ. Я шутлю, что это искусственные бенчмарки искусственного интеллекта. К середине 2026 года реальные агентные нагрузки работают с 100 000‑400 000 токенов контекста в течение тысяч ходов. Если оценки безопасности будут опираться на эти игрушечные бенчмарки, мы будем сертифицировать системы для несуществующего мира. Регуляторы уже усиливают свои возможности: NIST опубликовал открытый инструментарий оценки безопасности агентов, а первые результаты показывают новые атаки «agent‑hijack», происходящие в несколько раз чаще, чем известные базовые сценарии. Именно такие непрерывные, враждебные и дорогостоящие тесты я ожидаю от будущих рамок безопасности.

Стоит ли организациям создавать избыточные вычислительные и дата‑ресурсы специально для будущих требований соответствия и безопасности, или есть более эффективный способ проектировать с учётом этой неопределённости?

Закупать лишние GPU в надежде, что их utilisation вырастет, значит лишь замораживать капитал в быстро обесценивающемся оборудовании.

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

Текущая рамка, как сообщается, фокусируется на продвинутых закрытых моделях, исключая открытые модели. Какие инфраструктурные или безопасностные вызовы могут возникнуть при разном обращении к этим двум категориям?

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

Открытая модель может быть дообучена и развернута в средах, где оригинальный поставщик не имеет никакой видимости. Регулирование поставщика в таком случае ничего не меняет. И уже сейчас виден разрыв: экспортный контроль в этом году охватил новейшие закрытые «frontier»‑модели, тогда как открытые модели свободно пересекают границы и уже находятся в верхних строках публичных рейтингов возможностей. Однако администрация определяет «frontier»‑модели, а управление не может остановиться только на самой модели. Необходимо видеть, где модели работают, к каким данным они обращаются, какие запросы, ответы и метаданные сохраняются, как они модифицировались и может ли подлежащая инфраструктура действительно поддерживать управляемый ИИ в масштабе. Потребуются новые обновления ISO 27001 и SOC 2.

Мой ответ — доверяй, но проверяй. Если ваша инфраструктура предоставляет токен‑пропускную способность, вы можете запускать разнородные ограничители против любой модели до того, как её вывод будет отправлен: отечественной или зарубежной, открытой или закрытой. Объективная проверка превосходит слепое доверие или недоверие, основанное на происхождении модели. По мере распространения открытых моделей эта проверочная возможность будет находиться в слое инфраструктуры, и именно там предприятия будут различаться. Политика может определять, какие модели разрешены. Инфраструктура решает, могут ли эти модели быть развернуты ответственно и экономично.

По мере того как AI‑агенты становятся более автономными и работают с более длинными контекстами, как это меняет объём данных, памяти и вычислений, которые организации должны выделять на мониторинг и безопасность?

Чат‑бот — это запрос и ответ. Автономный агент — это запущенный процесс. Он взаимодействует с десятками систем, извлекает информацию, принимает промежуточные решения и накапливает состояние в течение часов или дней, прежде чем завершит задачу.

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

Защита — это то, где всё становится срочным. Проблема памяти ИИ превращается в проблему безопасности. Кодирующий агент может запуститься, отработать и завершиться. Кибер‑агент не может. Ему необходимо сохранять контекст между ежедневными сменами в центре операций безопасности, частыми обновлениями моделей и сложными многоэтапными атаками, которые раньше растягивались на недели, а теперь работают скоординированными машинными скоростями. Когда рабочая память ИИ постоянно выгружается и пересчитывается заново каждые несколько минут, агент, обнаруживший аномалию в первый час инцидента, уже не помнит её во второй час. У атакующих такой проблемы нет. Их агенты постоянно идентифицируют и используют уязвимости, а цепочки атак теперь завершаются на токеномически оптимизированных скоростях, поэтому AI‑защита должна работать автономно круглосуточно. И это не теория. Поставщики кибербезопасности уже готовятся к 24/7 постоянным киберагентам, и первое, что они обнаруживают, — экономика таких нагрузок сильно отличается от чат‑нагрузок. Некоторые организации нуждаются в агентах на границе, в помещениях, где нельзя разместить GPU‑стойку или даже охладитель в этом году. Реальный тест для корпоративного ИИ — это удержание контекста в течение длительного времени, а не разовый вывод. Это превращается в битву за токен‑аттрицию, и тот, кто решит задачу постоянной контекстной памяти в масштабе, запустит первое горизонтальное «killer‑app» в корпоративном ИИ: постоянно действующие синие рой‑агенты.

Вы говорили о растущей важности «контекстной памяти», когда рабочие нагрузки ИИ выходят за пределы простого чата к постоянным агентам. Может ли контекстная память стать важной также для аудита, воспроизведения или расследования поведения ИИ?

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

Технически большая часть этого состояния хранится в KV‑кеше, а отрасль всё ещё воспринимает его как временное «scratch‑space», а не как долговременные данные. Если вы сохраняете это состояние и можете эффективно его извлекать, вы сможете воссоздать, что система знала в момент действия. Команды сначала будут использовать это для отладки, затем для оценок безопасности, а в конечном итоге кто‑то понадобится в расследовании. Удаление контекстной памяти означает удаление единственной записи, объясняющей, почему ваш ИИ сделал то, что сделал.

Может ли регулирование ИИ в конечном итоге заставить компании сохранять значительно больше информации о входных и выходных данных моделей, контрольных точках, происхождении данных и активности агентов? Что это будет означать для архитектуры AI‑инфраструктуры?

В целом, да. По мере того как системы ИИ становятся более значимыми, требования к видимости расширятся, охватывая каждый шаг конвейера. Уже сейчас видны ранние сигналы: команды планируют хранить «застаревшую» контекстную память в более дешёвых уровнях объектного хранилища исключительно для аудита, ещё до того как появятся регулятивные требования.

Аутентификация мониторинга с неизменяемостью становится критической. Подделка журналов и других судебных артефактов злоумышленными агентами стала рутиной, требующей сложных криптографических систем проверки, нечувствительных к сконцентрированным централизованным целям атак. Простейшие прозрачные журналы или цепочки хэшей уже недостаточны против коллаборации координированных роев агентов. Высокодецентрализованные публичные блокчейн‑архитектуры идеально подходят для этого, подчёркивая часто упускаемую из виду ценность целостности в тройке «C‑I‑A» кибербезопасности.

Хранение — это не только масштабируемая проблема неизменяемого хранилища. Сложность заключается в том, чтобы эта информация оставалась доверенной, организованной, индексированной и доступной достаточно быстро, чтобы быть полезной в срок, будь то запрос регулятора, реакция на инцидент или судебное разбирательство. Пэтабайт активности агентов, который нельзя запросить, — это обязательство, а не запись. Сдвиг в архитектуре происходит от «больше хранилища» к инфраструктуре, построенной вокруг объективно проверяемых, постоянных, запросных AI‑данных как ядра нагрузки.

Многие организации сосредоточены на покупке большего количества GPU, но где вы видите менее очевидные узкие места инфраструктуры, возникающие по мере масштабирования AI‑нагрузок и ужесточения требований безопасности?

GPU часто попадает в заголовки, потому что это заметный бюджетный пункт. Но GPU и, особенно, новые ускорители, оптимизированные под «decode» (ASIC+SRAM), редко являются реальным ограничением. Ограничивающими факторами являются пропускная способность памяти, гравитация данных и их перемещение, производительность хранилища и сеть, определяющие, работают ли ускорители продуктивно или простаивают.

По мере того как ИИ становится более контекстно‑тяжёлым, стеной памяти определяется ограничение. Вы можете продолжать добавлять GPU, но если они тратят свои циклы на пересчёт токенов или перемещение контекста между системами, вы платите за пустую работу, снова и снова. Масштабирование стенки памяти означает превращение слоя данных в совместное хранилище, но с реальной скоростью памяти. Эта планка скорости, близкая к HBM, важна для приближающихся решений по выгрузке KV‑кеша: любой из них должен предоставлять истинную память‑классовую производительность, чтобы токеномика «схлопнулась». Стоимость удержания KV‑кеша — это обсуждение центра затрат, второстепенное по сравнению с центром прибыли. И если чтение кэшированного контекста медленнее, чем его пересчёт, кеш теряет ценность в бизнес‑модели. Главное — не количество GPU, а их продуктивность. Экономика ИИ сводится к ценности, извлекаемой из каждого токена, байта и ватта, а требования безопасности лишь усилят эту формулу.

Смотрим вперёд: ожидаете ли вы, что безопасность и соответствие ИИ станут отдельной инфраструктурной нагрузкой, аналогичной тому, как кибербезопасность превратилась в отдельный слой корпоративных технологий?

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

Но нам стоит учесть ошибки, допущенные в сфере безопасности. Она превратилась в «bolt‑on»: отдельный стек, отдельный бюджет, отдельная команда, обнаруживающая проблемы постфактум. Инфраструктура безопасности не должна повторять эту ошибку. Мониторинг, оценка, аудит и неизменяемое хранение должны быть встроены в саму AI‑инфраструктуру, совместно спроектированы с самого начала.

Вот то, что большинство упускает: безопасный ИИ требует больше ИИ. Модели‑ограничители не бесплатны. Их нужно постоянно обучать, донастраивать и выполнять вывод на каждом этапе работы агента. Бюджеты задержки токенов делают это конкретным: каждый ответ имеет фиксированное окно, и чем больше токенов вы сможете обработать внутри этого окна, тем больше проверок сможете выполнить до того, как вывод будет отправлен. Реальная угроза от «frontier»‑моделей — их агентные применения. Агенты работают в виде высоко‑объёмных циклов вывода, делая повторные обращения к моделям на длительных горизонтах. Каждый цикл — наблюдение, ориентация, решение, действие, и каждый шаг сжигает токены. Это превращает безопасность ИИ в войну токеновой аттриции. Атакующие используют «red»‑рои агентов, защитники — «blue»‑рои, и сторона, способная генерировать больше токенов за доллар и ватт, выигрывает. Токеномика находится на критическом пути как атаки, так и защиты. Это перестало быть лишь мыслительным экспериментом этим летом, когда «red»‑роевой атаки на крупный репозиторий моделей испугали отрасль, и в течение нескольких дней сформировался специализированный альянс безопасного ИИ. Тем временем объёмы продолжают расти: обработка токенов в отрасли перешла от триллионов к квадриллионам.

Как только безопасность станет постоянным требованием, её вычислительные, память и дата‑расходы перестанут быть надбавкой. Они станут частью фундаментальной экономической модели запуска ИИ. Компании, которые рано интегрируют это, будут рассматривать безопасность как входной параметр дизайна. Все остальные будут воспринимать её как налог.

Спасибо за отличное интервью, читатели, желающие узнать больше, должны посетить WEKA.