DeepSeek V4.1 Flash НАМНОГО лучше, чем я ожидал

Опубликовано
23 сентября 2026 года
Продолжительность
8:16
Нажмите, чтобы загрузить плеер YouTube

Дайте DeepSeek V4.1 Flash маленький интерактивный прототип с чётким тестом: пройти через вход в замок, осмотреть механизм часов, запустить требушет или собрать крышу. Попросите рабочий проект и явные элементы управления. Затем используйте эти элементы управления и зафиксируйте дефекты перед добавлением деталей.

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

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

Перед началом: выберите версию модели и проект, который вы можете проверить

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

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

Запишите точного поставщика, модель, дату и настройки. Источник тестировал сентябрьский выпуск V4.1 Flash. По состоянию на 28 октября 2026 года, текущий deepseek-flash API DeepSeek называется DeepSeek-V4.1-Flash-1017. Старые имена Flash также направляют на новую контрольную точку. Поэтому запуск сегодня через этот псевдоним не является повтором сентябрьской модели. Смотрите текущий справочник API и объявление о выпуске октября.

Для существующей установки OpenCode, DeepSeek документирует этот путь подключения:

  1. Начать opencode в каталоге проекта.
  2. Enter /connect, выберите DeepSeek и предоставьте ваш ключ API DeepSeek через запрос учетных данных.
  3. Использовать /models для выбора доступной модели Flash и подтвердите выбранного поставщика/модель перед началом задачи.

С Руководство по интеграции DeepSeek по-прежнему иллюстрирует старую метку V4-Flash; текущая документация API объясняет её новый маршрут. Документация OpenCode по выбору модели подтверждает /models. Если необходимо установить инструмент программирования, следуйте текущим инструкциям по установке для вашей платформы, ссылка на которые приведена в руководстве по интеграции. Не предполагается, что старая метка модели закрепляет старую контрольную точку.

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

Поймите, что делает архитектура, не принимая её за маленькую загрузку.

Объяснение «двух половин» исходного кода относится к причинно-следственной кодер-декодер архитектуре. Оригинальная модель имеет 40 слоёв, разделённых на 20-слойный кодер и 20-слойный декодер. Кодер обрабатывает входные данные и подготавливает информацию для декодера; большая часть длинного запроса избегает полного второго прохода, хотя недавняя часть воспроизводится. Генерация ответа использует обе половины.

Сообщаемые цифры касаются активной работы на каждый токен: примерно восемь миллиардов параметров во время обработки входных данных и 16 миллиардов во время генерации вывода. Основная модель значительно больше. DeepSeek’s оригинальная карточка модели перечисляет 552 миллиарда параметров основной модели. “Flash” и цифры активных параметров не означают, что вы можете загрузить полную модель как настольную модель с восемью миллиардами параметров.

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

Сравнение поставщиков было смешанным: DeepSWE v1.1 оценил V4.1 Flash на 74,2%, Opus 5 на 74,0% и GPT-5.6 Sol на 73,0%; Terminal-Bench 3.0 поместил Flash позади обоих. Эти цифры взяты из карточки модели DeepSeek; источник обсуждает их относительный рейтинг. Это не независимые результаты тестов Mantis. Оригинальная карточка модели документирует настройки оценки. Используйте рейтинги для выбора задания для тестирования, а не для того, чтобы пропустить его тестирование.

Напишите один прототип краткого отчета с наблюдаемыми условиями успеха

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

Предлагаемый краткий план:

Создайте небольшой прототип браузера в этом проекте. Сначала определите существующую структуру и выполните команды. Реализуйте основную сцену и заданное взаимодействие. Предоставьте видимые элементы управления и способ сброса. Сохраните редактируемые исходные файлы. Выполните доступные проверки, осмотрите результат, если ваши инструменты это позволяют, и перечислите все дефекты, которые вы не смогли проверить или исправить.

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

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

Тестируйте детализированную среду как для распознавания, так и для перемещения по ней

Хельмова Падь выглядела впечатляюще визуально, потому что она объединяла три элемента, которые были важны для Рона: длинная стена, горная местность и подъездной мост. Обычный замок не соответствовал бы этим требованиям, даже если бы его освещение выглядело привлекательно. Определите сопоставимые ориентиры для вашей собственной сцены и изучите их взаимосвязь с подхода, а не только с выгодного ракурса сверху.

Прототип Хельмовой Пади, показывающий горы, длинную стену и подход к ее воротам.
В 2:11 горная местность, стена и подъездной мост делают сцену узнаваемой. Пройдитесь по подходу, а также изучите силуэт: источник также столкнулся с «пробиванием» на этом маршруте. ; откройте изображение в полном размере.

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

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

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

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

Сохраняйте согласованность анимированного механизма и удобство камеры.

Часы дают две отдельные вещи для оценки: смоделированные части и элементы управления, используемые для их осмотра. Источник показал чистый, детализированный механизм с реальными 3D-формами шестеренок. Сообщённая анимация использовала одни имитированные часы, сохраняя синхронизацию частей при изменении скорости воспроизведения. Контакт между каждой парой зубьев шестеренок не вычислялся.

Механизм часов DeepSeek, показывающий смоделированные шестерни, стрелки и открытое кольцо циферблата.
Механизм на 3:40 показывает детальные детали, которые стоит сохранить. Источник сообщает о согласованной анимации от общего таймера, в то время как взаимодействие с камерой всё ещё требовало доработки. ; откройте изображение в полном размере.

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

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

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

Если ваша реализация использует Three.js OrbitControls, его официальная справка раскрывает скорость вращения, ограничения дистанции приближения и демпфирование. Демпфирование требует update() в цикле анимации. Попросите агента проверить существующую конфигурацию управления перед её настройкой, затем повторите небольшой набор целенаправленных жестов. Сброс вида помогает различить плохую исходную камеру и управление, которое становится нестабильным после нескольких вводов. Это добавленное руководство по реализации, а не утверждение, что изменение одной настройки исправило бы исходный запуск.

Отделите симуляционный часовой механизм требюшета от дисплея.

Требюкет Штормвинда запустил снаряд с его стандартными настройками и достиг ворот замка. Окружающая среда и видимый выстрел создали сильный прототип, но сообщенное воплощение является более полезным уроком: движение продвигалось в 240 небольших шагов за каждую симулируемую секунду, отдельно от обновления экрана. Рука и праща были связаны, а полет снаряда включал сопротивление воздуха.

Сцена катапульты DeepSeek с машиной, воротами-мишенью и регулируемыми элементами управления симуляцией.
В 4:50 видны машина и настройки перед показанным стандартным выстрелом. Используйте сброс и те же настройки при проверке повторяемости; сообщаемые 240 обновлений в секунду — это шаги симуляции, а не кадры отображения. ; откройте изображение в полном размере.

Это означает шаг симуляции в 1/240 секунды, примерно 4,17 миллисекунды симулируемого времени. Это не значит, что браузер отображал 240 кадров в секунду. Последовательный шаг физики помогает избежать изменения расчета только потому, что на одном устройстве отрисовывается меньше кадров. Фактическая стабильность и точность всё равно зависят от уравнений, параметров и обработки прошедшего времени.

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

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

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

Осмотрите собранную крышу как связанную поверхность

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

Сборка храма, показывающая уклоны крыши и поддерживающую деревянную конструкцию.
В 5:58 собранная крыша имеет согласованную общую форму. Рон всё ещё замечает незавершённые детали. Осмотрите соединения и скрытые стороны, а не рассматривайте этот вид как доказательство полной геометрии. ; откройте изображение в полном размере.

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

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

Используйте геометрические детали там, где они нужны зрителю. Гребни на плитках могут передавать поверхность без тысяч отдельных объектов. Если вашему приложению требуется удаление отдельных плиток или внимательный осмотр каждой плитки, это меняет требование и может оправдать другую конструкцию. Выбирайте представление в соответствии с взаимодействием, которое вы планируете поддерживать.

Рон описал это как первое завершение крыши модели Flash в собственных тестах, даже признавая незавершенные детали. Объяснение DeepSeek о том, что более ранние модели испытывали трудности из-за управления слишком большим количеством отдельных плиток, остается диагностикой, предоставленной моделью, а не установленным объяснением каждой предыдущей неудачи. Практическим доказательством является форма и реализация, сообщенные для этого запуска.

Включите слабые результаты в решение

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

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

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

Операционным выбором команды было использование DeepSeek для первой версии идеи, которая в противном случае могла бы быть дорогой, а затем передача многообещающей работы GPT-6 Astra. Astra оставалась основной моделью. Энтузиазм Рона по поводу ценности Flash был суждением, основанным на этих результатах, а не подтвержденным счетом или продемонстрированным универсально самым дешевым результатом модели. Упоминания о текущих тестах Sol, Luna и Opus 5.5, включая ограничение аккаунта Anthropic, не добавляют завершенных сравнений к этому эксперименту.

Бюджет на попытки и работу, необходимую для завершения

Проверьте текущие цены поставщика перед крупным запуском. На 28 октября DeepSeek страница с ценами указал следующие прямые тарифы API для текущей конечной точки Flash за миллион токенов:

ИспользованиеВнепиковое времяПиковое время
Кэшированный ввод$0.003$0.006
Некешированный ввод$0.15$0.30
Вывод$0.60$1.20

Пиковые часы указаны как 01:00–04:00 и 06:00–10:00 по UTC в будние дни, за исключением китайских государственных праздников; все остальные часы являются непиковыми. Это актуальные цены от прямого поставщика, а не историческая стоимость записанных прототипов или обещание относительно счета реселлера.

В гипотетическом расчете два миллиона необработанных входных токенов и 200 000 выходных токенов будут стоить $0,42 по этим непиковым тарифам: $0,30 за вход и $0,12 за выход. Те же самые количества по пиковым тарифам будут стоить $0,84. Этот пример не включает другие оплачиваемые услуги и предполагает, что все входные данные необработанные. При расчете стоимости используйте фактические показатели попаданий и промахов кэша, а также использование выходных данных во время вашего запуска.

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

Устраните неполадки в прототипе, прежде чем его расширять

Используйте одну воспроизводимую проблему на запрос на исправление и повторно выполните соответствующее взаимодействие после этого.

СимптомСначала исследуйтеПроверка принятия
Неверная модель или недоступный выборУчетные данные поставщика, идентификатор модели и маршрутизация псевдонимовПодтвердите выбранную конечную точку и зафиксируйте фактическую версию при раскрытии
Сцена выглядит правильно, но обход клипуетсяПоверхность для ходьбы, представление коллизий и маршрутПовторите тот же подход в обоих направлениях
Камера обзора неудобнаНастройки вращения/масштабирования, цель и сброс видаВыполняйте те же маленькие движения, не теряя объект
Анимация меняется после регулировки скоростиОбщие смоделированное время и состояние паузы/сбросаВозобновление и изменение скорости без необъяснимого скачка
Выстрел требушета меняется в зависимости от нагрузки на рендерингОбновления с фиксированным шагом, обработка прошедшего времени и начальное состояниеПовторите тот же пресет и сравните последствия
Крыша выглядит завершенной только с одной стороныСоединения поверхностей, видимость и состояние сборкиОсмотрите все стороны и шаг назад через сборку
Агент заявляет о успехе, не показывая егоФайлы, команда для запуска и фактические доказательства тестаОткройте проект и повторите заявленное взаимодействие

Для передачи включите запустимый проект, выбранную модель и настройки, исходное задание, то, что уже работает, и короткий список дефектов с шагами воспроизведения. Например: «Сохраните силуэт замка и пакетную обработку материалов. Исправьте прохождение верхнего моста, затем снова запустите маршрут от точки появления». Это дает следующему агенту конкретное исправление, одновременно защищая наиболее сильный результат прототипа.

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