DeepSeek: бюджет веб-поиска

Какое решение принимает владелец

Представим дистрибьютора, который утром готовит менеджеру закупок список открытых условий доставки. Сотрудник должен получить рабочую таблицу до обсуждения предложений. Здесь решается вопрос о запуске такого сбора по расписанию. Автоматическая закупка, изменение цен и запись в CRM требуют отдельной приёмки.

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

Общий учёт AI-затрат

Для прямых API ставка — 0,75 USD за 1000 запросов с HTTP 200 и результатом: непустым results у Search или содержимым у Fetch. Ошибки, пустой поиск и тайм-ауты не оплачиваются. Число возвращённых результатов цену запроса не меняет.

Платный результат Search возможен и без текста страницы.

Нужны API-ключ и достаточный баланс. Серверные Search/Fetch через DeepSeek Harness, Claude Code или Codex пока бесплатны; их оплата начинается 1 ноября 2026 года в 00:00 по Пекину (UTC+8).

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

Один пакет, два счётчика

Все числа далее придуманы. Это локальный контрольный журнал, а не выгрузка DeepSeek или результат внедрения. Каждая строка описывает отдельную попытку; повтор остаётся новой попыткой той же рабочей задачи. В этой версии журнала тайм-аутов и последующих повторов нет.

Исходные события: Search — 100 ответов с результатами и 20 пустых; Fetch — 150 ответов с содержимым, 20 ошибок 404 и 10 ошибок 429. У всех успешных ответов код 200. Суммарно записано 300 попыток.

Расчёт по указанному правилу: (100 + 150) × 0,75 / 1000 = 0,1875 USD.

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

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

Проверьте общую очередь

Лимиты на аккаунт независимы: Search — 100 запросов/с, Fetch — 25, независимо от ключа. Есть дополнительный предел Fetch по домену, без указанного числа. Превышение даёт 429.

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

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

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

Если срок не выдерживается, у владельца есть понятные варианты: раньше начать сбор, уменьшить согласованный объём или оставить часть строк для ручной проверки. Каждый вариант меняет рабочее обещание менеджеру и требует его согласия. Снижение требований к полноте нельзя скрыть за прежней отметкой «готово».

Что должно остаться после теста

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

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

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

Для самой таблицы менеджер заранее задаёт обязательные поля: поставщик, ссылка, время чтения и нужное условие доставки. Отсутствующее условие остаётся неизвестным. Полученная страница может оказаться устаревшей или не относиться к нужному предложению; её наличие само по себе не завершает рабочую задачу.

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

Проверка готового файла