🛡 Продвинутый совет по Docker, который экономит часы и нервы.

Большинство разработчиков используют Docker как «виртуалку в коробке». Продвинутый уровень начинается, когда ты начинаешь мыслить слоями, кешем и размером образа.

Главное правило - многоступенчатые сборки (multi-stage builds).

Зачем это нужно:

Ты разделяешь процесс сборки и запуска.
В одном образе у тебя компиляторы, dev-зависимости, инструменты сборки.
Во втором - только чистый рантайм и готовый артефакт.

В итоге:
- образ меньше в разы
- меньше уязвимостей
- быстрее деплой
- быстрее pull на серверах

Как правильно мыслить:

1. Build stage - всё тяжёлое
Здесь ты устанавливаешь build-essential, gcc, node, go, poetry, всё что нужно для сборки.

2. Runtime stage - только то, что нужно приложению в работе
Никаких компиляторов. Никаких dev-зависимостей.

3. Кеш слоёв - твой главный ускоритель
Файлы зависимостей копируются раньше кода. Тогда при изменении кода Docker не пересобирает всё.

4. Не запускай контейнеры от root
Создай пользователя внутри контейнера. Это реальный прирост безопасности.

5. Используй конкретные версии образов
Не python:latest, а python:3.12.2-slim. Иначе однажды всё сломается без твоего участия.

# Stage 1 - сборка
FROM python:3.12-slim AS builder

WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install --no-cache-dir -r requirements.txt

COPY . .


# Stage 2 - минимальный рантайм
FROM python:3.12-slim

WORKDIR /app

COPY --from=builder /install /usr/local
COPY --from=builder /app .

RUN useradd -m appuser
USER appuser

CMD ["python", "app.py"]

📊 ПОЧЕМУ МАЛЕНЬКИЕ ИИ-МОДЕЛИ ИНОГДА ЛУЧШЕ БОЛЬШИХ

Большие модели выглядят впечатляюще в бенчмарках, но в реальных системах часто выигрывают маленькие. Причина проста — продакшен живёт не метрикой “кто умнее”, а метриками latency, стоимости и стабильности.

Маленькая модель отвечает быстрее. Это значит меньше задержки для пользователя, меньше таймаутов и выше конверсия. Когда у тебя API, чат или рекомендационная система, каждые 100 мс влияют на поведение людей.

Она дешевле. Меньше VRAM, меньше серверов, меньше энергопотребление. Можно масштабировать горизонтально без огромных GPU-кластеров. В итоге ты платишь за инфраструктуру в разы меньше.

Она стабильнее. Большие модели чаще галлюцинируют на узких задачах, перегружаются контекстом и сложнее дебажатся. Маленькая модель, обученная под конкретную задачу, ведёт себя предсказуемее.

И самое важное — маленькие модели проще дообучать, быстрее деплоить и легче держать под контролем. Поэтому в проде часто побеждает не “самая умная”, а “самая управляемая”.

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch, time

model_name = "Qwen/Qwen2.5-1.5B-Instruct" # маленькая модель
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.float16, device_map="auto")

prompt = "Explain why smaller models can be better in production:"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

start = time.time()
out = model.generate(**inputs, max_new_tokens=100)
latency = time.time() - start

print(tokenizer.decode(out[0], skip_special_tokens=True))
print(f"Latency: {latency:.2f}s")