Dev48
ЯЗЫК
  • О нас
  • Услуги
  • Индустрии
  • Технологии
  • Статьи
  • Контакты
Забронировать звонок
    Главная/Статьи/Sozdanie agentov realnogo vremeni dlya zaryadki elektromobiley s pomoschyu gemma
Dev48
info@dev48.org+375 29 320-40-96WhatsApp@isky_by

© 2026 · Все права защищены.

Создание агентов реального времени для зарядки электромобилей с помощью Gemma и TPU

Источник: Google Cloud Blog•12 ноября 2026 г. в 00:03

Создание агентов реального времени для зарядки электромобилей с помощью Gemma и TPU

Чтобы внедрить передовой ИИ в сферу зарядки электромобилей и создать лучший в мире разговорный ИИ для распределенного оборудования, компании lemonflow потребовались легкие, но надежные модели. Узнайте, почему они выбрали Gemma.

С возвращением в The Blueprint — регулярную рубрику, в которой мы рассказываем о том, как клиенты Google Cloud решают уникальные и типичные отраслевые задачи с помощью новейших технологий ИИ и облачных вычислений. Мы надеемся вдохновить тех, кто стремится к инновациям в своей работе.

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

Задача

Прежде чем основать lemonflow, мы тесно сотрудничали с ведущими игроками рынка мобильности в Европе и не понаслышке знали, как часто возникают проблемы с зарядкой: от 15% до 25% попыток зарядки электромобилей в Европе заканчиваются неудачей. На быстрорастущем европейском рынке электромобилей, где продажи аккумуляторных электромобилей выросли 30% in 2025 и тысячи операторов зарядных станций управляют общественными зарядными устройствами, водители, столкнувшиеся с неработающими точками зарядки, часто оказывались в безвыходном положении или застревали в медленных очередях колл-центров.

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

  • Строгие пороговые значения задержки: Разочарованные водители хотят получить немедленную помощь. Наше тестирование подтвердило, что задержки обслуживания выше 800 миллисекунд создают риск перебивания собеседника, заставляя водителей прерывать агента и нарушая ход взаимодействия.
  • Узкие места управляемых API: Изначально полагаясь на управляемые API LLM, мы столкнулись с отклонениями задержки в часы пик (скачки с 1,0–1,2 секунды до более чем 1,7 секунды) и ошибками ограничения частоты запросов HTTP 429, когда глобальное использование достигало пика.
  • Вычислительно интенсивные разговоры: Каждый агент работает на основе одного комплексного промпта в сочетании с динамическими вызовами инструментов, которые считывают данные зарядного устройства и реагируют на них в реальном времени. Такая конструкция создает интенсивные всплески вычислительной нагрузки во время звонков, что затрудняет обеспечение пропускной способности на общих управляемых мощностях при пиковых нагрузках.
  • Сильно фрагментированная экосистема: Нам был нужен стандартизированный разговорный движок, способный объединить около 30 различных систем управления зарядными станциями (CPMS) — бэкендов, которые операторы используют для управления своими зарядными устройствами, каждая из которых имеет свои API, модели данных и особенности.
  • Сотни специализированных агентов: Нет двух операторов, которые осуществляют поддержку одинаково. У каждого свои тарифы, способы оплаты, пути эскалации и часы работы службы поддержки, и большинство из них используют несколько агентов, например, по одному на страну, бренд или горячую линию, с поведением, которое может меняться в зависимости от времени суток. Промпт каждого агента уникален и должен обслуживаться на полной скорости и улучшаться, не нарушая работу остальных.

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

Решение

Мы хотели, чтобы каждый водитель получал первоклассную поддержку, которая кажется легкой, почти волшебной: никакой очереди, никакого меню, просто короткий разговор, который заканчивается зарядкой автомобиля. Представьте себе водителя в долгой поездке через границу, который заезжает на станцию техобслуживания на автомагистрали в 23:00. Она подключается, но зарядка не начинается: предыдущий сеанс не был должным образом завершен. Она звонит по номеру на зарядном устройстве, и ей отвечают на ее родном языке. В течение нескольких секунд наш агент обнаруживает зависший сеанс в журналах зарядного устройства, удаленно перезапускает его и остается на линии, пока не пойдет ток.

Чтобы достичь этого, нам пришлось устранить узкие места в задержках и обеспечить выделенные вычислительные мощности. Мы перешли от управляемых API к самостоятельному размещению открытой модели Gemma 4 на оборудовании Google Cloud TPU v6e в ЕС.

Как и многие стартапы, использующие Gemma, совместимость этих открытых моделей с Gemini позволила нам перенести нашу существующую инфраструктуру промптов с минимальными изменениями.

Переход на собственные TPU открыл более полный архитектурный контроль, необходимый нашей инженерной команде для создания детерминированного базового уровня, который обрабатывает специфические для электромобилей защитные барьеры, защищает от инъекций промптов и стандартизирует ранее фрагментированные протоколы бэкенда в наш внутренний формат, прежде чем они попадут в LLM. Контроль дал второй результат: поскольку модель и стек обслуживания меняются только тогда, когда мы их меняем, каждый результат теста остается значимым. Эта стабильность заложила основу для Agent Coach, нашего фонового движка обучения для ИИ-агентов, описанного ниже.

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

Пользовательские оптимизации для движка обслуживания vLLM с открытым исходным кодом и многоуровневое распределение памяти между TPU и хост-памятью позволили одному сегменту TPU держать гораздо больше агентов операторов готовыми к мгновенным ответам без пересчета их контекста.

Мы также внедрили автоматическую маршрутизацию с переходом на собственные GPU и конечные точки Gemini Enterprise. Благодаря надежности TPU, Gemma отвечает более чем на 99,9% всех живых разговоров, а эти резервные варианты служат в основном в качестве буферов развертывания во время обновлений системы. Будь то основной или резервный вариант, каждый запрос обслуживается из защищенных вычислительных мощностей ЕС.

Архитектура

Результат

Для компаний в сфере электронной мобильности, с которыми мы работаем, и для их водителей результатом является поддержка, которая просто работает: наши агенты обычно отвечают на каждый звонок, обрабатывают более 80% разговоров от начала до конца без участия человека и обеспечивают 95% удовлетворенности водителей. За кулисами самостоятельное размещение Gemma на Google Cloud TPU изменило нашу производительность:

  • Быстрые циклы развертывания: Время цикла обновления и тестирования промптов сократилось с 2–3 часов до примерно 10 минут, что более чем в десять раз ускорило цикл улучшений.
  • Задержка обслуживания менее секунды: Мы снизили нашу задержку P50 до примерно 350 миллисекунд, а задержку P90 — до примерно 600 миллисекунд. Это примерно в три раза быстрее, чем наш базовый уровень с управляемым API, и достаточно быстро, чтобы резко сократить количество перебиваний со стороны клиентов.
  • Нулевое дросселирование и стабильная задержка: Выделенная инфраструктура TPU устранила ошибки ограничения частоты запросов HTTP 429, а задержка остается стабильной даже при пиковом трафике звонков во второй половине дня.
  • Тестирование без ограничений: На выделенных мощностях каждый цикл TPU, который не требуется для живых разговоров, становится мощностью для тестирования, поэтому наша команда может экспериментировать и проверять гипотезы по своему усмотрению.
  • Создано для масштабирования: Сегодня наши агенты круглосуточно поддерживают более 40 зарядных сетей в 17 странах, охватывая более 250 000 точек зарядки. И это только начало: та же платформа готова принять еще много сетей и рынков.

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

Заглядывая в будущее, мы готовимся перейти на Ironwood — тензорный процессор Google седьмого поколения, как только он станет доступен в нашем регионе ЕС. Обладая в шесть раз большим объемом памяти с высокой пропускной способностью на чип, Ironwood увеличит количество операторских агентов, которые один TPU может держать готовыми в памяти для мгновенных ответов.

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

Детали

Наша платформа запускает два вида ИИ-агентов: агенты поддержки, которые общаются с водителями в режиме реального времени и работают на базе Gemma в Cloud TPU для обеспечения минимальной задержки, и агенты мониторинга, которые анализируют разговоры и журналы зарядных станций в фоновом режиме на базе Gemini, чтобы операторы могли устранить неисправности до того, как это затронет следующего водителя. Чтобы поддерживать единообразие своей базовой платформы для множества компаний в сфере электротранспорта — от операторов зарядных станций (CPO) и поставщиков услуг электротранспорта (eMSP) до производителей зарядных устройств, — компания lemonflow создала уровень трансляции, который преобразует разнообразные интерфейсы CPMS в стандартизированный формат.

Когда водитель звонит на линию поддержки, указанную на зарядной станции, вызов попадает в наш разговорный движок через собственную горячую линию оператора. Затем движок в режиме реального времени извлекает из CPMS оператора текущий статус зарядной станции и логи протокола Open Charge Point Protocol (OCPP) — сообщения, которыми зарядные устройства обмениваются со своим бэкендом. Поскольку зарядные станции часто не имеют цифровых дисплеев, водители нередко не подозревают о скрытых проблемах, таких как ожидающие авторизации мобильные платежи 3D-Secure, тайм-ауты сеансов, зарядные карты, не активированные для роуминга, снижение мощности из-за локального управления нагрузкой или автомобиль, завершивший сеанс по достижении собственного лимита заряда. Наш движок передает структурированные сводки журналов непосредственно в Gemma на TPU для информирования взаимодействия с водителями.

Прямой контроль над моделью позволяет нам выборочно передавать поток токенов. Токены частичного текста мгновенно передаются в наш движок преобразования текста в речь (TTS), в то время как токены структурированных вызовов инструментов асинхронно передаются в бэкенд-системы для выполнения реальных действий, таких как удаленная перезагрузка зарядных устройств, разблокировка застрявших кабелей, остановка сеансов, которые не удалось завершить, отправка водителям деталей по SMS или электронной почте либо уведомление технических специалистов.

Детерминированные средства контроля безопасности проверяют входные данные до того, как они попадут в LLM, размещенную на TPU, блокируя вредоносные промпты. Эта архитектура разработана с учетом требований к европейской критической инфраструктуре и при этом обеспечивает высокую скорость диалогов: типичный ответ начинает поступать примерно через 350 миллисекунд.

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

  • Стартапы
  • Производство
  • Клиенты
← Все статьи

О чём эта статья

Ещё в разделе «Данные и аналитика»

Все →
Новый ИИ-агент Databricks говорит генеральному директору Али Годси всю правду без прикрасПресса
Databricks

Новый ИИ-агент Databricks говорит генеральному директору Али Годси всю правду без прикрас

Знакомьтесь с Relate by Neo4j: встроенная база данных для ИИ-агентов
Neo4j

Знакомьтесь с Relate by Neo4j: встроенная база данных для ИИ-агентов

SRE Agent теперь общедоступен: расследование и приоритизация начинаются в момент обнаружения проблемы
Dynatrace

SRE Agent теперь общедоступен: расследование и приоритизация начинаются в момент обнаружения проблемы

Быстрый режим теперь стоит 1 доллар за 1000 страниц и лучше распознает таблицы
Datalab

Быстрый режим теперь стоит 1 доллар за 1000 страниц и лучше распознает таблицы

Почему RAG, основанный только на векторах, не справляется с аналитическими вопросами, и эталонная архитектура, которая решает эту проблему
Couchbase

Почему RAG, основанный только на векторах, не справляется с аналитическими вопросами, и эталонная архитектура, которая решает эту проблему

Сертификация Google Cloud Agentic Architect
Looker

Сертификация Google Cloud Agentic Architect

Ещё от Looker

Сертификация Google Cloud Agentic Architect
Looker

Сертификация Google Cloud Agentic Architect

Загадка трехслойной сети GKE
Looker

Загадка трехслойной сети GKE

Лимиты расходов Google Cloud теперь доступны всем пользователям
Looker

Лимиты расходов Google Cloud теперь доступны всем пользователям

Инфраструктура Google Cloud на конференции NVIDIA GTC Berlin 2026
Looker

Инфраструктура Google Cloud на конференции NVIDIA GTC Berlin 2026

Google Cloud добавляет модели OpenAI для клиентов
Looker

Google Cloud добавляет модели OpenAI для клиентов

Конфиденциальные графические процессоры G4 стали общедоступны (GA)
Looker

Конфиденциальные графические процессоры G4 стали общедоступны (GA)