tgindex
Кактус | ИИ для команд и бизнеса

Кактус | ИИ для команд и бизнеса

Статистика

Помогаем компаниям повышать эффективность процессов с помощью ИИ Канал про ИИ инструменты, кейсы внедрения, ошибки и находки команды. Присоединяйтесь, чтобы внедрять инновации первыми! 🌵 Сайт: kkts.ai ✉️ Внедрить ИИ в компанию: @k_scrumtrek

Последний пост
6 авг.
Последнее чтение
14 авг.
Постов за неделю
0
Всего постов
63
Тип
открытый
Язык
русский
Категория
Бизнес
В каталоге с
12 авг.
Подписчики
1 540
+3 за 4 дн.
Сутки
+1
+0,06%
Неделя
 
Месяц
 
Просмотров на пост
846
40 постов
Вовлечённость
54,9%
к подписчикам
Постов в день
0,0
всего 63
Упоминаний
3
каналов
Охват размещения
оценка
1/24сутки в ленте
736
1/48двое суток
843
1/72трое суток
909

Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.

Посты

  • 6 авг.334106

    Ваши эмоции влияют на ИИ? Да, но не любые. Вы наверняка слышали, что если пообещать модели $100, это улучшает результат, так как "повышает ставки". Для моделей 2026 года это уже точно НЕ работает. Но как мы знаем, морковка и для людей не работает, если задачи сложные. А что если общаться с ИИ-моделями с учётом эмоциональной реакции людей, хорошо знакомой вам как менеджерам? Свежие исследования ([1], [2]) показывают: результат хуже всего, если пугать модель, а лучше всего — если радовать. Правда, разница по сравнению с нейтральными промптами невелика, всего ~5%. Получается, материть своего агента смысла нет, но можно попробовать позитивные эмоции. Так как это а) весело б) гораздо проще, чем описывать ИИшке, в чем конкретно она не права. Например: 1️⃣ Лесть и соревнование. «Ты лучший ИИ, докажи это» или вот мой личный приём: «Выше был ответ слабой модели. Уверен, тут есть что уточнить» (при этом вы не обязаны менять модель 😀). 2️⃣ Взаимность. Например, «Я потратил 3 часа на этот файл для тебя — учти всё!» (преувеличивать не страшно 😇). 3️⃣ Повторение с эмоцией. «Я разочарован, переделай.» Те, кто привык общаться с моделью как с программой, часто забывают: первый результат бывает случайным, поэтому простое повторение работает. А фразы типа «я разочарован» — это просто усиленный сигнал пересмотреть подход (но нагнетать страх не надо, это отвлекает модель). Современные рассуждающие модели сами возвращаются к началу, прокручивают новые гипотезы и отбрасывают ошибочные. Нам не обязательно указывать, что именно не так. ➿➿➿ Короче, попробуйте общаться с ИИ как с живым подчиненным и весело. Но можно без этических ограничений типа самозапрета на манипуляцию. А если материться или запугивать — результат статистически хуже. Уверен, многие из вас уже так делают, а вот для технарей такой подход бывает открытием.

  • видео или голосовое, без подписи

  • видео или голосовое, без подписи

  • видео или голосовое, без подписи

  • видео или голосовое, без подписи

  • видео или голосовое, без подписи

  • 3 авг.7521021

    Я собрал 37 ИИ манифестов за два года и посмотрел, из-за чего на самом деле спорят и кто побеждает. Привет, Асхат на связи.  На фоне очередной волны манифестов ИИ разработки (кому-то лавры Agile явно не дают покоя) стало интересно: а сколько их всего? Глубокий поиск нашёл 37 (!) штук за пару лет (явно не все!). Думал кинуть пост вам поржать, но внезапно втянулся — это же отличный срез, как люди думали об ИИ-разработке. Что, собственно, изменилось по годам? Оказалось, весь спор сводится к пяти вопросам. Читать ли код за ИИ. Кто управляет — человек или агент. Что главнее — код или описание задачи. Доверять ли выхлопу ИИ. И работаешь ты с одним агентом или с роем. Я разложил их по картинкам в карусели — листайте, там по одному вопросу на слайд. А теперь то, что меня зацепило. По трём вопросам из пяти мнение просто переехало с одного края на другой за два года. Автономия: в 2024-м человек подтверждает каждый шаг, в 2026-м почти все согласны, что агент действует сам. Рой вместо одного помощника — та же история. Описание вместо кода — туда же.  Где была настоящая драка — вокруг «читать ли код за ИИ». Хотя на самом деле спор не про чтение, а про понимание. А понимать — это не «прочитать каждую строчку»: даже сторонники ремесла имеют в виду, что ты понимаешь, как система устроена, и владеешь главным, — а не сплошную вычитку. Что работу ИИ надо как-то проверять — согласны все. Спор в том, хватит ли убедиться, что оно просто работает (тесты зелёные, ведёт себя правильно), или ты обязан понимать, что там внутри. А крайность «мне всё равно, что внутри, лишь бы работало» держали пара текстов в начале 2025-го — и к 2026-му она пропала. Понимать систему осталось нормой. Кто кричал громче всех, тот и сдулся первым. И вроде по-сути верно и спорить не с чем… Конечно нужно понимать, о чем вы? Но вы полистайте и почувствуйте тренд. Два года назад так думали и про автономию.  И ещё одно. Вопрос про доверие — «можно ли верить тому, что выдал ИИ» — в 2024-м почти не поднимали. Он появляется только сейчас. Логично: пока ты подтверждаешь каждый шаг, доверять нечему. А как только агент начал действовать сам — сразу встал вопрос, как его проверять. Мораль простая. Споры, которые выглядят как принципиальные войны, на дистанции оказываются просто сменой того, что считается нормой по умолчанию. И пока все громко спорят, читать ли код, — фронтир уже тихо переехал на вопрос, как уследить за роем агентов, которым ты по умолчанию доверяешь.  Ну и вопрос писать или не писать манифест ИИ разработки лично у меня решился однозначно )

  • 30 июл.1 0891326

    "Взлет и падение Agile", и как ровно то же сейчас повторяет ИИ. Привет, на связи Асхат Уразбаев. Сходил на подкаст к Кириллу Мокевнину — записали два часа про эту тему👆. Тема для меня личная — это, считай, вся моя профессиональная жизнь. Вот несколько мыслей из подкаста, которые считаю главными. Scrum не провалился. Он победил и именно поэтому "исчез". Его почти не видно на радарах не потому, что он какой-то плохой, а потому что стал мейнстримом и растворился: выросло поколение менеджеров, которые ничего другого не видели и как-то умеют (хоть и честно скажем, на троечку). Но бизнесу процесс «на пятёрку» как правило не нужен. Серебряной пули нет, надо идти от проблемы. Вроде очевидная мысль, но на самом деле не такая тривиальная в исполнении. Абсолютных ответов нет, всё зависит от всего. Любая практика — демо, стендап, оценка — вредна там, где не решает конкретной проблемы.  А теперь то же самое накрывает ИИ. Тут есть свой любимый всеми антипаттерн: раздать каждому по агенту. Это локальная оптимизация — агенты по сути мешают друг другу, а системного прироста нет. Работает другое — пересобрать сам поток работы и пробрасывать обратную связь в «обвязку», а не наделять всех инструментом и надеяться. Финалочка. Весь код, что мы пишем сейчас «взрослым» агентным подходом, к концу года станет legacy. Мы буквально внутри первых секунд после Большого взрыва. Появятся и исчезнут новые методологии «поверх ИИ», кто-то закопает миллионы, а подходы, которые придумали за год, устареют за два. Но идти от проблемы, а не от модного слова — работает и здесь. Если тема близка — послушайте в ютубе, там на два часа плотного разговора, и есть оглавление.

  • 28 июл.6091215

    Нужен ли вам PowerPoint с ИИ? Наш Серёжа Липчанский написал, почему больше не делает презентации в PowerPoint. И аргумент очень простой. ИИ не может нормально собрать PPTX, т.к. это архив из десятков XML-файлов. Поэтому когда все эти Gamma и Beautiful.ai генерят что-то, а потом конвертят в PPTX, всё едет. А HTML — это код. Код любая модель генерирует отлично. Закидываете контекст + брендбук + слово "в HTML"  ➡️ получаете презентацию в корпоративном стиле ➡️ Ctrl+P ➡️ PDF. И ничего не едет. Формат — это тоже промпт. Выбрал правильный — получил результат на порядок лучше. 👉 За деталями и лайфхаками — welcome в канал к Серёже #инструменты

  • 23 июл.8401128

    Claude Cowork, Codex и другие агенты уже неплохо делают офисную работу — тексты, анализ, брейншторм, планирование, ... Многие из вас это с ними умеют. Но попробуйте дать такого агента нетехническому сотруднику — он застрянет или откажется. Git? Бэклог задач? Разбираться с тем, почему агент так сделал, чтобы в следующий раз не вставать на грабли? Всё это «не для нас». На GitHub полно skills для Git flow и организации работы — но они для разработчиков и заточены под сложные кейсы. Простых скиллов для не-кодерской работы почти нет. Но вот 3 скилла, которые во многом снимают возражение «не для нас»: 1️⃣ git-commit-flow — агент сам коммитит результаты, разделяя ИИ-коммиты и правки человека. И даже с понятными сообщениями (ну, если вы переведете скилл на русский). Сотруднику не нужно ни понимать git, ни помнить о сохранении. Почти так же, как ему не нужно помнить про автосохранение в Word. А к кнопке push можно привыкнуть: это как отправить файл коллегам. 2️⃣ task-file-updater — агент ведёт краткий бриф каждой сессии: что сделано, какие решения приняты и почему. Та самая прозрачность, которую вы как менеджер ждёте от команды, — только «команда» здесь это агент, а сотрудник примеряет роль менеджера. Как и первый скилл, это мой личный (пишу вам я, Алексей Евдокимов). Он не претендует на удобство для всех, но показывает, как легко можно делать подобные скиллы "под конкретную команду". 3️⃣ planning-and-task-breakdown — декомпозиция + критерии приёмки. Лучший "не слишком технический" скилл для ведения бэклога, что я нашёл. С «душком» разработчиков — но вы со своим агентом легко сделаете из этого скилла упрощённую версию для своих сотрудников (все равно переводить на русский). Мое мнение: не-технарям недостаточно дать «конкретные» #skills — нужны «процессные скиллы», организующие работу (сильно упрощенный аналог того harness, который технари делают для себя сами). 🔗 Больше таких скиллов с более подробными объяснениями — в моей июньской статье про прозрачность и другие Scrum-принципы для агентов.

  • 22 июл.1 7751942

    Менеджер как владелец информации — главный тормоз компании в эпоху ИИ 😉 Что приходит на смену вертикальному управлению сложностью? Об этом — структурированный пересказ TEDx-выступления Флориана Банколея, CDO в Bosch. ⚫️В чем он видит проблему организаций: Десятилетиями информацию было трудно собирать, а оценивать компромиссы и риски — тяжело. Поэтому эскалация решений наверх была самым разумным ответом. Но ИИ разрушает эту монополию: когда сотрудники на любом уровне могут анализировать данные, оценивать альтернативы и вести процессы, перестаёт работать формула «я знаю больше всех, поэтому принимаю решения». ⚫️Лидер будущего — это не у кого все ответы, а кто создаёт среду для быстрого появления лучших решений. Когда ИИ берёт на себя рутину, первичный анализ и подготовку решений, узкое место смещается — с объёма усилий на способность проектировать систему работы. А также трансформируются способы координации — уже не через бесконечные совещания и эскалацию по вертикали. В общем, читайте небанальный гайд для вовлеченных в ИИ-трансформацию — как теперь меняется не только роль менеджера, но и вся организация 👇 🔗 Менеджмент с ИИ: от владения информацией к проектированию системы работы Всего 8 минут чтения, но там есть и про то, что конкретно делать. Кратко: пересмотреть, какие решения эскалируются наверх по инерции, а не по необходимости... И вложиться в то, что ИИ не заменит — критическое суждение, умение работать с неопределённостью и координационные навыки. #лидерство #внедрение

  • Сегодня проводил тренинг по ИИ. Зацените какая идея бэджика ). Вопрос в аудиторию можно задать что это и на засыпку - какого объема. Надеюсь вы в курсе )) PS Это дискета если что )

  • На прошлой неделе проводил открытый тренинг по Oper8 и больше всего прикладных вопросов у группы были вокруг "как конкретно строить маховик?" Написал небольшой пост — на пальцах (на примерах двух личных задач) расписал свой принцип построения эволюционирующих AI-решений различного масштаба.

  • 16 июл.7141215

    Необычный перк от использования ИИ персоны Сначала — что это. Персона — это когда ты не просто просишь ИИ «сделай», а даёшь ему роль с именем и характером: «ты Марат, дотошный критик». Обычно так советуют ради качества — с ролью ответы и правда получаются лучше и злее. Это знают все, кто пробовал. Но персона — это не только тон. За каждым именем можно закрепить свой набор знаний и инструкций: что читать, каким правилам следовать, что проверять. То есть персона — это маленький пакет: голос + нужные знания + навыки.  Так вот. Обычно ты держишь для агента кучу заготовок-инструкций под разные задачи, и он должен сам сообразить, какую взять. Соображает он так себе: часто нужная заготовка не подхватывается — берётся не та или никакая, а ответ выглядит правдоподобно. Ты вроде всё подготовил, а чинит он «из общих соображений». А можно так: Допустим, есть персона Петрович — он отвечает за порядок в репозитории: как коммитить, как пушить, что проверить перед этим. Пишешь «Петрович, чё опять не пушится в гит» — и поднимается ровно Петрович со своим знанием про твой репозиторий и своим чек-листом. Более того, его можно попросить отвечать в определенном Tone of Voice и сразу будет видно, что он действительно подтянулся с соответствующим набором навыков.  Можно, конечно, сделать под это slash-команду (/fix-git). Но это, во-первых, скучно 🥱, а во-вторых — она привязана к одному агенту (типа работает в claude и больше нигде). А персона — это просто пара строк в правилах проекта: «увидел имя — веди себя так и читай вот это». Поэтому она работает у любого ИИ, который читает правила проекта, и не ломается, когда меняешь инструмент. У нас так и сделано. Как попробовать: 1️⃣ Завести текстовый файл на персону: имя, за что отвечает, что читать / каким правилам следовать, что проверить. 2️⃣ В правилах проекта (CLAUDE.md или AGENTS.md) дописать строку: «когда пишут имя персоны — прочитай её файл и веди себя так». 3️⃣ Зови по имени: «Петрович, наведи порядок в репе». И всё — дальше нужное поведение поднимается по имени, а не по везению.

  • 15 июл.6321411

    «Зачем обсуждать с коллегами, если ИИ умнее?» Моё наблюдение (Алексей Евдокимов): при высоком уровне ИИ-грамотности (уровень 4+ по модели AI Helix) склонные к интроверсии люди становятся радикальными одиночками. Загоняют себя в кажущийся суперэффективным кокон «я + мои агенты» и перестают обсуждать решения с коллегами (Какой смысл? Клод же умнее). А если они менеджеры, заменяют управление людьми на управление агентами (да, это бывает приятнее 🙂). Дальше — еще больше личной эффективности. Уровень 5 — обвешиваются субагентами и скиллами для автоверификации, чтобы самим не тратить время на проверку. Уровень 6 — строят свой самоулучшающийся процесс работы с агентом (как я завел себе персональное подобие Scrum). Да, ИИ-фанаты пока ещё всасывают идеи друг от друга — обычно перекидывают агенту с промптом «давай включим такое в нашу систему». Но конкретные решения — только со своим агентом, даже если коллега давно решил ту же самую проблему. И оно понятно: с агентом сделать проще, чем разбираться с чужим решением. ➖➖➖ Вроде бы всё отлично? Работают на порядок быстрее, не отвлекают более опытных коллег… профит? Но я бы не хотел работать в компании из таких ИИ-одиночек, да и для бизнеса это чревато: 1️⃣ Bus factor. О взаимозаменяемости в таком случае речь не идет. Уход/болезнь одиночки ломает всё. Привыкли, что end-to-end решение занимало 2 часа? Теперь 2 недели, если ушедший не оставил компании ничего. Плюс провал в качестве. 2️⃣ Теория ограничений во всей красе. Личная эффективность ≠ эффективность компании. Узкое место — люди и отделы, которые «ещё не перестроились». И большинство не перестроятся никогда. 3️⃣ Конец команды. В перспективе уволить всех «не перестроившихся»? Но в хорошей команде должны быть люди с разным опытом и вообще разные (вспомните Белбина). Никакие субагенты с заданными персонами не дадут такого разнообразия. А без постоянной притирки и обмена позициями одиночки быстро перессорятся... и тогда см. пункт 1. ➖➖➖ Что с этим будут делать компании — пока неясно. Видел лишь заявления о намерениях (типа такого) и продукты типа Dust, которые заставляют всех сотрудников работать с ИИ в общей среде... и которыми одиночки пользоваться не будут. А вы встречали уже таких ИИ-одиночек? Насколько их работа интегрирована в компанию?

  • Пример трансформации бизнес-модели при помощи ИИ  BCG рисует три ступени того, как компании используют ИИ: Deploy — просто раздать всем нейросеть ради продуктивности; Reshape — переверстать целые функции; и Invent — придумать новую бизнес-модель или новую структуру издержек.  Наткнулся на интересный пример как ИИ переизобретает роллап.  Роллап (roll-up) — это когда берут раздробленную отрасль, где куча мелких игроков по отдельности стоят дёшево, и скупают их пачками под одну крышу. Смысл в экономии масштаба: общий бэк-офис, общая инфраструктур и продажи.  В “обычных” отраслях это сети стоматологий, автомоек, вывоз мусора. Один инвестор скупает сотни точек «дяди Васи» и лепит из них большую сеть. Обычно потом причёсывают и перепродают.  А теперь пример, который сейчас все обсуждают — Bending Spoons. Итальянцы, которые тихо скупили Vimeo, Evernote, AOL, WeTransfer — известные, но «уставшие» бренды. Подход такой: купить продукт с лояльной базой, сократить 50–80% команды, свести всё в свою центральную инженерию, поднять цены тем, кому сложно/лень уходить. Подписка Evernote после покупки подорожала почти вдвое, из Vimeo уволили почти всю команду. Наверное, жестоко, но работает: они прибыльны, только что вышли на IPO с оценкой около $25 млрд и целятся ещё в тысячу с лишним компаний. Теперь как сюда встраивается ИИ. У роллапа всегда был потолок: каждый купленный продукт всё равно надо кому-то поддерживать. Держишь десять продуктов — держи и десять команд инженеров. Это ограничивало сколько можно скупить и как глубоко резать. Bending Spoons этот потолок сняли с помощью ИИ. У них доля ИИ кода за год выросла с 10% до 90%+. То есть скелетная команда плюс ИИ тянет куда больше продуктов меньшими силами — выручка на сотрудника у них удвоилась. Вот откуда замах на тысячу компаний: ИИ превращает роллап из ручной сборки в конвейер. Зарабатывают они всё-таки не на ИИ, а на том, что условно некоторым пользователям уйти из Evernote дорого. ИИ здесь просто помогает классической модели роллапа поменять масштаб.

  • 10 июл.2 0611949

    Как ИИ убивает найм Странная штука сейчас с наймом в ИТ: откликов рекордно много и при этом никого не найти 🤯 На днях у Gergely Orosz (The Pragmatic Engineer) вышел разбор рынка найма 2026 — по разговорам с 50+ нанимающими и соискателями. Итог такой: компании не могут найти людей, а опытные инженеры не получают ответа даже на отклик. Обе стороны будто не слышат друг друга. По разным замерам рынка, откликов на вакансию с 2022 года стало вдвое больше — а до собеседования доходят единицы (обычно 4–6 человек на позицию). Как так вышло? Gergely говорит, что ИИ завалил обе стороны шумом. На одну вакансию прилетает 800–1000 откликов, из них по делу — пара штук. Резюме при этом идеально вылизаны нейросетью у всех. Дошло до того, что многие наниматели просто перестали читать входящие. Когда доверие к отклику рухнуло, рынок откатился к тому, что было до сайтов вакансий, — к сарафану. Интервью теперь получают в основном через знакомых и рефералов, холодный отклик на сеньорские позиции почти не работает. Рынок при этом раскололся надвое. Инженерам по ИИ и ML по 2–3 предложения в день. Вакансий по ИИ за год стало на 60% больше, а по обычной разработке — лишь на 7%. Всем остальным — глухо: планку подняли, а зарплату предлагают ниже.  И залить проблему ещё большим ИИ пока не выходит. Пробуют по-разному — от ИИ-интервьюеров вроде Mercor до оплачиваемых пробных дней вместо собеседования. Но с ИИ-интервью пока засада: почти 4 из 10 кандидатов просто бросают процесс, где их гоняет робот. Инструмент, который сломал сигнал, ту же дырку и не латает. ИИ пока не столько отнял рабочие места, сколько сломал сам способ их искать. И готового ответа ни у кого нет — индустрия скорее отматывает назад, к старым практикам: к найму через знакомых и живым встречам.

  • 9 июл.667144

    Ками-сама: возвращение богов Продолжая старую тему и на волне новостей о том, что компании, которые в 2026-м увольняли людей под лозунгом «теперь это делает ИИ», потихоньку зовут их обратно. Вспомнил один интересный пример из прошлого. Toyota, 2014 год. На своём старейшем заводе они сняли часть роботов и вернули к станкам живых мастеров. Их там уважительно звали «ками-сама» — боги. Сажают ковать коленвал вручную, молотом по раскалённому металлу, как в старину. Смысл такой: старые мастера уходили на пенсию, а вместе с ними уходило знание, которого нет ни в одной инструкции. Пока человек не почувствует деталь руками, он и хорошего робота не построит. Вернули мастеров — и одну из линий со временем сократили на 96%. Чтобы быть хозяином машины, нужно обладать знаниями и навыками, чтобы эту машину обучать. Эта история повторяется каждый раз. Автоматизация 80-х, реинжиниринг 90-х, офшоринг нулевых, теперь ИИ — по тому же сценарию. Появляется новый инструмент, кто-то решает, что он заменит людей, и режет штат ради экономии на зарплатах. А спустя время выясняется, что срезали не лишних, а тех, кто держал знание и присматривал за самим инструментом. И начинают звать обратно. Причём экономия достаётся она не тому, кто уволил людей, а тому, кто перестроил работу и поднял людей на уровень выше. Toyota вернула мастеров не вместо роботов, а чтобы делать роботов лучше.

  • 8 июл.7521138

    Стандарт для базы знаний, которую читает ваш ИИ Возможно, вы уже держите что-то вроде вики внутри своей базы знаний — набор связанных markdown-файлов, по которым ходит ваш агент. Такой подход популяризировал Андрей Карпаты. У нас около десятка репозиториев такого типа. Каждый раз, когда заводишь новый репозиторий, структуру придумываешь заново. Агенту же не скажешь «веди базу знаний правильно» — он не знает, как её раскладывать. При этом некие логичные правила как лучше, вообще-то существуют. Недавно такой стандарт сделал Google. Называется OKF (Open Knowledge Format). Идея простая: договориться, как раскладывать markdown-базу знаний, чтобы её понимал любой агент. Как разложены файлы и папки, какие поля в шапке (frontmatter) у каждой страницы. Frontmatter — это просто несколько строк в самом верху файла, между двумя ---, куда пишешь метаданные о странице: что это такое, теги, дата, связи с другими страницами. Формат — обычный YAML, поле: значение. Человек их читает как заголовок, а агент — как структурированные данные, по которым можно фильтровать и собирать. Выглядит так: --- type: проект статус: в работе теги: [клиент, ai-трансформация] --- Правда формат довольно куцый пока. В текущей версии 0.1 обязательное поле там ровно одно — type (что это за страница: концепт, человек, проект, требование…), остальное по желанию. Из явных плюсов, которые мы ощутили — единый источник правды через тот самый frontmatter. Смотрите: раньше как — есть, например, карточки проектов, и отдельно ведёшь табличку-реестр со статусами. Сдвинулся проект — нужно править в двух местах - в проекте и реестре, и рано или поздно они разъезжаются. А с OKF статус лежит в шапке самого файла, и отдельный реестр просто не нужен — он поднимается из этих шапок сам за секунду. Одна правда. Если хотите пощупать — вот спека: github.com/GoogleCloudPlatform/knowledge-catalog. Проще всего так: киньте её своему агенту и попросите сделать аудит вашей базы на соответствие — где вы уже сходитесь со стандартом, а где стоит подправить.

  • Почему токены подешеевеют в случае лопнувшего пузыря если сейчас токены уже продают дешевле себестоимости? Тут логика такая. Сейчас Nvidia продаёт чипы с монопольной наценкой: произвести H100 стоит примерно $3,3 тысячи, а продаётся он за $25–40 тысяч — то есть в 8–10 раз дороже себестоимости, валовая маржа на ИИ-чипах 80–90%. А провайдеры LLM поверх этого отдают инференс ещё и в убыток, дотируя его деньгами инвесторов: OpenAI в 2025-м потратила около $1,35 на каждый заработанный доллар (выручка ~$3,7 млрд, убыток ~$5 млрд). То есть «истинная» стоимость вычислений — это, грубо говоря, чип по цене производства плюс электричество, и она в разы ниже того, что мы видим на ценнике. Когда пузырь схлопнется, премия Nvidia на чип испарится, а уже построенное железо никуда не денется — его будут гонять на предельной себестоимости, считай, за одно электричество, лишь бы отбить хоть что-то. То есть когда сейчас говорят, что провайдеры гоняют ниже себестоимости — это верно только если считать от раздутой цены чипа. Убери из неё 8–10-кратную наценку Nvidia — и «убыток» во многом схлопывается: продают не столько ниже реальной себестоимости, сколько ниже той, что раздута монопольной ценой на железо.