Положить LLM в карман: стоит ли выносить языковую модель из облака?

В какой-то момент гонка за облачными мощностями начинает утомлять. Ты привыкаешь, что для любой серьезной задачи с LLM нужен API-ключ и хороший бюджет. Но в IT, как известно, все циклично, и вот снова набирает силу тренд на on-device AI - возвращение вычислений с небес на землю, прямо на наши устройства

Поработав с разными облачными провайдерами, начинаешь задумывался об альтернативе - запуске LLM на собственном железе.

Для меня последней каплей стал пост Иэна Баллантайна (Linkedin), где он заставил свежую Gemma 3 270M от Google летать на Raspberry Pi 5. Его цифры - около 30-32 токенов в секунду на голом CPU - звучали слишком хорошо, чтобы быть правдой (ниже будет видео от автора)

Цитата автора:

как быстро работает Gemma 3 270M "из коробки" на Raspberry Pi 5? Около 30 токенов/сек на CPU для квантизованной модели Q4_0 при использовании Ollama. Я также попробовал Llama.cpp и получил около 32 токенов/сек

Увидев такие цифры, я окончательно решился повторить его эксперимент

Мой тестовый стенд
Конечно, в мечтах - домашний мини-кластер на четырех GPU, но начнем с малого. Мой сетап для эксперимента:

Устройство: Orange Pi 5 Pro с 16 ГБ оперативной памяти (оно по некоторым параметрам даже превосходит то, что было у Иэна)

Кандидаты на запуск:
✨ Frida - компактная русскоязычная модель от команды ai-forever, удобная для экспериментов за счёт небольшого размера (<300 M параметров) и открытых QAT-чекпоинтов
✨ Gemma 3 270M - свежая модель от Google, оптимизированная для энергоэффективности и быстрой тонкой настройки

Главный вопрос: какая в этом мотивация?
Прежде чем погружаться в технические дебри, я решил посчитать, имеет ли эта затея экономический смысл

Окупаемость железа
- Аренда схожего по характеристикам облачного CPU-сервера – ≈ 5 300 ₽/мес
- Покупка Orange Pi 5 Pro – ≈ 12 000 ₽
- Разделив, получаем ≈ 2.3 месяца до полной окупаемости оборудования

Дополнительные затраты
Конечно, в расчёт не вошла стоимость моего времени на настройку. Но для энтузиаста это скорее удовольствие, а потребление энергии устройством (≈ 6–10 Вт под нагрузкой) сравнимо с ежемесячным счетом за лампочку, в то время как облачные серверы обходятся в сотни рублей за час работы.
📌 Вывод: локальный деплой выгоден при регулярных нагрузках; для редких задач облако остаётся привлекательным

Экономия на API-токенах
А вот здесь все не так однозначно. Если вам нужно лишь изредка обращаться к модели, использование API через облако может быть очень дешевым. Например, для редких задач вызовы самой доступной русскоязычной модели обошлись бы примерно в 0,02 ₽ за 1 000 000 токенов. Очевидно, что покупать отдельное устройство из-за такой низкой цены токена бессмысленно.
📌 Вывод: Локальный деплой выгоден, если вы заменяете им постоянно работающий облачный сервер, а не редкие API-вызовы

Зачем это нужно в глобальном смысле?
Экономия - это приятно, но потенциал локальных моделей гораздо шире. Вы думаете, успехи Китая в роботизации - это шутки? Локальные LLM играют в этом ключевую роль. Робот на производстве или дрон-курьер не могут зависеть от стабильности интернет-соединения с дата-центром. Им нужна автономия

Перенос AI на устройства дает:
🔵Приватность: Данные обрабатываются локально и не утекают на сторонние серверы
🔵Низкую задержку: Отклик модели происходит мгновенно, что критически важно для систем реального времени
🔵Надежность: Устройство работает даже без подключения к сети

Что дальше?
Я пока только приступил к тестам и в ближайших планах развернуть Frida и Gemma 3 270m на своем Orange Pi. Очень интересно, какие результаты удастся получить и насколько они будут близки к показателям на Raspberry Pi

#hardware

Спонсор вайба на выходных - Илон Маск, а с меня - свежий лайфхак для vibe-кодинга

Начну сразу с главного: два дня тестирую новую Grok Code Fast 1 (xAI), которую сейчас бесплатно раздают в Cursor (аж до 2 сентября, вы тоже успеете потестировать), но все таки, пока что личный фаворит - это Claude 4 Sonnet

Grok Code Fast 1 генерирует код с какой-то нечеловеческой скоростью (авторы заявляют 160 tokens per second). Я с ним за час набросал ядро сложного мультимодального RAG-поиска. А потом пришло время все это собирать воедино с основным сервисом. И пошли проблемы. Ассистент, пытаясь исправить одну ошибку, создавал три новых. Думаю эта ситуация знакома многим

И вот мой лайфхак, который спасает 90% времени и нервов - это тесты с подробными логами. Это ваш единственный объективный критерий того, что все работает как надо

Этот подход можно разбить на две части

Допустим, мы только что собрали мультимодальный RAG-поиск. Мой промпт будет выглядеть так (обычно пишу на английском - субъективно работает лучше и дешевле):

🟡Пишем тесты:

Here is the python module with multi-modal RAG logic [code]. Your job is write an extensive tests for it using pytest. I need at least 20 tests covering huge bunch of cases: from file uploads to API responses and edge cases like empty inputs and hard cases with different input combinations.

Обычно в момент написания все тесты проходят без проблем, но это только пока мы не насоздавали еще десятки зависимостей

🟡А если зависимости все ломают, то дебажим при помощи тестов:

Okay, look. Here is the output of the tests we wrote before. [вставляю лог с ошибками]. 4 / 20 tests failed. Your changes broke the critical functionality. Your one and only goal right now is to fix the code so that all 20 tests pass again. start fixing all failed tests.

И это отлично работает! Особенно когда приходится переключаться между чатами с потерей контекста

Что касается моих впечатлений от Grok Code Fast 1 - модель быстрая, но сыровата, хотя метрики на SWE bench могут впечатлить. Для большинства практических задач связка Claude 4 Sonnet с описанной выше методологией пока остается непревзойденной. Я потратил час на написание фичи с Grok, а потом еще 30 минут дебажил результат с помощью Claude и тестов..

Всем вайбовых выходных!

💃 #vibe_coding@ml_maxim

🔍 Что скрывается под капотом Perplexity?

Когда AI отказывается выполнить задачу, ссылаясь на "лимиты ресурсов", возникает вопрос: а что это за лимиты? Со мной случился как раз такой кейс.

Я решил выяснить, что происходит внутри Perplexity, когда он выполняет код. Попросил AI проанализировать собственные логи и окружение. И он буквально сам рассказал: "Я работаю в Docker-контейнере на Linux 6.1, у меня 2 CPU и 1GB RAM..." и далее выдал полную базу, вплоть до локации своего сервера (кстати, США, штат Орегон)

Perplexity использует E2B Sandbox - специализированную платформу для AI-агентов. Каждый ваш запрос с кодом запускается в контейнере.

🔵 Архитектура: FastAPI ↔ WebSocket ↔ Jupyter Kernel
🔵 Оптимизация: uvloop + orjson + httptools

Это объясняет, почему AI иногда "отказывается" - не из-за технических лимитов, а из-за бизнес-логики системы. Ведь критически важно быстро отдавать пользователю результат - это основной приоритет таких решений

GitHub Copilot, Replit, CodeSandbox - все используют похожие решения

Зная архитектуру подобных решений, можно:
🔜 Правильно использовать контекст
🔜 Оптимизировать запросы под систему (и манипулировать системой)
🔜 Понимать реальные ограничения и бизнес-логику

Понимание внутреннего устройства AI-систем становится критически важным навыком. Это не просто любопытство - это практический инструмент для более эффективной работы

📖 Полное исследование на Habr

Разбор решения Yandex Cup

Прошел Yandex Cup, где в треке ML я выбрал задачу STEM problem Q&A для VLM моделей (это когда надо решать задачи по математике и физике с листочка - но только в нашем случае, при помощи VLM)

Самое время подвести черту и поделиться решением 📃

Сразу отмечу: радует, что агенты стали нормой. Комьюнити созрело, орги не банят за LLM-кодинг. Кажется, все приняли как данность, что без этого теперь никуда.

Мой технический стек

В итоге я вышел на такое решение:

Ядро: Qwen3-VL-8B-Instruct + 4-bit квантование
Методы: Chain of Thought + Prompt Routing
Почему так: Большие модели лучше маленьких - это факт. Я пробовал собирать ансамбли из мелких моделей, но они никак не могли приблизиться к одной большой. Time Limit в 1 час сильно ограничивал: на полноценную Thinking-модель времени инференса мне просто не хватило (квантованные версии не попробовал). До finetune версий моделей тоже не дошел


Что было больно (и интересно)

🔵Недетерминированность. На графике динамики лидеров видно, как участников штормило. Один из вариантов решения - поставить высокую температуру и устроить Voting одной и той же версии модели. Понятно что такое решение невоспроизводимо. Даже с температурой 0 метрика гуляла. Ты запускаешь топовое решение второй раз, и оно падает в рейтинге

Инженерные вызовы и хаки

🔵Контейнеризация. Часть успеха - корректно развернуть модель в докере. Это был отдельный инженерный вызов

🔵Железо. Хорошо бы иметь домашний Linux GPU-кластер (ну или брать его в аренду). Это единственный способ сделать локальную валидацию быстрой и приближенной к проду.

Моя главная ошибка:

Я собрал неверный сет для локальной валидации. Использовал ScienceQA, Geometry3k и MathVista, но поздно понял, что у меня нет корреляции Local / Public Leaderboard. Был момент, когда из-за бага давали 8 сабмитов в день - идеальный шанс подобрать val data, но я его упустил. В итоге локально метрика росла, а на лидерборде - нет.

Классический совет себе на будущее:

Не нужно долбиться в одно решение. Не работает с трех попыток - делаем шаг назад и думаем еще

Завтра расскажу про свой подход к vibe-competiting - как решать задачи с помощью co-solver’а и не сойти с ума

P.S. Интересно, кто-то из финалистов уже рассказал о своем решении? Если знаете - скидывайте ссылки в комментарии

🤓 Интересное из собесов на ML-щика

Давно не было про собесы, поэтому принес важные кейсы с моих собесов, что сейчас есть актуального по теории ML и практике в system design

⚡️ Кейс 1 - Алгоритмы бустинга

Вот тут писал 💡, что сделаю разбор, что я спрашиваю на собесах про catboost. Исправляюсь - сегодня расскажу про важные особенности основных алгоритмов, понимание которых отличает новичка от профи.

Джентельменский набор алгоритмов бустинга: Аманда, Линда и Роуз XGBoost, LightGBM и CatBoost


🌟 XGBoost (2016, original paper 📑)

🔵Особенность 1 - Функция оптимизации для деревьев. В objective явно добавляется штраф за сложность дерева (например, за число листьев и L2 по весам листьев), поэтому контроль переобучения вшит в математику алгоритма, а не только в внешние приемы вроде early stopping

🔵Особенность 2 - Параллелизация и системные оптимизации. XGBoost проектировался как scalable GBDT - поддерживает параллельный поиск сплитов (по фичам/блокам данных), эффективные структуры хранения и обработку данных, что дает выигрыш на больших датасетах и многоядерных CPU (один из самых первых!)

🔵Особенность 3 - Second-order boosting (использование гессиана). В XGBoost каждый шаг бустинга минимизирует локальную квадратичную аппроксимацию лосса: дерево строится так, чтобы наилучшим образом уменьшить сумму grad и hess вкладов по объектам, где градиенты задают направление исправления ошибок, а гессианы - насколько агрессивным может быть это исправление; из этой аппроксимации напрямую выводятся формулы и для выбора сплитов (gain), и для оптимальных весов листьев, что делает обучение и точнее, и стабильнее



🌟 LightGBM (2017, original paper 📑)

🔵Особенность 1 - Histogram-based обучение (binned признаки). Непрерывные величины бьются на бины, дальше сплиты считаются по гистограммам, что резко снижает стоимость поиска сплитов и память

🔵Особенность 2 - Leaf-wise (best-first) рост дерева. LightGBM обычно растит дерево в глубину по самому выгодному листу, а не layer-wise по уровням, из‑за чего при той же глубине может быть быстрее/точнее, но легче переобучиться (нужны ограничения вроде max_depth/num_leaves/min_data_in_leaf)

🔵Особенность 3 - Две ключевые оптимизации: GOSS и EFB. GOSS (Gradient-based One-Side Sampling) для уменьшения числа объектов при оценке gain и EFB (Exclusive Feature Bundling) для склейки взаимно-исключающих sparse фич (например one-hot), чтобы уменьшить effective features



🌟 CatBoost (2019, original paper 📑)

🔵Особенность 1 - Ordered boosting. Обучающие градиенты/статистики строятся по перестановке (permutation), чтобы снизить специфический target leakage, который возникает в классическом бустинге при некоторых схемах использования таргета/статистик

🔵Особенность 2 - Ordered target statistics / target encoding для categorical фичей. Категориальные признаки обрабатываются через целевые статистики по таргету, рассчитанные аккуратно (в ordered-порядке), чтобы не подглядывать в истинный таргет текущего объекта

🔵Особенность 3 - Симметричные деревья. Деревья одной структуры на уровне (один и тот же split на каждом уровне) дают быстрый инференс и удобную реализацию/векторизацию, ценой ограничений на класс деревьев (это часто ключ к скорости CatBoost на CPU)


⚡️ Кейс 2 - System design

Это свежий кейс с недавнего собеса. Кандидату надо было показать и рассказать, как бы он собрал RAG Pipeline удобного QnA поиска по корпоративной JIRA, и его итоговый результат на картинке (последняя картинка 🖼). Вы уже могли заметить проблемы в схеме, особенно если помните эту публикацию 💡, в которой детально разобрано, что надо реализовывать и как улучшать.

Вообще, вес секции system design сейчас подрос, особенно на middle+ позиции. И конечно одна из причин - активное внедрение copilots и coding agents. Становится критически важно держать в голове полную схем проекта, даже при разработке маленькой его части. Кстати, уже поднимал эту тему и писал об этом здесь 💡.


Всем сильных собесов 💪 и усидчивости при подготовке