Коротко — у дешёвых «говорящих» игрушек обычно нет полноценного облачного GPT‑уровня «on demand». Чтобы получить быстрые ответы при низкой цене, используют комбинацию трюков: упрощённые/локальные алгоритмы, заранее подготовленные фразы и дешёвый/оптимизированный бэкенд. Ниже — технически подробнее и с примерами, как это может быть устроено и почему это дешёво и быстро.
Возможные архитектуры (реальные игрушки используют одно или сочетание нескольких)
1) Полностью локальная (на самой плате)
- Wake‑word + VAD (voice activity detection) работает на MCU/DSP (например ESP32, MCU с Cortex‑M/DSP или специализированные аудио-чипы).
- Набор заранее подготовленных ответов / диалоговых деревьев / шаблонов. По распознанным ключевым словам выбирается готовая реплика.
- Озвучивание — не облачный TTS, а:
- заранее записанные аудиофайлы (самый дешёвый и частый вариант), или
- простые parametric TTS (espeak‑подобное) или лёгкие NN‑вокодеры (LPCNet, небольшие quantized модели), которые можно запустить на SoC.
- Плюс: мгновенный отклик (нет сетевого лага), почти нулевые серверные расходы — только себестоимость железа и флеш для хранения звуков.
2) Гибридный (локальный фронт + облачный бэкенд для «тяжёлых» случаев)
- На устройстве — wake/ASR (упрощённый) и локальная логика. Простые запросы обрабатываются локально.
- Сложные/новые вопросы посылаются на сервер, но:
- используют быстрые маломасштабные модели на сервере,
- кэшируют ответы по типичным запросам,
- держат постоянное соединение (увеличивает скорость) и оптимизируют передачу (сжатие, только текст, минимальные заголовки).
- TTS может быть локальным (аудиодорожки) либо серверным, но чтобы снизить издержки: кэш ответов и заранее синтезированные наборные фразы.
3) Почти облачный, но оптимизированный
- Сервер держит слабые/средние модели (не GPT‑4, а компактные open‑source варианты), чтобы сократить время отклика и стоимость.
- Масштабирование и мультиарендность: одна модель обслуживает миллионы устройств, запросы обрабатывают батчами, используют дешёвые китайские облака и собственные оптимизации.
- Частая агрессивная кеш‑политика: если 90% вопросов — «Как тебя зовут?», «Расскажи сказку», то ответы заранее хранятся.
Почему ответы такие быстрые
- Нет сетевой RTT (если локально) — отклик мгновенный.
- Используют очень простую обработку речи: ключевые слова, intent‑классификатор (малые модели или правила) вместо генеративных LLM.
- Если облако — то лёгкие модели, постоянное соединение, кэш, и сервера расположены в той же стране/регионе (низкая задержка).
- Для TTS: заранее записанные фразы или очень быстрые и лёгкие синтезаторы/вокодеры. Никаких тяжёлых нейровокодеров в реальном‑времени на облаке при каждом запросе.
Аппаратные компоненты, которые часто используют
- Микрофон + простой ADC, иногда массив микрофонов с алгоритмами шумоподавления.
- MCU/SoC: от недорогих ESP32/STM32 до дешёвых ARM Cortex‑A SoC (Allwinner, Rockchip, Unisoc) с 32–512+ MB RAM.
- Небольшой DSP/NPU в дешёвых вариантах (например Kendryte K210 или интегрированный аудио‑DSP) для ускорения wake‑word/инференса маленьких моделей.
- Flash для хранения аудиофайлов и прошивки.
- Wi‑Fi / Bluetooth для соединения с телефоном/облаком.
Как они экономят на TTS и AI‑API (финансовая модель)
- Нет подписки → одноразовая маржа на железе: массовое производство и минимальная себестоимость (формы, электроника, упаковка). При больших тиражах даже небольшая маржа окупает разработку.
- Использование заранее записанных фраз: ноль расходов на каждый запрос.
- Использование open‑source моделей и собственного хостинга (в Китае услуги облака дешевле для массовых провайдеров) или хостинг на дешёвых VPS с GPU/CPU.
- Кэширование и шаблоны: существенно снижает число «тяжёлых» запросов на сервер.
- Ограничение функций: игрушка не решает произвольные вопросы — спектр вопросов ограничен, поэтому можно заранее сгенерировать/записать большую часть ответов.
- Реклама/монетизация через сопутствующие сервисы (приложение, подписка на дополнительные истории, дополнительные аксессуары), хотя не обязательно.
- Сбор данных и дальнейшая их монетизация/усовершенствование продукта (в некоторых случаях).
- Экономия на программном обеспечении: купленные или доработанные дешёвые движки ASR/TTS вместо платных API по модели «за запрос».
Как проверить самому, что за подход используется в конкретной игрушке
- Отключите Wi‑Fi/интернет: отвечает ли игрушка? Если да — всё локально (записи/шаблоны/локальная модель).
- Повторяющиеся ответы: если ответы звучат одинаково на одни и те же вопросы, это шаблоны/записи.
- Ограниченный словарь и «непонимание» неожиданных формулировок указывает на правила/малые модели.
- Время отклика: <200–400 ms почти всегда локально; если >500–1000 ms и есть сетевой индикатор — вероятно облако.
Резюме и риски
- «ИИ‑игрушка» не обязательно использует тяжёлые облачные LLM; чаще это локальные распознавание ключевых фраз + шаблонные ответы или лёгкие модели, плюс кэширование и заранее сгенерированные аудио. Это делает отклик быстрым и себестоимость низкой.
- Риски: приватность (голосовые данные), ограниченность ответов, возможные скрытые передачи данных. Если важна безопасность/приватность ребёнка — проверяйте политику производителя и возможность работы без интернета.
Если нужно, могу разобрать конкретные признаки в видео/устройстве по ссылке (что смотреть в корпусе/на PCB, какие майорные чипы ищут), или дать примеры реальных дешёвых SoC и лёгких ASR/TTS‑библиотек, которые чаще всего используют китайские производители.