Комментарии

Спасибо большое, все теперь все ясно и понятно, наконец есть цифры, благодарствую

В среднем, расходы на маркетинг зависят от множества факторов, включая стремление к увеличению дохода. Маркетинг предлагает множество инструментов, которые могут быть самоокупаемыми, что делает его вложение выгодным. Однако это возможно только в том случае, если его проводят профессионалы.

Для стартапов сейчас средний бюджет на маркетинг составляет примерно 120-150 тысяч рублей в месяц. Дальнейшие расходы зависят от множества индивидуальных особенностей.

​Спасибо, конечно понимаю что пальцем в небо и у всех по разному, но все же, сколько в среднем обойдётся маркетинг, есть же какой то опыт запуска разных проектов в разных сферах

Ну это очевидно, конечно расходов будет больше чем просто покупка лицензии, например это:

1. Покупка лицензии — 650 т.р.
2. Снять сервер (в среднем) — 7 т.р. в месяц
3. Покупка домена — это копейки
4. Ну и главный момент это реклама и маркетинг (тут уже бюджет от Вашей фантазии и желания). Некоторым например как нам это было не нужно т.к. в основном у нас наработанная база клиентов + корпоративные продажи.

Я правильно понимаю что используя готовое решение мы существенно сократим сроки и бюджет? То есть это покупка лицензии 650 т.р. + какие еще могут быть расходы?

DST запускало несколько маркетплейсов и сетевых магазинов на Laravel, сложно сказать почему клиенты решили так поступить, ведь были готовые решения, скорее всего из-за уже готовой инфраструктуры на стеке laravel и не желания переходить на что-то новое.

На данный момент несколько проектов работают и вполне успешно, например Larava, LaModa, Гамма и.т.д. так что говорить что на Laravel нельзя сделать успешный и рабочий проект не совсем верно, но вот то что долго и дороже это верно, срок и цену конечно вы тоже написали примерную, но в целом тоже верно.

В 2025 году идея создания маркетплейса с нуля кажется не только рискованной, но и неперспективной. На рынке уже есть проверенные и масштабируемые решения, которые могут облегчить жизнь как уже работающим компаниям, так и стартапам.

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

Конечно, есть вариант использовать фреймворки, такие как Symphony, Laravel и другие. Однако стоит признать, что работа с ними тоже занимает много времени, и нет никаких подтверждений того, что на них уже реализовано что-то, что можно увидеть здесь и сейчас. Поэтому этот вариант тоже не идеален. Кроме того, создание маркетплейса на фреймворке обойдётся в значительную сумму — минимум от 3 миллионов рублей и выше, а процесс займёт как минимум 1,5 года.

По поводу показателей рынка то у нас довольно высококонкурентный рынок, и каждый продавец выбирает подходящие ему каналы реализации своих товаров. В России даже больше перспектив в этом плане, чем за рубежом, где как раз-таки всё произошло иначе с доминированием одного многопрофильного игрока. Так что конкуренция всё расставит на свои места. Если смотреть в целом, то доля интернет-торговли в России составляет 14%, в то время как в некоторых западных странах этот показатель доходит до 30%. Так что, считайте, что наш рынок ещё может вырасти вдвое за следующие три-пять лет, и на нём места хватит всем

​MVP — это минимально жизнеспособный продукт, который способен зарабатывать деньги. Подчеркиваю — минимально жизнеспособный продукт.

За 2 месяца наша команда запустит маркетплейс, у которого будет, конечно грубо говоря и простыми словами:

— своя стилистика,

— платежная система,

— сервис доставки,

— каталог товаров,

— стандартный процесс покупки: с момента посещения покупателем сайта — до оформления заказа.

Но главное предназначение MVP — проверить, насколько жизнеспособна бизнес-гипотеза. Понять, есть ли интерес у покупателей к продукту; какой трафик необходим, чтобы магазин выходил на самоокупаемость. И в целом — как скорректировать бизнес-план, чтобы проект был успешным.

Если после запуска обнаружатся стратегические ошибки, предприниматель может и вовсе отказаться от проекта (иногда так происходит, и да, это лучше, чем строить убыточный бизнес). Если же все идет по плану, продолжаем развивать онлайн-гипермаркет (доработки можно внедрять на живом проекте).

В принципе маркетплейс на готовом решении DST Marketplace, можно запустить за 2 месяца

Подойти к разработке маркетплейса можно разными способами.

Первый: запустить с нуля, то есть написать проект полностью самим. Это будет максимально индивидуальное решение. НО. Есть свои недостатки:

1) процесс долгий, технологии быстро устаревают и за ними можно банально не успеть (хоп, а конкуренты уже впереди!);

2) нужна команда с высокой экспертизой — это весьма дорого.

Разработка с нуля выгоднее, когда есть стратегия долгосрочного развития проекта на 5+ лет вперед.

Второй: использовать готовые решения. Этот вариант позволяет на старте проверить жизнеспособность проекта. Короткий срок (2 месяца) и сравнительно небольшой бюджет.

Как понять стоимость разработки маркетплейса?

Она будет зависеть от пожеланий клиента и сложности проекта. Простой пример: вы приходите в магазин за новым шкафом. Можно купить готовый, а можно оформить дизайнерский заказ. Он будет интересней, функциональней, но дороже и изготавливаться дольше.

В целом, стоимость разработки складывается из 4-х позиций: лицензия программы, настройка, интеграция сервисов и доработки (переход из MVP в FVP).

Что такое FVP?

FVP (fully viable product) — это законченное полотно художника, если говорить художественным языком. FVP — зрелая версия eCom-продукта, она выполнена в полном соответствии с видением своего продукта владельцем бизнеса.

На период mvp предприниматель должен поставить определенные цели: количество поставщиков, объем трафика, процент конверсий. Они могут быть и более прикладными: найти дополнительный склад, разобраться в услуге дропшиппинга и прочее.

Спустя 2-6 месяцев ПОСЛЕ запуска mvp нужно ответить на вопрос: каких результатов и показателей мы достигли. И если они положительны, строим план, как будем развивать наш проект. Если хотим вывести товар на новый рынок, интегрируем дополнительные платежные системы, строим логистику. Если хотим развивать геймификацию, развиваем другие инструменты.

PoC (Proof of Concept)

В период экономической турбулентности предпринимателям мало идеи — они хотят быть уверенными в его прибыльности. Это подтолкнуло нас к созданию новой услуги — Proof of Concept, или “Доказательство бизнес-гипотезы”.

Это погружение и проработка следующих вопросов:

— как должна выглядеть концепция развития маркетплейса на основе идеи клиента, чтобы быть успешной;

— варианты монетизации — на чем может зарабатывать маркетплейс (на данный момент в DST Marketplace встроено 3 типа монетизации); как должны строиться процессы создания и реализации товаров в рамках бизнеса клиента;

— где зоны риска и как их обойти;

— как взаимодействуют пользователи между собой (сценарии поведения покупателей, их взаимодействие с продавцом, управление процессами внутри магазина);

— как выстроить маркетинговую кампанию в бизнес-реалиях клиента.

Такой анализ проводится командой из 4 специалистов: бизнес-аналитика, системного аналитика, тимлида, проектного менеджера. Длительность работы составляет 2 недели с последующей презентацией решений.

Как понять переход из MVP в FVP, на каких параметрах это основывается и стоимость разработки маркетплейса?

Рассмотрим основные преимущества и недостатки этой системы управления базами данных, основанные на опыте внедрения в нашей компании.

Плюсы:

Масштабируемость и производительность. Oracle обеспечивает высокую скорость работы даже при обработке больших объёмов данных. Систему легко расширять, что позволяет увеличивать её мощность по мере роста бизнеса. Благодаря технологии RAC база данных может работать на нескольких серверах, что повышает доступность и распределяет нагрузку.

Отказоустойчивость. Oracle гарантирует надёжность и защиту данных. Data Guard позволяет создавать резервные копии и переключаться на них в случае сбоя. Это минимизирует риск потери информации и простоев.

Безопасность. Система управления базами данных предоставляет все необходимые инструменты для обеспечения информационной безопасности. В ней реализованы передовые методы шифрования, контроля доступа и мониторинга действий пользователей. Это особенно важно для компаний, работающих с конфиденциальными данными.

Многофункциональность. Oracle предлагает широкий спектр дополнительных модулей и инструментов, которые позволяют адаптировать систему под конкретные потребности бизнеса.

Кроссплатформенность. Система управления базами данных поддерживает все операционные системы и аппаратные платформы, что делает её универсальной. Она может работать на Windows, Linux, Unix и других системах, что упрощает интеграцию в существующую ИТ-инфраструктуру.

Мощные инструменты для администрирования. Oracle Enterprise Manager предоставляет администратору удобный интерфейс для управления базой данных. С его помощью можно отслеживать производительность, настраивать параметры и автоматизировать рутинные задачи, такие как создание резервных копий и восстановление данных.

Но у этой системы управления базами данных есть и недостатки. Вот основные из них:

Сложность настройки и администрирования. Oracle — это мощная и сложная система, требующая высокой квалификации от администратора. Навыки настройки, оптимизации и управления базой данных высоко ценятся на рынке труда.

Потребление ресурсов. Oracle требует значительных вычислительных ресурсов, особенно в крупных установках. Для обеспечения высокой производительности может потребоваться мощное оборудование, что увеличивает затраты на инфраструктуру.

Ну и конечно длительное обучение. Поскольку Oracle предлагает множество функций и возможностей, для полного освоения системы требуется значительное время. Это может быть препятствием для организаций, которые хотят быстро внедрить эту систему управления базами данных.

Топология «все-всем» (Full-Mesh)

В этой системе каждый узел может одновременно отправлять и получать данные от других узлов. Это означает, что каждый узел может выступать как источником, так и получателем информации.

Преимущества:

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

Низкая задержка распространения. Обновления, сделанные на любом узле, отправляются на все остальные узлы по прямым ссылкам. Эта прямая связь исключает промежуточные узлы, обеспечивая быструю синхронизацию данных.

Распределение нагрузки. Операции чтения и записи могут быть распределены между несколькими узлами, что повышает производительность. Поскольку каждый узел содержит полную копию набора данных, запросы на чтение могут быть направлены на любой доступный узел. Это позволяет системе балансировать трафик чтения между всеми узлами, снижая вероятность того, что какой-либо отдельный узел станет узким местом. С другой стороны, записи распределяются по узлам на основе таких факторов, как географическая близость, предпочтения пользователя и логика приложения.

Недостатки:

Сложное разрешение конфликтов. В топологии базы данных «все-все» разрешение конфликтов становится сложным, поскольку каждый узел может одновременно обрабатывать операции записи. Когда несколько узлов пытаются обновить один и тот же элемент данных почти в одинаковые моменты времени, традиционные механизмы последовательной обработки выходят из строя. Каждый узел генерирует свою собственную версию данных, создавая многомерное пространство версий, где определение «правильной» или «авторитетной» версии может стать сложной вычислительной проблемой.

Сложность связи. Для n узлов каждый узел должен поддерживать n-1 прямых соединений с другими узлами. Общее количество соединений в сети упрощается до O(n²). По мере увеличения количества узлов дополнительная сложность может не оправдать ожидаемый выигрыш. Это связано с тем, что большее количество узлов увеличивает вычислительную нагрузку на отдельные узлы. Это особенно верно, поскольку механизмы разрешения конфликтов и согласованности масштабируются с увеличением количества соединений. Кроме того, поскольку в прямой связи участвует больше узлов, конкуренция за сетевые ресурсы и увеличение накладных расходов на управление соединениями могут привести к замедлению времени ответа и снижению пропускной способности.

Сложность безопасности и уязвимостей. Чем больше подключений, тем сложнее требования к аутентификации, шифрованию и безопасности. Увеличивается поверхность атаки для потенциальных уязвимостей безопасности. Это может привести к увеличению сложности реализации безопасных каналов связи между узлами.

Тоже три года работы с ceph, никаких разработчиков держать не нужно. Вполне коробочный продукт, типа glusterfs или gpfs, в понимании их инсталляции под линукс, через использование которых прошли. Все работает и ставится из пакетов, настраивается достаточно просто и очень гибко. Ну а если нужен gui, то и этого навалом. Да и данные добываются просто, если вдруг по криворукости развалите, как мы на заре использования, неправильно настроив multipath на паре массивов :-)

На мой взгляд, одна из лучших систем для хранения данных на данный момент, а я их немного повидал разных.

Используем и под виртуализацию и для отдачи по nfs, и для прямого подключения как дисков.
Вот хотим на cephfs перейти для хранения файлов пользователей.

Используем только реплику. А восстанавливали так. Узнали формат хранения rbd.

Далее написали програмку на питоне, которая доставала кусочки с дисков и сливала их в один файл, после чено просто этот файл подмонтировали, получилось со второго раза и за 3 дня работы программы.

С IBM у нас, к сожалению, как то не задаются отношения. То у нас с тсм их не вяжется, то предлагали в тест объектный сторадж Cleversafe, который мы от них ожидаем до сих пор и тд… А что касается HPE… при всём моём к ним уважении и любви, у меня с железным StoreVirtual перед новым годом сложилась очень странная ситуация, которая не знаю, решилась уже или нет, но впечатление оставила не очень положительное, да и VSA как то особо не выделяется, что бы прям сильно захотелось его внедрить.

А где IBM Spectrum Accelerate и что-то от Хапе?

Сейчас все таки идет тренд к снижению стоимости владения ИТ-инфраструктурой.

В крупных организациях системы хранения данных занимают значительную долю стоимости ИТ-инфраструктуры (по оценкам специалистов – до 25%). Эта цифра может существенно вырасти. Причины – рост объема данных и увеличение потребности в емкостях систем хранения данных (СХД), в том числе из-за законов, которые обязывают эти данные хранить. В то же время компании активно стараются экономить ИТ-бюджеты, что вынуждает их находиться в постоянном поиске наиболее выгодных технологических решений, которые бы позволили сократить эти расходы не в ущерб качеству сервиса. Это же относится к хранению и обработке данных.

Требования заказчиков к снижению стоимости владения ИТ-инфраструктурой заставляют поставщиков инвестировать в разработки и предлагать новые технологии. Одна из них — программно-определяемые системы хранения данных (Software-Defined Storage, SDS). Компании начинают задумываться о внедрении SDS, когда процедуры работы с данными становятся неэффективными и их поиск отнимает много времени.

Концепция SDS позволяет получить такие преимущества, как:

— абстрагирование от нижнего уровня (аппаратной платформы),
— масштабируемость,
— упрощенная инфраструктура хранения,
— низкая стоимость решений.

Благодаря технологиям SDS можно значительно снизить стоимость СХД и их администрирования. По прогнозам Gartner, к 2020 году 70–80% неструктурированных данных будут храниться на недорогих системах, управляемых с помощью SDS, а уже к 2019 году 70% существующих массивов хранения станут доступны в полностью программной версии.

Когда и зачем нужна SDS

ПО управления СХД должно обеспечивать гибкую организацию хранения данных, а также:

— дедупликацию,
— репликацию данных,
— динамическое выделение емкости,
— снимки данных,
— соблюдение политик хранения.
SDS определяют в Storage Networking Industry Association (SNIA, Ассоциация производителей и потребителей систем хранения) как виртуализированную среду хранения данных с интерфейсом управления сервисами, которая должна включать в себя:

— автоматизацию — упрощенное управление, снижающее издержки на обслуживание инфраструктуры хранения данных;
— стандартные интерфейсы — API для управления, выделения и освобождения ресурсов, обслуживания сервисов и устройств хранения;
— виртуализацию путей доступа к данным — блочный, объектный и файловый доступ в соответствии с интерфейсами приложений;
— масштабируемость — изменение инфраструктуры хранения без снижения требуемого уровня доступности или производительности;
— прозрачность — мониторинг потребляемых ресурсов хранения, управление ими и контроль их стоимости.

Отмечу, что для SDS нужен стандартизированный интерфейс управления – такой, как SNIA Storage Management Initiative Specification (SMI-S). Он является составной частью концепции программно-определяемых дата-центров (SDDC). Эта программная логика облачной инфраструктуры хранения и облачных аппаратных платформ может быть элементом и традиционных ЦОД. Сервисы хранения и обработки данных могут выполняться на серверах, специализированных устройствах хранения (storage appliance) или на обеих этих платформах, устраняя традиционные границы.

Сравниваем SDS-решения

Software-Defined Storage предлагают многие вендоры:

— Dell EMC (решения Dell Nexenta, EMC ScaleIO),
— HPE (решение StoreVirtual VSA),
— IBM (решение Spectrum Storage),
— NetApp (решение ONTAP Select),
— VMware (решение vSAN),
— Red Hat (решение Red Hat Storage),
— StoneFly (решения SCVM, SDUS),
— DataCore (решение SANsymphony),
— SwiftStack,
— Pivot3 и др.

Уточню, что решение RedHat Storage представлено двумя продуктами: RedHat Ceph Storage и RedHat Gluster Storage (RH Storage Server). Здесь они подразумеваются оба, но в приведенном ниже сравнении они не участвовали, так как значительно отличаются от других упомянутых решений.

Ceph — не совсем коробочный продукт. Его использование без штата разработчиков достаточно затруднительно, что сделало его неинтересным для нашей компании. Поэтому этого решения нет в сравнительной таблице.

Условно все SDS-решения можно разделить на три категории:

— классические (CEPH, Red Hat Storage Server, EMC ScaleIO),
— на основе традиционных систем хранения (NetApp ONTAP Select, HPE StoreVirtual VSA),
— в составе вычислительных комплексов (VMware vSAN).

Некоторые производители предлагают как комплексные решения, так и программную часть (Huawei, Dell EMC). Это позволяет гибко подходить к подбору продуктов и использовать унаследованное «вычислительное» оборудование для решения менее ресурсоемких задач хранения данных. Еще одной заслугой SDS стала возможность применения в некоторых классических СХД виртуализации дисковых массивов.

Решения архитектурно строятся по двум принципам:

— слабо связанные,
— распределенные (без общих элементов).

В первом случае отказоустойчивость обеспечивается за счет распределенных копий данных, но из-за избыточности коммуникаций между узлами (нодами) снижается скорость записи. Критичным местом является сеть передачи данных, поэтому такие решения обычно реализованы на основе InfiniBand. По такому принципу построены решения VMware vSAN, HPE StoreVirtual VSA, Dell EMC ScaleIO.

В системах без общих элементов данные записываются на один узел, а потом с заданной периодичностью копируются на другие для обеспечения отказоустойчивости. При этом записи не являются транзакционными. Такой подход наиболее дешев. Чаще всего в качестве интерконнекта в нем используется Ethernet. Данная архитектура удобна с точки зрения масштабируемости. Яркий ее представитель — CEPH.

Сейчас многие компании занимаются разработкой как программной SDS (например, Atlantis Computing, Maxta, StarWind, DataCore Software, Sanbolic, Nexenta, CloudByte), так и выпуском комплексных решений (Dell EMC, IBM) или специализированных устройств (Tintri, Nimble, Solidfire).

Из наиболее известных на рынке мы выбрали для сравнения семь решений, которые интереснее всего для задач «Онланты». Это:

— VMware vSAN,
— HPE StoreVirtual VSA,
— NetApp ONTAP Select,
— EMC ScaleIO,
— Huawei Fusion Storage,
— StarWind Virtual SAN,
— Datacore SANsymphony.

В этой таблице мы сравнили их основные характеристики.

Инструмент будущего

Технология SDS начала развиваться еще в начале 2000-х, но пока не смогла заменить классические СХД по целому ряду причин — сейчас мы их обсуждать не будем. Но производители активно занимаются развитием своих продуктов и интерес к технологиям SDS растет. По нашим оценкам, в ближайшее время они станут тем инструментом, который позволит сокращать стоимость ИТ-инфраструктуры при росте потребности в увеличении емкости СХД.

В заключение отмечу, что в настоящем материале я не пытался предложить варианты выбора подходящего для вас решения. Такое решение нужно выбирать, исходя из нагрузки, SLA и т.д. В предлагаемой таблице сравниваются лишь возможности решений, и не сравниваются производительность, скорость репликации, время переключения нод и др. Т.е. это именно сравнительный анализ возможностей, а не продуктивное тестирование.

После тщательного знакомства с продуктами SDS мы пришли к выводу, что в текущей своей реализации под наши задачи они подходят не очень хорошо. Для себя мы все же выбрали классическое решение, внедрением которого мы в данный момент занимаемся, и о чём, возможно, в ближайшее время вам расскажем.

Но надеюсь, что представленные результаты сравнения помогут вам сориентироваться, сэкономят время и облегчат задачу выбора, какое решение подходит в вашем случае.

Сегодня специалисты разных сфер внедряют LLM в свои повседневные задачи. С их помощью можно сократить отчет, извлечь информацию, оптимизировать разметку данных. Те же дата сайентисты 50–70% времени тратят на написание кода и предобработку данных. Сейчас с этим неплохо помогает LLM. Одна из главных перспектив LLM в будущем — это создание ассистентов для автоматизации и персонализации. Есть ассистенты для здоровья, которые анализируют медицинские записи и дают советы. Есть ассистенты, которые разрабатывают обучающие системы или делают анализ в real-time, когда база данных пополняется и модель тут же делает выводы на основе этих данных. Также LLM можно использовать в юриспруденции для анализа документов и составления договоров. Сейчас это работает не очень хорошо, и модели нужно дообучать, но у этого направления есть большой потенциал.

Параметры LLM можно сравнить с нейронными связями: чем их больше, тем “умнее” модель. Следовательно, модель с большим количеством параметров может справляться с более сложными задачами, выявлять многообразные паттерны. Для простых задач, например классификация текста или чат-бот, достаточно простых моделей с десятками миллионов параметров, как у BERT. У более сложных моделей, например ChatGPT, сотни миллиардов параметров. Не всегда стоит гнаться за более «умной» моделью. Это можно сравнить с наймом сотрудников. Мы берем кандидата, ставим ему задачи, оцениваем работу и понимаем, справляется ли он. Если модель не справляется, значит, нужно большее количество параметров. Если она справляется на приемлемом для вас уровне, значит, их достаточно.

Насколько понимаю самые популярные опенсорсные модели сегодня:

— GPT-J: разработана EleutherAI. Считается более мощной и эффективной по сравнению со своим предшественником GPT-Neo. У нее шесть миллиардов параметров, и она очень производительна при обработке естественного языка. Модель обучали на большем объеме данных, поэтому она умеет генерировать качественный текст.

— BERT: модель от Google, которая стала основой для многих последующих моделей. Широко используется для классификации и анализа текста. Еще есть улучшенная версия RoBERTa от Facebook AI*, которая демонстрирует лучшие результаты на многих задачах.

— LLaMA: разработка от Meta*, предназначенная для обработки естественного языка. Включает несколько моделей с различным количеством параметров (от 7 до 65 миллиардов). Это позволяет пользователям выбирать модель в зависимости от их потребностей и вычислительных ресурсов.

— T5: еще одна языковая модель от Google, представленная в 2020 году. Использует единый фреймворк для всех задач NLP, включая перевод, суммирование, классификацию и генерацию текста. Каждая задача формулируется как преобразование одного текста в другой, что упрощает процесс обучения.

— Mistral: современная языковая модель, разработанная Mistral AI. Качественно обрабатывает текстовые данные и доступна в различных конфигурациях, включая модели с большим числом параметров. Обучена на разных источниках информации, поэтому генерирует разнообразные и качественные ответы.

— Yandex YaLM: языковая модель от Яндекса. Была представлена в 2023 году для обработки естественного языка. Модель обучена на русскоязычных и англоязычных источниках, что улучшает качество генерации текста. Доступна для пользователей в нескольких версиях, различающихся по количеству параметров.

Процесс обучения языковой модели можно разделить на несколько этапов:
— Сбор данных: в качестве источников могут выступать книги, сайты в интернете, статьи. Важно, чтобы модель училась на разных примерах и большом количестве данных.
— Обработка: информацию делят на более мелкие части, чтобы модель могла понять структуру языка.
— Обучение: для этого используют специальный алгоритм. Например, модель пытается предсказать следующее слово в предложении, основываясь на предыдущих словах. При ошибке алгоритм корректирует ее, чтобы в следующий раз она могла предсказать лучше. Этот процесс повторяется миллионы раз, поэтому требует больших вычислительных мощностей и занимает много времени.
— Тестирование и доработка: инженеры оценивают, насколько хорошо модель справляется с различными задачами. Важно, чтобы финальное тестирование проходило на новых данных, которые LLM еще не видела. При необходимости модель дорабатывают и улучшают.

После этого LLM загружают в приложение, где она может начать работу. При этом разные модели будут давать разные ответы на один и тот же вопрос, ведь они обучались на разных данных.

Обучение LLM — это ресурсоемкий процесс, который требует значительных временных и вычислительных затрат, но все зависит от размера модели и количества данных, на которых она обучается. Для небольшой модели, типа BERT, нужно несколько недель на нескольких GPU. Обучение большой модели, как GPT-4, займет месяцы на суперкомпьютерах. Нужны тысячи GPU или TPU, работающих параллельно, куча терабайтов текстовых данных для обучения, высокое электропотребление и специалисты. Поэтому это дорогостоящий процесс, который не все могут себе позволить.