Все думают, что для локального LLM нужен **один дорогой GPU с большой VRAM**. На практике часто выгоднее собрать память из нескольких карт и не переплачивать за «топ» 👇
У человека уже была `RTX 4080` на 16 ГБ — для игр ок, для тяжёлых моделей мало. Вместо покупки новой флагманской карты он взял **серверный GPU за £200**, подключил его через адаптер и получил **32 ГБ VRAM в системе**.
Итог: на двух GPU крутится модель на **27 млрд параметров** со скоростью около `32 tok/s`.
Вывод для тех, кто считает бюджеты, а не железки: в задачах ML/AI часто важнее __собрать рабочую конфигурацию__, чем гнаться за одной «идеальной» видеокартой. То же самое и в таргете: не всегда нужен один большой бюджет — иногда эффективнее связка из нескольких сегментов, креативов и событий, которые вместе дают нужный результат.
У человека уже была `RTX 4080` на 16 ГБ — для игр ок, для тяжёлых моделей мало. Вместо покупки новой флагманской карты он взял **серверный GPU за £200**, подключил его через адаптер и получил **32 ГБ VRAM в системе**.
Итог: на двух GPU крутится модель на **27 млрд параметров** со скоростью около `32 tok/s`.
Вывод для тех, кто считает бюджеты, а не железки: в задачах ML/AI часто важнее __собрать рабочую конфигурацию__, чем гнаться за одной «идеальной» видеокартой. То же самое и в таргете: не всегда нужен один большой бюджет — иногда эффективнее связка из нескольких сегментов, креативов и событий, которые вместе дают нужный результат.
Все думают, что для диагностики Wi‑Fi нужен ноутбук, ноутбук и ещё раз ноутбук. На практике в полях чаще не хватает не железа, а _быстрого_ доступа к данным.
В Yandex Infrastructure сделали мобильные сканеры для iOS и Android: `WiFi Prober` и `WiProber`. Это не «приложение для галочки», а рабочий комбайн для NOC и сетевиков: собрать параметры сети на точке, понять, где просел сигнал, увидеть, что происходит с Wi‑Fi, и не гонять инженера на каждый чих.
Интересный момент — продукт сначала был внутренним инструментом для удалённых офисов, складов и дарксторов, а потом его выкатили в общий доступ. Это хороший пример, когда _операционная боль_ рождает нормальный полевой софт, а не очередной «удобный дашборд» 🙃
Для таргета и e-commerce тут тот же принцип: чем ближе инструмент к точке проблемы, тем быстрее решение. Не «соберём отчёт завтра», а сразу увидим, где ломается цепочка.
—
Рядом по теме: @PaidAdsPro (там про performance маркетинг)
В Yandex Infrastructure сделали мобильные сканеры для iOS и Android: `WiFi Prober` и `WiProber`. Это не «приложение для галочки», а рабочий комбайн для NOC и сетевиков: собрать параметры сети на точке, понять, где просел сигнал, увидеть, что происходит с Wi‑Fi, и не гонять инженера на каждый чих.
Интересный момент — продукт сначала был внутренним инструментом для удалённых офисов, складов и дарксторов, а потом его выкатили в общий доступ. Это хороший пример, когда _операционная боль_ рождает нормальный полевой софт, а не очередной «удобный дашборд» 🙃
Для таргета и e-commerce тут тот же принцип: чем ближе инструмент к точке проблемы, тем быстрее решение. Не «соберём отчёт завтра», а сразу увидим, где ломается цепочка.
—
Рядом по теме: @PaidAdsPro (там про performance маркетинг)
Все думают, что ИИ в разработке — это уже почти бесплатный способ «сделать быстрее». На практике чаще выходит наоборот: **меняется не скорость, а видимость работы**.
Менеджмент требует агентов, воркшопы, инструкции, новые пайплайны. Внешне — прогресс. Внутри — разработчик тратит время не на решение задачи, а на **проверку, правки и разбор чужих галлюцинаций**.
В таргете ровно такая же история с «автоматизацией ради автоматизации».
Все хотят `автоправила`, `AI-оптимизацию`, «пусть система сама найдёт связку». А потом выясняется, что без нормальной гипотезы, сегмента и контроля событий это просто дорогой способ быстрее сжигать бюджет.
**Инструмент не заменяет мышление.**
Он ускоряет только то, что уже умеет работать.
Если у вас нет базы — пикселя, событий, чистых аудиторий, понятной структуры тестов — ИИ не спасёт. Он просто масштабирует хаос.
Менеджмент требует агентов, воркшопы, инструкции, новые пайплайны. Внешне — прогресс. Внутри — разработчик тратит время не на решение задачи, а на **проверку, правки и разбор чужих галлюцинаций**.
В таргете ровно такая же история с «автоматизацией ради автоматизации».
Все хотят `автоправила`, `AI-оптимизацию`, «пусть система сама найдёт связку». А потом выясняется, что без нормальной гипотезы, сегмента и контроля событий это просто дорогой способ быстрее сжигать бюджет.
**Инструмент не заменяет мышление.**
Он ускоряет только то, что уже умеет работать.
Если у вас нет базы — пикселя, событий, чистых аудиторий, понятной структуры тестов — ИИ не спасёт. Он просто масштабирует хаос.
Все думают: если инструмент «из коробки», значит он недонастроен. На практике часто наоборот — **лишняя кастомизация съедает время и ломает стабильность**.
В таргете это видно постоянно:
люди месяцами шлифуют `сегменты`, `события`, `UTM`, `look-alike`, меняют структуру кампаний — а потом не могут понять, **что реально дало рост**. Потому что тест превратился в ритуал, а не в систему.
Параллель из Linux очень точная:
необязательно строить сложный стек, если базовая связка уже решает задачу. В рекламе это значит:
**сначала рабочая схема, потом оптимизация**.
Не 15 скриптов и 8 костылей, а понятная воронка, нормальный пиксель, чистые аудитории и креативы, которые можно сравнивать.
Часто лучший апгрейд — это не ещё одна настройка, а **убрать лишнее**.
В таргете это видно постоянно:
люди месяцами шлифуют `сегменты`, `события`, `UTM`, `look-alike`, меняют структуру кампаний — а потом не могут понять, **что реально дало рост**. Потому что тест превратился в ритуал, а не в систему.
Параллель из Linux очень точная:
необязательно строить сложный стек, если базовая связка уже решает задачу. В рекламе это значит:
**сначала рабочая схема, потом оптимизация**.
Не 15 скриптов и 8 костылей, а понятная воронка, нормальный пиксель, чистые аудитории и креативы, которые можно сравнивать.
Часто лучший апгрейд — это не ещё одна настройка, а **убрать лишнее**.
Все привыкли списывать хроническую усталость на рекламу, дедлайны и «просто недоспал». Но есть неудобная версия: **не всегда дело в нагрузке**.
Все больше данных показывает, что после ковида у части людей остаются не «разовые хвосты», а системные симптомы:
— постоянная усталость
— туман в голове
— непереносимость нагрузки
— скачки давления
— странные сосудистые реакции
Почему это важно для нас, не врачей? Потому что мейнстримовый ответ «да просто выгорел» часто закрывает реальную причину. А если проблема не в режиме, а в последствиях инфекции, то **отдых, кофе и отпуск не решают вопрос**.
На практике это хороший пример того, как организм может долго молчать и потом начать сыпать сигналами, которые легко перепутать с обычным стрессом. И именно поэтому такие симптомы лучше не героизировать.
Если усталость стала фоном, а не исключением — это уже не про лень и не про слабую дисциплину. Это повод разбираться глубже.
Все больше данных показывает, что после ковида у части людей остаются не «разовые хвосты», а системные симптомы:
— постоянная усталость
— туман в голове
— непереносимость нагрузки
— скачки давления
— странные сосудистые реакции
Почему это важно для нас, не врачей? Потому что мейнстримовый ответ «да просто выгорел» часто закрывает реальную причину. А если проблема не в режиме, а в последствиях инфекции, то **отдых, кофе и отпуск не решают вопрос**.
На практике это хороший пример того, как организм может долго молчать и потом начать сыпать сигналами, которые легко перепутать с обычным стрессом. И именно поэтому такие симптомы лучше не героизировать.
Если усталость стала фоном, а не исключением — это уже не про лень и не про слабую дисциплину. Это повод разбираться глубже.
В таргете многие до сих пор ищут «одну правильную связку»: один кабинет, одна аудитория, один креатив, один бюджет. Китайский подход к ракетам — хороший антипример этой логики.
Там не ставят на один «Falcon 9-клон» и не ждут чуда. Параллельно тестируют несколько конструкций, двигателей и топлив — чтобы быстрее понять, что реально работает, а что красиво выглядит на бумаге. 🚀
В paid ads это ровно то же самое:
не один look-alike на всю воронку,
не один ретаргетинг на все сегменты,
не один креатив «на удачу».
Нормальная стратегия — это набор гипотез, запущенных одновременно:
— разные аудитории
— разные офферы
— разные форматы
— разные окна ретаргета
Парадокс в том, что «дешевле» почти всегда оказывается дороже, если тестировать по одной версии. Вы проигрываете не в CPC — вы проигрываете во времени и количестве выводов.
В сильных проектах выигрывает не тот, кто дольше ждет, а тот, кто быстрее собирает статистику по нескольким вариантам и режет слабые связки без жалости.
Там не ставят на один «Falcon 9-клон» и не ждут чуда. Параллельно тестируют несколько конструкций, двигателей и топлив — чтобы быстрее понять, что реально работает, а что красиво выглядит на бумаге. 🚀
В paid ads это ровно то же самое:
не один look-alike на всю воронку,
не один ретаргетинг на все сегменты,
не один креатив «на удачу».
Нормальная стратегия — это набор гипотез, запущенных одновременно:
— разные аудитории
— разные офферы
— разные форматы
— разные окна ретаргета
Парадокс в том, что «дешевле» почти всегда оказывается дороже, если тестировать по одной версии. Вы проигрываете не в CPC — вы проигрываете во времени и количестве выводов.
В сильных проектах выигрывает не тот, кто дольше ждет, а тот, кто быстрее собирает статистику по нескольким вариантам и режет слабые связки без жалости.
Пока все обсуждают «страшный сбор данных», полезнее смотреть на механику холодно: любой сто́р, лаунчер или предустановленное приложение — это не магия, а набор событий, разрешений и точек доступа к атрибуции.
Если разбирать такие кейсы как performance-специалист, вопрос не в панике, а в рисках для экосистемы:
— какие permission’ы реально нужны для функции,
— что уходит в фон без пользовательского действия,
— где заканчивается удобство и начинается лишний сбор сигналов,
— как это влияет на доверие к рекламным связкам и постклик-аналитике.
Для таргетолога здесь есть важный вывод: чем больше «серых» системных событий, тем хуже качество сигналов для оптимизации. Платформа любит простые, чистые события — install, lead, purchase, add_to_cart. А когда вокруг них много фоновой активности, алгоритм может оптимизироваться не туда.
Практический контраргумент мейнстриму простой: не надо строить медиаплан на допущении, что «данных и так хватит». Проверяйте, откуда приходит событие, чем оно подтверждено и можно ли его повторить в сплите. Именно там чаще всего и ломается эффективность 👀
Если разбирать такие кейсы как performance-специалист, вопрос не в панике, а в рисках для экосистемы:
— какие permission’ы реально нужны для функции,
— что уходит в фон без пользовательского действия,
— где заканчивается удобство и начинается лишний сбор сигналов,
— как это влияет на доверие к рекламным связкам и постклик-аналитике.
Для таргетолога здесь есть важный вывод: чем больше «серых» системных событий, тем хуже качество сигналов для оптимизации. Платформа любит простые, чистые события — install, lead, purchase, add_to_cart. А когда вокруг них много фоновой активности, алгоритм может оптимизироваться не туда.
Практический контраргумент мейнстриму простой: не надо строить медиаплан на допущении, что «данных и так хватит». Проверяйте, откуда приходит событие, чем оно подтверждено и можно ли его повторить в сплите. Именно там чаще всего и ломается эффективность 👀
«Покажи чертёж нормально» — это как «сделай ретаргетинг, чтобы он просто работал».
Звучит просто. А потом выясняется, что у каждого вьюера свой рендер, своя логика отображения и свой набор сюрпризов. И вот ты уже не смотришь на задачу как на “рисовалку”, а на проблему совместимости, производительности и контроля результата.
В performance это очень знакомая история. Мейнстрим-совет обычно такой: подключи готовый сервис, поставь бюджет и не трогай. Но в реальности именно «простые» слои — пиксель, события, сегменты, look-alike — чаще всего и ломают экономику. Не потому что инструмент плохой, а потому что логика внутри не совпадает с ожиданием.
Хорошая практика здесь одна: не верить интерфейсу на слово. Проверять, как именно событие доезжает, что видит платформа, где теряется сигнал и как это влияет на CPC и конверсию. И только потом масштабировать.
Проблема редко в том, что “чертёж не открывается”. Чаще — в том, что его открывают не тем способом. 🔧
Звучит просто. А потом выясняется, что у каждого вьюера свой рендер, своя логика отображения и свой набор сюрпризов. И вот ты уже не смотришь на задачу как на “рисовалку”, а на проблему совместимости, производительности и контроля результата.
В performance это очень знакомая история. Мейнстрим-совет обычно такой: подключи готовый сервис, поставь бюджет и не трогай. Но в реальности именно «простые» слои — пиксель, события, сегменты, look-alike — чаще всего и ломают экономику. Не потому что инструмент плохой, а потому что логика внутри не совпадает с ожиданием.
Хорошая практика здесь одна: не верить интерфейсу на слово. Проверять, как именно событие доезжает, что видит платформа, где теряется сигнал и как это влияет на CPC и конверсию. И только потом масштабировать.
Проблема редко в том, что “чертёж не открывается”. Чаще — в том, что его открывают не тем способом. 🔧
Пока все спорят, как «безопасно подтвердить возраст», рынок снова пытается решить задачу через тяжелую идентификацию: документы, биометрию, лишние согласия, высокий риск отказов.
Но для performance-маркетинга здесь важнее другой вопрос: что будет с воронкой, если на входе появится лишний friction?
Любая проверка возраста, которая просит пользователя сделать лишний шаг, почти всегда бьет по конверсии сильнее, чем кажется в теории. Особенно в leadgen и e-commerce: растет drop-off, дорожает CPC по цепочке, а ретаргетинг получает меньше качественных событий для обучения.
Контринтуитивный вывод простой: не всегда нужно «проверять всех». Иногда эффективнее строить ограничения на уровне сегментов, креативов, посадочных и событийной логики — и не тащить сложную верификацию туда, где она убивает CR.
Если задача про compliance, а не про красивую технологию, сначала считайте потери в конверсии. И только потом — риски утечек. 🔍
Но для performance-маркетинга здесь важнее другой вопрос: что будет с воронкой, если на входе появится лишний friction?
Любая проверка возраста, которая просит пользователя сделать лишний шаг, почти всегда бьет по конверсии сильнее, чем кажется в теории. Особенно в leadgen и e-commerce: растет drop-off, дорожает CPC по цепочке, а ретаргетинг получает меньше качественных событий для обучения.
Контринтуитивный вывод простой: не всегда нужно «проверять всех». Иногда эффективнее строить ограничения на уровне сегментов, креативов, посадочных и событийной логики — и не тащить сложную верификацию туда, где она убивает CR.
Если задача про compliance, а не про красивую технологию, сначала считайте потери в конверсии. И только потом — риски утечек. 🔍
Дашборды часто переоценивают.
В агентствах и у рекламодателей я много раз видел один и тот же сценарий: отчёт собрали, KPI вывели, доступы выдали — и кажется, что управление наконец «оцифровали». Но через 2–4 недели команда всё равно живёт в чатах, Excel и созвонах.
Почему так? Потому что дашборд — это не система принятия решений, а витрина. Он показывает, что уже произошло. Но не отвечает на главный вопрос: что меняем в VK Ads прямо сейчас?
Если в процессе не зашиты правила, дашборд ничего не решит:
— какой CPL считаем критичным,
— при каком CPC останавливаем креатив,
— когда чистим сегмент,
— что делаем, если ретаргетинг выгорел.
Без этого BI превращается в красивый справочник. Его открывают, чтобы подтвердить уже готовую версию, а не чтобы принять решение.
Нормальная аналитика в paid ads начинается не с графика, а с регламента: какие метрики смотрим, кто и на что реагирует, какой следующий шаг делаем при отклонении. Тогда отчёт становится частью управления, а не просто экраном с цифрами 📊
В агентствах и у рекламодателей я много раз видел один и тот же сценарий: отчёт собрали, KPI вывели, доступы выдали — и кажется, что управление наконец «оцифровали». Но через 2–4 недели команда всё равно живёт в чатах, Excel и созвонах.
Почему так? Потому что дашборд — это не система принятия решений, а витрина. Он показывает, что уже произошло. Но не отвечает на главный вопрос: что меняем в VK Ads прямо сейчас?
Если в процессе не зашиты правила, дашборд ничего не решит:
— какой CPL считаем критичным,
— при каком CPC останавливаем креатив,
— когда чистим сегмент,
— что делаем, если ретаргетинг выгорел.
Без этого BI превращается в красивый справочник. Его открывают, чтобы подтвердить уже готовую версию, а не чтобы принять решение.
Нормальная аналитика в paid ads начинается не с графика, а с регламента: какие метрики смотрим, кто и на что реагирует, какой следующий шаг делаем при отклонении. Тогда отчёт становится частью управления, а не просто экраном с цифрами 📊