HIGGS — новый open-source метод сжатия LLM от Яндекса и научных партнёров

Исследователи из Yandex Research, ВШЭ, MIT, KAUST и ISTA представили HIGGS — способ квантизации больших языковых моделей без потери качества.

Метод уже доказал свою эффективность на DeepSeek R1 (671B параметров) и Llama 4 Maverick (400B), позволяя запускать их на более доступных устройствах.

Что делает HIGGS:
⏺Уменьшает размер модели без дообучения
⏺Работает даже без доступа к обучающим данным
⏺Лучше GPTQ и AWQ в диапазоне 2–4 бит
⏺Уже проверен на Llama 3, Llama 4, Qwen2.5

Доступно на:
• GitHub
• Hugging Face
• arXiv (научная статья принята на NAACL 2025)

HIGGS делает LLM доступнее не только для корпораций, но и для независимых разработчиков и лабораторий.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает CRIU и зачем он нужен?

✅Ответ: CRIU (Checkpoint/Restore In Userspace) — это утилита для создания контрольных точек (checkpoint) работающих процессов и их восстановления. Она позволяет “заморозить” состояние приложения и перенести его на другой сервер или восстановить позже.

Основные возможности:
— Сохранение состояния памяти, сокетов, дескрипторов, PID и даже TCP-соединений.
— Используется в live-миграции контейнеров (например, в Docker и LXC).
— Полезен для отказоустойчивости, быстрого запуска сервисов и отладки.

Пример:

criu dump -t <pid> --images-dir /tmp/checkpoint  
criu restore --images-dir /tmp/checkpoint

Мониторинг сети с помощью sFlow

sFlow — это протокол мониторинга сети, который позволяет администраторам получать выборочные данные о трафике в реальном времени.

Его основное преимущество — минимальная нагрузка на устройство благодаря выборочному сбору данных.

Как работает sFlow

• Агент sFlow: встроен в сетевое устройство и собирает выборки пакетов.
• Коллектор: сервер, принимающий выборки и анализирующий данные.
• Выборки: небольшие фрагменты трафика передаются на коллектор для анализа.

Настройка sFlow на коммутаторе

1️⃣Включение агента sFlow

На устройствах Cisco:

sflow enable  

На устройствах HPE/Aruba:

sflow 1 sampling 1000  
sflow 1 destination 192.168.1.2 6343  

2️⃣ Настройка параметров

Cisco: Установите IP-адрес агента (IP устройства):

sflow agent-ip 192.168.1.1  

Укажите частоту выборок:

sflow sampling-rate 1000  

Настройте интервал опроса счётчиков:

sflow polling-interval 30  

Укажите IP и порт коллектора:

sflow collector-ip 192.168.1.2 6343  

3️⃣ Проверка и мониторинг

Проверьте текущую конфигурацию:

show sflow  

На HPE:

show sflow agent  

Убедитесь, что данные отправляются на коллектор. Для анализа можно использовать инструменты, такие как sFlowTrend или ntopng.

Swap-файл vs swap-раздел: как влияет на SSD и работу в системах с малым ОЗУ

На слабых серверах и миниатюрных VPS наличие подкачки решает всё. Даже базовая установка apt без swap может закончиться «убийством» процессов через OOM-killer.

Но что выбрать: swap-файл или swap-раздел? И главное — как сделать, чтобы не угробить SSD и не словить тормоза?

Что выбрать — swap-файл или swap-раздел?

Swap-раздел исторически считался более «надёжным» вариантом: он выделяется на физическом уровне и не фрагментируется. Но в реальности:
⏺менять его размер сложно (особенно без LVM);
⏺требует переформатирования или изменения разметки;
⏺неудобен в облаках и на VPS.

Swap-файл — более гибкий и удобный. Особенно если:
⏺вы работаете на облаке с единственным диском;
⏺у вас ограниченное место;
⏺нужно быстро изменить размер или выключить swap.

На современных ядрах swap-файл работает почти так же эффективно, как и раздел, особенно если создать его правильно.

Как правильно создать swap-файл

Не используйте dd — он может создать фрагментированный файл:

# Плохо:
dd if=/dev/zero of=/swapfile bs=1M count=1024

Вместо этого:

# Хорошо:
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

В fstab:

/swapfile none swap sw 0 0

Дополнительные улучшения: zswap и zram

Чтобы продлить срок службы SSD и ускорить работу на слабых системах:

Zswap — сжатая подкачка в RAM. Включается одной командой:

echo 1 > /sys/module/zswap/parameters/enabled

Zram — компрессированный swap в памяти. Особенно эффективен на embedded и ARM-устройствах:

modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
echo 512M > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

Настройка поведения подкачки

Чтобы система не бросалась в swap при любой нагрузке:

sysctl vm.swappiness=10

10–20 — хороший баланс: сначала используется RAM, и только потом swap.

Почему apt не чистит /var/cache/apt — и как это может убить ваш контейнер

На голом Ubuntu-бейзовом контейнере вы устанавливаете пару пакетов, а потом обнаруживаете, что образ раздулся на сотни мегабайт.

Причина почти всегда одна — автоматический кэш deb-пакетов, который apt сохраняет в /var/cache/apt/archives, но не торопится удалять.

Что происходит

При установке пакета:

apt install nginx

apt скачивает .deb в /var/cache/apt/archives, а потом уже ставит. Но не удаляет их, если вы явно не вызвали:

apt clean

или

apt autoclean

Во многих минималистичных контейнерных сборках вы этого не делаете — и копите десятки мегабайт мусора при каждом apt install.

Почему это критично в контейнерах
⏺Образы раздуваются — и занимают в 2–3 раза больше места, чем нужно.
⏺Файловая система в overlayfs не освобождается даже если удалить файл вручную позже. Он всё равно останется в нижнем слое.
⏺Контейнеры могут падать из-за переполнения ограниченного volume или rootfs (особенно в CI/CD).

Как это чинить правильно

Перед завершением сборки — чистите кэш:

apt-get clean
rm -rf /var/lib/apt/lists/*

или в Dockerfile:

RUN apt update && apt install -y \
    curl \
 && apt clean \
 && rm -rf /var/lib/apt/lists/*

Трюк с overlayfs

Если вы уже создали контейнер, в котором /var/cache/apt раздулся, а чистка не помогает — потому что это уже лежит в нижнем readonly-слое — можно:
1️⃣Использовать docker export / import — сохранит только активный слой.
2️⃣ Пересобрать образ с clean’ом до commit.
3️⃣ Смонтировать внешний tmpfs в /var/cache/apt в рантайме:

mount -t tmpfs -o size=100m tmpfs /var/cache/apt

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое systemd-nspawn и как он используется?

✅Ответ: systemd-nspawn — это легковесный инструмент контейнеризации, встроенный в systemd. Он позволяет запускать изолированные окружения, похожие на контейнеры, используя chroot и namespaces.

Ключевые особенности:
— Изоляция через PID, mount, user и network namespaces.
— Интеграция с systemd: контейнер можно управлять как обычным сервисом.
— Поддержка journald и машинного журнала логов.

MTU + TSO/GSO/UDP: когда jumbo frame ломает overlay-сеть

VxLAN, GENEVE и прочие overlay-технологии давно стали стандартом — но часто ломаются на ровном месте.

Один из таких кейсов — «всё работает, кроме какого-то странного трафика, который висит/рвётся/отваливается без объяснения». Виновник — неправильное сочетание MTU, jumbo-фреймов и offload’ов.

Что происходит

При использовании VxLAN поверх обычной сети каждый пакет получает дополнительный заголовок (VxLAN + UDP + IP), что увеличивает размер.

Если интерфейсы или туннельная прослойка не умеют в fragment/reassembly или MTU меньше ожидаемого, пакеты просто начинают теряться.

Особенно часто это бьёт по TCP SYN-ACK и UDP VoIP/QUIC.

Где это проявляется
• SSH зависает после ввода пароля
• веб-приложения внезапно «грузятся вечно»
• мониторинг теряет метрики
• nginx падает в 502 на старте TLS
• kubelet не подключается к apiserver через туннель

Как диагностировать
1️⃣Проверить MTU на всех интерфейсах в цепочке:

ip link show dev eth0
ip link show dev vxlan0

2️⃣ Проверить наличие offload’ов:

ethtool -k eth0 | grep -E '(tso|gso|gro)'

3️⃣ Поймать разрыв через tcpdump — будут видны обрезанные пакеты или ICMP fragmentation needed (не всегда!):

tcpdump -i vxlan0 -n -s 0 -vvv

4️⃣ Визуально ловить баги через ping -M do:

ping -s 8972 -M do <ip>

Как лечить
⏺Убедитесь, что внутренний MTU на overlay-интерфейсах (vxlan0, flannel.1 и т.п.) занижен хотя бы на 50 байт.
⏺Отключите GSO/TSO, если видите нестабильность:

ethtool -K eth0 gso off tso off

⏺Используйте sysctl для отключения Path MTU discovery в VxLAN:

sysctl -w net.ipv4.ip_no_pmtu_disc=1

⏺Проверяйте наличие проблемных маршрутов:

ip route get <destination>

TCP FIN_WAIT2 как зомби: кто на самом деле виноват

Когда сервер задыхается от тысяч FIN_WAIT2, первая реакция — «приложение не закрывает сокет». Но в реальности всё сложнее.

Это состояние — часть TCP state machine, в которой соединение уже завершено с одной стороны, но другая не закрыла свой конец. И залипнуть в нем можно надолго.

Что такое FIN_WAIT2?

После того как приложение вызывает close() на сокете, TCP-стек отправляет FIN и попадает в FIN_WAIT1. Как только получает ACK, соединение переходит в FIN_WAIT2. Ожидается, что вторая сторона тоже закроет соединение и отправит свой FIN.

Но если этого не происходит — соединение залипает. ОС ждёт. Иногда — вечно.

Где зарыта проблема?

1️⃣Клиент не закрывает соединение
Часто виновник — клиентское приложение, которое “забывает” вызывать close(), особенно если сессия рвётся без ошибок.

2️⃣ Сервер не настраивает таймауты FIN_WAIT2
Linux по умолчанию может держать FIN_WAIT2 бесконечно, если сокет уже передан в userspace.
Проверить:

sysctl net.ipv4.tcp_fin_timeout

Но это работает только для сокетов, не переданных в userspace. Если accept() уже был вызван — ядро не может удалить соединение самостоятельно.

3️⃣ Не освобождается сокет в приложении
Даже если вы вызываете close(), соединение может оставаться активным, если сокет всё ещё держится в дескрипторах. Проверить можно так:

lsof -nP | grep TCP | grep FIN_WAIT2

Как диагностировать
• Посмотреть, кто держит соединения:

ss -o state fin-wait-2 '( sport = :443 )'

• Локализовать виновника через lsof и netstat -p
• Проверить tcp_fin_timeout, tcp_keepalive_time и поведение приложения

Как лечить
⏺Явно закрывайте соединения на клиенте, особенно если используете keep-alive
⏺Включите tcp_tw_reuse и tcp_tw_recycle с осторожностью (лучше нет)
⏺На стороне сервера: оберните close() в таймер или настройте logic shutdown после inactivity
⏺Для embedded/ограниченных систем: можно использовать iptables для отсечения FIN_WAIT2 через conntrack timeout

Вместо вывода

FIN_WAIT2 — это не баг, а следствие честной реализации TCP. Но в проде оно ведёт к исчерпанию ресурсов и зомби-соединениям. Решение — всегда баланс между корректным shutdown и агрессивным таймаутом.