далеко не все валюты копейки в одну сотую от основного номинала. есть исключения.
далеко не все цены определяются в копейках, есть и доли копеек.
даже если цены в копейках и есть только копейки, есть ставки с долями, и опять по кругу, нужно считать правильно деньги с учетом таких ставок
вычисления с numeric относительно дорогие, но деньги как правило дороже. плюс в бд логику сейчас редко держат, вычисляют в приложениях. в приложениях вычисления в "numeric" тоже сильно дороже, но опять же "деньги дороже". плюс приложения горизонтально масштабируются. базе остается только хранить numeric.
и есть пачка исключений, когда int выгоднее numeric. но то исключения.
так 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-адреса, тут увы...
наверно, точнее сказать "проектировать".
Stacker портировали в винду? ;)
чтение качает навык чтения. и почти не влияет на навык говорения.
не водяные знаки, а стеганография
же...
храните деньги в numeric, в общем случае.
далеко не все валюты копейки в одну сотую от основного номинала. есть исключения.
далеко не все цены определяются в копейках, есть и доли копеек.
даже если цены в копейках и есть только копейки, есть ставки с долями, и опять по кругу, нужно считать правильно деньги с учетом таких ставок
вычисления с numeric относительно дорогие, но деньги как правило дороже. плюс в бд логику сейчас редко держат, вычисляют в приложениях. в приложениях вычисления в "numeric" тоже сильно дороже, но опять же "деньги дороже". плюс приложения горизонтально масштабируются. базе остается только хранить numeric.
и есть пачка исключений, когда int выгоднее numeric. но то исключения.
беда ж не в триггерах как таковых, беда ж в дублировании логики в разных местах.
а какие секюрные?
а что делаете с "мало обещает/мало делает"?
так 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-адреса, тут увы...