Интернет пропал, а помощь пришла: как Qwen3:14B на Arch Linux сам себя починил

Тишина. Полная цифровая тишина

Знакомо чувство, когда внезапно обрывается интернет? На сервере, на рабочей машине, в самый неподходящий момент. Обычно лезешь в поиск, гуглишь ошибки, читаешь форумы. А если интернета нет совсем? Ни на одном устройстве в сети? Вот тогда начинается настоящий ад.

У меня именно такая ситуация случилась на домашнем сервере под Arch Linux 16 февраля 2026 года. Сеть умерла после очередного обновления системы. Классическая история для Arch - "обновился и сломалось". Только обычно ты хотя бы можешь погуглить решение. А тут - тишина.

Почему обычные методы не работали

Первая реакция - стандартный набор:

• ip a - интерфейсы на месте
• ping 8.8.8.8 - Destination Host Unreachable
• systemctl status NetworkManager - работает
• journalctl -xe - море логов, но ничего очевидного

Проблема в том, что без интернета ты не можешь:

• Поискать ошибку по коду
• Скачать пакет для исправления
• Посмотреть актуальную документацию
• Спросить на форуме или в чате

Ты остаешься один на один с системой. И вот здесь я вспомнил, что несколько недель назад поставил Ollama с моделью Qwen3:14B - просто поиграться, посмотреть, что умеет локальный ИИ. Хард у меня приличный: AMD Radeon RX 7800 XT с 16 ГБ VRAM, 64 ГБ оперативки. Модель летает.

Настройка Ollama и Qwen3:14B - что уже было готово

К счастью, Ollama у меня уже стоял и работал. Вот как я его настраивал изначально (это важно для понимания, почему все сработало):

1 Установка Ollama на Arch Linux

# Официальный способ через AUR
yay -S ollama

# Или через curl (если бы интернет был)
# curl -fsSL https://ollama.com/install.sh | sh

# Запуск и включение в автозагрузку
sudo systemctl enable ollama
sudo systemctl start ollama

2 Загрузка Qwen3:14B

# Это я делал заранее, когда интернет еще был
ollama pull qwen2.5:14b

# На февраль 2026 актуальная версия - Qwen2.5:14B
# Модель весит около 8.5 ГБ в формате GGUF

sudo pacman -S rocm-hip-sdk rocm-opencl-sdk

Диалог с машиной, которая должна починить саму себя

Итак, интернета нет. Запускаю Ollama через curl к localhost API:

# Проверяем, что Ollama работает
curl http://localhost:11434/api/tags

# Должен вернуть список моделей, включая qwen2.5:14b

Теперь самый интересный момент - диалог. Я открываю терминал и начинаю общаться с моделью через простой Python-скрипт, который у меня уже был:

#!/usr/bin/env python3
import requests
import json
import sys

def ask_ollama(prompt, model="qwen2.5:14b"):
    url = "http://localhost:11434/api/generate"
    data = {
        "model": model,
        "prompt": prompt,
        "stream": False
    }
    
    try:
        response = requests.post(url, json=data)
        return response.json()['response']
    except Exception as e:
        return f"Error: {e}"

# Первый запрос
problem = """
У меня Arch Linux. После вчерашнего обновления пропал интернет.
Локальная сеть работает, роутер пингуется (192.168.1.1),
но во внешний мир ничего не идет. Ping 8.8.8.8 дает 
"Destination Host Unreachable".

NetworkManager работает. Что проверить в первую очередь?
"""

print(ask_ollama(problem))

Ответ модели был структурированным и точным:

Пошаговая диагностика с подсказками ИИ

Я последовал советам и стал выполнять команды, а результаты снова кормить модели. Вот как выглядел диалог:

3 Шаг 1: Проверка маршрутизации

ip route show
# Вывод: default via 192.168.1.1 dev enp3s0 proto static metric 100

Шлюз есть. Передаю результат модели:

prompt = """
Результат ip route show: default via 192.168.1.1 dev enp3s0 proto static metric 100
Шлюз есть. Что дальше?
"""

Модель предлагает проверить, отвечает ли шлюз на ARP:

ip neigh show | grep 192.168.1.1
# Вывод: 192.168.1.1 dev enp3s0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Шлюз в ARP-таблице, связь на L2 есть. Передаю дальше.

4 Шаг 2: Трассировка на уровне L3

Модель предлагает сделать traceroute до шлюза:

sudo traceroute -n 192.168.1.1
# Первый хоп есть, дальше ничего

Потом она спрашивает про iptables. И вот здесь начинается самое интересное:

sudo iptables -L -n -v
# Вижу странное правило в FORWARD chain

Решение, которое нашла модель

После того как я показал моделью полный вывод iptables, она дала конкретную команду:

# То, что предложила Qwen3:14B
sudo iptables -P FORWARD ACCEPT
sudo iptables -F FORWARD

# И сразу проверяем
ping -c 3 8.8.8.8

И... о чудо! Пинг пошел! 3 пакета, 3 ответа. Интернет вернулся.

Но модель на этом не остановилась. Она продолжила:

Оказалось, что виноват был пакет `iptables-services`, который обновился и принес свои демоны, конфликтующие с NetworkManager.

Что я вынес из этого кейса

Это не просто "ай, как интересно, модель помогла". Это фундаментальное изменение в подходе к администрированию:

• Локальный ИИ - это резервный канал знаний. Когда интернета нет, у тебя есть "второй мозг" с доступом к огромному массиву знаний (пусть и замороженному на момент обучения модели)
• Контекст имеет значение. Qwen3:14B знает про Arch Linux, про iptables, про тонкости сетевой настройки. Это не общая модель, а специализированный инструмент
• Скорость реакции. Вместо часов поиска по логам и мануалам - 15 минут диалога с моделью
• Обучение на ходу. Модель не просто дает ответ - она ведет диалог, уточняет, просит дополнительную информацию

Как настроить такую систему для себя

Если хотите повторить мой опыт (а я очень рекомендую), вот минимальный набор:

Если у вас слабое железо, посмотрите мою статью про запуск Qwen2.5-3B на облачном сервере. Или вариант с запуском больших моделей на CPU.

Ошибки, которых стоит избегать

За месяц работы с локальными моделями я набил шишек. Вот главные:

• Не доверяй слепо. Модель может ошибаться. Всегда проверяй опасные команды (rm, dd, iptables -F без условий)
• Контекст решает. Чем точнее опишешь проблему, тем точнее ответ. Не "не работает интернет", а "после обновления пакета X перестал пинговать внешние адреса"
• Версии имеют значение. Qwen2.5:14B (2025) знает про systemd, но может путаться в старых sysvinit скриптах
• Память ограничена. 14B модель знает много, но не всё. Для узкоспециальных тем может понадобиться fine-tuning

Что будет дальше?

После этого случая я серьезно задумался о роли локальных ИИ в инфраструктуре. Представьте:

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

Уже сейчас есть проекты, которые идут дальше. Например, интеграция Qwen с Cursor для администрирования или настройка долгой памяти для локальных моделей.

Мой совет? Поставьте Ollama с Qwen2.5:14B сегодня. Пока интернет есть. Загрузите модель, проверьте, что она работает. Настройте простой скрипт для запросов. И когда в следующий раз что-то сломается в самый неподходящий момент, у вас будет секретное оружие - ваш собственный, локальный, офлайн-доступный эксперт по Linux.

А если лень возиться с терминалом, посмотрите one-click установщик для локальных LLM. Там все проще.