LLM на 1000 TPS и эпоха телефонных AI-агентов

Скорость модели еще не делает полноценного телефонного агента

Когда появляется разговор про LLM на 1000 TPS для телефонных AI-агентов, легко сосредоточиться на цифре и пропустить главное. 1000 токенов в секунду - это сигнал о скорости инференса, а не готовый агент, который сам безопасно управляет телефоном. Быстрый вывод снижает ожидание, делает диалог живее и позволяет агенту быстрее переходить от мысли к следующему шагу. Но телефонный AI-агент состоит не только из модели. Ему нужны планирование, инструменты, доступ к контексту, разрешения Android, видимое подтверждение и проверка результата.

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

В FoneClaw мы относимся к скорости модели как к верхнему уровню рассуждения. Чем меньше задержка, тем лучше агент может уточнять, проверять и объяснять следующий шаг. Но наш продуктовый фокус находится ниже: поддерживаемые Android-действия, которые видны пользователю и не обходят разрешения. Если нужен широкий контекст о том, как работает AI-агент на Android, его лучше читать отдельно; здесь мы разбираем более узкий вопрос - что именно меняет быстрый инференс.

Что показывает MiMo UltraSpeed и где нужна осторожность

MiMo V2.5 Pro UltraSpeed стал заметным сигналом именно потому, что Xiaomi описывает его как UltraSpeed experience mode для MiMo-V2.5-Pro, 1T flagship model. По данным, указанным на официальной странице Xiaomi MiMo, проверенной 15 июля 2026 года, режим заявлен как текстовый input/output с поддержкой tool calling, streaming и cache support. Xiaomi также заявляет, что output TPS для UltraSpeed находится примерно в диапазоне 500-1000 против 50-100 для MiMo-V2.5-Pro.

Эти цифры важно читать как заявление производителя, а не как независимый benchmark. Они показывают направление: рынок хочет модели, которые не просто сильнее рассуждают, но и отвечают достаточно быстро для real-time сценариев. Xiaomi указывает такие примеры, как количественная торговля, real-time risk control, scientific research и real-time coding assistance. Все это области, где ожидание между запросом, промежуточным выводом и следующим действием быстро превращается в ограничение.

Для phone agent важен не сам бренд MiMo, а импульс: модельный слой движется к меньшей задержке и более плотной работе с инструментами. Мы не утверждаем, что FoneClaw использует MiMo, и не переносим цифры Xiaomi на наш продукт. Если читателю нужен отдельный контекст по семействам моделей, рядом стоит материал про MiMo V2.5 Pro UltraSpeed и другие model-capability темы. В этой статье вывод уже прикладной: быстрый инференс повышает ценность агентного цикла, но не заменяет телефонный уровень действий.

Почему задержка особенно важна в длинных задачах

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

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

Но есть граница. Скорость повышает удобство и позволяет чаще делать проверку, однако она не делает автоматизацию правильной. Если агент быстро выбирает неверный контакт, это все еще ошибка. Если он мгновенно готовит сообщение, но не показывает его перед отправкой, скорость только ускоряет риск. Если он открывает приложение, где требуется ручной выбор, модель не должна угадывать. Поэтому быстрый инференс полезен прежде всего для plan-act-check loop: быстрее планировать, быстрее проверять, быстрее исправлять, но не пропускать контрольные точки.

Длинные задачи на телефоне часто выглядят простыми только снаружи. «Подготовься к встрече» может означать найти адрес, проверить календарь, открыть маршрут, написать участнику, включить режим без звука и поставить напоминание. Каждый шаг зависит от контекста, разрешений и состояния приложений. Чем быстрее модель помогает держать этот контекст, тем больше шансов, что агент останется полезным. Но завершение все равно должно проходить через поддерживаемые действия на устройстве.

Быстрая и глубокая модель: полезный цикл для агента

Один из практичных выводов из темы 1000 TPS - не обязательно «всегда используйте самую быструю модель». Более интересная архитектурная идея - сочетать быстрые проверки и более глубокое рассуждение. Легкая или ускоренная модель может быстро обрабатывать черновые шаги: распознать тип задачи, предложить следующий вопрос, проверить простую неоднозначность, подготовить короткий ответ. Более глубокая модель может подключаться там, где решение сложнее, риск выше или нужен анализ большого контекста.

Для real-time conversation это означает меньше мертвых пауз. Пользователь говорит: «Ответь, что я задержусь, и проверь маршрут». Быстрый слой может сразу понять, что нужно сообщение и навигация. Затем более глубокая проверка может уточнить контакт, текст, время прибытия и условия маршрута. Если пользователь меняет намерение, быстрый слой помогает не начинать весь процесс заново. Такая связка важна не потому, что она звучит модно, а потому что телефонные задачи часто состоят из мелких корректировок.

При этом fast/slow split - это концептуальный прием, а не заявление о внутренней реализации FoneClaw. Мы не описываем здесь закрытую архитектуру и не привязываем ее к конкретной модели. Важно другое: raw TPS сам по себе не равен хорошему агенту. Важна система, которая знает, когда отвечать быстро, когда думать глубже, когда спросить пользователя и когда остановить выполнение.

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

Почему действия на телефоне требуют отдельного уровня исполнения

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

Именно здесь проходит граница между быстрым AI и надежным phone agent. Быстрый инференс помогает лучше понять намерение и быстрее подготовить план. Но выполнение на телефоне требует дополнительных проверок: есть ли разрешение, какой контакт выбран, какой файл используется, можно ли открыть нужный экран, что делать, если приложение изменило интерфейс, и где нужен ручной выбор. Если действие не поддержано, правильный результат - fallback, а не попытка притвориться, что все возможно.

В FoneClaw мы строим продукт вокруг поддерживаемых Android phone actions. Это означает, что модельный слой для нас не конечная точка, а вход в более строгий сценарий: подготовить, показать, подтвердить, выполнить или остановиться. Для более широкого контекста о том, почему смартфон стал местом, где AI переходит в действия на телефоне, есть отдельный материал. Здесь же важно не переписать эту тему, а подчеркнуть: скорость меняет качество взаимодействия, но не отменяет уровень исполнения.

На практике это выглядит так. Агент может быстро понять: «пользователь хочет отправить последний скриншот в чат». Но до действия нужно проверить доступ к изображениям, выбрать правильный скриншот, показать его пользователю, уточнить получателя и получить подтверждение. Если скриншотов несколько или разрешения нет, агент должен спросить или открыть ручной выбор. Модель может быть очень быстрой; безопасное действие все равно остается многошаговым.

Как мы в FoneClaw используем этот урок

В FoneClaw мы видим в быстрых моделях не замену нашему продукту, а усиление верхнего уровня. Чем быстрее модель понимает намерение, тем естественнее становится разговор с телефоном. Чем быстрее она проверяет варианты, тем меньше пользователь ждет между шагами. Чем лучше она работает с инструментами, тем легче подготовить разумный план. Но наш вклад находится в том, чтобы этот план превратился в поддерживаемое Android-действие с понятными границами.

Для FoneClaw это уже не только рыночный сигнал, но и практическая работа над продуктом. FoneClaw получила внутренний тестовый доступ к MiMo V2.5 Pro UltraSpeed и использует эту модель класса 1T, для которой Xiaomi заявляет пиковую скорость выше 1000 TPS, чтобы улучшать пользовательский опыт FoneClaw. В телефонном агенте польза скорости проявляется не в абстрактном числе, а в более быстром понимании намерения, корректировке шагов и выполнении поддерживаемых действий на телефоне.

Мы не утверждаем, что FoneClaw использует MiMo V2.5 Pro UltraSpeed. Мы не заявляем, что каждый phone agent будет работать на 1000 TPS. Мы не говорим, что скорость модели решает автоматизацию приложений. Наш подход осторожнее и практичнее: быстрый инференс полезен там, где он уменьшает паузы, улучшает уточнения и помогает проверять состояние задачи. Но финальный шаг на телефоне должен оставаться видимым, разрешенным и поддержанным.

Для нас хороший AI-агент на Android - это не самый быстрый генератор текста. Это система, которая помогает пользователю завершить реальную задачу без потери контроля. Она знает, когда спросить, когда показать, когда выполнить, а когда отказаться от действия. Если быстрые модели делают эти циклы короче, мы считаем это важным направлением. Но мы не переносим скорость модели на обещание любого устройства, любого приложения и любого сценария.

Практический takeaway такой: 1000 TPS меняет ощущение агентной работы, особенно в длинных задачах и real-time диалоге. MiMo UltraSpeed показывает, что рынок движется к более быстрым моделям и более плотным tool workflows. Но эпоха phone agents наступает не только через скорость. Она требует надежного слоя действий на телефоне. Именно там мы в FoneClaw строим свою часть: поддерживаемые Android-действия, разрешения, видимое подтверждение и fallback вместо универсальных обещаний.