TNWS AI — новости нейросетей и подбор моделей

Контекстный кэш полезен, когда несколько запросов имеют одинаковый длинный префикс. Стабильные инструкции и документы ставьте в начало, динамический вопрос — в конец. Реальную работу кэша подтверждают поля usage/cache hit, а не субъективно быстрый ответ.

Рабочий пример

const base=[
 {role:"system",content:LONG_STABLE_RULES},
 {role:"user",content:REFERENCE_DOCUMENT}
];
await client.chat.completions.create({model:"deepseek-chat",messages:[...base,{role:"user",content:"Вопрос 1"}]});
await client.chat.completions.create({model:"deepseek-chat",messages:[...base,{role:"user",content:"Вопрос 2"}]});
// Сравните usage и документированные cache-hit поля.

Что важно в реализации

• Совпадение должно приходиться на начало контекста.
• Дата, UUID или таймер внутри префикса ломают повторяемость.
• Кэш не хранит готовый ответ и не является памятью пользователя.
• Экономию считают по реальному распределению трафика.

Пошаговая проверка

1. Отправьте два запроса с идентичным префиксом и сравните usage.
2. Измените один символ в начале и повторите измерение.
3. Проверьте, что ответы всё равно генерируются заново и могут различаться.

Чего не делать

Сначала разделите задержку на сеть, очередь, время до первого токена и генерацию оставшегося текста. Самый универсальный рычаг — уменьшить ненужный вывод; для интерфейса включить streaming; независимые операции запускать параллельно. Смена модели помогает не всегда и должна подтверждаться тестом качества.

Рабочий пример

const started = performance.now();
let firstTokenAt = null;
let chars = 0;

for await (const event of stream) {
  if (event.type === "response.output_text.delta") {
    if (firstTokenAt === null) firstTokenAt = performance.now();
    chars += event.delta.length;
  }
}
console.log({
  ttft_ms: Math.round(firstTokenAt - started),
  total_ms: Math.round(performance.now() - started),
  chars
});

Конкретные факты и поля

• TTFT показывает отзывчивость интерфейса, total time — время готовности полного результата. Это разные метрики.
• Длинный ответ естественно генерируется дольше; точный лимит и краткий формат часто полезнее «ускоряющего» промпта.
• Параллельность помогает только независимым запросам и может упереться в rate limits.
• Кэширование стабильно повторяемого префикса и результатов вашего приложения сокращает ненужную работу, но требует корректного ключа кэша.

Как внедрить

1. Соберите p50, p95 и p99 отдельно по модели и типу задачи.
2. Измерьте TTFT и total, входные/выходные токены, ошибки и повторные попытки.
3. Уберите лишний контекст и ограничьте формат ответа.
4. Включите streaming для длинного пользовательского текста.
5. Сравните альтернативную модель на eval-наборе, сохраняя приемлемое качество.

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

Что нужно знать до начала

• Ollama некоторое время держит модель в памяти для следующих запросов.
• keep_alive управляет временем удержания модели.
• Значение 0 выгружает модель после обработки запроса.
• Отрицательное значение может удерживать модель загруженной постоянно согласно FAQ.
• Холодный запуск повышает задержку первого ответа.
• Одновременные модели конкурируют за RAM/VRAM.

Пошаговая настройка

1. Выполните обычный запрос и посмотрите ollama ps.
2. Запишите время первого и повторного ответа.
3. Для редкой задачи передайте keep_alive:0.
4. Убедитесь через ollama ps, что запись исчезла.
5. Для частых запросов задайте ограниченное время удержания.
6. Сравните экономию памяти и cold-start latency.

Рабочий пример

curl http://localhost:11434/api/generate -d '{
 "model":"qwen3",
 "prompt":"Ответь OK",
 "stream":false,
 "keep_alive":0
}'
ollama ps

Как проверить результат