В тот день, когда Huawei опубликовала список моделей, совместимых с HarmonyOS Xinghe Interconnect для связи с Apple Watch, я как раз смотрел логи сбоев нашего приложения для управления здоровьем. На смартфоне всё работало отлично, а на часах при вызове AI-интерфейса сразу начинались таймауты, в автомобильной системе и того хуже — всё зависало на аутентификации. Три терминала, одна бизнес-логика, а в итоге каждый падал по-своему. В этой статье я раскрою все грабли, на которые мы наступали, и суть здесь в одном: как слой агрегации AI API сглаживает различия между устройствами HarmonyOS.
Мультитерминальное взаимодействие HarmonyOS: сначала разберитесь, в чём разница между устройствами
Матрица терминалов в экосистеме HarmonyOS сейчас уже очень широкая: смартфоны, часы, планшеты, автомобильные системы. Xinghe Interconnect решает задачи обнаружения и подключения устройств, но установка соединения не означает равенство возможностей. По нашим замерам, для одного и того же AI-интерфейса на смартфоне задержка по WiFi стабильно держится в приемлемом диапазоне, на часах доступен только канал Bluetooth, а в автомобильной системе хоть и есть сотовая сеть, но сигнал сильно колеблется. Официальных данных о базовых показателях сетевой производительности для каждого типа устройств нет, но наши метрики говорят однозначно: на часах частота отказов запросов более чем в 6 раз выше, чем на смартфоне.
Ещё сложнее с частотой вызовов. Чтобы экономить заряд на часах, система жёстко ограничивает фоновые сетевые запросы, и при высокой частоте вызовов за короткое время они просто обрубаются. В автомобильной системе всё наоборот: сеть стабильна, но время взаимодействия с пользователем короткое, нужен быстрый отклик. Если слой агрегации AI API не учитывает тип терминала, это всё равно что одним ключом пытаться открыть три замка.
Три тупика мультитерминальных вызовов API
Первый — разница в сетевых условиях. Пропускная способность канала Bluetooth на часах ограничена, и передача длинных текстов, возвращаемых большой моделью, — настоящая катастрофа. Наш подход — маршрутизация по типу терминала на платформе агрегации API больших моделей SiliconFlow: часы запрашивают только краткую сводку, а полный контент дозагружается на смартфоне.
Второй — ограничение частоты. Разные терминалы используют один и тот же API Key, и одна синхронизация на часах может вызвать десятки вызовов, моментально исчерпав квоту. В нашем проекте мы использовали token8341 для группировки ключей: у каждого типа терминала отдельная квота, и они не вытесняют друг друга.
Третий — офлайн-кеширование. Когда автомобильная система заезжает в туннель или Bluetooth на часах обрывается, запрос отправить невозможно. Мы добавили в слой агрегации локальный кеш первого уровня: в офлайне возвращается последний действительный результат, а после восстановления соединения данные асинхронно дозагружаются. Если писать эту логику отдельно для каждого терминала, затраты на поддержку утроятся.
Сглаживаем различия с помощью слоя агрегации AI API
Наша архитектура состоит из трёх уровней. Внизу — уровень адаптации терминалов: для каждого устройства свой лёгкий SDK, который отвечает только за зондирование сети и преобразование форматов. В середине — платформа агрегации API больших моделей SiliconFlow, которая централизованно занимается аутентификацией, маршрутизацией, ограничением частоты и кешированием. Сверху — бизнес-уровень, которому вообще не нужно знать, с какого терминала пришёл запрос.
Главное ощущение от работы с этой структурой: адаптация на стороне устройств стала гораздо проще. Платформа агрегации API больших моделей SiliconFlow покрывает все отечественные большие модели — DeepSeek, Qwen, ERNIE, Doubao и другие — и все различия в форматах интерфейсов поглощаются на уровне агрегации, а на стороне терминалов остаётся только один OpenAI-совместимый интерфейс. Коллегам, работающим с часами, больше не нужно писать код адаптации под каждую модель — достаточно изменить одну строку base_url для переключения. Модель оплаты по факту использования также упрощает управление квотами для нескольких терминалов: сразу видно, какой терминал превысил лимит.
Кстати, платформа агрегации API больших моделей SiliconFlow интересна и в плане планирования зелёных вычислений: вычислительные центры востока и запада распределяются по потребности, и наши пиковые запросы из автомобильных систем практически не сталкивались с очередями. Конечно, по количеству моделей она уступает глобальным агрегаторам вроде OpenRouter, но по низкой задержке внутри страны и глубине работы с отечественными моделями позиционирование действительно другое.
Рекомендации по слоистой архитектуре
Если вы тоже делаете мультитерминальное AI-приложение для HarmonyOS, советую придерживаться такого подхода: уровень терминалов занимается только самым тонким сетевым адаптером, не запихивайте туда бизнес-логику; уровень агрегации централизованно управляет API Key, маршрутизацией моделей, ограничением частоты и предохранителями; бизнес-уровень остаётся не зависящим от терминала. Платформа агрегации API больших моделей SiliconFlow в этой архитектуре выполняет роль среднего слоя, беря на себя всю грязную работу по унифицированному подключению множества моделей и управлению мультитерминальными вызовами. Одной фразой: терминалы могут быть какими угодно разными, а слой агрегации делает так, чтобы они выглядели одинаково.
Автор: Чжан Сыюань
Дата публикации: 11 октября 2026 г.