← Все статьи

LLM API peak/off-peak pricing: как планировать workloads и снижать cost

Peak/off-peak API pricing у DeepSeek делает время реальным cost lever. Разбираем, какие LLM workloads можно переносить, как планировать их безопасно и где помогает router без обещаний automatic cheapest routing.

· TheRouter

30-second answer: peak/off-peak LLM API pricing имеет смысл, если workload может подождать, безопасно retry-иться и потом reconciled по stable ID. DeepSeek сейчас публикует peak windows 01:00-04:00 и 06:00-10:00 UTC. Off-peak rates в два раза ниже peak rates, а после Beijing-time rule от 23 августа weekends billing становится off-peak на весь день. Offline evals, document enrichment, embeddings, nightly summaries и non-urgent agent traces можно переносить в дешёвые окна. Live chat, customer-visible tool calls, payment decisions и incident workflows должны оставаться latency-first.

Главная граница здесь в ответственности. Routing layer помогает выбрать configured providers и model fallback через OpenAI-compatible path. Это не automatic time-of-day arbitrage, если такая feature не проверена в live product path. На практике queue или scheduler решает, когда запускать job. TheRouter решает, в какой configured OpenAI-compatible route уйдёт request.

  1. Меняйте три значения, а не три SDK. Замените api_key, base_url и model в существующем клиенте OpenAI. Код запроса и ответа оставьте неизменным.
  2. Сопоставьте model ID явно. ID модели у целевого провайдера почти никогда не совпадает с OpenAI ID. Держите словарь { openai_id: target_id } вне бизнес-логики.
  3. Проверьте формат streaming. SSE-чанки должны соответствовать контракту OpenAI: data: {...} + data: [DONE]. Прогоните один streaming вызов до продакшена.
  4. Проверьте rate-limit заголовки. Некоторые провайдеры не возвращают x-ratelimit-*. Добавьте обёртку с безопасным дефолтом.
  5. Оставьте путь отката. Раскатайте замену под feature flag, гоняйте оба endpoint в shadow-режиме 24 часа, затем переключайтесь.

Что изменилось в pricing у DeepSeek

DeepSeek в August 13 V4-Pro GA note объявила flexible reasoning effort, native OpenAI Responses API support и pricing update с peak/off-peak API rates. Pricing page теперь показывает DeepSeek V4-Flash, V4-Pro и V4-Flash-Vision-Exp с off-peak prices ровно в половину peak prices. Там же указано, что peak hours идут 01:00-04:00 и 06:00-10:00 UTC, остальное время считается off-peak, а после August 23 billing-rule adjustment weekends in Beijing time становятся all-day off-peak.

Время стало отдельной cost dimension. V4-Pro output стоит $3.96 за 1M tokens в peak и $1.98 в off-peak. V4-Flash output переходит с $1.32 на $0.66. Cache-miss input и cache-hit input используют тот же 2x ratio.

Это не общий закон рынка LLM. OpenAI и Anthropic чаще документируют batch discounts для async work, а не публичные time-of-day windows. OpenAI Batch API guide описывает batch jobs для requests without immediate responses, с 50% lower costs и 24-hour completion window. Anthropic Message Batches docs описывают results после завершения или после 24 hours, whichever comes first, а official pricing snippets говорят о 50% discount для batch processing.

Какие workloads можно переносить

Безопасные кандидаты обычно имеют три свойства: answer не нужен пользователю прямо сейчас, job можно replay, output можно соединить обратно со stable ID.

WorkloadMove to off-peak?Why
Offline eval suitesYesQuality comparison happens later, outside user session
Document enrichmentYesQueue can write reviewed metadata after completion
Embedding backfillsYesHigh volume, low urgency, checkpoint-friendly
Dataset classificationYesNatural row-level ID shape
Nightly summariesYesAlready scheduled work
Customer chatNoWaiting for price window breaks product latency
Agent tool calls inside live sessionUsually noDelay changes agent behavior and UX
Payment, safety, abuse decisionsNoFreshness and audit timing beat token discount

Хороший тест простой. Если request с задержкой на шесть часов создаст support ticket, не переносите его.

Scheduling pattern

Treat off-peak execution как отдельную lane, а не global default. Minimal production design выглядит так:

  1. Classify job. Добавьте latency_class, например realtime, deferred, batch_window.
  2. Attach deadline. Deferred job всё равно нужен latest acceptable completion time.
  3. Record pricing rule. Храните provider, timezone, peak windows, weekend rule, retrieval date и source URL.
  4. Enqueue with stable key. Durable job ID не даёт retries создать duplicate writes.
  5. Run during window. Worker releases jobs, когда provider находится в off-peak и deadline ещё позволяет ждать.
  6. Route and fallback. Реальный OpenAI-compatible request уходит в configured provider или router path.
  7. Reconcile outcomes. Сравните accepted outputs, retries, stale jobs и actual billable tokens.
const deepseekOffPeak = (date: Date) => {
  const utcHour = date.getUTCHours();
  const isPeak = (utcHour >= 1 && utcHour < 4) || (utcHour >= 6 && utcHour < 10);
  return !isPeak;
};

export function shouldRelease(job: { latencyClass: string; deadline: Date }, now = new Date()) {
  if (job.latencyClass === "realtime") return true;
  if (now > job.deadline) return true;
  return deepseekOffPeak(now);
}

Этот пример специально неполный. Он не кодирует Beijing-time weekend billing, holidays, provider policy changes и model-specific exceptions. В production лучше хранить такие правила как data и refresh их из official pricing pages, а не прятать в application code.

Где здесь TheRouter

TheRouter routes OpenAI-compatible requests through configured providers и поддерживает provider/model routing plus fallback там, где это подтверждено live product path. Это полезно после того, как scheduler решил, что job пора запускать.

Например, deferred eval worker может вызвать один stable OpenAI-compatible base_url, выбрать configured DeepSeek target для off-peak lane и держать fallback chain на provider errors. Scheduler owns time. Router owns provider/model path.

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.THEROUTER_API_KEY,
  baseURL: "https://api.therouter.ai/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek/deepseek-v4-flash",
  messages: [{ role: "user", content: "Classify this support ticket." }],
});

Используйте DeepSeek, когда price window и model quality подходят workload. DeepSeek V4-Pro оставьте для hard reasoning или agent tasks, а DeepSeek V4-Flash проверьте для high-volume jobs. Для соседних cost patterns смотрите LLM batch processing guide, LLM API cost optimization guide и DeepSeek V4-Pro GA pricing guide.

Failure modes

Первый failure mode — stale pricing. Provider pricing pages меняются, и scheduler со старым window может тихо стать дорогим. Храните retrieved source и timestamp рядом с rule, затем alert, если rule давно не refreshed.

Второй — deadline inversion. Если все deferred jobs ждут одно cheap window, queue может burst-нуть в rate limits. DeepSeek lists concurrency limits 500 for V4-Pro and 2,500 for V4-Flash. Считайте это capacity constraint, а не обещанием, что every queued job instantly clears.

Третий — unsafe retry. Classification row можно retry. Customer email send, billing action или database mutation требуют idempotency и review перед replay.

Четвёртый — quality drift. Перенос job на cheaper model или cheaper window не должен менять acceptance criteria. Track cost per accepted output, not only cost per token.

Decision matrix

If your workload is...Use this pattern
Live and user-visibleRoute for latency and reliability; ignore peak/off-peak discounts
Offline and high-volumeQueue for off-peak, use row IDs, reconcile outputs
Offline but deadline-boundWait for off-peak until deadline threshold, then run immediately
Quality-sensitiveKeep stronger model and use off-peak timing before downgrading quality
Provider-risk-sensitiveSample alternate providers and keep fallback ready; do not treat time discount as availability control

Самые устойчивые savings обычно приходят от комбинации levers: off-peak timing для movable DeepSeek work, provider batch APIs для true async bulk jobs, prompt caching для repeated prefixes, routing/fallback для reliability boundaries.

Sources

Модели, упомянутые в статье

Помощь и контакты