Google выпустила Gemini CLI — бесплатный open source ИИ-ассистент для командной строки

Не так все просто - файлы по запросу отдавать надо, mcp подключать и множество прочих функций в догонку.
В целом - да, при должной сноровке и понимании "что делать" можно достаточно быстро сделать.

Google выпустила Gemini CLI — бесплатный open source ИИ-ассистент для командной строки

Каждый вызов инструмента - это +1 запрос к модели (на обработку результатов вызова).

Google выпустила Gemini CLI — бесплатный open source ИИ-ассистент для командной строки

Интересно, как быстро форкнут и сделают подключение к локальной LLM?

15 минут — и у тебя бесплатная ИИ-модель для генерации кода, текста, чтения иллюстраций

Для "просто спросить" можно каждый раз новый диалог начинать - длинный контекст не нужен. Хватит и нескольких тысяч токенов.

Если модель "думающая" - то контекст нужен больше (раза в 2-3), "размышления" зачастую больше ответа или сравнимы с ним (сужу по qwen3 и deepseek-r1).

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

15 минут — и у тебя бесплатная ИИ-модель для генерации кода, текста, чтения иллюстраций

В работе с текстами - да, gemma-3 лучше будет. Но вот в технических вопросах qwen3 лучше себя показывает, на мой взгляд.

15 минут — и у тебя бесплатная ИИ-модель для генерации кода, текста, чтения иллюстраций

Qwen3-30B-A3B даст на порядок более высокую скорость генерации )

15 минут — и у тебя бесплатная ИИ-модель для генерации кода, текста, чтения иллюстраций

Заботимся о приватности данных и используем LM Studio с закрытыми сорцами?

И очень странные советы по выбору модели исходя из объема RAM.
Gemma 3 12B Q4_K_M как раз 8GB весит, c 8GB памяти запустится, но будет ОЧЕНЬ медленно.
И если у вас 16GB RAM - то и Gemma 3 12B Q8 можно запускать смело, все лишнее уйдет в своп. Главное - чтобы на модель и контекст под нее хватило памяти.

15 минут — и у тебя бесплатная ИИ-модель для генерации кода, текста, чтения иллюстраций

Qwen3 хорош. Единственное - через Ollama API плохо вызывает инструменты.
Но ollama поддерживает и OpenAI API (http://localhost:11434/v1/, любой токен в качестве ключа), через него лучше.

Еще есть devstral, но он более требователен к железу. С ним нареканий к Ollama API не было у меня.

Ускорение DeepSeek-R1 с подвохом: Когда токены в секунду врут о реальной скорости

Тут важна скорость памяти, число каналов памяти. Ядра - у меня 2х канальную DDR4 "забивает" 4 ядра (на вывод, для наибыстрейшей обработки запросов нужно 8 ядер). Проц - i7-10700, так что не сказать, что ядра особо шустрые.
Я настроил в итоге использование 4х ядер - меньше греется и шумит.

Так что есть все шансы ускориться - если не все каналы используете, 16 ядер должно "хватить" на 8 каналов памяти.

Ускорение DeepSeek-R1 с подвохом: Когда токены в секунду врут о реальной скорости

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

Ускорение DeepSeek-R1 с подвохом: Когда токены в секунду врут о реальной скорости

Идея для следующего теста: взять более компактную модель взять, да сравнить больше квантализаций )
Например, ту же qwen3:235b-a22b можно запустить в fp16 на таком сервере, а потом понижать постепенно.

На чём нам можно экономить и на чём нет — включаем здравый смысл

Т.е. именно о доступе к запущенным моделям речи не идет. В лучшем случае - арендуй VDI или через ML-платформу пробуй.

Жаль. Но может ML-платформа даст подобный сценарий использования - с оплатой за хранение модели и потребляемые ресурсы GPU на инференс.

Спасибо за информацию!

На чём нам можно экономить и на чём нет — включаем здравый смысл

С кучей GPU не думали предоставлять доступ к Open-source LLM? С оплатой за токены на входе / выходе (инференс).

Как я вижу, сейчас все в основном перепродают доступ к зарубежным провайдерам AI - что порождает много вопросов приватности данных.

А для частников в РФ, навскидку, я вариантов не нашел (за разумный прайс, не арендуя сразу GPU в облаке).

Локальный 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