так RPA в большинстве случаев использовали, когда нормального API не было. т.е. условная кнопочка была, ее можно было нажимать, а условного REST API не было.
Я бы все таки различал случаи, "в принципе запустить модель" и "запустить модель и нагружать ее реальными запросами по которым ожидается определенного качества ответ".
и модельки обычно не грузят в 5 gpu, обычно в 2, 4, 8 gpu.
Насколько LLM дорогая штука в эксплуатации, можно понять только если развернешь любую большую LLM на своих мощностях за свои деньги.
Допустим развернешь GLM 4.6 на nvidia h200 x 8, и понагружаешь ее запросами, чтобы понять сколько она тянет нагрузки. И дальше простая математика по подсчету стоимости инфраструктуры в пользовательские запросы. И становится понятно, что все текущие предложения - это жесточайший демпинг.
пока с меня берут деньги за доступ к ИИ - меня совершенно не волнует их экономика и я хочу получать то что заявлено при оплате
Это все верно, не поспоришь.
Но экономика вещь упрямая. Сейчас продают все на этом рынке в минус, чтобы занять большую долю рынка. Но вечно это не может продолжаться. Дальше, либо кончились деньги и бизнес закрылся, либо смог продавать дороже и остался в бизнесе. Любой из вариантов для клиентов плох. Но селя ви.
мой опыт говорит об обратном. требования к коду для тестов кардинально отличаются требований для основного кода
1) тест должен быть максимально понятным для любого стороннего, с одного взгляда понятно что тестировалось, и что сломалось
2) чем более изолирован тест, тем лучше; дублирование кода в тестах в целом ок, масс-апдейт изменений в учетом современных инструментов не большая боль.
Получить публичный из приватного легко. Обратно, вычислить приватный из публичного, на обычном компьютере невозможно
Это к хешам относится.
Для пары ключей - ключи эквивалентны, и назначение "приватный", "публичный" чисто номинальное. И из одного (любого) получить второй считается очень сложным.
для манипуляций, например, с ansible запускаю в отдельном окружении, где нет bash истории, важных ssh ключей, и прочего. потом git push. и git pull в приватном окружении, где агенты не запускаются.
зы
знаю что некоторые параноят, и секретами объявляют имена пользователей и ip-адреса, тут увы...
Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
а что делаете с "мало обещает/мало делает"?
так RPA в большинстве случаев использовали, когда нормального API не было. т.е. условная кнопочка была, ее можно было нажимать, а условного REST API не было.
а без API, нет и MCP.
software vs hardware, как бы намекает, почему software прощает некачественное планирование
hardware тупо сложнее исправлять
6 млн записей в день - примерно 250 тыс в час, 70 в сек, с учетом пиков наверно 200-300 в сек.
Postgres на nvme дисках не напрягаясь дает такую нагрузку, узкое место которое надо смотреть - конкуренция за записи.
Забыли добавить Правило №0.
зы
не потому что я не люблю очереди ;)
по аналогии с правилами использования кеширования - Правило №0 "Не используй кеширование"
Я бы все таки различал случаи, "в принципе запустить модель" и "запустить модель и нагружать ее реальными запросами по которым ожидается определенного качества ответ".
и модельки обычно не грузят в 5 gpu, обычно в 2, 4, 8 gpu.
Насколько LLM дорогая штука в эксплуатации, можно понять только если развернешь любую большую LLM на своих мощностях за свои деньги.
Допустим развернешь GLM 4.6 на nvidia h200 x 8, и понагружаешь ее запросами, чтобы понять сколько она тянет нагрузки. И дальше простая математика по подсчету стоимости инфраструктуры в пользовательские запросы. И становится понятно, что все текущие предложения - это жесточайший демпинг.
Это все верно, не поспоришь.
Но экономика вещь упрямая. Сейчас продают все на этом рынке в минус, чтобы занять большую долю рынка. Но вечно это не может продолжаться. Дальше, либо кончились деньги и бизнес закрылся, либо смог продавать дороже и остался в бизнесе. Любой из вариантов для клиентов плох. Но селя ви.
вызваны текущие увольнения в больших ИТ компаниях только ИИ, или набрали больше людей чем нужно и давно нужно было оптимизироваться - вопрос открытый.
если объявить просто о сокращении 10% персонала, то это сигнал для рынка, что у тебя не все хорошо в делах. и акции вниз.
если объявить о сокращении 10% персонала в связи с ИИ, то это сигнал для рынка, что ты оптимизируешь косты. и акции вверх.
За минуту можно тяжелый кластер запустить.
Вообще в оригинале речь по < 60ms.
мой опыт говорит об обратном. требования к коду для тестов кардинально отличаются требований для основного кода
1) тест должен быть максимально понятным для любого стороннего, с одного взгляда понятно что тестировалось, и что сломалось
2) чем более изолирован тест, тем лучше; дублирование кода в тестах в целом ок, масс-апдейт изменений в учетом современных инструментов не большая боль.
Это к хешам относится.
Для пары ключей - ключи эквивалентны, и назначение "приватный", "публичный" чисто номинальное. И из одного (любого) получить второй считается очень сложным.
все секреты лежат в секретах.
для манипуляций, например, с ansible запускаю в отдельном окружении, где нет bash истории, важных ssh ключей, и прочего. потом git push. и git pull в приватном окружении, где агенты не запускаются.
зы
знаю что некоторые параноят, и секретами объявляют имена пользователей и ip-адреса, тут увы...
так mcp это не другой интерфейс, это второй уровень абстракции за curl.
т.е. curl (или его аналог) все еще нужен, но что передать и как распарсить - вот тут mcp и пригодился. а дальше jq, awk и прочее.
Я понимаю ваш оптимизм и желание попробовать новое. Как говорится, велкам. ;)
Но лично мне вы не продали идею со смешанным хранением данных в memory/drive. Мои эксперименты показали, что важные сервисы, связанные с деньгами должны быть persistence only. Их можно обкладывать кешами различной природы и сложности, но за понимание важности durability, иногда, приходится расплачиваться условно "потом и кровью".
А если вспомнить, что ограничение в 1-2К фин. операций, это же при условии апдейта одного объекта. А такой кейс крайне специфичен, с одной стороны. С другой, при апдейте непересекающихся объектов, лимит вырастает до 10-15К. А я не знаю фин.систем, где бы было недостаточно 10-15К. Хотя допускаю, что они есть. ;)
Насколько я понял, вы сделали аля in-memory database с поддержкой ledger dsl, где история лежит в обычной rdbms.
Соответственно, у этого решения есть свои плюсы и минусы.
Плюсы - скорострельность по исполнению фин операций. Что логично, если все в памяти.
Минусы - давно известны для любого in-memory решения.
как дешево обеспечить конкурентный доступ к объектам. насколько я понял, у вас это решено через однопоточность (как в redis, tarantool, voltdb и т.д.)
в целом к однопоточности вопросов нет, до тех пор пока данных не становится сильно больше чем помещается в memory для одного сервера. что в этом случае делать, тоже уже давно известно, нужно часть данных скидывать в обычную rdbms. и вот тут начинаются разные сложности. уверен, кто эксплуатировал подобные решения, смогут рассказать много историй из своего опыта.
Мое имхо, с учетом современного железа, потюненный Postgres дает плюс минус 50K TPS.
Финансовых транзакций, примерно 10-15К.
Есть еще задержки от блокировки объектов из-за конкуренции, тогда скорость падает до 1-2К при плохом раскладе. Вполне допускаю что есть игроки для кого 1-2K фин. операций - это мало, и им нужны альтернативы, допустим в виде qazna ;)
Ночные остановки сейчас мало связаны с отчетами.
Сейчас остановки из-за обязательных операций, типа начислить проценты, начислить пени, и .т.д. Они не выполняются мгновенно на большой выборке.
Но в большинстве случаев - сейчас конечный пользователь про это не знает. Переводы с карты на карту работают 24/7 для конечных пользователей.
зачем kafka, если у вас есть таблица outbox_payments, которая выполняет по сути роль кафки?
да нет никаких чудес, идемпотентность - это только один нюансов.
надежная платежная логика основана на локах. есть некоторые частные случаи, когда можно обойтись без локов, в обмен на ... (и тут разные опции).
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.