Hacker News Digest

OpenRouter предоставляет доступ к одинаковым моделям через разных провайдеров, но их реализация сильно различается: одни хосты дают результаты близкие к оригиналу, другие — значительно хуже из-за различий в точности, оптимизациях и парсерах. Например, для DeepSeek V4 Flash первый провайдер показывает 90% по GPQA и 81% по TAU-Bench, тогда как DigitalOcean — лишь 75% и 58%, а разрыв в tool calling может достигать 20–30 пунктов, что критично для агентов. Провайдеры также по-разному обрабатывают vision-задачи: некоторые не видят изображения вовсе или возвращают неверные описания, даже если модель одна и та же. Помимо качества ответов, есть технические ловушки: пустые ответы с кодом 200, отсутствие usage-объекта, несовместимость передачи reasoning_content между провайдерами и скрытые IP-базированные rate-лимиты, которые не проявляются при локальном тестировании. Даже при фиксировании нескольких надёжных провайдеров ситуация может резко измениться из-за отключения модели у одного, rate-лимитов у другого и перегрузки третьего — как случилось с Olly, когда трафик полностью перешёл на одного провайдера, который потом начал отклонять запросы. Ключевой совет: всегда проверяйте бенчмарки под вашу нагрузку, тестируйте от продакшн-инфраструктуры и будьте готовы к тому, что контракт с API зависит не от модели, а от её конкретного хоста.

OpenRouter обеспечивает ненадёжный доступ к моделям из-за скрытой квантизации, нестабильного fallback-механизма (переключение на другие модели без уведомления), плохого кэширования токенов (падает производительность, растут расходы) и слабого биллинга. Кредиты истекают через год, неиспользованные средства исчезают. Ответы с HTTP 200 часто пусты, JSON-вывод поддерживается не всеми эндпоинтами — требует индивидуального тестирования. Vision-модели часто не поддерживают нативные URL, создавая риски. Слабая защита API-ключей и IP-ограничения (особенно на DeepSeek V4.1 Flash) позволяют злоумышленникам превышать лимиты и блокировать доступ. Отсутствие публичных метрик кэширования и SLA затрудняет мониторинг. Большинство пользователей рекомендуют фиксировать (pin) конкретных провайдеров, отслеживать их метрики (latency, throughput, cache %), вводить собственные SLA, использовать белый список провайдеров (исключая сбор данных) и переходить на прямой доступ при необходимости. Некоторые считают OpenRouter гибким инструментом для управления расходами, но его ненадёжность преобладает в отзывах.

Главная идея — модель deepseek-v4-flash-vision-exp умеет принимать изображения вместе с текстом и выполнять с ними те же операции, что и с обычными запросами. Поддерживаются три способа подачи изображения: встраивание через base64‑data‑URL, публичный URL и ссылка на файл, загруженный через Files API. Каждый способ имеет свои ограничения: общий размер запроса ≤ 48 MiB, отдельный файл ≤ 32 MiB (для inline‑изображений) и ≤ 64 MiB при использовании Files API; внешняя ссылка должна быть ≤ 8192 символов и загрузиться за ≤ 60 секунд.

Факт, который стоит запомнить: изображение можно передать как image_url в составе массива content, где каждый элемент — либо текст, либо блок‑изображения с полем type: "image_url" (или file_id). Важно указывать правильный media_type (jpeg, png, gif, webp) и, при необходимости, параметр detail (low, high, original, auto). Эти детали позволяют гибко интегрировать визуальные данные в чат‑запросы без лишних сложностей.

DeepSeek-v4-flash-vision-exp демонстрирует лучшее соотношение стоимости и производительности в агентных задачах — например, 59.3% на DeepSWE при использовании лишь 1/18 ресурсов Gemini 5.6-Sol Medium — но имеет значительные ограничения в визуальном распознавании. Модель ошибочно интерпретирует время на часах (5:10:45 вместо 08:09:25), что может быть связано с системной проблемой в обработке визуальных подсказок; однако некоторые пользователи отмечают, что изображение часов нестандартно, и даже люди могут ошибаться, ставя под сомнение релевантность такого теста. Ограничение в 800×800 пикселей не позволяет корректно анализировать полные страницы A4/Letter, что ограничивает применение в OCR-задачах. Модель не поддерживает изображения как результат инструментального вызова, что мешает визуальной верификации в агентных сценариях. Режим рассуждения увеличивает галлюцинации и снижает точность — его рекомендуется отключать при работе с изображениями. В детальной визуальной классификации (например, архитектурных объектов) модель уступает Bytedance Seed 2.1 Turbo. Для повышения точности пользователи применяют гибридные решения: DeepSeek для текста и Kimi K2.6 на Cloudflare для изображений. При попытках модели «выдумывать» доступ к изображениям используют обходные пути — например, явное назначение ей навыка внешней vision-модели. Ранее DeepSeek уже имел отдельную vision-модель для чата, поэтому выпуск v4-flash-vision-exp — логичное развитие, а не неожиданный поворот. Для тестирования без API-ключа можно использовать playground на OpenRouter с небольшим балансом ($5). Текущая версия — предварительный релиз; ожидается дообучение и улучшение в ближайшие недели.

GPT‑5.6 Sol стал лучшей визуальной моделью, которую OpenAI представила до сих пор. В тестах на нашем предстоящем VLM‑бенчмарке, охватывающем детекцию, подсчёт, OCR и извлечение данных, Sol показал резкий рост: mAP@50 вырос с 13,8 у GPT‑5.5 до 46,2, а Terra и Luna набрали 44,7 и 43,3 соответственно. Это превратило объектное распознавание из слабого места в практичную возможность, особенно заметную в сложных сценах с множеством похожих предметов — например, таблеток, яиц или монет.

Пара ярких фактов: Sol обрабатывает документные макеты, выделяя заголовки, таблицы, подписи и подписи, а также умеет работать с плотными сценами, хотя иногда генерирует коробки в случайных местах, не совпадающих с реальными объектами. Стоимость и скорость тоже важны: Sol стоит около 2,5 ¢ за изображение и тратит ~10 секунд, Terra — ~6 секунд и ~1 ¢, а Luna — чуть более 5 секунд и < 0,5 ¢. При этом Gemini 3.5 Flash дешевле (0,8 ¢) и лидирует по точности при массовом использовании, делая его более выгодным для больших потоков данных.

GPT-5.6 Sol демонстрирует прогресс в визуальных задачах, но его практическая применимость ограничена высокой стоимостью, низкой скоростью (в 25–50 раз медленнее специализированных моделей) и ненадёжностью в production-сценариях. Gemini 3.5 Flash превосходит его по всем метрикам, кроме OCR, при трёхкратно меньшей цене, делая его предпочтительным для детекции и подсчёта. Локальные альтернативы — Qwen3.8 и MiniCPM-V-4.6 (0.8B) — показывают сопоставимую или лучшую производительность, особенно при требованиях к скорости, экономичности и работе на потребительском оборудовании. Подсчёт объектов, например таблеток, решается эффективнее классическими CV-методами (OpenCV), что ставит под сомнение ценность Sol в таких задачах. Sol ошибочно интерпретирует геометрию изображений (например, поворот монет на 90°) и галлюцинирует содержимое чёрных изображений, что указывает на фундаментальные проблемы понимания реальности. Он не распознаёт надёжно редкие или выцветшие кириллические надписи, несмотря на высокую точность в других OCR-задачах. Для распознавания нотной записи Sol показал неожиданно высокую точность, возможно, благодаря способности к сложному пространственному анализу. Для анализа изображений и кода лучше подходят модели OpenAI (Terra, Luna). Для обработки старых документов рекомендуется предварительная обработка изображений через Python. В задачах с низкой задержкой (например, робототехника в аптеках) Sol неприменим. Использование нескольких специализированных моделей (Fable, Gemini, Sol) по задачам эффективнее, чем полагаться на одну. Визуальные бенчмарки не учитывают глубину восприятия — отсутствие бинокулярных данных делает сравнение неполным, особенно для автономного вождения.