Я бы все таки различал случаи, "в принципе запустить модель" и "запустить модель и нагружать ее реальными запросами по которым ожидается определенного качества ответ".
и модельки обычно не грузят в 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 ;)
Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
В Agile команды работают над небольшими итерациями и могут менять направление в зависимости от фидбэка. В анти‑Agile акцент делается на планировании всей работы заранее.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile подразумевает, что команды сами определяют, как работать, тогда как в анти‑Agile каждая команда имеет четко определенные роли и обязанности.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Сертификат пользователя («фактор владения», расположен в хранилище сертификатов компьютера пользователя, можно сделать не экспортируемым)
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
Я бы все таки различал случаи, "в принципе запустить модель" и "запустить модель и нагружать ее реальными запросами по которым ожидается определенного качества ответ".
и модельки обычно не грузят в 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 требуется внимание спеца, начиная с этапа развертывания.
Единственное справедливое утверждение:
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Вся преимущество GraphQL в федерации.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Неделя войны микрорепа vs монорепа объявляется открытой!
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
Я бы сказал, наоборот.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.