Локальный DeepSeek-R1: Когда скорость улитки – не приговор, а точка старта

Т.е. ждать будем столько же, но энергопотребление будет ниже )

Можно просто уменьшить число ядер, обрабатывающих запрос - будет меньше нагрузка. Потому как они действительно просто греют воздух в большинстве своем, ожидая данных из памяти )

У меня 2х канальная память - и по скорости вывода разницы нет, что 8 ядер обрабатывают, что 4 ядра (у меня 16 ядер с учетом HT, без GPU).
Правда скорость обработки запроса (prompt) меняется (падает в 2 раза), но и процессор не так греется - для меня это допустимый компромисс.

Локальный DeepSeek-R1: Когда скорость улитки – не приговор, а точка старта

Если сейчас в память упирается - то как расширенный набор инструкций процессора поможет (AMX или AVX512)?
Максимум - меньше нагрузка на ядра будет.

Огромный гайд по настройке рабочего окружения: Linux, VScode, Python

Может на редактирование реагирует адекватно, а на изменения через git - нет?

Огромный гайд по настройке рабочего окружения: Linux, VScode, Python

В свое время MS сделали очень много для того, чтобы разработчики ушли c Windows...
И эта тенденция стала так заметна, что они встроили Linux в Windows )
И получился WSL )

Локальный DeepSeek-R1: Когда скорость улитки – не приговор, а точка старта

Хм... А двух процессорная сборка приведет к удвоению скорости?
В 2 раза больше каналов памяти будет... А по деньгам, насколько я понимаю, сравнимо.

Семантический поиск по статьям Хабра в PostgreSQL + индексация текстов LLM в Ollama

Статья оставила двоякое впечатление... С одной стороны - достаточно интересная тема... А с другой - осталось впечатление, что просто в рабочем проекте, "на коленках", поиграли с технологией, что-то получили, и решили по-быстрому оформить в виде статьи.

Отсюда странный выбор технологий - использовали просто то, что и так было в проекте и под рукой в целом (подозреваю, что изначально просто junit-тест был написан для пробы).

Зачем тут spring? Main-класса было бы достаточно. Инъекция зависимостей ради пары зависимостей?
Зачем lombok? Пару геттеров-сеттеров можно и руками написать.
Чем обусловлен выбор testcontainers для БД? Есть полноценные встраиваемые БД. А то и просто в RAM/файлах можно было хранить.

Как бы да, это все "лучшие практики" в Java, но в таком маленьком проекте они просто избыточны - руками все сделать не сильно сложнее, а то и проще было бы.

Ну и главное - а где собственно семантический поиск? Получили просто индекс близости статей к друг другу.

Для полноценного же поиска не хватило малости - просто строки ввода, которую надо было через embedding прогнать и вывести список статей по близости к запросу (опционально - перевести через LLM текст запроса).

P.S. ну или просто кто-то с ИИ для кодинга игрался - что тоже нельзя исключать. Ну или лабораторная работа какая...

Вы уверены, что defer всегда безопасен?

Это немного другой прикол с defer - изменение возвращаемых значений:

package main

import "fmt"

func main() {
	fmt.Println("Hello, 世界", test())
}

func test() (n int) {
	defer func() {
		fmt.Println(n)
		n = 2
	}()

	return 1
}

https://go.dev/play/p/oCpFl6trX_6

Нейросети и реален ли сильный ИИ: большая проблема, о которой мало говорят

В процессе чтения статьи возникла мысль, что добавь в LLM возможность редактировать свой же системный промт - и LLM сразу же превратится в сильный ИИ, потому как появится опыт, целеполагание и прочие элементы сильного ИИ.

Альтернативы свинцовому аккумулятору ИБП

10А на батарею не означает, что сборка только 10А тянет. Разные типы батарей имеют разную токоотдачу, не говоря уже про разные схемы подключения батарей в сборке.

У меня LiFePo4 сборка до 25А выдает (1 акб), что урезало ИБП на 450VA примерно вдвое (если очень грубо считать).
Но мне пиковые показания и не нужны были - так что я мало что потерял в итоге.

Альтернативы свинцовому аккумулятору ИБП

Вроде читал что и работу с неполным зарядом они переносят хорошо, но за это не подпишусь.

Да, хорошо (как и все литий-ионные), другое дело что при полном заряде они деградируют быстрее, но с LiFePo4 это не так критично вроде )

И с LiFePo4 есть другой нюанс - из-за ровной кривой разряда нельзя определить (по напряжению) степень заряда батареи (только "полностью заряжено" и "полностью разряжено") - для этого надо считать "сколько ушло" и "сколько пришло". Поэтому при неполном заряде расчетные показания могут уплывать со временем. Но для подобного подсчета надо и продвинутую BMS иметь.

если напряжение ЗУ ИБП предназначенного для свинца окажется выше чем рекомендуемое для LiFePo4

Для свинца (на 12В) напряжение чуть ниже чем у сборки с LiFePo4 (на 12В) - так что замена безопасной должна быть. Как раз поэтому LiFePo4 и используют активно как простую замену свинцовым батареям.

Альтернативы свинцовому аккумулятору ИБП

Пиковая отдача - да, свинцовые впереди будут. Хотя LiFePo4 и тут хороши (если речь про кратковременную нагрузку).

Но ни кто не мешает параллельно батареи цеплять - и 10А превращаются в 20А, 30А и т.д.
Правда с BMS могут возникнуть нюансы - не всегда допустимы параллельные или последовательные соединения сборок батарей.

Альтернативы свинцовому аккумулятору ИБП

Можно подумать, что реально все 3kVA используются. В предельных режимах ИБП обычно держит считанные минуты - если ИБП не просто для "успеть сохраниться", то и смысла в пиковом потреблении нет.

Да и большой вопрос к состоянию свинцовых батарей - не факт, что все 3kVA выдадут даже на несколько минут.

Альтернативы свинцовому аккумулятору ИБП

Ноутбук + док-станция - довольно неплохая замена ПК.
Когда нужно - в режиме ПК работаешь, со всеми удобствами (клавиатура, мышь, мониторы и т.д.). Когда нужно - появляется портативность и компактность.

Альтернативы свинцовому аккумулятору ИБП

Перешел со свинцовых на LiFePO4 в своих ИБП (для ПК и сетевого оборудования).
Да, дороже. Да, емкость меньше. Да, токоотдача меньше (ограничение из-за дешевой BMS). Но пиковую нагрузку все равно не использовал, а надежность важнее - поставил и забыл. Играть в лотерею с покупкой свинцового не захотел - отзывы практически у всех от "работает годами" до "не проработал и пары месяцев".

Это безопасная замена - сборки LiFePO4 имеют схожую вольт-амперную характеристику со свинцовыми. Пиковый вольтаж у сборки LiFePO4 чуть выше свинцовых, но на емкость это не критично сказывается - кривая разряда у LiFePO4 практически плоская (так что когда ИБП сообщит о низком заряде - счет уже на секунды идет, так у меня во всяком случае).

Но размеры сборки могут быть чуть выше свинцового аккумулятора для ИБП - надо это учитывать (разница в несколько мм). В итоге я взял меньшей емкости, но с гарантированно "правильными" размерами - и не прогадал, лишнего места в ИБП не было.

P.S. свинцовые при работе могут выделять кислоту в воздух. Даже герметичные, необслуживаемые и специальные для ИБП - у них просто выделяется меньше и реже. Так что с переходом на LiFePO4 ушел и характерный запах работы ИБП.

От песка в глазах к панораме: как 49-дюймовый монитор заменил два 27-дюймовых и сделал жизнь и работу комфортнее

Думаю причина сухого глаза в частоте предыдущих экранов в 60 Гц. А на новом 144 Гц, отсюда и повышение удобства.

И второй фактор - VA-матрица. VA-матрицы считаются комфортнее для глаз за счет более глубокого черного цвета и высокой контрастности. Но темные объекты могут сливаться с черным - особенности матрицы.

Зацените BUSY Bar — устройство для продуктивности

Даже если без девайса с экраном не обойтись - старый телефон может заменить весь девайс, если приложение написать подобное (не уверен, что уже нет таких). Да, не так стильно, не так красиво, не так удобно - но почему бы и нет?

P.S. впрочем, это хороший подарок для тех, у кого "все уже есть" )

P.P.S. если сделать стильный эмулятор устройства под мобильный - то популярность устройства (и сценариев использования) может сильно возрасти. А главное - каждый запущенный эмулятор будет бесплатной рекламной площадкой. При такой цене не думаю, что реальное устройство будет конкурировать с эмулятором )

Зацените BUSY Bar — устройство для продуктивности

Туда бы еще встроить мониторинг качества воздуха )

Минус Lua, плюс перформанс: как толстый клиент на Go сделал работу с Tarantool эффективнее

Масштабирование бывает двух видов: горизонтальное и вертикальное. Горизонтальное также делится на два типа:

• репликация, которая отвечает за масштабирование вычислений;

• шардинг, который используется для масштабирования данных.

Оригинальное определение репликации и шардингу.

Репликация - это несколько серверов, работающих над одними и теми же данным. Если что и масштабируется что, то только операции чтения. Но зато повышается отказоустойчивость.

Шардинг - разделение данных по разным серверам. Да, данные масштабируются, но и операции чтения/записи тоже масштабируются. Отказоустойчивость если и повышается, то только в виде "стали недоступны не все данные, а только часть".

Софт для VDS-сервера, на который стоит обратить внимание новичкам

btop - bpytop переписанный на плюсах )

Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

Отличная статья!

Я бы еще добавил, что алгоритмы консенсуса распределенных систем (тот же Raft) хорошо на CQRS+Event Sourcing ложатся - что может быть полезно для повышения отказоустойчивости.

Ну и горизонтальное масштабирование на чтение можно получить до кучи (но не запись - пишут все узлы параллельно).