Артефакты моделей и выбор open или closed

TL;DR

Когда вы выпускаете ИИ-фичу в видеопродукте, вы принимаете два ключевых решения ещё до написания первой строки кода. Первое – использовать ли модель через API стороннего вендора или развернуть её локально, скачав файл. Второе – если файл, то в каком формате. В 2026 году важны пять форматов: GGUF для сжатых локальных моделей, Safetensors для канонических обучающих чекпоинтов, ONNX для кросс-платформенного инференса, TensorRT engines для GPU от NVIDIA и Core ML packages для устройств Apple. Выбор между open и closed в 2026 году – уже не вопрос идеологии: закрытые frontier API по-прежнему лидируют в сложных задачах reasoning, open weights сравнялись с ними по большинству production-задач, а оптимальное решение почти всегда – гибрид, маршрутизирующий запросы в зависимости от use case.

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

Если вы выпускаете видеопродукт, ИИ-функции в вашем роадмапе будут работать либо на локальной модели, которую вы скачали, либо через API, к которому обращаетесь по сети. От этого решения зависят ваша кривая затрат, политика конфиденциальности, задержки, нагрузка по соблюдению норм и размер инженерной команды на ближайшие три года. Выберете неподходящий формат – App Store отклонит ваше iOS-приложение из-за чекпоинта размером 4 ГБ; ошибётесь с закупкой – обнаружите, что счёт OpenAI превысит счёт AWS уже при 100 000 пользователей в месяц. Эта статья – шпаргалка, после которой продукт, инженерия и финансы приходят к согласию за одну встречу, а не за целый квартал.

Два закупочных решения простыми словами

Каждая ИИ-фича в вашем продукте начинается с двух ключевых вопросов. Первый – закрытая или открытая модель: вы используете модель через API поставщика или развертываете её самостоятельно на собственном оборудовании? Второй – о формате: если вы запускаете модель сами, в каком формате инженерный отдел её принимает?

Эти вопросы независимы в теории, но тесно связаны на практике. Closed-API решает оба сразу – формат представляет собой HTTPS-эндпоинт вендора, и вам не важно, что за ним стоит. Open-weights дают выбор по второму вопросу: у вас есть файл весом 13 ГБ с Hugging Face, и теперь нужно решить, запускать ли его через vLLM в собственном датацентре, через llama.cpp на компьютере разработчика, через Core ML на iPhone или через TensorRT на GPU NVIDIA.

Думайте об этом как о покупке дома. Закрытый и открытый форматы – это как аренда или собственность. Если речь о собственности, то формат может быть как сырой пиломатериал, так и готовые стеновые панели или сданный «под ключ» этаж. Каждый вариант даёт разные инструменты, скорость и свободу перепланировки.

В статье мы рассмотрим оба решения полностью. Сначала – пять форматов: что это такое, кто их поддерживает, какие рантаймы их загружают. Затем проанализируем, как каждый формат работает с топологиями развёртывания (on-device, edge, in-region cloud, cross-region cloud), которые мы обсуждали в предыдущем уроке про латентность и развёртывание. И, наконец, разберём вопрос закупок: open против closed – с арифметикой, требованиями к соответствию и деревом решений.

Пять форматов артефактов модели, которые работают в 2026

Пять форматов охватывают около 95% того, что вы встретите в проектах с видео и ИИ. Два из них хранят чистые тензоры: Safetensors и устаревшие pickle/PyTorch .bin. Ещё два – это пакеты, оптимизированные под инференс и скомпилированные под конкретный рантайм: TensorRT engines и Core ML .mlpackage. Один – ONNX – является кросс-платформенным промежуточным форматом. И последний – GGUF – предназначен для выполнения инференса на CPU устройства, и именно на нём держится почти весь опыт «запусти LLM на ноутбуке».

Идём по порядку: Safetensors (стандарт для обучения), GGUF (сжатая локальная версия), ONNX (переносимая), TensorRT (оптимизированная под NVIDIA), Core ML (оптимизированная под Apple).

Safetensors – канонический обучающий чекпоинт

Safetensors – это бинарный формат файлов, разработанный и открытый Hugging Face в 2022 году. Он хранит сырые тензоры – миллионы и миллиарды чисел, которые и составляют обученную нейронную сеть – вместе с небольшим JSON-заголовком, описывающим имя, форму и тип данных (dtype) каждого тензора. Внутри файла Safetensors нет исполняемого кода. Это заложено в его архитектуре: при открытии файл ничего не выполняет – он просто возвращает тензоры.

Это последнее свойство – причина существования Safetensors. Оригинальные PyTorch .bin и .pt используют сериализацию через pickle, у которой есть фундаментальная уязвимость в безопасности: загрузка pickle-файла позволяет выполнить произвольный Python-код, встроенный в файл при сохранении. Злоумышленник, подменивший чекпоинт в model registry, может заставить всех пользователей, использующих его далее, выполнить нужный ему код – просто вызвав torch.load(). Это не теория – атаки на цепочку поставок с использованием pickle-чекпоинтов Hugging Face задокументированы с 2023 года. Safetensors устроен так, что такая атака становится невозможной: файл содержит только данные, никакого кода в нём нет.

Safetensors-файлы имеют расширение .safetensors. Большие модели разбиваются на части – чекпоинт Llama 70B приходит как папка с файлами model-00001-of-00030.safetensors, model-00030-of-00030.safetensors и index.json, в которых лоадер определяет, где находится каждый тензор. В той же папке также находятся файл config.json с архитектурой модели, файл tokenizer.json для текстовых моделей и файл README.md («model card») с лицензией, описанием обучающих данных и результатами бенчмарков.

К 2026 году Safetensors вытеснил pickle в качестве де-факто формата чекпоинтов. Hugging Face публикует новые релизы в формате Safetensors в первую очередь; PyTorch интегрировал поддержку Safetensors в основной API сериализации, а документация фреймворка теперь рекомендует Safetensors как формат по умолчанию для сохранения. Если релиз 2026 года доступен только в .bin – это тревожный сигнал: либо провайдер отстаёт на годы, либо чекпоинт был создан в старом обучении и ещё не был пересохранён.

Чего не делает Safetensors: не сжимает данные и не предназначен для прямого развёртывания в production. Llama 4 70B в формате Safetensors с точностью float-16 занимает около 140 ГБ. Обучать, дообучать и запускать модель можно – при условии, что у вас есть GPU с 140 ГБ видеопамяти. Для развёртывания в production на менее мощном оборудовании модель нужно конвертировать в один из форматов, перечисленных ниже.

GGUF – формат сжатого локального инференса

GGUF («GGML Universal File») – бинарный формат, представленный в августе 2023 года мейнтейнерами llama.cpp. Именно он позволил запускать большие языковые модели на обычном ноутбуке. Один GGUF-файл объединяет тензоры, метаданные модели (архитектура, длина контекста, правила токенизатора) и конфигурацию приложения в единый memory-mappable бинарник, который llama.cpp и другие инструменты загружают за миллисекунды.

Определяющая особенность GGUF – поддержка квантизации. Простыми словами, квантизация – это способ хранить каждое число модели меньшим количеством бит, чем использовалось при обучении: вместо 16-битных чисел с плавающей точкой – 8-битные целые, затем 4-битные, всё чаще 2-битные и даже 1.58-битные. Каждый шаг снижения точности уменьшает размер модели на диске, снижает потребление памяти при работе и позволяет запускать её на более скромном оборудовании – ценой некоторой потери точности. GGUF стал первым форматом, который стандартизировал метаданные о том, какая схема квантизации применена к каждому тензору, чтобы лоадер мог прочитать файл и восстановить исходные тензоры при инференсе.

Лейблы квантизации, которые вы видите на каждой GGUF-загрузке – Q4_K_M, Q5_K_M, Q8_0, F16, BF16 – это не случайные названия. Это конкретные алгоритмы. По соглашению: цифра после Q означает среднее количество бит на вес (4, 5, 6, 8); K – это «K-quants» (современная версия); M – «medium» (баланс между размером и качеством, существуют также S – small и L – large); F16 и BF16 – не квантованные half-precision базовые модели. Недавние добавления Q4_K_XL и семейство IQ (imatrix-основанные «I-quant») позволяют извлечь чуть больше качества из каждого бита.

Таблица ниже – это решение, которое каждая команда принимает при выпуске локально-инференсной фичи. Цифры взяты из независимых бенчмарков 2026 года, сравнивающих квантизацию с неквантизованным базовым вариантом на той же модели. Читайте их как порядок величин: точные значения немного варьируются от модели к модели и от бенчмарка к бенчмарку, но относительный порядок остаётся стабильным.

Пример с цифрами. Llama 3 70B в формате F16 занимает около 140 ГБ на диске и около 145 ГБ видеопамяти при работе – что практически недостижимо для большинства ноутбуков. Та же модель в формате Q4_K_M сжимается до 140 × 0,28 ≈ 39 ГБ, спокойно работает на Mac Studio с 64 ГБ оперативной памяти и сохраняет около 95% точности исходной модели. Если перейти к Q2_K, размер файла сокращается до 22 ГБ, но качество падает ниже уровня, который большинство пользователей в продакшене сочтут приемлемым.

GGUF в первую очередь используется llama.cpp, а затем – всеми решениями, построенными на его основе: Ollama (обёртка, упрощающая использование llama.cpp как сервиса), LM Studio (десктопный интерфейс для локальных моделей), GPT4All, Jan, koboldcpp. К 2026 году на Hugging Face будет размещено десятки тысяч GGUF-чекпоинтов со встроенным просмотрщиком метаданных и сервисом для вывода. На странице библиотеки GGUF в Hub реализована фильтрация моделей по уровню квантизации, так что команда, выбирающая релиз, может отфильтровать модели до Q4_K_M 7B-вариантов при подборе модели под конкретную задачу.

Чего GGUF не делает: на нём не обучаются и его не используют на большинстве production-серверов. GGUF оптимизирован под инференс на CPU и в системах с унифицированной памятью (Apple Silicon, AMD APU, современные процессоры Intel), а его поддержка GPU через CUDA-бэкенд llama.cpp, хоть и работает, уступает vLLM и TensorRT по пропускной способности. Если вы обрабатываете тысячи одновременных запросов на оборудовании NVIDIA, вы не выберете GGUF – вы выберете vLLM с Safetensors или TensorRT с скомпилированным движком.

ONNX – кросс-платформенный формат обмена

ONNX («Open Neural Network Exchange») – это open-source формат, изначально разработанный совместно Microsoft и Facebook в 2017 году, а ныне находящийся под управлением Linux Foundation. Его цель – решить конкретную задачу: модель, обученная в PyTorch, должна корректно загружаться в TensorFlow, в среды выполнения Apple и NVIDIA, а также в браузере без необходимости переписывания кода. ONNX определяет стабильный граф на диске – ориентированный ациклический граф математических операций, – который могут экспортировать и импортировать все основные фреймворки.

Расширение файла – .onnx. Один файл хранит граф модели: каждую операцию, каждый вес и каждую связь между операциями, а также формы входных и выходных тензоров. Поддержка тулинга есть в каждом фреймворке: torch.onnx.export() – самый распространённый путь; в Hugging Face optimum реализованы высокоуровневые вспомогательные функции для трансформеров. ONNX Model Zoo на GitHub содержит канонические экспортированные модели компьютерного зрения (ResNet, семейство YOLO, MobileNet) и множество моделей для обработки речи и языка.

ONNX наиболее полезен в паре с ONNX Runtime – кросс-платформенным движком вывода от Microsoft. ONNX Runtime загружает .onnx-файл и при старте выбирает «execution provider»: CUDA для NVIDIA, TensorRT для дополнительной оптимизации, DirectML для GPU на Windows, CoreML на устройствах Apple, OpenVINO на процессорах Intel и QNN на чипах Qualcomm. Один и тот же файл работает везде – рантайм автоматически подбирает самый быстрый бэкенд для текущей платформы. На Azure Cobalt 100 (Arm64) с моделью SqueezeNet-INT8 ONNX Runtime обеспечивает более 538 инференсов в секунду при пиковой нагрузке на память менее 37 МБ – типичный пример «лёгкой и переносимой» модели в экосистеме ONNX.

Зачем ONNX в видеопродукте: вы экспортируете YOLO-детектор один раз, а затем развертываете один и тот же артефакт – в браузер через ONNX Runtime Web, на Android с помощью ONNX Runtime Mobile, на Linux-устройствах на краю сети через ONNX Runtime + OpenVINO и в облачных GPU – через ONNX Runtime + CUDA. Каждый релиз YOLO от Ultralytics поставляет экспорт .onnx рядом с PyTorch-чекпоинтом именно благодаря этому мультиплатформенному свойству.

Чего ONNX не делает: он не так быстр на конкретном железе, как нативный формат этого железа. YOLO в ONNX Runtime на GPU от NVIDIA будет в 1,5–3 раза медленнее той же модели, сконвертированной в TensorRT engine. ONNX – правильный выбор, когда переносимость важнее производительности; TensorRT – когда производительность важнее переносимости.

Второй нюанс: не каждая архитектура экспортируется корректно. Новые варианты трансформеров, кастомные ядра внимания, динамический контроль потока – всё это может вызывать сбои или ухудшение качества при экспорте в ONNX. Всегда экспортируйте модель, а затем проводите проверку качества (PSNR, точность или специфичную для задачи метрику), чтобы убедиться, что экспортированная версия ведёт себя так же, как оригинальная. Исследование 2022 года по проблемам конвертации моделей глубокого обучения подтверждает: ошибки при преобразовании PyTorch→ONNX встречаются достаточно часто, чтобы требовать регулярной валидации после конвертации.

TensorRT – скомпилированный движок для NVIDIA

TensorRT – это SDK для вывода от NVIDIA, а также формат файла, который он генерирует: скомпилированный «engine», оптимизированный под конкретную архитектуру GPU (Ampere, Hopper, Blackwell) и под конкретную модель. Вы передаёте в TensorRT ONNX-файл (или PyTorch-модель через torch_tensorrt), и он выдаёт .engine или .plan. Этот файл работает быстрее, чем любой универсальный рантайм, – TensorRT выполняет слияние слоёв, автоматическую настройку ядер, калибровку точности (FP16, INT8, FP8, FP4 на новых GPU) и оптимизации размещения памяти, ориентированные на конкретный чип, под который была выполнена компиляция.

Прирост производительности от компиляции с помощью TensorRT зависит от модели и нагрузки, но стабильно составляет 2–5× по сравнению с режимом eager в PyTorch на той же GPU и 1,5–3× – по сравнению с ONNX Runtime с CUDA execution provider. Для сервинга LLM существует специализированный инструмент – TensorRT-LLM (специализация TensorRT под трансформерные языковые модели), который достигает почти state-of-the-art производительности, часто уступая vLLM всего на 10–20%, а на отдельных квантизованных задачах – опережая его.

Зачем TensorRT в видеопродукте: высокопроизводительный сёрвинг CV-моделей на NVIDIA-оборудовании. Surveillance-система, обрабатывающая тысячи параллельных камер на кластере H100, будет запускать YOLO и SAM 2 через TensorRT-движки, а не через PyTorch. Real-time видео-VLM инференс, где каждая миллисекунда работы GPU стоит денег, существует именно здесь.

Чего не делает TensorRT: он не переносится между поколениями GPU. Engine, скомпилированный под A100, не запустится на B200. При смене оборудования придётся пересобирать – это усложняет эксплуатацию. Это не формат, который можно публиковать, – это формат, который вы генерируете локально под конкретный GPU. И это не решение, если ваша нагрузка работает не на NVIDIA: TensorRT поддерживает только оборудование этой компании.

Core ML – формат пакета для устройств Apple

Core ML – это on-device рантайм машинного обучения от Apple и формат файлов, которые он использует: современный расширяемый формат .mlpackage (появился в Xcode 13) или устаревший формат .mlmodel. .mlpackage – это папка, а не файл, содержащая граф модели (в формате Apple ML Program), веса и JSON-манифест. Пакет работает на iPhone, iPad, Mac, Apple Watch и Vision Pro.

Конвертация выполняется с помощью Python-пакета coremltools, который поддерживается Apple. Типичный путь преобразования – PyTorch → ONNX → Core ML или напрямую PyTorch → Core ML через coremltools.convert(). Полученный модельный файл .mlpackage размещается внутри app bundle для распространения через App Store или загружается с CDN разработчика при первом запуске приложения.

Зачем Core ML в видеопродукте: on-device-функции в iOS/macOS-приложениях, где важна задержка, а данные не должны покидать устройство. Размытие фона, beauty-фильтры, коррекция взгляда, on-device-сегментация, компактные ASR-модели для live-субтитров, on-device-обнаружение объектов в системах видеонаблюдения. Core ML автоматически выбирает лучшее доступное железо – Neural Engine на iPhone с A14 и новее, GPU в остальных случаях, CPU как резервный вариант – и модель работает без сетевого трафика. Vision Framework на iOS естественно дополняет Core ML для обработки изображений и видео.

Чего Core ML не делает: это не формат для чего-либо, кроме платформ Apple. Он также не подходит для очень больших LLM; Apple-овский MLX (отдельный, но смежный проект) – лучший выбор для трансформерных моделей на Apple Silicon благодаря нативным ядрам Metal и поддержке общей памяти. Core ML отлично работает с конволюционными и лёгкими трансформерными моделями; чтобы запускать Llama 70B на Mac – конкуренция идёт между MLX и llama.cpp.

Нажмите, чтобы увеличить

Как форматы соотносятся с топологией развёртывания

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

На устройстве пользователя – телефоне, лэптопе, в браузере, SoC IP-камеры – формат платформо-зависимый. iOS- и macOS-приложения используют Core ML. Android – LiteRT (бывший TensorFlow Lite) или ONNX Runtime Mobile. Браузеры – ONNX Runtime Web с execution provider WebGPU, transformers.js или WASM-сборку llama.cpp под LLM-сценарии. Linux edge с дискретным GPU – TensorRT (если NVIDIA), OpenVINO (если Intel) или ONNX Runtime с подходящим provider. Лэптопы разработчиков и prosumer Mac под локальную LLM – GGUF через llama.cpp или Ollama.

На edge – CDN-узел, 5G mobile edge compute, региональный GPU-пул – выбор сужается. Cloudflare Workers AI в основном поддерживает ONNX; AWS Lambda и аналогичные serverless GPU-платформы предпочитают ONNX или скомпилированные TensorRT-движки. LiveKit Agents worker на edge-GPU обычно запускает квантизованную модель в vLLM (Safetensors) или GGUF-модель через Ollama – в зависимости от целевого уровня пропускной способности.

В локальном облаке – собственном AWS/GCP/Azure или специализированном GPU-облаке (Modal, Replicate, Together, Fireworks, RunPod) – формат Safetensors является источником истины и тем, что использует ваш стек сервинга. vLLM, де-факто стандартный сервер для открытых моделей LLM, загружает Safetensors напрямую. NVIDIA Triton Inference Server поддерживает ONNX, TensorRT-движки, PyTorch, TensorFlow и Python-бэкенды. Для максимальной производительности на NVIDIA в масштабируемом режиме используется цепочка: Safetensors → компиляция через TensorRT-LLM → развёртывание движка. Для максимальной переносимости – Safetensors → экспорт в ONNX → запуск в Triton или ONNX Runtime.

В межрегиональном облаке почти всегда используется закрытый API. Если вы обращаетесь к Anthropic, OpenAI или Google из региона, где нужная вам модель не размещена, вы платите штраф за задержку при межрегиональном взаимодействии за возможность использовать передовую модель. Формат ответа – тот, который предоставляет вендор по HTTPS, обычно совместимый с OpenAI JSON.

Таблица ниже представляет собой сводку матрицы. Читайте её так: «при слое X и задаче Y используйте следующий формат».

Типичные ошибки при закупках – и подводные камни каждого формата

Перед тем как переходить к вопросу open vs closed, отметим несколько типичных ошибок – они повторяются в каждом проекте, где не было человека, уже имеющего опыт выпуска.

Ошибка первая: выложить Safetensors-чекпоинт внутри мобильного приложения. Самая распространённая ошибка новичков – она легко выявляется на этапе проверки в App Store или Google Play. Чекпоинт объёмом 13 ГБ не пройдёт по лимитам размера, а даже если бы прошёл – устройство просто не сможет загрузить его в память. Решение – конвертация: PyTorch или Safetensors → ONNX → Core ML (для iOS) или LiteRT (для Android). Готовый продукт для мобильных устройств всегда представляет собой сконвертированную, квантизованную версию модели, а не чекпоинт для обучения.

Ошибка вторая: GGUF на high-throughput NVIDIA-сервере. GGUF может работать на CUDA через llama.cpp, но его производительность по пропускной способности (throughput) не сравнима с другими решениями: при высокой нагрузке vLLM с Safetensors или TensorRT-LLM с скомпилированным engine обгоняют llama.cpp в 3–4 раза на том же оборудовании. Используйте GGUF для ноутбуков разработчиков и Mac на Apple Silicon; vLLM или TensorRT – для серверных ферм.

Ошибка третья: доверять pickle-чекпоинту от незнакомого паблишера. Если релиз модели публикуется только в .bin или .pt, а паблишер – не известный институт, не используйте его без проверки. Для таких случаев существует picklescan. Лучше отказаться от артефакта и запросить экспорт в формате Safetensors. В 2026 году нет веских причин, чтобы новый релиз выпускался исключительно в формате pickle.

Ошибка четвёртая: считать, что «open weights» = «MIT licensed». Для frontier-моделей это почти никогда не так. Llama 4 – под Llama 4 Community License: коммерческое использование разрешено только организациям с менее чем 700 миллионами MAU, производные работы требуют обязательной атрибуции, мультимодальные варианты явно не лицензируются для физических лиц или компаний, зарегистрированных в ЕС. Mistral 3 – в отличие от них – настоящая Apache 2.0. У Qwen 3 – кастомная лицензия. У DeepSeek – тоже кастомная. MiniMax недавно перешёл на «Modified-MIT», которая ограничивает коммерческое развертывание без письменного разрешения. Перед подписанием сделки необходимо внимательно изучить лицензию каждой модели – универсального правила нет.

Ошибка пятая: сравнивать closed-API и open-weights по цене за токен. Closed-API рассчитываются по цене за миллион токенов. Open-weights оцениваются по стоимости GPU-часа плюс затраты на инженеров для поддержки стека, а также с учётом коэффициента загрузки в вашем профиле одновременных запросов. Экономика зависит от объёма: closed-решения выигрывают при малом объёме, а open – с большим отрывом при масштабировании. Ниже считаем точку безубыточности.

Решение open vs closed при закупке

Можем перейти ко второму вопросу. Вы ознакомились с format map. Будете ли вы вообще изменять файл формата – зависит от одного решения по закупке: арендуете ли вы интеллект (closed API) или владеете артефактом и используете его самостоятельно (open weights)?

В абстракции правильного ответа не бывает. Есть правильный ответ для конкретного use case и определённого объёма. Ниже – фреймворк, которым мы в Фора Софт пользуемся, когда клиент просит оценить фичу.

Шаг 1 – Отбор по критериям конфиденциальности и соответствия требованиям

Первый фильтр – бинарный. Если данные, с которыми работает фича, не могут покидать вашу сеть – будь то требования HIPAA в США, GDPR для граждан ЕС, PCI для платёжных данных, обязательства SOC 2 Type II, статья 50 EU AI Act или отраслевые нормы – то closed-API автоматически исключается из data path. Использовать closed-API можно лишь для проверки идей на этапе разработки, но трафик в продакшене должен проходить через оборудование, которым вы управляете. Исключения – это сфера open weights, независимо от их стоимости.

EU AI Act полностью вступает в силу с 2 августа 2026 года для большинства операторов. Приложение XII обязывает поставщиков моделей general-purpose ИИ предоставлять техническую документацию downstream-интеграторам – это требование сложнее выполнить, если модель представляет собой closed-API «чёрный ящик», и проще, если вы контролируете артефакт.

Телемедицина, регулируемые финансы, оборонная сфера, многие enterprise-внедрения – по умолчанию попадают сюда. Большинство consumer-видеофич – нет.

Шаг 2 – Отбор по capability gap

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

Под термином frontier reasoning – многосценарное планирование, сложная математика, продвинутые агентные рабочие процессы – закрытые модели (Claude Opus 4.6, GPT-5, Gemini 3.1 Deep Think) демонстрируют измеримое лидерство на бенчмарках GPQA Diamond и Humanity's Last Exam. Открытые модели на переднем крае (Llama 4 Maverick, DeepSeek V4, Qwen 3) близки к ним, но пока не достигают того же уровня.

Под большинство production-работ – модерация контента, суммаризация, транскрипция, перевод, задачи компьютерного зрения, понимание видео на типичных масштабах – модели с открытыми весами сопоставимы или превосходят закрытые на задачеспецифичных бенчмарках. У пайплайна видеонаблюдения, использующего YOLO и SAM 2, нет оснований обращаться к закрытым API.

Под task-specific маленькие модели – распознавание речи (Whisper), генерация эмбеддингов, детекция объектов (YOLO, RT-DETR), сегментация (SAM 2, Florence-2) – открытые веса стали стандартом уже много лет. Закрытые конкуренты отстают.

Если ваша фича находится в сегменте frontier-reasoning и качество влияет на бизнес – closed побеждает. В любом другом случае open хотя бы конкурентен.

Шаг 3 – Расчёт точки безубыточности по стоимости

После compliance и capability – арифметика. Closed-API рассчитываются по миллиону input/output токенов; open weights – по GPU-часу плюс операционные расходы на инженерию.

Пример с цифрами. Выпускаете фичу AI meeting summary. Каждая встреча генерирует 8 000 входных токенов и 800 выходных токенов. На старте ожидаете 100 000 сводок в месяц, рост до 1 000 000 в месяц за год.

Закрытая API-математика (по цене, эквивалентной GPT-4: $0.40 за миллион токенов – нижний предел для этого уровня возможностей в 2026 году):

Стоимость одного резюме = (8 000 / 1 000 000 × 0,40 $) + (800 / 1 000 000 × 0,40 $) = 0,0032 $ + 0,00032 $ ≈ 0,0035 $.

На 100 000 сводок в месяц: 350 долларов в месяц. На 1 000 000 сводок в месяц: 3 500 долларов в месяц.

Open-weights математика (vLLM, модель класса 70B на одной H100 SXM по $2,50 в час, реалистичный батчинг обеспечивает 200 сводок в час на GPU при сохранении качества):

Часов в месяц на 100 000 сводок: 100 000 / 200 = 500 часов. По $2,50 за час – $1 250 в месяц, плюс расходы на ops, мониторинг, autoscaling и дежурства инженеров. В режиме steady state с использованием одного GPU эквивалентной мощности закрытый API оказывается выгоднее.

На 1 000 000 сводок в месяц – 5 000 часов вычислений, что эквивалентно примерно 7 GPU, работающих постоянно. При использовании батчинга и эффективной загрузке стоимость GPU-счёта составляет $7 000–9 000 в месяц, плюс около $5 000 в месяц на инженерные и инфраструктурные расходы. На таком масштабе открытые модели начинают выигрывать: закрытые решения обходятся в $35 000 в месяц, а открытые – около $14 000 в месяц. Разница – в 2,5 раза.

Точка пересечения зависит от трёх факторов: стоимости токена в закрытом API, стоимости GPU-часа в вашем развёртывании с открытыми весами и эффективности батчинга. Для большинства задач video-ИИ в 2026 году закрытые API выгоднее при объёме ниже 5–10 миллионов токенов в день; открытые модели – при нагрузке выше 50–100 миллионов токенов в день; а в промежуточной зоне выбор зависит от инженерных возможностей.

Стоимость инференса LLM за токен снижается примерно в 10 раз год к году с 2023 года, и точка безубыточности смещается: то, что в 2024 году давало преимущество open-weights, к 2026 году может оказаться выгоднее через closed-API при том же объёме. Пересчитывайте каждый год.

Шаг 4 – Налог на инженерную ёмкость

Развёртывание моделей с открытыми весами требует затрат инженерного времени, в то время как использование закрытых API – нет. Реалистичный базовый уровень для production-сервиса на основе одной open-weights LLM в 2026 году – один-два ML-инженера на обслуживание serving-стека (vLLM, Triton, автоскейлинг, мониторинг), один DevOps на управление GPU-ресурсами и реагирование на инциденты, а также часть времени security-инженера на сканирование цепочки поставок и SRE на oncall-поддержку. Назовём это $30 000–60 000 в месяц – полная стоимость инженерных ресурсов на рынке США и Западной Европы.

При работе с закрытым API инженерные затраты составляют одного прикладного инженера, который вызывает HTTPS-эндпоинт, плюс затраты на prompt-инжиниринг. Оценим это в $10 000–20 000 в месяц.

Дельта – примерно $20 000–40 000 в месяц – это стоимость опциональности. Вы платите за владение артефактом, за хранение данных на своём железе, за возможность менять модели без перезаключения контрактов, за контроль качества и задержек по своему графику. Для функции, которая генерирует material revenue, это дёшево. Для экспериментальной – дорого.

Шаг 5 – Гибрид

Правильный ответ для большинства команд – не сторона. Это router. Вы маршрутизируете лёгкие 80% трафика на open-weights, которые хостите сами, а тяжёлые 20% – на closed-API, замеряете и корректируете параметры ежеквартально. Стартуйте с closed-решения ради скорости запуска, постепенно мигрируйте отдельные high-volume или privacy-sensitive нагрузки на open, когда данные это оправдывают, и оставляйте closed как fallback на случай, если open не справится.

Это паттерн, который Фора Софт применяет практически во всех ИИ-интеграциях, выходящих в продакшн в 2026 году, и к которому пришли большинство агентств и инженерных команд.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт интегрирует ИИ в видеопродукты с 2019 года – в видеоконференции, OTT-стриминг, системы видеонаблюдения, телемедицину и электронное обучение. Мы выводили каждый формат артефакта из этой статьи в продакшн: Safetensors на кластерах vLLM для meeting copilots, GGUF на Mac Studio для on-prem развёртываний, ONNX в браузерах для клиентской модерации, TensorRT-движки для аналитики видеонаблюдения, пакеты Core ML для beauty-фильтров и субтитров в реальном времени на устройстве. Закупочный фреймворк из статьи – тот, которым мы пользуемся, когда клиент спрашивает: «запускать на OpenAI или на собственных GPU?». Правильный ответ почти всегда – «оба, с маршрутизацией по use case» – и карта форматов выше показывает, как эта маршрутизация реализуется на практике.

Cost-crossover лист под ваши цифры

Чтобы адаптировать стоимостную арифметику под ваш продукт, мы публикуем одностраничный чек-лист, который поможет пройти пятишаговый закупочный фреймворк и собрать все необходимые входные данные. Этот же артефакт наши инженеры распечатывают перед звонками по scoping. Скачать чек-лист по артефактам моделей и закупке (PDF).

Главное

• В 2026 году пять форматов артефактов модели будут важны: Safetensors – для обучения, GGUF – для ноутбуков, ONNX – для переносимости, TensorRT – для пропускной способности на NVIDIA, Core ML – для устройств Apple.
• Safetensors вытеснил pickle как стандартный формат чекпоинтов. Релиз, доступный только через pickle, – это сигнал о проблемах с безопасностью.
• Лейблы квантизации GGUF (Q4_0, Q5_0, Q8_0) – это конкретные алгоритмы с предсказуемым балансом между размером и качеством.
• При выборе решения приоритеты идут в таком порядке: конфиденциальность и соответствие требованиям, разрыв в возможностях, точка пересечения затрат, инженерные возможности команды.
• Закрытый API выгоднее при нагрузке ниже ~5 миллионов токенов в день; открытые веса становятся предпочтительнее при нагрузке выше ~50 миллионов токенов в день. В промежуточной зоне – решение принимается на основе оценки.
• Правильный ответ для большинства production-фич видео-ИИ в 2026 году – гибридная архитектура, в которой выбор модели зависит от конкретного use case.

Что читать дальше

• Латентность, топология развёртывания и выбор между real-time и batch
• Реальная стоимость ИИ в видеопродуктах – Gemini, OpenAI и карта цен 2026
• Форма ИИ внутри видеопродукта