Оптимизации генерации токенов нейросетей
Пересмотрел статьи с ICLR 2025 и собрал статьи по эффективным нейросетям.
Начнём с авторегрессионного декодирования — спекулятивный декодинг и другие методы всё ещё активно развиваются.
Если не понимаете, зачем это нужно — у меня есть разбор на Habr.
1. DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference
[oral presentation][paper]
При ризонинге (tree-of-thought) и спекулятивном декодинге с генерацией нескольких токенов сразу (как у Medusa) возникает древообразная структура новых токенов. Из-за этого наивная схема вычисления будет загружать общий префикс KV кэшей много раз.
В статье попилили KV кэш на блоки, выпрямили дерево и блочно эффективно генерируют токены, убирая повторные загрузки кеша из VRAM.
2. Faster Cascades via Speculative Decoding
[poster][paper]
Помимо спекулятивного декодинга, есть еще спекулятивные каскады - драфт модель целиком используется для генерации. У них нет верификации, а токены принимаются на основе эвристик (например, уверенности draft модели в следующем токене).
В статье совместили два подхода. Получился спекулятивный декодинг с критериями принятия токенов из каскадов.
3. Judge Decoding: Faster Speculative Sampling Requires Going Beyond Model Alignment
[paper]
Спекулятивный декодинг сравнивает схожесть распределений выхода draft и base моделей, а не правильность токенов в определенном контексте. Из-за этого много токенов отклоняется, даже если они вполне корректны.
В статье авторы дообучили небольшую Judge head на классификацию правильности токена. И заменили критерий принятия: base_model_accept(spec_tokens) OR judge_accept(spec_tokens).
Метрики качества в том же домене не проседают, количество принятых токенов (а значит и ускорение) становится больше.
4. Multi-Draft Speculative Sampling: Canonical Decomposition and Theoretical Limits
[paper]
В спекулятивном декодинге в основном используют одну draft модель. Для нескольких моделей были теоретические выкладки, но без конкретных правил.
В статье выводится формула оптимального критерия принятия для нескольких моделей. Нужно решить LP задачу, где сложность - квадрат размера словаря.
Для упрощения они предлагают Truncated LP схему, где большая часть параметров выставляется в 1 и сводит задачу к настраиваемой сложности s^2.
Количество принятых токенов растет, но замеров ускорения не увидел.
@deploy_ml
Пересмотрел статьи с ICLR 2025 и собрал статьи по эффективным нейросетям.
Начнём с авторегрессионного декодирования — спекулятивный декодинг и другие методы всё ещё активно развиваются.
Если не понимаете, зачем это нужно — у меня есть разбор на Habr.
1. DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference
[oral presentation][paper]
При ризонинге (tree-of-thought) и спекулятивном декодинге с генерацией нескольких токенов сразу (как у Medusa) возникает древообразная структура новых токенов. Из-за этого наивная схема вычисления будет загружать общий префикс KV кэшей много раз.
В статье попилили KV кэш на блоки, выпрямили дерево и блочно эффективно генерируют токены, убирая повторные загрузки кеша из VRAM.
2. Faster Cascades via Speculative Decoding
[poster][paper]
Помимо спекулятивного декодинга, есть еще спекулятивные каскады - драфт модель целиком используется для генерации. У них нет верификации, а токены принимаются на основе эвристик (например, уверенности draft модели в следующем токене).
В статье совместили два подхода. Получился спекулятивный декодинг с критериями принятия токенов из каскадов.
3. Judge Decoding: Faster Speculative Sampling Requires Going Beyond Model Alignment
[paper]
Спекулятивный декодинг сравнивает схожесть распределений выхода draft и base моделей, а не правильность токенов в определенном контексте. Из-за этого много токенов отклоняется, даже если они вполне корректны.
В статье авторы дообучили небольшую Judge head на классификацию правильности токена. И заменили критерий принятия: base_model_accept(spec_tokens) OR judge_accept(spec_tokens).
Метрики качества в том же домене не проседают, количество принятых токенов (а значит и ускорение) становится больше.
4. Multi-Draft Speculative Sampling: Canonical Decomposition and Theoretical Limits
[paper]
В спекулятивном декодинге в основном используют одну draft модель. Для нескольких моделей были теоретические выкладки, но без конкретных правил.
В статье выводится формула оптимального критерия принятия для нескольких моделей. Нужно решить LP задачу, где сложность - квадрат размера словаря.
Для упрощения они предлагают Truncated LP схему, где большая часть параметров выставляется в 1 и сводит задачу к настраиваемой сложности s^2.
Количество принятых токенов растет, но замеров ускорения не увидел.
@deploy_ml
🔥4❤2
Куда развиваются серверные GPU?
Серверные GPU превращаются в супер-вычислители.
Вот как меняются характеристики от поколения к поколению у NVIDIA:
1. Шина CPU<->GPU: PCIe → SXM → NVLink C2C
2. Память: 32 GB (V100) → 80 GB (H100) → 192 GB (B200)
3. NVLink: 600 (A100) → 900 (H100) → 1800 (GB300) Gb/s [link]
4. NVLink full-mesh стойки: NVL72
5. Датацентровая сеть: 200Gb/s infiniband -> 400Gb/s BlueField
Все эти улучшения идут в том числе за счет увеличения тепла:
1. 450Watt A100 SXM -> 700Watt on B200 SXM
2. 6500Watt A100 DGX -> 10200Watt B200 DGX
Как это влияет на сервера и датацентры?
1. Air -> Liquid.
DGX H-серии были последними, что использовали воздушное охлаждение.
GPU B-серии требуют жидкостного охлаждения — иначе невозможно обеспечить плотность и мощность.
Хотя данная проблема появилась раньше, когда начали пытаться уместить 4-8х 4090 в 4U короб.
2. Direct-to-Chip (D2C) охлаждение с водоблоками + контур вывода тепла наружу.
Контур отвода тепла от стоек и контур вывода тепла наружу. Уже сейчас есть выбор серверов с D2C и стартапы, строящие системы охлаждения под ключ.
3. Возможное развитие иммерсивного охлаждения.
Это когда все ваши сервера круглосуточно погружены в ванну с диэлектриком.
Потенциал есть, заявляют лучшую PUE (Power Usage Effectiveness) до 1.02 (где 1.0 - идеально), но массовое внедрение сдерживается практическими ограничениями.
4. Проприетарные стойки (DGX, NVL72).
Экономически оправданы только при полной загрузке. Требуют специфичной инфраструктуры и часто не совместимы с обычными датацентрами.
5. Архитектура ЦоД меняется
Серверов в помещении становится меньше, появляются острова GPU и больше вспомогательной инфраструктуры вокруг. Больше веса, давления, новые требования к зданию и инженерным системам.
На изучить:
1. EdgeConneX - Impacts of Introducing Liquid Cooling into Data Center Infrastructure
2. Schneider Electric - Navigating Liquid Cooling Architectures for Data Centers with AI Workloads
3. Schneider Electric - The Different Technologies for Cooling Data Centers
4. CoolIT Systems - The Impact of Liquid Cooling Technology in AI-Era Data Centers
@deploy_ml
Серверные GPU превращаются в супер-вычислители.
Вот как меняются характеристики от поколения к поколению у NVIDIA:
1. Шина CPU<->GPU: PCIe → SXM → NVLink C2C
2. Память: 32 GB (V100) → 80 GB (H100) → 192 GB (B200)
3. NVLink: 600 (A100) → 900 (H100) → 1800 (GB300) Gb/s [link]
4. NVLink full-mesh стойки: NVL72
5. Датацентровая сеть: 200Gb/s infiniband -> 400Gb/s BlueField
Все эти улучшения идут в том числе за счет увеличения тепла:
1. 450Watt A100 SXM -> 700Watt on B200 SXM
2. 6500Watt A100 DGX -> 10200Watt B200 DGX
Как это влияет на сервера и датацентры?
1. Air -> Liquid.
DGX H-серии были последними, что использовали воздушное охлаждение.
GPU B-серии требуют жидкостного охлаждения — иначе невозможно обеспечить плотность и мощность.
Хотя данная проблема появилась раньше, когда начали пытаться уместить 4-8х 4090 в 4U короб.
2. Direct-to-Chip (D2C) охлаждение с водоблоками + контур вывода тепла наружу.
Контур отвода тепла от стоек и контур вывода тепла наружу. Уже сейчас есть выбор серверов с D2C и стартапы, строящие системы охлаждения под ключ.
3. Возможное развитие иммерсивного охлаждения.
Это когда все ваши сервера круглосуточно погружены в ванну с диэлектриком.
Потенциал есть, заявляют лучшую PUE (Power Usage Effectiveness) до 1.02 (где 1.0 - идеально), но массовое внедрение сдерживается практическими ограничениями.
4. Проприетарные стойки (DGX, NVL72).
Экономически оправданы только при полной загрузке. Требуют специфичной инфраструктуры и часто не совместимы с обычными датацентрами.
5. Архитектура ЦоД меняется
Серверов в помещении становится меньше, появляются острова GPU и больше вспомогательной инфраструктуры вокруг. Больше веса, давления, новые требования к зданию и инженерным системам.
На изучить:
1. EdgeConneX - Impacts of Introducing Liquid Cooling into Data Center Infrastructure
2. Schneider Electric - Navigating Liquid Cooling Architectures for Data Centers with AI Workloads
3. Schneider Electric - The Different Technologies for Cooling Data Centers
4. CoolIT Systems - The Impact of Liquid Cooling Technology in AI-Era Data Centers
@deploy_ml
NVIDIA
Impacts of Introducing Liquid Cooling into Data Center Infrastructure (Presented by EdgeConneX) EXS74208 | GTC 2025 | NVIDIA On…
Explore the drivers and overall impacts of deploying liquid cooling infrastructure into the physical data center
🔥7
Diagonal Batching Unlocks Parallelism in Recurrent Memory Transformers for Long Contexts
[huggingface][arxiv][code]
Выложили статью по оптимизации рекуррентного линейного трансформера (ARMT).
Мы оптимизировали вычисление графа линейного трансформера ARMT. С нашим методом он масштабируется практически как простое увеличение батча на практичных размерах сегментов.
В сочетании с малым использованием памяти (25МБ против 4ГБ для 128к контекста) можно утилизировать современные GPU без сложных техник типа пайплайнинга и одновременно обрабатывать больше запросов.
Будем рады поддержке в виде апвоутов на HF🙈
Нам чуть-чуть до верха рейтинга, проголосовать можно на странице
@deploy_ml
[huggingface][arxiv][code]
Выложили статью по оптимизации рекуррентного линейного трансформера (ARMT).
Мы оптимизировали вычисление графа линейного трансформера ARMT. С нашим методом он масштабируется практически как простое увеличение батча на практичных размерах сегментов.
В сочетании с малым использованием памяти (25МБ против 4ГБ для 128к контекста) можно утилизировать современные GPU без сложных техник типа пайплайнинга и одновременно обрабатывать больше запросов.
Будем рады поддержке в виде апвоутов на HF
Нам чуть-чуть до верха рейтинга, проголосовать можно на странице
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🏆2❤🔥1👍1
Зачем нужен бизнес-сценарий при нагрузочном тестировании?
Когда MVP нового функционала разработан, часто инженеры теряются при постановке задачи нагрузочного тестирования: не ясно, как и что тестировать, как добиться репрезентативности.
Причина в том, что производительность сильно зависит от конкретных сценариев использования и взаимодействия компонент. Общей картины обычно у большинства нет, а сложные коммуникации технари не любят.
Например, для инференса LLM реальны такие сценарии:
1. Короткие запросы,
2. RAG с файлами разного размера,
3. Длинное во времени интерактивное взаимодействие (с офлоадингом KV кешей),
4. Редкие запросы к разным моделям (с офлоадингом весов моделей),
5. Мульти-модельный деплой и деплой модели с большим количеством LoRA-адаптеров.
Каждый сценарий требует отдельных профилей нагрузки (размер контекста, паттерн обращения) и выявляет свои узкие места. End2End-тесты помогают обнаружить эти проблемы заранее, прежде чем о них сообщат пользователи.
Это касается не только инференса, но и любых компонентов: кешей, баз данных, cicd. Узкое место не всегда очевидно — это может быть медленная авторизация, сброс долгих запросов или ошибки взаимодействия микросервисов команд.
Без понимания бизнес-задачи сетапы выбираются как-нибудь.
В итоге команда рискует исправлять не то, что действительно важно.
@deploy_ml
Когда MVP нового функционала разработан, часто инженеры теряются при постановке задачи нагрузочного тестирования: не ясно, как и что тестировать, как добиться репрезентативности.
Причина в том, что производительность сильно зависит от конкретных сценариев использования и взаимодействия компонент. Общей картины обычно у большинства нет, а сложные коммуникации технари не любят.
Например, для инференса LLM реальны такие сценарии:
1. Короткие запросы,
2. RAG с файлами разного размера,
3. Длинное во времени интерактивное взаимодействие (с офлоадингом KV кешей),
4. Редкие запросы к разным моделям (с офлоадингом весов моделей),
5. Мульти-модельный деплой и деплой модели с большим количеством LoRA-адаптеров.
Каждый сценарий требует отдельных профилей нагрузки (размер контекста, паттерн обращения) и выявляет свои узкие места. End2End-тесты помогают обнаружить эти проблемы заранее, прежде чем о них сообщат пользователи.
Это касается не только инференса, но и любых компонентов: кешей, баз данных, cicd. Узкое место не всегда очевидно — это может быть медленная авторизация, сброс долгих запросов или ошибки взаимодействия микросервисов команд.
Без понимания бизнес-задачи сетапы выбираются как-нибудь.
В итоге команда рискует исправлять не то, что действительно важно.
@deploy_ml
❤3🔥3
Обогнали, но "кого?" и "как?". Новые сетевые карточки AMD.
Несколько дней назад вышла новость, что AMD в партнерстве с Oracle Cloud развернет свои UALink (Nvidia NVL72-like) стойки.
У нас эту новость подхватили в контексте новой сетевой карточки AMD Pensando™ Pollara 400 AI, аналога infiniband.
Кратко характеристики:
1. RoCE v2 + UEC 1.0 RDMA
2. До 4х портов. Можно подключить 1x400Gb/s, 2x200Gb/s, 4x100Gb/s
И вы могли слышать, что заявляется выше эффективность по сравнению с конкурентами (так на сайте нарисовано).
Там, как обычно, забавно:
1. Сравниваются они с Nvidia ConnectX-7, вышедшим в 2022 году. И обгоняют его на 10%.
А у Nvidia уже есть серия BlueField и новый ConnectX-8.
2. В релизе дают ссылки на статьи с обоснованиями, почему они круче. Так вот там две статьи:
- Enhancing Large-Scale AI Training Efficiency: The C4 Solution for Real-Time Anomaly Detection and Communication Optimization [arxiv]
- The Llama 3 Herd of Models [arxiv]
Но в обоих статьях AMD не использовали. Там Nvidia BlueField в сетапах, с которым они по производительности не сравниваются.
Вот что пишут на том же релизе в footnote: "Claim reflects technology used in AMD Pensando Pollara 400 NICs, however testing and data not specific to the Pollara 400. Results may vary."
Вот так вот. На самом деле, маркетинг догоняющих продуктов - это очень не просто.
Не сказать же в релизе "мы медленнее, но дешевле и готовы с вами персонально работать" (хотя мне кажется персональность работы в b2b поставках - это куда более конкурентное преимущество, чем 10% к производительности).
И я очень рад, что у AMD появляются конкурентные решения. Им очень не хватало наличия конкурентного аналога infiniband, чтобы иметь замкнутую поставку для обучения и инференса, учитывая крутость последних суперчипов mi300 с большим количеством памяти.
@deploy_ml
Несколько дней назад вышла новость, что AMD в партнерстве с Oracle Cloud развернет свои UALink (Nvidia NVL72-like) стойки.
У нас эту новость подхватили в контексте новой сетевой карточки AMD Pensando™ Pollara 400 AI, аналога infiniband.
Кратко характеристики:
1. RoCE v2 + UEC 1.0 RDMA
2. До 4х портов. Можно подключить 1x400Gb/s, 2x200Gb/s, 4x100Gb/s
И вы могли слышать, что заявляется выше эффективность по сравнению с конкурентами (так на сайте нарисовано).
Там, как обычно, забавно:
1. Сравниваются они с Nvidia ConnectX-7, вышедшим в 2022 году. И обгоняют его на 10%.
А у Nvidia уже есть серия BlueField и новый ConnectX-8.
2. В релизе дают ссылки на статьи с обоснованиями, почему они круче. Так вот там две статьи:
- Enhancing Large-Scale AI Training Efficiency: The C4 Solution for Real-Time Anomaly Detection and Communication Optimization [arxiv]
- The Llama 3 Herd of Models [arxiv]
Но в обоих статьях AMD не использовали. Там Nvidia BlueField в сетапах, с которым они по производительности не сравниваются.
Вот что пишут на том же релизе в footnote: "Claim reflects technology used in AMD Pensando Pollara 400 NICs, however testing and data not specific to the Pollara 400. Results may vary."
Вот так вот. На самом деле, маркетинг догоняющих продуктов - это очень не просто.
Не сказать же в релизе "мы медленнее, но дешевле и готовы с вами персонально работать" (хотя мне кажется персональность работы в b2b поставках - это куда более конкурентное преимущество, чем 10% к производительности).
И я очень рад, что у AMD появляются конкурентные решения. Им очень не хватало наличия конкурентного аналога infiniband, чтобы иметь замкнутую поставку для обучения и инференса, учитывая крутость последних суперчипов mi300 с большим количеством памяти.
@deploy_ml
🔥4⚡2
Замеры MultiLoRA для оффлайн/асинхронного инференса
Опубликовал статью на habr по сравнению функционала MultiLoRA в vllm и TensorRT-LLM.
Интересно, что в релизных докерах результат не в ту сторону, которую вы могли бы подумать - vllm на всех сетапах круче*.
Думал, что дело в настройках TensorRT-LLM, ускорил в 1.2-1.5 раз, но vllm оно так и не догнало (на графиках и табличках замеры уже с оптимизацией)
*сравниваются python3 обертки в сетапе оффлайн/асинхронного инференса. Без интерактивности (потому без time-to-first-token) и сетевой обвязки.
@deploy_ml
Опубликовал статью на habr по сравнению функционала MultiLoRA в vllm и TensorRT-LLM.
Интересно, что в релизных докерах результат не в ту сторону, которую вы могли бы подумать - vllm на всех сетапах круче*.
Думал, что дело в настройках TensorRT-LLM, ускорил в 1.2-1.5 раз, но vllm оно так и не догнало (на графиках и табличках замеры уже с оптимизацией)
*сравниваются python3 обертки в сетапе оффлайн/асинхронного инференса. Без интерактивности (потому без time-to-first-token) и сетевой обвязки.
@deploy_ml
Хабр
Эффективный инференс множества LoRA адаптеров
LoRA — популярный метод дообучения больших моделей на небольших датасетах, однако на этапе инференса низкоранговые адаптеры работают неэффективно, а их объединение с весами требует хранения отдельной...
❤🔥5🔥3🍌1
Летняя школа AIRI
Приехал в Томск чтобы провести пару лекций на летней школе по ИИ от AIRI и заменторить проекты.
Ну и поесть окрошку и варенье из шишек.
4 июля буду читать о практичных инженерных штуках в обучении моделей.
Слайдами тут обязательно поделюсь)
Приехал в Томск чтобы провести пару лекций на летней школе по ИИ от AIRI и заменторить проекты.
Ну и поесть окрошку и варенье из шишек.
4 июля буду читать о практичных инженерных штуках в обучении моделей.
Слайдами тут обязательно поделюсь)
🔥10⚡2❤1
А вот и слайды.
Небольшой обзор по эффективному обучению и релевантным тематикам для студентов с летней школы.
В начале прикладные материалы + материалы для начинающих.
Для тех кто много знает - в конце начинается более инфровая часть и технические репорты.
На многих слайдах внизу есть ссылки на статьи/технические блоги.
Небольшой обзор по эффективному обучению и релевантным тематикам для студентов с летней школы.
В начале прикладные материалы + материалы для начинающих.
Для тех кто много знает - в конце начинается более инфровая часть и технические репорты.
На многих слайдах внизу есть ссылки на статьи/технические блоги.
Google Docs
Final efficient training airi 2025
Практические инструменты эффективного обучения Сивцов Данил Инженер-исследователь, AIRI
🔥10🦄1
Как понять, что «тормозит» DataLoader?
Недавно был задан классный вопрос:
"Может ли малая утилизация CPU означать проблемы с DataLoader?"
Утверждать нельзя, потому что в DataLoader:
1. Утилизируют CPU только аугментации и декодинг файла.
Это, пожалуй, единственная вычислительная нагрузка в нем, и ее может не хватать для создания существенной утилизации.
Декодинг файла - актуально для медиа-данных, хранящихся в сжатом виде.
2. Загрузка файлов - I/O-bound, т.к. представляет из себя ожидание получения очередного блока с сети/диска.
Поэтому и около нулевая утилизация CPU.
Смотреть надо на метрики диска (если чтение локально) или сети (если чтение с общего хранилища).
А для того, чтобы проверить, тормозит ли DataLoader, cравните скорость обучения в трёх вариантах:
1. Бейзлайн: ваш исходный код.
2. Минус аугментации: отключите/упростите тяжёлые трансформации.
3. Синтетика чтения: как в п.2, но данные не читаются с диска/сети — генерируйте случайные тензоры той же формы
4. Синтетика декодирования для image/video/voice: как в п.3, только генерируйте содержимое файла до декодирования.
Интерпретация:
1. Ускорение 1→2 — «тяжёлые» аугментации, оптимизируем их.
2. Ускорение 2→3 — бутылочное горлышко в доступе к данным.
3. Ускорение 4→3 — тормозит декодирование файлов.
4. Ускорения нигде нет — DataLoader вас не тормозит; ищите проблемы в самом тренировочном цикле.
Накидайте реакций/конфигов и сделаю замеры по разным сетапам даталоадеров.
@deploy_ml
Недавно был задан классный вопрос:
"Может ли малая утилизация CPU означать проблемы с DataLoader?"
Утверждать нельзя, потому что в DataLoader:
1. Утилизируют CPU только аугментации и декодинг файла.
Это, пожалуй, единственная вычислительная нагрузка в нем, и ее может не хватать для создания существенной утилизации.
Декодинг файла - актуально для медиа-данных, хранящихся в сжатом виде.
2. Загрузка файлов - I/O-bound, т.к. представляет из себя ожидание получения очередного блока с сети/диска.
Поэтому и около нулевая утилизация CPU.
Смотреть надо на метрики диска (если чтение локально) или сети (если чтение с общего хранилища).
А для того, чтобы проверить, тормозит ли DataLoader, cравните скорость обучения в трёх вариантах:
1. Бейзлайн: ваш исходный код.
2. Минус аугментации: отключите/упростите тяжёлые трансформации.
3. Синтетика чтения: как в п.2, но данные не читаются с диска/сети — генерируйте случайные тензоры той же формы
4. Синтетика декодирования для image/video/voice: как в п.3, только генерируйте содержимое файла до декодирования.
Интерпретация:
1. Ускорение 1→2 — «тяжёлые» аугментации, оптимизируем их.
2. Ускорение 2→3 — бутылочное горлышко в доступе к данным.
3. Ускорение 4→3 — тормозит декодирование файлов.
4. Ускорения нигде нет — DataLoader вас не тормозит; ищите проблемы в самом тренировочном цикле.
Накидайте реакций/конфигов и сделаю замеры по разным сетапам даталоадеров.
@deploy_ml
🔥7❤🔥1
У меня в последнее время подгорает на cursor, потому что
1. На запрос генерируется несколько файлов (код, тесты, readme, скрипты запуска).
2. Проект превращается в свалку файлов от разных запросов.
3. Лимиты на cursor улетают очень быстро. А ведь они недавно еще их и порезали.
Проблема в том, что в одном продукте смешан функционал для разных целевых аудиторий:
1. Вайбкодеры
Надо быстро и под ключ. Чтобы сразу весь проект сделало, скрипты сетапа и запуска. Те самые MVP, которые нужны, чтобы поглядеть как выглядит реализация идеи, выкинуть и сделать хорошо.
2. Профессиональные разработчики
Нужно добавить конкретный узкий функционал. Или даже один конкретный класс или функцию. Возможно несколько запросов подряд для реализации разного функционала.
В итоге интерфейсы и первые скетчи кода я сейчас вынуждено генерирую в chatgpt. И потом довожу их до ума в cursor, вечно добавляя "do not over engineer, make it simple, ...".
И все чаще ловлю себя на мысли "лучше бы сам руками сделал".
А где-то радуется один вайбкодер. И Сэм, пытающийся продать gpt как замену разработчика 😀
@deploy_ml
1. На запрос генерируется несколько файлов (код, тесты, readme, скрипты запуска).
2. Проект превращается в свалку файлов от разных запросов.
3. Лимиты на cursor улетают очень быстро. А ведь они недавно еще их и порезали.
Проблема в том, что в одном продукте смешан функционал для разных целевых аудиторий:
1. Вайбкодеры
Надо быстро и под ключ. Чтобы сразу весь проект сделало, скрипты сетапа и запуска. Те самые MVP, которые нужны, чтобы поглядеть как выглядит реализация идеи, выкинуть и сделать хорошо.
2. Профессиональные разработчики
Нужно добавить конкретный узкий функционал. Или даже один конкретный класс или функцию. Возможно несколько запросов подряд для реализации разного функционала.
В итоге интерфейсы и первые скетчи кода я сейчас вынуждено генерирую в chatgpt. И потом довожу их до ума в cursor, вечно добавляя "do not over engineer, make it simple, ...".
И все чаще ловлю себя на мысли "лучше бы сам руками сделал".
А где-то радуется один вайбкодер. И Сэм, пытающийся продать gpt как замену разработчика 😀
@deploy_ml
😁6🔥4💯3