У вас не будет ускорения за счёт использования gpu. (Первый удар по производительности)
У вас вряд ли завалялось под 250гб оперативной памяти на вашем компьютере, поэтому веса поочерёдно придётся считывать веса с жёсткого жиска, проводить часть вычислений, выгружать веса, загружать другие веса и опять по новой. (Это ещё медленнее будет).
Поэтому вероятнее всего эту авантюру пускай и можно будет провернуть, но скорость получения каждого токена будет убийственно медленной. Точных цифр приводить не стану, но скажу вам что проще заплатить за аренду кластера гпу/использовать апишки тех, у которых есть свой кластер. Вероятно, это и дешевле выйдет чем издержки за условное электричество:)
Ну если в кратце - скорость разнится. Но этим можно пожертвовать.
Прелесть RAG в том что одна модель отвечающая за ответ может обслуживать множество источников данных, в том числе и более актуальных. Использование векторной бд это лишь один из способов предоставлять модели актуальные знания по %SUBJECT%.
Можно использовать поисковые движки (хотя, они в целом используют индексаторы, которые делают +- тоже самое)
Можно использовать поиск по файловой системе, заставить llm брутфорсить википедию, искать по ключевым словам, заставить использовать wolfram, calc.exe и прочие вещи для поиска ответов. Тем более инструментов, помимо langchain на рынке хватает. Huggingface, например, год назад выпустили agents, который позволяет делать много всяких вещей.
Если вам нужен исключительно rag + vector db можно пощупать и haystack, api которого +- стабилен и многое работает без принудительного использования openai.
А ещё некоторые не вмешивают веса на основную модель, а ограничиваются префиксным тюнингом. И могут менять части модели на лету оркестрируя "адаптеры".
Сколько же боли группировка по типу классов вносит в проект. Помимо сложности с навигацией и расширением, указанным выше есть и другие.
Очень часто вижу подобное разделение в Angular. И с этим можно работать, конечно. Но! Вместо нескольких модулей подгружаемых по-требованию в таких проектах более характерен SharedModule/CommonModule со всей логикой приложения с размером в несколько десятков мегабайт. (На всякий случай - это непозволительно много, даже в эпоху гигабитных каналов у конечного пользователя)
Уже настроенная система/комплекс как правило работает стабильно и не требует существенных усилий по поддержке
Имею мнение, что дело тут далеко не в мейнфрейме. Любая система настроенная правильным образом позволит наращивать производительность и при этом не требовать обслуживания.
Ну как уже отметили раньше — достаточно сложно уйти с этой инфраструктуры.
Вот причины:
Многие компании уже влили достаточно денег на этот мейнфреймовый ад. (Речь идёт не о десятках тысяч УЕ, и даже не о сотнях) — а все благодаря (практически) безграничному вертикальному масштабированию.
Носители — отдельная проблема. Тейпы используются активно, а перегон архива — это не просто загнать данные на флешку.
Ходят ещё мнение среди мейнфрейм-адептов что мейнфрейм предоставляет недостижимый уровень безопасности, что достаточно часто является правдой, но с ньюансом — когда есть непопулярная архитектура — сторонних адептов в ней будет не так много.
А ещё система которая работает 30 лет, конфиги трогались 25 лет назад последний раз по мануалу 40-летней давности — это прекрасно (нет). Страшно трогать.
Но, минусы… Про них нужен отдельный пост. Лицензирование, интерфейсы, особенности разработки, процессы и кастомер-сервис.
Имхо. Это просто айти в общем понимании, только наоборот.
Шансы есть. Но:
У вас не будет ускорения за счёт использования gpu. (Первый удар по производительности)
У вас вряд ли завалялось под 250гб оперативной памяти на вашем компьютере, поэтому веса поочерёдно придётся считывать веса с жёсткого жиска, проводить часть вычислений, выгружать веса, загружать другие веса и опять по новой. (Это ещё медленнее будет).
Поэтому вероятнее всего эту авантюру пускай и можно будет провернуть, но скорость получения каждого токена будет убийственно медленной. Точных цифр приводить не стану, но скажу вам что проще заплатить за аренду кластера гпу/использовать апишки тех, у которых есть свой кластер. Вероятно, это и дешевле выйдет чем издержки за условное электричество:)
Ну если в кратце - скорость разнится. Но этим можно пожертвовать.
Прелесть RAG в том что одна модель отвечающая за ответ может обслуживать множество источников данных, в том числе и более актуальных. Использование векторной бд это лишь один из способов предоставлять модели актуальные знания по %SUBJECT%.
Можно использовать поисковые движки (хотя, они в целом используют индексаторы, которые делают +- тоже самое)
Можно использовать поиск по файловой системе, заставить llm брутфорсить википедию, искать по ключевым словам, заставить использовать wolfram, calc.exe и прочие вещи для поиска ответов. Тем более инструментов, помимо langchain на рынке хватает. Huggingface, например, год назад выпустили agents, который позволяет делать много всяких вещей.
Если вам нужен исключительно rag + vector db можно пощупать и haystack, api которого +- стабилен и многое работает без принудительного использования openai.
А ещё некоторые не вмешивают веса на основную модель, а ограничиваются префиксным тюнингом. И могут менять части модели на лету оркестрируя "адаптеры".
И более того - уже долгое время работающая в OSS:
https://github.com/bigscience-workshop/petals
Ну, справедливости ради, 10 лет назад многие адепты писали себе код на turbolinks и были крайне довольны.
(Например, вот статья на хвбре 11 летней свежести - https://habr.com/ru/articles/167161/)
Workspaces встроенный тоже вполне себе. Правда всего 3 экрана даёт шарить, но бесплатно и "нативно".
Ага.
Возможно дело в том что я не в РФ.
У меня почему-то вообще обфускации никакой нет.
Кстати, годов с 2005 заметил что через wine некоторые игры играются сильно лучше чем на винде, под которую их и клепают. Такая же история с proton.
Игры падают реже, если, конечно, запускаются.
Diaspora :)
Избавление от одного ненужного уровня вложенности в виде папки src.
Но это конфигурируется при помощи nuxtconfig.
Рекомендую посмотреть документацию на английском языке, так как не все материалы переведены на русский.
Спасибо автору!
Появилось сильное желание потрогать/вспомнить как там Delphi поживает.
Сколько же боли группировка по типу классов вносит в проект. Помимо сложности с навигацией и расширением, указанным выше есть и другие.
Очень часто вижу подобное разделение в Angular. И с этим можно работать, конечно. Но! Вместо нескольких модулей подгружаемых по-требованию в таких проектах более характерен SharedModule/CommonModule со всей логикой приложения с размером в несколько десятков мегабайт. (На всякий случай - это непозволительно много, даже в эпоху гигабитных каналов у конечного пользователя)
Забавный комментарий, а ситуация страшная.
"Можно не учить ПДД, потому что потом всю жизнь машинку вперёд просто катать"
Хотя, с другой стороны в этом комментарии зарыт и OCP, зачем знать детали реализации, когда нужно только JSON-получить?)
А где цифры?
>> Ну и сопоставьте одно с другим – особенности процесса работы с её результатами. Так вы вычислите бандерлогов
Какие метрики использовать? KPI? Время поставки? Время обработки тикетов/сторей?
Snap, на самом деле, достаточно прогрессивная штука.
Приложения устанавливаются в песочнице, цикл доставки кода подходит намного быстрее чем через "традиционые" репозитории.
Но с точки зрения "уверенного пользователя" это выглядит не так радужно, к сожалению.
Кстати, snap удален из mint последних ревизий.
Имею мнение, что дело тут далеко не в мейнфрейме. Любая система настроенная правильным образом позволит наращивать производительность и при этом не требовать обслуживания.
Ну как уже отметили раньше — достаточно сложно уйти с этой инфраструктуры.
Вот причины:
Многие компании уже влили достаточно денег на этот мейнфреймовый ад. (Речь идёт не о десятках тысяч УЕ, и даже не о сотнях) — а все благодаря (практически) безграничному вертикальному масштабированию.
Носители — отдельная проблема. Тейпы используются активно, а перегон архива — это не просто загнать данные на флешку.
Ходят ещё мнение среди мейнфрейм-адептов что мейнфрейм предоставляет недостижимый уровень безопасности, что достаточно часто является правдой, но с ньюансом — когда есть непопулярная архитектура — сторонних адептов в ней будет не так много.
А ещё система которая работает 30 лет, конфиги трогались 25 лет назад последний раз по мануалу 40-летней давности — это прекрасно (нет). Страшно трогать.
Но, минусы… Про них нужен отдельный пост. Лицензирование, интерфейсы, особенности разработки, процессы и кастомер-сервис.
Имхо. Это просто айти в общем понимании, только наоборот.
Так это же копипаста с официальной документации. Или в России уже запретили и ее?
:disabled="pageNumber=0"
Поправте на
:disabled="pageNumber==0"