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

TL;DR

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

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

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

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

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

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

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

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

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

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

Идём в порядке: Safetensors (training canonical), GGUF (compressed local), ONNX (portable), TensorRT (NVIDIA-optimised), Core ML (Apple-optimised).

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

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

Это последнее свойство – причина существования Safetensors. Оригинальные PyTorch .bin и .pt используют сериализацию через pickle, у которой фундаментальная дыра в безопасности: загрузка pickle-файла разрешает выполнить произвольный Python-код, зашитый в файл при сохранении. Злоумышленник, который подменил чекпоинт в model registry, заставляет всех downstream-пользователей выполнить нужный ему код просто фактом вызова torch.load(). Это не теория – supply-chain атаки на 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 first; PyTorch смержил поддержку Safetensors в core serialization API, и документация фреймворка теперь рекомендует Safetensors как default save format. Если релиз 2026 года выходит только в .bin – это yellow flag: либо провайдер отстал на годы, либо чекпоинт от старого обучающего запуска, который ещё не пересохранили.

Чего Safetensors не делает: не сжимает и не разворачивается напрямую в production. Llama 4 70B в Safetensors в float-16 – это ~140 GB. Тренироваться, файнтюнить и сёрвить с него можно – если у вас есть GPU-память на все 140 GB. Для production-развёртывания на менее тяжёлом железе вы конвертируете его в один из форматов ниже.

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

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

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

Лейблы квантизации, которые вы видите на каждой 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 baseline. Недавние добавления Q4_K_XL и семейство IQ (imatrix-based «I-quants») выжимают чуть больше качества из каждого бита.

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

Пример с цифрами. Llama 3 70B в F16 занимает около 140 GB на диске и около 145 GB VRAM при работе – недостижимо почти для любого лэптопа. Та же модель в Q4_K_M занимает 140 × 0.28 ≈ 39 GB, спокойно работает на 64 GB Mac Studio и сохраняет ~95% task-accuracy исходной. Если опуститься до Q2_K – файл сжимается до 22 GB, но качество падает ниже порога, который большинство production-пользователей примет.

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

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

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

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

Расширение файла – .onnx. Один файл хранит граф модели (каждая операция, каждый вес, каждая связь между операциями) вместе с input/output формами тензоров. Тулинг есть в каждом фреймворке: torch.onnx.export() – самый частый путь; в Hugging Face optimum есть high-level helpers под трансформеры. ONNX model zoo на GitHub держит канонические экспорты компьютерного зрения (ResNet, YOLO-семейство, MobileNet) и многих speech/language-моделей.

ONNX наиболее полезен в паре с ONNX Runtime – Microsoft-овским cross-platform inference engine. ONNX Runtime принимает .onnx-файл и выбирает «execution provider» при загрузке: CUDA на NVIDIA, TensorRT для дальнейшей оптимизации, DirectML на Windows-GPU, CoreML на Apple, OpenVINO на Intel, QNN на Qualcomm. Один и тот же файл везде; рантайм выбирает самый быстрый backend на хосте. На Azure Cobalt 100 (Arm64) с SqueezeNet-INT8 ONNX Runtime держит более 538 инференсов в секунду при пиковой памяти меньше 37 MB – типичный «lean and portable» envelope ONNX.

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

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

Второй caveat: не каждая архитектура экспортируется чисто. Новые transformer-варианты, кастомные attention-ядра, dynamic control flow – могут падать или деградировать при экспорте в ONNX. Всегда экспортируйте, потом гоняйте quality check (PSNR, accuracy или task-specific метрику), чтобы убедиться, что экспорт ведёт себя как источник. Исследование 2022 года по challenges in DL model conversion подтверждает: ошибки PyTorch→ONNX встречаются достаточно часто, чтобы требовать рутинной post-conversion валидации.

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

TensorRT – это NVIDIA inference SDK и формат файла, который он производит – скомпилированный «engine», оптимизированный под конкретную архитектуру GPU (Ampere, Hopper, Blackwell) и под конкретную модель. Вы кормите TensorRT-у ONNX-файл (или PyTorch-модель через torch_tensorrt), и он отдаёт .engine или .plan. Этот файл быстрее, чем любой general-purpose рантайм может быть – TensorRT делает layer fusion, kernel auto-tuning, precision calibration (FP16, INT8, FP8, FP4 на новых GPU) и memory layout оптимизации, нацеленные на конкретный кремний, под который скомпилировали.

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

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

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

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

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

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

Зачем Core ML в видеопродукте: on-device фичи в iOS/macOS приложениях, где latency важна, а данные не должны покидать устройство. Background blur, beauty-фильтры, gaze correction, on-device сегментация, маленькие ASR-модели для live-captioning, on-device object detection в surveillance-приложениях. Core ML выбирает лучшее доступное железо устройства – Neural Engine на iPhone с A14 и новее, GPU иначе, CPU как fallback – и модель работает без сетевого трафика. Vision framework на iOS естественно пара к Core ML для image/video пайплайнов.

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

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

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

Предыдущий урок про латентность и развёртывание ввёл четыре слоя, на которых может физически жить модель: on-device, on-edge, in-region cloud, cross-region cloud. Пять форматов ложатся на эти слои так.

На устройстве пользователя – телефоне, лэптопе, в браузере, 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 ИИ принимает в основном ONNX; AWS Lambda и подобные serverless GPU предпочитают ONNX или скомпилированные TensorRT engines. LiveKit Agents worker на edge-GPU обычно крутит квантизованную модель в vLLM (Safetensors) или GGUF-модель через Ollama, в зависимости от throughput-таргета.

В in-region cloud – собственный AWS/GCP/Azure или специализированный GPU-cloud (Modal, Replicate, Together, Fireworks, RunPod) – Safetensors источник истины и формат, который потребляет ваш serving-стек. vLLM, де-факто open-weights LLM-сервер, грузит Safetensors напрямую. NVIDIA Triton Inference Server принимает ONNX, TensorRT engines, PyTorch, TensorFlow и Python backends. Под максимум throughput на NVIDIA в масштабе цепочка: Safetensors → TensorRT-LLM compilation → engine deployment. Под максимум portability: Safetensors → ONNX export → Triton или ONNX Runtime.

В cross-region cloud – почти всегда closed API. Если вы зовёте Anthropic, OpenAI или Google из региона, где они не разместили нужную вам модель, вы платите cross-region latency-штраф за привилегию использования frontier-модели. Формат здесь – что вендор выставит по HTTPS – обычно OpenAI-compatible JSON.

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

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

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

Ошибка первая: выложить Safetensors-чекпоинт внутри мобильного приложения. Самая частая rookie-ошибка, ловится на App Store или Play Store review. Чекпоинт в 13 GB не пройдёт лимиты размера, а даже если бы прошёл – устройство не загрузит его в память. Фикс – конвертировать: PyTorch или Safetensors → ONNX → Core ML (для iOS) или LiteRT (для Android). Mobile deliverable – это всегда сконвертированный, квантизованный derivative, не training-чекпоинт.

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

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

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

Ошибка пятая: сравнивать closed-API и open-weights по token-price. Closed-API считают за миллион токенов. Open-weights считают за GPU-час плюс инженерное headcount на эксплуатацию стека плюс load factor вашего профиля concurrent. Экономика зависит от объёма – closed выигрывает на низком объёме, open выигрывает с большим отрывом на масштабе. Считаем breakeven ниже.

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

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

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

Шаг 1 – Отсев по privacy и compliance

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

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

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

Шаг 2 – Отсев по capability gap

Второй фильтр смотрит, есть ли у задачи open-weights модель, которая её реально решает. На середину 2026 капабилити-ландшафт примерно такой.

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

Под большинство production-workloads – content moderation, summarisation, transcription, перевод, CV-задачи, video understanding на типичных масштабах – open-weights модели матчат или превосходят closed на task-specific бенчмарках. У surveillance-пайплайна, который крутит YOLO и SAM 2, нет повода звать closed-API.

Под task-specific маленькие модели – распознавание речи (Whisper), embedding generation, object detection (YOLO, RT-DETR), сегментация (SAM 2, Florence-2) – open weights стандарт уже годы. Closed-конкуренты отстают.

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

Шаг 3 – Расчёт точки пересечения по стоимости

После compliance и capability – арифметика. Closed-API считают по миллиону input/output токенов; open weights считают за GPU-час плюс engineering operating cost.

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

Closed-API математика (по GPT-4-equivalent pricing $0.40 за миллион токенов – 2026 floor для этого capability-tier):

Cost per summary = (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/час, реалистичный batching даёт 200 сводок/час на GPU при том же качестве):

Часов в месяц на 100 000 сводок = 100 000 / 200 = 500 часов. На $2.50/час = $1 250/мес – плюс ops, мониторинг, autoscaling и engineering oncall. На single-GPU-equivalent steady state closed-API выигрывает.

На 1 000 000 сводок/мес = 5 000 часов = ~7 GPU постоянно занятых. С batching и разумной утилизацией это сводится к $7 000–9 000/мес GPU-spend плюс ~$5 000/мес инженерной/инфраструктурной нагрузки. На этом масштабе open weights начинают выигрывать: closed обходится в $35 000/мес, а open all-in – в районе $14 000/мес. Дельта 2.5×.

Точка пересечения зависит от трёх переменных: стоимости токена closed API, стоимости GPU-часа в вашем open-weights развёртывании и того, насколько эффективно вы batch-ите. Под большинство video-AI workloads в 2026 closed-API дешевле ниже 5–10 миллионов токенов/день; open-weights выигрывают выше 50–100 миллионов токенов/день; середина – judgement, который зависит от инженерной ёмкости.

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

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

Open-weights развёртывание стоит инженерного времени, которое closed API – нет. Реалистичный baseline для production-сервиса одной open-weights LLM в 2026 – один-два ML-инженера на serving-стек (vLLM, Triton, autoscaling, мониторинг), один DevOps на GPU-капу и инциденты, плюс часть времени security-инженера на supply-chain сканирование и SRE на oncall. Назовём это $30 000–60 000/мес fully loaded инженерной стоимости на US/Западноевропейском рынке.

Под closed-API инженерная стоимость – один application engineer, который зовёт HTTPS-endpoint, плюс prompt-engineering. Назовём $10 000–20 000/мес.

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

Шаг 5 – Гибрид

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

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

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

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

Фора Софт встраивает ИИ в видеопродукты с 2019 года – в видеоконференции, OTT-стриминг, surveillance, telemedicine и e-learning. Мы запускали каждый формат артефакта из этой статьи в production: Safetensors на vLLM-кластерах под meeting copilots, GGUF на Mac Studio под on-prem развёртывания, ONNX в браузерах под client-side moderation, TensorRT engines под surveillance-аналитику, Core ML packages под on-device beauty-фильтры и live captions. Закупочный фреймворк из статьи – тот, которым мы пользуемся, когда клиент спрашивает «выпускать на OpenAI или на собственном GPU?». Правильный ответ почти всегда – «оба, routed по use case» – и format map выше – это то, как routing реально реализуется.

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

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

Главное

• Пять форматов артефактов модели важны в 2026: Safetensors для обучения, GGUF для лэптопов, ONNX для portability, TensorRT для NVIDIA throughput, Core ML для устройств Apple.
• Safetensors вытеснил pickle как канонический чекпоинт. Pickle-only релиз – security flag.
• Лейблы квантизации GGUF (Q4_K_M, Q5_K_M, Q8_0) – конкретные алгоритмы с предсказуемыми trade-off размера и качества.
• Закупочный фильтр идёт по порядку: privacy и compliance, capability gap, cost crossover, инженерная ёмкость.
• Closed API дешевле ниже ~5 миллионов токенов/день; open weights выигрывает выше ~50 миллионов токенов/день. Середина – judgement.
• Правильный ответ под большинство production видео-ИИ фич в 2026 – гибрид, routed по use case.

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

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