# Предварительный спрос на вычисления: как обсуждать резерв мощности

Как предварительное обсуждение потребности в инференсе помогает планировать GPU: профиль запросов, ресурс, сроки, оплата и различие между интересом и обязательствами.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/compute-offtake/
Language: ru

Финансировать новую конфигурацию проще, когда понятно, для какой потребности она нужна. Один из способов уточнения — заранее обсудить с потенциальным пользователем профиль нагрузки и период, когда ресурс может понадобиться. Это позволяет связать инфраструктуру с задачей ещё до закупки.

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

## Начните с измеримого профиля нагрузки

Уточните модель, нужные функции, длину контекста и ожидаемый характер запросов. Спросите, насколько нагрузка предсказуема и допускаются ли перерывы. Если пользователь пока не знает объём, сначала полезно провести ограниченный тест.

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

## Разделите ресурс и фактическое использование

Резерв означает определённый способ обеспечить доступность мощности, а фактическая работа — её использование. Даже у крупных облачных платформ это разные понятия: [документация AWS Capacity Reservations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) отдельно описывает учёт используемого и неиспользуемого резерва.

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

## Подготовьте карту предварительных договорённостей

На исследовательском этапе можно зафиксировать вопросы без обещания готового сервиса:

| Вопрос | Что нужно уточнить |
| --- | --- |
| Нагрузка | Модель, функции и ограничения качества |
| Период | Возможное начало и длительность |
| Гибкость | Изменение объёма и допустимые перерывы |
| Ресурс | Выделенная машина или разделяемая мощность |
| Статус | Интерес, тест либо подтверждённые условия |

Такая карта помогает понять, какие данные ещё отсутствуют. Она не является готовым договором или предложением оплатить услугу. Юридическое оформление реальных обязательств обсуждается отдельно, когда определены стороны и предмет работы.

## Свяжите потребность с этапом финансирования

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

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

## Практические выводы

Начнём с профиля задач и доступных ресурсов.

Подготовиться помогут материалы о [проверке спроса](/ru/journal/gpu-demand-before-capex/) и [планировании мощности](/ru/journal/inference-capacity-planning/). Чем точнее описана задача, тем легче определить, какую проверку или конфигурацию имеет смысл финансировать следующей.