Kimi K3.1 Pro обещает открытые веса: как я делю задачи между своей моделью и облачным API

Moonshot выпустила Kimi K3.1 Pro и обещает открыть веса к 4 ноября. Независимые тесты ставят её рядом с закрытыми моделями первого ряда. Тогда же n8n опубликовал таблицу, какие открытые модели влезают в какую видеокарту, Vercel добавил подписку на открытые модели за 30 долларов, а Ollama научилась маленьким моделям решений. Для владельца бизнеса вопрос прежний: что считать у себя, что отдавать в API и по какому правилу делить.

Что вышло

Саймон Уиллисон 23 октября написал о Kimi K3.1 Pro: модель доступна через API, веса обещаны к 4 ноября 2026 года. Цена 2 доллара за миллион входных токенов и 10 за миллион выходных, столько же, сколько у GPT-6.1 Sol, и вдвое дешевле Claude Opus 5.5. Версия Highspeed в 2–3 раза быстрее за двойную цену. По индексу Artificial Analysis модель набрала 55 баллов против 58 у Claude Opus 5.5.

Latent Space 24 октября в сводке собрал подробности и возражения. Модель на 2,8 триллиона параметров, из них 104 миллиарда активных, контекст миллион токенов. И тут же арифметика: 2,8 триллиона параметров это порядка 5,6 ТБ в 16-битном виде или 1,4 ТБ в 4-битном. Авторы прямо пишут: «можно запустить у себя» и «работает на обычном компьютере» это разные свойства. Лицензию и маленькую версию Flash пока не объявили.

Vercel 23 октября добавил обе версии Kimi K3.1 Pro в AI Gateway: цены провайдера без наценки, бюджет на ключ и переключение провайдера при сбое. Неделей раньше, 15 октября, тот же Vercel запустил Token Pass: за 30 долларов в месяц команда получает 80 долларов кредита на GLM 5.3 и Kimi K3, неиспользованный остаток сгорает, а при исчерпании кредита запросы останавливаются без доплат. Для небольшой команды это понятный потолок расходов.

n8n 22 октября выложил разбор про свои модели и облачные API. Самое полезное там таблица: Qwen3 8B примерно в 8 ГБ видеопамяти в 8-битном варианте, Mistral Small 3.1 на 24B в 12–16 ГБ при 4-битном квантовании и 44–55 ГБ без него, Llama 4 Scout на 109B от 55 до 80 ГБ. Совет, который я поддерживаю: сначала прогнать задачу через открытые модели по API, найти самую маленькую, которая справляется стабильно, и только её ставить к себе. Для пакетной обработки они советуют арендовать GPU-сервер только на время работы.

И релиз Ollama v0.40.11 от 25 октября, заметки к версии: на macOS появилась генерация речи через OpenAI-совместимый эндпоинт, а семейство d3 принесло модели решений из vLLM Semantic Router на 2B, 4B, 9B и 27B: дали текст или картинку, получили да или нет, вариант из списка или оценку с вероятностью. Это локальный аналог того, что OpenAI продаёт как Decisions API.

Зачем это бизнесу

Возьмём производство, где состав изделий лежит в Excel-спецификациях, а рядом цены подрядчиков и конструкторская документация. Отправлять эти файлы во внешний сервис не хочется, и объём стабильный: каждый день одни и те же типы документов. Это случай для маленькой модели на своём сервере: отсортировать, вытащить номера позиций, пометить, чего не хватает. Редкую сложную задачу, нестандартную смету от нового поставщика, дешевле отдать облачной модели: она случается раз в неделю.

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

Как это у меня

В парсерах документов для PDR-компании в США я использую три облачных сервиса, Anthropic, OpenAI и Gemini, каждый под свою задачу. Там важна точность на каждой смете: документы до 60–70 страниц, и ошибка в одной строке стоит денег. После подключения валидаторов около 99,9 % документов проходят без ручной правки, а сотрудник делает только финальную проверку.

Речь, наоборот, я гонял локально. В конце 2023 и начале 2024 года я сделал систему субтитров для консалтинговой компании в Лондоне на локальной модели Whisper: видео из Google Drive, подкасты, YouTube, на выходе SRT с временными метками. За минуту записи платить не требовалось.

Сервер моей студии общий, с 2 ГБ памяти, там крутятся сайт и сервис «Кофе вместе» в Docker. Никакая модель туда не влезет, и я не делаю вид, что влезет. Kimi K3.1 Pro я не запускал: по объёму из сводки Latent Space ей нужен дата-центр, сервер малого бизнеса её не потянет. Я бы смотрел на неё через API, как на ещё одного поставщика рядом с остальными.

Что я бы сделал

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

Для первой стопки взял бы самую маленькую модель из таблицы n8n, которая стабильно проходит мои реальные примеры. Проверял бы на 50–100 настоящих документах, а не на демо.

Для второй стопки поставил бы шлюз вроде AI Gateway или свой прокси с бюджетом на ключ. Тогда смена модели это строка в конфиге.

Посчитал бы точку окупаемости на год: аренда GPU или покупка карты плюс часы на обслуживание против счёта за токены. Пока объём маленький, облако дешевле, и это нормально.

Связанные материалы

Про проверку результата моделей: статья AI в обработке данных: извлечение и проверка и на странице AI в процессе, где результат можно проверить. Кейсы: парсеры документов для PDR-компании и субтитры SRT на локальном Whisper. Из обзоропо той же теме: почему я строю на бесплатных инструментах, речевые модели на своём сервере, что меняется в бюджете на AI у малого бизнеса и модель на устройстве и парк площадок. Раньше: себестоимость AI по принятым задачам и граф знаний или векторный RAG. Если вы решаете, какую часть обработки держать у себя, расскажите про объём и типы документов. Обсудить задачу.