Проекты в r/LocalLLaMA показывают в регулярном треде Project Showcase, а не отдельным постом. Чтобы презентацию не удалили, нужны четыре вещи: понятное описание без маркетинга, конкретное сравнение с альтернативами, доказательства реального тестирования и подтверждение того, что проект открытый, open source или запускается локально. Закрытые коммерческие сервисы сообщество удаляет.
Ниже разобраны требования к презентации, антипримеры формулировок и готовый каркас поста, который можно заполнить и опубликовать.
Что такое Project Showcase в r/LocalLLaMA и кому он подходит
Project Showcase - регулярный тред в r/LocalLLaMA, где авторы представляют свои проекты. Формат собирает показы в одном месте: сообщество не тонет в потоке анонсов, а читатель заходит в тред, когда готов смотреть новое.
Кто может публиковаться в Project Showcase
В тред логично приносить то, что участник сообщества может запустить на своём железе или прочитать в исходниках. Практически это такие категории:
- обёртки и веб-интерфейсы для локального инференса;
- пайплайны RAG и работа с локальной базой знаний;
- утилиты для запуска, квантования и оценки моделей;
- инструменты для замеров скорости и потребления VRAM;
- скрипты и агенты, которые работают с моделями через локальный API.
Быстрый тест на соответствие: если проект нельзя запустить локально и он не open source, скорее всего его удалят. Промежуточный вариант, когда открыта только часть, требует честного пояснения: что именно лежит в репозитории, а что осталось закрытым.
Чем Project Showcase отличается от обычного поста
Project Showcase - это тред, а не свободная публикация в ленте. Модераторы рекомендуют описывать проект простым языком: что он делает и почему это должно быть интересно пользователям. Дублирование презентации отдельным постом, скорее всего, привлечёт внимание модераторов и приведёт к удалению.
Пишите сам пост на английском: аудитория r/LocalLLaMA англоязычная. Заготовку удобно собрать на русском по шаблону ниже, а потом перевести, сохранив технические названия и команды без перевода.
Точных формальных правил (нумерация тредов, даты публикации, лимит длины поста) в открытых рекомендациях нет. Не выдумывайте пункты, которых не существует, и не ссылайтесь на несуществующие требования.
Как описать проект простым языком: что он делает и почему это интересно
Первое предложение решает больше, чем всё остальное. Читатель треда просматривает десятки анонсов и решает за пару секунд, открывать ли ссылку.
Формула первого абзаца: что, для кого, зачем
Каркас на четыре предложения:
- Что делает проект.
- Для кого он.
- Какую задачу решает.
- Почему это интересно именно аудитории r/LocalLLaMA.
Шаблон: «[Название] - это [тип проекта], который [что делает] для [кого]. Он решает [задачу] и запускается [как и где]».
Заполненный пример на вымышленном проекте, чтобы был виден уровень конкретики: «[Название] - это локальный веб-UI для llama.cpp, который даёт поиск по вашим документам без отправки данных в облако. Он закрывает задачу приватного RAG на домашнем ПК и запускается одной командой в Docker». Подставьте свои факты: тип проекта, задачу, способ запуска. Бенчмарки и цифры выдумывать не нужно, они появляются дальше, в блоке про тестирование.
Какие формулировки убивают интерес к посту
Антипаттерны, на которых сообщество реагирует предсказуемо плохо:
- «революционный AI-инструмент нового поколения»;
- «универсальная платформа для всего»;
- «мы протестировали» без единого сценария и условия запуска;
- кликбейт в заголовке поста, который не подтверждается содержимым;
- общие слова про инновации вместо ответа на вопрос «что это даёт мне».
Конкретика важнее эпитетов. Если проект закрывает узкую задачу, так и напишите: узкая, но честно описанная польза работает лучше расплывчатого обещания универсальности. Заодно проверьте собственные утверждения по первоисточникам: карточке модели, technical report, release notes. Как выстроить такой разбор и не утонуть в потоке новостей, разобрано в материале про Daily Papers на Hugging Face.
Чем ваш проект отличается от альтернатив и почему стоит перейти
Отдельный блок сравнения обязателен: без него пост читается как рекламное объявление, и внимание к нему падает. Нужно назвать существующие решения и объяснить, чем ваше от них отличается и для кого это отличие критично.
Как выбрать альтернативы для сравнения
Берите те решения, которые аудитория r/LocalLLaMA уже знает и использует. Три практичные категории:
- готовые локальные инструменты с похожей функцией;
- облачные сервисы, которые решают ту же задачу;
- самописные скрипты, которыми люди обходятся сейчас.
Сравнивайте по делу, а не по количеству галочек: функциональность, требования к железу, лицензия, сложность первого запуска. О том, как оценивать модель и её условия использования без маркетингового шума, подробно рассказано в разборе критериев оценки новой модели Mistral: лицензия, квантование, локальный запуск и стоимость токенов там идут отдельными пунктами.
Почему стоит перейти: аргументы без давления
Формула перехода: «Если вы используете X и вам важно Y, то [проект] может быть полезен, потому что Z». Причина перехода должна быть конкретной:
- меньше потребление VRAM на том же сценарии;
- данные не покидают машину, телеметрии нет;
- код открыт и его можно править под себя;
- настройка занимает один шаг вместо ручной сборки;
- поддерживается тот формат моделей, который у вас уже скачан.
Универсального превосходства не бывает, и заявлять его не стоит. Перечисляйте ограничения рядом с достоинствами: честная строка «работает только с этим форматом квантования» повышает доверие сильнее, чем обещание всеядности.
Как подтвердить, что проект протестирован, а не собран за пару часов
Сообщество ожидает подтверждения, что проект проверен и работает, а не собран за пару часов с помощью модного AI-инструмента. Скриншот красивого интерфейса ничего не доказывает. Доказывает конкретика: сценарии, условия запуска, известные проблемы.
Какие артефакты показывают реальное тестирование
- ссылка на репозиторий с историей коммитов;
- README с инструкцией запуска, которую можно повторить;
- список протестированных сценариев и условий, в которых они проверялись;
- раздел с известными проблемами и ограничениями;
- требования к железу и версии зависимостей;
- changelog, из которого видно развитие проекта во времени.
Если проверка ограничена, скажите об этом прямо. «Протестировано на одной конфигурации, на других GPU не запускалось» звучит куда лучше, чем молчание, после которого первый же пользователь находит падение.
Как писать о тестировании без ложных заявлений
Рабочие формулировки:
- «Проект протестирован на [сценарий] в [условиях]»;
- «Известные ограничения: ...»;
- «Пока не проверено: ...»;
- «Воспроизводится на [версия] с [зависимости]».
Фразы вроде «мы всё протестировали» без деталей вызывают ровно обратную реакцию. Полезно заранее понимать, чем ограничены любые замеры: у бенчмарка есть методология, набор задач и условия прогона, и эти условия сильно влияют на выводы. Ограничения таких тестов разобраны в статье про бенчмарк Real-SWE и преждевременные выводы из него.
Open source и локальный запуск: что показать, чтобы не удалили
Сообщество ориентировано на открытые, open source и локально запускаемые решения. Закрытые коммерческие сервисы удаляются. Это главный фильтр, и его стоит пройти ещё до написания поста.
Лицензия и репозиторий: что указать в посте
- название лицензии;
- прямую ссылку на исходники;
- инструкцию по сборке и запуску;
- список зависимостей и их версии.
Отсутствие ссылки на код - частый повод для вопросов и удаления. Если проект частично закрытый, честно назовите, какая часть открыта, а какая нет. Приписывать проекту статус open source, когда это не так, бессмысленно: проверка занимает один переход по ссылке.
Локальный запуск: какие требования к железу указать
- поддерживаемые операционные системы;
- требования к GPU и объёму VRAM;
- минимальную и рекомендуемую конфигурации;
- поддерживаемые модели и форматы квантования;
- работает ли проект на CPU и с какой скоростью.
Если проект запускается только на определённом железе, скажите это сразу. Как сравнивать модели по VRAM, контекстному окну, KV-cache и стоимости инференса, подробно разобрано в материале про выбор модели для локального ПК или облачного API. Такой разбор помогает корректно сформулировать требования, не завышая их.
Структура поста для Project Showcase: готовый каркас
Порядок блоков можно менять, но все они должны присутствовать.
- Короткое описание проекта: что делает, для кого, как запускается.
- Задача, которую проект решает, и для кого она актуальна.
- Отличия от альтернатив и причина перехода, с ограничениями.
- Доказательства тестирования: сценарии, условия, известные проблемы.
- Open source и локальный запуск: лицензия, репозиторий, зависимости.
- Ссылки на репозиторий, демо и документацию.
- Ограничения и планы: что пока не работает и что дальше.
Чек-лист перед публикацией
- суть проекта объяснена простым языком, без жаргона в первом абзаце;
- сказано, почему это интересно пользователям;
- есть сравнение с альтернативами;
- есть доказательства тестирования;
- указаны лицензия и ссылка на код;
- описан локальный запуск;
- честно перечислены ограничения;
- текст опубликован в треде Project Showcase, а не отдельным постом.
Типичные ошибки, из-за которых пост удаляют или игнорируют
- маркетинговые клише и громкие обещания без доказательств;
- отсутствие ссылки на код;
- скрытая коммерция под видом open source;
- нет ни одного подтверждения тестирования;
- публикация не в Project Showcase;
- умолчание об ограничениях, которые вылезают при первом запуске.
Коротко: что важно показать в презентации AI-проекта
- Project Showcase - регулярный тред, презентация идёт туда, а не отдельным постом.
- Простой язык: что делает проект, для кого и почему это интересно пользователям.
- Отличия от альтернатив и конкретная причина перехода.
- Доказательства тестирования: сценарии, условия, известные проблемы.
- Open source, ссылка на код и описание локального запуска.
- Честные ограничения вместо идеальной картинки.
Закрытые коммерческие сервисы удаляются, это главный фильтр. Соберите пост по каркасу выше, проверьте по чек-листу и публикуйте в треде, когда он снова откроется.