Модели искусственного интеллекта. Например, если рассмотреть модель gpt-3.5-turbo-0125, то напрямую у openai ее использование стоит $0.50 за 1 миллион токенов. У ребят из ProxyAPI, которые предоставляют доступ к тем же моделям openai, но решая вопрос региональных блокировок и оплат, эта же модель стоит 0.114 руб. за 1 тысячу токенов. То есть, 114 рублей ($1.24) за миллион токенов, против $0.50, что в 2.48 раз дороже. PS Почему-то не получилось 3.14 в этот раз, возможно, я ошибся в расчетах в прошлом комментарии, либо для другой модели считал.
Ради интереса посчитал насколько дороже получаются модели при использовании упомянутого сервиса, получилось в 3.14 раза. Теперь интересно: это совпадение, или ценообразование путем умножения на число пи :)
В инвестициях главное самому не уверовать в свою гениальность. Среди миллионов портфелей, составленных из отдельных бумаг, случайно будут попадаться такие, которые обходят широкие индексы, особенно на кратком промежутке времени.
Нет ничего хуже механизма дизлайков. Из-за них большинство людей не свободны в выражении собственного мнения, они постоянно вынуждены задумываться о том как их мысли воспримет среднестатистический член сообщества. Отношение количества плюсов к количеству просмотров — достаточный и объективный критерий оценки качества статьи, при этом не подрывающий мотивацию автора. А против спама, мата и прочей ереси спас бы механизм жалоб.
Поверьте, не все в курсе. От уровня «PHP программист» до уровня «Программист» должен пройти ощутимый рост. Кому-то важные истины объясняют старшие товарищи, а кто-то доходит до них сам. Второе, как правило, дольше. Большинство программистов, которых я встречал, были именно "{stackName} программистами", а предложение изучить новый язык или технологию вызвало бы у них внутренний протест и нежелание выходить из зоны комфорта. И даже формулировки могут быть разные: «я перешел с python на node.js» или «новый проект пишeм на node». В первом случае чувствуется, что человек кардинально изменил свою жизнь. А во втором — просто взял другой инструмент из чемодана.
Так что, не все в курсе. Уж поверьте.
Пока получается, что за «супер оружие» судят только тех, у кого его на самом деле нет. Никто не сможет осудить реального обладателя супер оружия, потому что рискует получить больно. А если кто-то сможет, то только имея оружие еще более серьезное. Но тогда возникает вопрос: почему второй судит первого, а не наоборот? Мне кажется, что все конвенции ООН и прочая дипломатия — просто завеса, за которой скрывается право сильного. Сильный судит слабых, но не наоборот.
Мне (программисту) приходится администрировать боевые сервера самостоятельно просто потому, что так повелось в нашей организации. Осознаю, что отдельный админ справился бы с этой задачей лучше, но пока всех всё устраивает: организации не надо платить зарплату отдельному человеку, а мне небольшой объем работ по администрированию позволяет делать это в охоточку, не погружаясь с головой.
Коллектив вообще любит середнячков, а слишком глупых и слишком умных отторгает. Но лично я, как разработчик, предпочел бы действовать иначе. Если у меня случается батхерт от того, что кто-то разбирается в моем предмете лучше меня (и нагло указывает на это), то я предпочту воспринять это как вызов и поднять свою квалификацию. Можно, конечно, устранить «обидчика» и расслабиться, но тогда пропадает хороший пинок к собственному развитию.
Подчеркну, что это мнение разработчика. Менеджеру, наверное, больше по душе набор покладистых середняков.
Я имел в виду, что читать будет logstash, чтобы передать в elasticsearch. Человек будет применяться уже непосредственно для работы с красивой kibana :).
Насчет асинхронности соглашусь, можно решить, навскидку, через простую очередь в памяти процесса с периодической bulk отсылкой в эластик. Но это же надо кодить, а логи на диске уже лежат готовые и ждут своего часа. В общем, у нас пока такой быстрый старт получился, с регулярками и минимальными затратами. (Если честно, я пока в некоторой эйфории пребываю от новых для меня и неожиданно крутых инструментов) Может быть, потом случится настроение убрать лишнее звено и запилить elasticsearch адаптер для log4net. Скорее всего даже готовый есть.
За видео спасибо, поглядим на досуге.
Еще вопрос есть: почему решили применить аспекты, а не написать реализацию логера для записи в эластик и ее указать в приложении?
Только сегодня занимались написанием регулярок под logstash. Совпадение? Не думаю.
Хотя мысль об отправке логов напрямую в эластик была, но отказались от такого варианта.
Подход с регулярками нам нравится тем, что:
1. Все сервисы умеют писать на диск. Значит, что логи можно читать из любого источника. Например, сегодня подцепились к access и error логам nginx, а также к логам одного из наших приложений. Так же планируем читать логи множества сторонних сервисов, которые мы используем, и которые могут писать логи только на диск или иное unix устройство.
2. Смущает возможная деградация производительности при записи приложением напрямую в эластик. У нас сложное приложение и достаточно много логов, и мы переживаем за время отклика.
3. Нас регулярками не запугать :)
Плохо, что ссылка появляется в адресной строке и сохраняется в истории браузера. С другой стороны, пароли тоже хранятся в браузере. Но они не появляются на экране в открытом виде при обычном использовании.
В MS SQL есть что-то вроде «даты последнего обновления индекса». Но это значение на реплике не соответствует реальности, сильно отстаёт и вообще не понятно в каких случаях обновляется.
Потому я хочу попробовать сделать таблицу с одной строкой и одним столбцом. Туда с каким-то небольшим интервалом (например, 500мс) писать текущую дату. Потом приложение будет сравнивать значение в этой таблице на мастере и на реплике. Таким образом можно понять насколько по времени отстал лог транзакций на реплике. Чем меньше интервал обновления, тем меньше погрешность измерения. Нагрузки большой это создать не должно, но надо поэкспериментировать.
Модели искусственного интеллекта. Например, если рассмотреть модель gpt-3.5-turbo-0125, то напрямую у openai ее использование стоит $0.50 за 1 миллион токенов. У ребят из ProxyAPI, которые предоставляют доступ к тем же моделям openai, но решая вопрос региональных блокировок и оплат, эта же модель стоит 0.114 руб. за 1 тысячу токенов. То есть, 114 рублей ($1.24) за миллион токенов, против $0.50, что в 2.48 раз дороже.
PS Почему-то не получилось 3.14 в этот раз, возможно, я ошибся в расчетах в прошлом комментарии, либо для другой модели считал.
Ради интереса посчитал насколько дороже получаются модели при использовании упомянутого сервиса, получилось в 3.14 раза. Теперь интересно: это совпадение, или ценообразование путем умножения на число пи :)
Вы им хоть не подсказывайте..
В инвестициях главное самому не уверовать в свою гениальность. Среди миллионов портфелей, составленных из отдельных бумаг, случайно будут попадаться такие, которые обходят широкие индексы, особенно на кратком промежутке времени.
Так что, не все в курсе. Уж поверьте.
xkcd.r-forge.r-project.org
stackoverflow.com/questions/12675147/how-can-we-make-xkcd-style-graphs
Подчеркну, что это мнение разработчика. Менеджеру, наверное, больше по душе набор покладистых середняков.
Насчет асинхронности соглашусь, можно решить, навскидку, через простую очередь в памяти процесса с периодической bulk отсылкой в эластик. Но это же надо кодить, а логи на диске уже лежат готовые и ждут своего часа. В общем, у нас пока такой быстрый старт получился, с регулярками и минимальными затратами. (Если честно, я пока в некоторой эйфории пребываю от новых для меня и неожиданно крутых инструментов) Может быть, потом случится настроение убрать лишнее звено и запилить elasticsearch адаптер для log4net. Скорее всего даже готовый есть.
За видео спасибо, поглядим на досуге.
Еще вопрос есть: почему решили применить аспекты, а не написать реализацию логера для записи в эластик и ее указать в приложении?
Совпадение? Не думаю.Хотя мысль об отправке логов напрямую в эластик была, но отказались от такого варианта.
Подход с регулярками нам нравится тем, что:
1. Все сервисы умеют писать на диск. Значит, что логи можно читать из любого источника. Например, сегодня подцепились к access и error логам nginx, а также к логам одного из наших приложений. Так же планируем читать логи множества сторонних сервисов, которые мы используем, и которые могут писать логи только на диск или иное unix устройство.
2. Смущает возможная деградация производительности при записи приложением напрямую в эластик. У нас сложное приложение и достаточно много логов, и мы переживаем за время отклика.
3. Нас регулярками не запугать :)
Потому я хочу попробовать сделать таблицу с одной строкой и одним столбцом. Туда с каким-то небольшим интервалом (например, 500мс) писать текущую дату. Потом приложение будет сравнивать значение в этой таблице на мастере и на реплике. Таким образом можно понять насколько по времени отстал лог транзакций на реплике. Чем меньше интервал обновления, тем меньше погрешность измерения. Нагрузки большой это создать не должно, но надо поэкспериментировать.