Как вы знаете, китайская LLM deepseek-R1 работает не хуже chatGPT-o1, но стоит в 20 раз дешевле. А знаете ли вы, что сама модель вообще бесплатная, её можно скачать себе и запустить на своём железе?

Мне стало интересно, как это делать, можно ли как-то запустить прямо на макбуке, и оказалось, что это делается буквально в два клика (конечно, полная модель на ноут не влезет, но дистиллированная - вполне).

Возможно, все уже это умеют, но расскажу для тех, кто, как и я, был в танке, так что держите инструкцию.

Для этого надо установить ollama, например так:

brew install ollama

и запустить

ollama serve

Запустить можно в отдельном окошке, чтобы смотреть логи, или в бекграунд убрать, пофиг. В общем, это некий сервис.

Дальше скачать и запустить модель. Это делается тупо одной командой.

ollama run deepseek-r1:8b

8b - это количество параметров (8 миллиардов). Другие варианты:
1.5b
7b
8b
14b
32b
70b
671b

Но понятно, что 671b на макбук не влезет, понадобилось бы больше 400 гигов видеопамяти. Зато 1.5b можно и на мобилу запихнуть.

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

Но это не очень юзер-френдли, поэтому дополнительно можно запусть web-интерфейс, например в докере одной командой

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

После чего на http://localhost:3000/ видна веб-морда, похожая на chatgpt.

Прикол китайской модели еще в том, что там показан процесс думания. Его можно посмотреть прямо в этом веб-интерфейсе.

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

По-моему, это очень круто: если вложиться в железо, можно очень быстро и просто поднять у себя самый топовый чат и не посылать больше свои секреты ни в OpenAI, ни в Китай.

Приглашаю вас подписаться на мой канал в telegram

🌐 HTTP-метод QUERY: новый метод для поисковых запросов

В мире HTTP давно существует проблема с передачей сложных поисковых запросов. Когда разработчику нужно передать большой набор параметров для поиска или фильтрации, у него есть два не самых удачных варианта.

Можно использовать GET и передавать всё в URL:

GET /feed?q=foo&limit=10&sort=-published&filters[]=status:active&filters[]=type:post

Но URL дефакто имеет ограничения по длине, а кодирование сложных параметров становится громоздким.

Второй вариант — использовать POST и передавать параметры в теле запроса. Однако POST не предназначен для таких операций: он не кэшируется и не является идемпотентным, что усложняет работу с CDN и повторную отправку запросов.

Именно поэтому появился новый метод QUERY. Он позволяет отправлять поисковые параметры в теле запроса:

QUERY /feed

Content-Type: application/json
{
  "q": "foo",
  "limit": 10,
  "sort": "-published",
  "filters": ["status:active", "type:post"]
}

При этом QUERY сохраняет все преимущества GET: он безопасный, идемпотентный и кэшируемый. Cочетает поддержку тела запроса с возможностью кэширования.

Метод официально получил статус PROPOSED STANDARD, что означает скорое появление поддержки в браузерах и веб-фреймворках.

Если вам интересны подобные посты, подписывайтесь на tg-канал Cross Join

Google выпустила новое API для Protocol Buffers в Go

Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной. 

До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:

type LogEntry struct {
  BackendServer *string
  RequestSize   *uint32
  IPAddress     *string
}

С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:

type LogEntry struct {
  xxx_hidden_BackendServer *string
  xxx_hidden_RequestSize   uint32
  xxx_hidden_IPAddress    *string
  // …внутренние поля опущены
}

// Доступ через методы
func (l *LogEntry) GetBackendServer() string
func (l *LogEntry) HasBackendServer() bool
func (l *LogEntry) SetBackendServer(string)
func (l *LogEntry) ClearBackendServer()
//...

Зачем это сделано?

Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)

Появилась возможность реализовать ленивое декодирование сообщений. Теперь вложенные сообщения декодируются только при первом обращении к ним, а не при общей десериализации. Для некоторых приложений это дает колоссальный прирост производительности и уменьшает аллокации

Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:

/*
message LogEntry {
  enum DeviceType {
    DESKTOP = 0;
    MOBILE = 1;
    VR = 2;
  };
  DeviceType device_type = 1;
}
*/

// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()

// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOP

С новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.

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

Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).

Старое API никуда не исчезнет – принцип обратной совместимости. 

Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.

cross-пост из tg-канала Cross Join

Я вот чего не понимаю.

Сейчас в мире продолжается тема с заталкиванием людей обратно в офисы.  Окей, менеджерам легче, когда они видят людей лично, кто-то считает, что люди в офисах будут работать эффективнее. Допустим, хотя никаких внятных подтверждений этому пока нет, исследования противоречивы. (Если знаете такие - скиньте.) Ну, допустим, даже так.

Но ведь это же всё не бесплатно. Я даже не говорю про косвенные потери от того, что лояльность людей падает, если им насильно меняют образ жизни. 

Это просто напрямую стоит денег:  люди, готовые работать в офисе стоят в среднем дороже, чем люди, которым дают выбор. Цена - это баланс спроса и предложения. Если предложение состоит только из людей одного города (где стоит офис), да еще и работающих только в офисе, а не дома - это прям существенно меньше чем "любые люди".

Особенно странно это выглядит у бигтехов, которые сначала делают массовые сокращения, чтобы сэкономить на ФОТ, а потом загоняют людей в офисы, что в конце концов увеличит ФОТ.

И вдвойне странно, если офисов много в разных частях страны/мира, и команда всё равно общается друг с другом через интернет.

Если же компании делают это, чтобы неявно сократить штат без затрат (некоторые люди увольняются сами, когда им предлагают вернуться в офис), то это тоже невыгодно на долгосроке - выплаты при сокращении платятся один раз, а зарплата - всегда.

Кросс-пост из tg-канала Cross Join

Всё чаще слышно про подключение ИИ к процессу код-ревью. Звучит круто, но есть нюансы.

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

Кроме того, AI смотрит только на код в текущем PR, не понимая ни архитектуры проекта, ни бизнес-требований. В итоге выдает технически правильные, но часто бесполезные рекомендации. Особенно это заметно в крупных проектах, где каждое изменение влияет на кучу связанных компонентов. Где есть "исторически сложившееся"

Код-ревью — это не только поиск багов. Это обмен опытом и обсуждение подходов. AI не может понять, подходит ли решение для конкретной команды, насколько оно масштабируемо и как впишется в существующую кодовую базу.

Сильные стороны AI все же есть. Он никогда не устает и не пропускает очевидные ошибки. Он быстро проверяет синтаксис, ищет типовые уязвимости, следит за стандартами кодирования. Может быстро проверить форматирование, найти потенциальные утечки памяти, отследить использование устаревших методов API. Это реально экономит время.

Поэтому AI в код-ревью лучше использовать как доп помощника - базовые проверки и очевидные ошибки. А разработчики-люди всё еще нужны для работы с пониманием контекста.

Приглашаю всех подписаться на мой канал https://t.me/crossjoin

Знакомая ситуация: диск забит, а вы понятия не имеете, куда делось всё свободное место? Стандартная утилита du не особо помогает разобраться в этом бардаке, надо обходить все папки и долго искать, что бы почистить.

Есть современный аналог du - опенсорсная утилита dust (написана на Расте).

dust - это как du, только удобнее и нагляднее. Вот что она умеет:

• Показывает файлы и папки в виде дерева - сразу видно, кто сколько весит. Не надо долго и мучительно ходить по папкам. Буквально сразу всё ясно.

  

• Раскрашивает вывод - большие файлы сами бросаются в глаза

• Сортирует всё по размеру - никаких лишних подсчетов

• Умеет фильтровать и исключать ненужное

Как начать пользоваться:

1. Ставим (в зависимости от):
   
   brew install dust
snap install dust
cargo install du-dust

2. Запускаем:
   
   dust [директория]

В dust много полезных опций, например

• Хотите заглянуть не слишком глубоко? dust -d 2

• Нужно только топ-10 прожорливых папок? dust -n 10

• Надоели временные файлы в выводе? dust -x "*.tmp"

• Интересует реальный размер файлов, а не то, что они занимают на диске? dust -s

• Хотите увидеть самые маленькие файлы первыми? dust -r

Взято из tg-канала Cross Join