На 2026-11-03/04 DeepSeek V4.1 Flash 1017 беше тестван при пет доставчика чрез AIHubMix с набора APB Full: едни и същи въпроси, параметри и скриптове за заявки при всеки. Този APB профил обхваща само изпълнението в ByteDance, раздел по раздел.
Числата по-долу са оценки, а не класация или препоръка за доставчик. Първо са Q, F, P, K и R; общата оценка е обобщен индекс, а не сертификация, и няма доверителен интервал. Правилата за оценяване са определени в AIHubMix Provider Benchmark Standard v2.0.
Оценки при пет доставчика
Получерният текст обозначава доставчика в тази публикация. Редът на доставчиците е фиксиран, а не класация. K е подоценка на P и съставлява 20% от него. Общата оценка е обобщен индекс без доверителен интервал. Официалният канал на DeepSeek и Alibaba Cloud се различават с 0.37 и не могат да бъдат разграничени.
Накратко
- Q 42.05. BFCL 85.20%, HLE 15.34%, AA-LCR 49.20%. Разликата спрямо официалния канал е −0.40 процентни пункта, с 95% интервал от −1.46 до +0.66: резултатите не могат да бъдат разграничени. При AA-LCR имаше 28 неуспешни заявки, всички в прозорец 1, отчетени като грешни.
- F 74.98. От 174 зачетени проверки 124 преминаха успешно.
reasoning_effort=noneне изключва режима на мислене. Вход от 10k токена беше отчетен като 10,026 токена (естествен брой — 10,000); вход от 8 токена беше отчетен като 34. - P 84.37. До първия токен от тялото на отговора: медиана 2.12 s при паралелност 1 и 2.10 s при паралелност 10; TPOT 3.43 ms/токен; всичките 180 заявки за скорост бяха валидни.
- K 93.83. При горещи заявки с 8k попадението беше 9/9; при 32k имаше 8 попадения, а една заявка не приключи до крайния срок от 300 s.
- R 100. И трите 300 специално изпратени заявки бяха успешни от първия опит.
Настройка на теста
| Параметър | Детайли |
|---|---|
| Модел | DeepSeek V4.1 Flash 1017 |
| Заявен идентификатор на модела | doubao-deepseek-v4.1-flash-1017 |
| Върнато име на модела | deepseek-v4-1-flash-261017 |
| Маршрут за достъп | Чрез AIHubMix с идентификатор на модел, специфичен за доставчика, а не чрез директна връзка към акаунта на доставчика |
| Параметри | Режим без мислене, temperature 1.0, max_tokens 16,384, изчакване 300 s, без автоматичен повторен опит |
| Изключен режим на мислене | Заявките за качество на отговорите, скорост, кеш и стабилност използваха вградения параметър thinking.type=disabled (при този доставчик reasoning_effort=none не изключи режима на мислене); във функционалните случаи reasoning_effort=none беше запазен, за да се провери дали параметърът има ефект |
| Период | 2026-11-03 18:07 – 11-04 16:33 UTC+8; петте доставчика използваха един Mac mini, една мрежа и един акаунт |
| Извадки | Качество на отговорите: 4,250 екземпляра на въпроси (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); функции: 60 случая × 3 прозореца; скорост: 90 при паралелност 1 и 90 при паралелност 10; стабилност: 300; кеш: 30 (по три групи с префикси от 8k и 32k) |
Заявките използваха маршрута начално ръководство на AIHubMix с идентификатор, специфичен за доставчика, а параметрите следваха документацията за API на DeepSeek; идентификаторите на другите доставчици са посочени на страницата с моделите.
Q — качество на отговорите: 42.05
Качеството на отговорите се оценява по три набора: 500 въпроса от BFCL с по 3 рунда всеки, 250 въпроса от HLE с по 10 рунда всеки и 25 въпроса от AA-LCR с по 10 рунда всеки. BFCL се оценява по автоматични правила; HLE и AA-LCR се оценяват от модела deepseek-flash. И петте доставчика получиха едни и същи въпроси, а резултатите от трите набора се обединяват в една обща точност. Десет отговора бяха изключени, защото въпросът не можеше да бъде оценен; останаха 4,240 оценени екземпляра на въпроси.
| Набор | Въпроси | Верни | Точност | Неуспешни заявки |
|---|---|---|---|---|
| Извиквания на инструменти в BFCL | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| Сложни въпроси и отговори в HLE | 250 × 10 | 382/2,490 | 15.34% | 7 |
| Разсъждения по дълги документи в AA-LCR | 25 × 10 | 123/250 | 49.20% | 28 |
| Общо · 95% интервал 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
Неуспешните заявки към услугата — неуспешни заявки или съкратен изход — остават в знаменателя и се броят за грешни. При HLE изходът достигна лимита max_tokens 7 пъти; при AA-LCR имаше 28 неуспешни заявки, всички в прозорец 1. BFCL се оценява автоматично; HLE и AA-LCR — от модел-съдия.
На всеки въпрос от BFCL беше отговорено 3 пъти; таблицата обобщава трите рунда.
| Категория в BFCL | Успешни | Процент на успех |
|---|---|---|
| simple_python — една функция, правилно извикване и аргументи | 329/360 | 91.39% |
| multiple — избор на една от няколко функции | 268/300 | 89.33% |
| parallel — многократно извикване на една и съща функция | 271/300 | 90.33% |
| parallel_multiple — извикване на няколко различни функции | 207/240 | 86.25% |
| irrelevance — няма подходяща функция и не трябва да се прави извикване | 102/150 | 68.00% |
| ahm_multi_turn — верига от инструменти в три стъпки | 101/150 | 67.33% |
Сравнение с останалите четири
Разлика спрямо официалния канал в процентни пунктове, като 95% интервалът е показан с отсечки. Ако интервалът обхваща 0, резултатът се отчита като неразличим. Моделът-съдия за HLE и AA-LCR, deepseek-flash, е от същото семейство DeepSeek като тествания модел и не е калибриран, затова оценките му може да са благосклонни.
F — поддръжка на функции: 74.98
Функционалният набор проверява единствено дали поведението на интерфейса съответства на протокола, а не дали моделът дава добри отговори. Шейсет случая в шест групи бяха изпълнени по три пъти — по веднъж на прозорец: общо 180 проверки, оценени спрямо формата, документиран от всеки доставчик. Проверките, които не бяха приложими, бяха невалидни или не можаха да бъдат наблюдавани, се изключват от знаменателя. ByteDance премина 124 от 174 зачетени проверки и получи 74.98 според теглата на групите.
Претеглената оценка отчита теглата на групите; тя не е броят на преминатите проверки, разделен на 174.
| Група | Тегло | Успешни | Изключени | Оценка на групата |
|---|---|---|---|---|
| Поточно предаване и протокол на съобщенията | 20% | 23/27 | 3 | 85.19 |
| Интерфейс за инструменти | 20% | 30/30 | — | 100.00 |
| Ограничения на изхода и параметри | 20% | 24/30 | — | 80.00 |
| Контекст и състояние | 15% | 14/30 | — | 46.67 |
| Грешки и възстановяване | 15% | 21/30 | — | 70.00 |
| Отчитане и протокол за кеширане | 10% | 12/27 | 3 | 44.44 |
| Общо · претеглена оценка | — | 124/174 | 6 | 74.98 |
„Неуспешни прозорци“ показва колко от трите прозореца не са преминали проверката.
| Неуспешен случай | Неуспешни прозорци | Причина |
|---|---|---|
| Разсъжденията не се показват в съдържанието — поточно предаване и протокол на съобщенията | 3/3 | При reasoning_effort=none съдържанието от мисленето все пак беше върнато |
| Настройката за мислене влиза в сила — ограничения на изхода и параметри | 3/3 | При reasoning_effort=none съдържанието от мисленето все пак беше върнато |
| Разнообразие на извадките — ограничения на изхода и параметри | 3/3 | Изходите при temperature 0 и 1 не се различаваха достатъчно; под предварително регистрирания праг |
| Дълъг вход от 10k — контекст и състояние | 3/3 | Отчетен вход от 10,026 токена; естественият брой трябва да е 10,000 |
| В рамките на лимита на контекста — контекст и състояние | 3/3 | Отчетен вход от 10,026 токена; естественият брой трябва да е 10,000 |
| Дълъг вход от 32k — контекст и състояние | 3/3 | Отчетен вход от 10,026 токена; естественият брой трябва да е 10,000 |
| Дълъг вход от 100k — контекст и състояние | 3/3 | Отчетен вход от 10,026 токена; естественият брой трябва да е 10,000 |
| Над лимита на контекста — контекст и състояние | 3/3 | Неуспешна връзка с upstream или изчакването изтече (1); трябваше да се върне грешка за параметър, върнато е 200 (2) |
| История от 12 хода — контекст и състояние | 1/3 | Неуспешна връзка с upstream или изчакването изтече |
| Грешка във формата на messages — грешки и възстановяване | 3/3 | Върнато е 400 с празно тяло; няма структурирано обяснение на грешката |
| Самостоятелен резултат от инструмент — грешки и възстановяване | 3/3 | Трябваше да се върне грешка за параметър, върнато е 200 |
| Грешка във формата на stream_options — грешки и възстановяване | 3/3 | Върнато е 400 с празно тяло; няма структурирано обяснение на грешката |
| Отчитане на токени за мислене — отчитане и протокол за кеширане | 3/3 | Отчетени са токени за мислене, след като мисленето е било изключено |
| Естествен брой входни токени — отчитане и протокол за кеширане | 3/3 | Отчетени са 34 токена; естественият брой трябва да е 8 |
| Дефинициите на инструменти се броят във входа — отчитане и протокол за кеширане | 3/3 | Контролната заявка без инструменти вече не съвпадаше с естествения брой входни токени |
| Съгласуван брой входни токени преди и след кеширане — отчитане и протокол за кеширане | 3/3 | При повторно използване на същия префикс отчетените входни токени не съвпадаха с естествения брой |
| Съгласуван брой входни токени при поточно и непоточно предаване — отчитане и протокол за кеширане | 3/3 | И в двата случая са отчетени 34 токена; естественият брой трябва да е 8 |
| Точно текстово съвпадение на изхода — поточно предаване и протокол на съобщенията | 1/3 | В края на тялото има една излишна точка; текстът не е точно този, който беше поискан |
Тези проверки се изключват от знаменателя; не се броят нито като успешни, нито като неуспешни.
| Статус | Случай | Брой | Причина |
|---|---|---|---|
| Не е наблюдавано | Последователности за спиране при поточно предаване | 3 | Заявката не беше изпратена след предишната стъпка; не може да бъде оценена |
| Неприложимо | Изричен cache_control | 3 | Предварително беше отбелязано, че този интерфейс не го поддържа |
Случаите с грешка във формата на messages и stream_options се провалиха при всичките пет доставчика: и двата върнаха 400 с празно тяло, така че клиентите не получават структурирано обяснение на грешката. Неуспех, общ за всичките пет, вероятно е на нивото на шлюза на AIHubMix и изисква отделно разследване. Отчитането на токени за мислене също се провали при всичките пет, но по различни причини: ByteDance и Fireworks отчетоха токени за мислене, след като то беше изключено; останалите три не върнаха брой токени за мислене.
Сравнение с останалите четири
P — скорост на отговор: 84.37
Всяка заявка съдържаше около 10,000 входни токена и изискваше около 1,100 изходни токена в текста на тялото. Във всеки от трите прозореца бяха изпълнени 30 заявки при паралелност 1 и 30 при паралелност 10: общо 180 заявки.
| Метрика | Резултат |
|---|---|
| Изчакване до първия токен от тялото (TTFA) | Медиана 2.12 s при паралелност 1; медиана 2.10 s при паралелност 10 |
| Скорост на генериране (TPOT) | 3.43 ms/токен при паралелност 1; 3.41 ms/токен при паралелност 10 |
| Ефективна пропускателна способност | 1,250.0 токена/s при паралелност 10 |
| Валидни заявки | 90/90 при паралелност 1; 90/90 при паралелност 10 |
| Оценки на компонентите | TTFA 48.59, TPOT 100.00, пропускателна способност 100.00; за TTFA и TPOT се взема по-ниската стойност от двете нива; тегла 35% / 35% / 30%; оценка за отговор 82.00 |
| Оценка P | Оценка за отговор 82.00 с тегло 80%, кеш K 93.83 с тегло 20%; общо 84.37 |
TPOT се изчислява по фрагментите от потока, а не се измерва за всеки токен на хардуера. Пропускателната способност е броят на валидните изходни токени при паралелност 10, разделен на времето за изпълнение на пакета.
Сравнение с останалите четири
И петте доставчика използваха една и съща машина, мрежа и акаунт. Трите прозореца бяха насрочени поотделно за всеки доставчик, така че периодите на събиране на данни не съвпадат напълно; не бива да се придава прекалено голямо значение на малките разлики.
K — кеш: 93.83
Всяка група изпраща пет заявки. Първата съдържа фиксиран префикс от около 8k или 32k токена и зарежда кеша. Заявки 2–4 запазват префикса и променят само последния въпрос, след 5 s, 30 s и 120 s. Петата използва нов префикс като контролен случай без кеш. Три прозореца и две дължини, по пет заявки на група, дават общо 30 заявки. K е броят на токените, прочетени от кеша при горещите заявки, разделен на броя токени, които според правилата трябва да могат да се използват повторно; двете дължини имат еднакво тегло. K съставлява 20% от P.
| Префикс | Прозорец | Начално зареждане | +5 s | +30 s | +120 s | Контрол без кеш |
|---|---|---|---|---|---|---|
| 8k | Прозорец 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Прозорец 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Прозорец 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | Прозорец 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Прозорец 2 | 0 | 32,000 | 32,000 | неуспешно | 0 |
| 32k | Прозорец 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
Стойностите са броят токени, прочетени от кеша, според отчета на сървъра.
И деветте горещи заявки с 8k попаднаха в кеша, като всяка прочете 7,936 токена. Осем от деветте горещи заявки с 32k попаднаха в кеша, като всяка прочете 32,000 токена; една заявка беше неуспешна. K е 93.83, като двете дължини са претеглени еднакво. Студените заявки не прочетоха данни от кеша, така че горещите и студените заявки се разграничават ясно. Неуспешната заявка е четвъртата заявка от групата с 32k в прозорец 2; тя достигна крайния срок от 300 s, без да завърши.
Сравнение с останалите четири
R — стабилност на услугата: 100
300-те заявки са от четири типа — кратък текст, дълъг вход, извиквания на инструменти и многоходова история — и бяха изпълнени при паралелност 1 в три прозореца. Заявка се счита за успешна само ако първият опит върне валиден, завършен отговор; точността на отговорите не се проверява и няма повторен опит. Неуспехите в разделите за качество на отговорите и скорост се отчитат съответно в Q и P, а не повторно в R.
| Тип заявка | Успех от първия опит |
|---|---|
| Кратък текст | 120/120 |
| Дълъг вход от 10k | 90/90 |
| Извиквания на инструменти | 60/60 |
| Многоходова история | 30/30 |
| Общо · 95% интервал 98.78%–100% | 300/300 |
И 300-те заявки върнаха валиден, завършен отговор от първия опит. R = 100 описва само тези 300 специално изпълнени заявки; това не означава, че цялата верига не е имала неуспехи. Долната граница на 95% интервала е 98.78%: 300 успеха позволяват да се заключи единствено, че вероятно делът на неуспехите е под 1.22%.
Сравнение с останалите четири
R обхваща само тези 300 специално изпълнени заявки; неуспехите в разделите за качество на отговорите и скорост се отчитат в Q и P и не се броят повторно в R.
| Доставчик | Успех от първия опит | 95% интервал |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek official | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
Често задавани въпроси
Наистина ли reasoning_effort=none не успя да изключи мисленето?
Да. И в трите прозореца заявките с reasoning_effort=none все пак върнаха съдържание от мисленето, така че проверката се провали и в трите случая. Заявките за качество на отговорите, скорост, кеш и стабилност използваха вместо това вградения превключвател thinking.type=disabled. В набора от тестове с функции нарочно беше оставен reasoning_effort=none, за да се провери дали параметърът влиза в сила.
Точността по BFCL е 85.20%. Защо Q е 42.05?
Q обединява три набора от тестове със съвсем различна трудност. BFCL даде 1,278 верни отговора от 1,500, HLE — 382 от 2,490, а AA-LCR — 123 от 250. Общо верни бяха 1,783 от 4,240 оценявани въпроса: 42.05%. Резултатът от 15.34% на HLE понижава общата стойност.
Включени ли са 35-те неуспешни заявки за Q в резултата?
Да. Неуспешните заявки и отрязаните изходи остават в знаменателя и се броят за грешни. Седем отговора за HLE бяха прекъснати при max_tokens; 28 заявки за AA-LCR бяха неуспешни — всички в прозорец 1.
Защо е важно отчитането на входните токени?
Защото таксуването трябва да съответства на вградения в модела брой токени. Вход с 10k токена беше отчетен като 10,026 токена (вграденият брой е 10,000), а вход с 8 токена — като 34. Контролната заявка без инструменти вече показваше разминаване, а при поточно предаване и без него се отчитаха по 34. И трите проверки на отчитането на токените се провалиха.
Резултатът за кеша при 32k беше пропуск или неуспех?
Неуспех. Осем от деветте горещи заявки с 32k попаднаха в кеша и прочетоха 32,000 токена. Единствената заявка, която не попадна в кеша, е четвъртата в прозорец 2; тя достигна крайния срок от 300 s, без да завърши. Групата с 8k попадна в кеша във всичките 9 случая и прочете по 7,936 токена.
Може ли да се разграничи качеството на отговорите на ByteDance от това на официалния канал?
Не. Общата точност е с 0.40 пункта по-ниска от тази на официалния канал, при 95% интервал от −1.46 до +0.66. Интервалът включва 0, така че двата резултата не могат да се разграничат. Това описва само тази партида и не представлява класация.
Продължете да четете: поредицата за DeepSeek V4.1 Flash
- Базовият резултат Q в тази публикация е от официалния канал; неговото собствено изпълнение, включително 15 невалидни сонди при паралелност 1, е описано в DeepSeek V4.1 Flash в официалния канал: 94.00 F, 15 невалидни сонди.
- Baidu е единственият доставчик, чийто интервал за Q е под този на официалния канал; неуспехите в канала, довели до този резултат, са описани в DeepSeek V4.1 Flash в Baidu: няма наличен канал, който да достигне Q и P.
- Данните за кеша на Alibaba Cloud са близки до отчетените тук 93.83: DeepSeek V4.1 Flash в Alibaba Cloud: 1.34s до първия токен, 99.37 за кеша.
- При Fireworks се наблюдават същите проблеми с мисленето и отчитането на токените, както тук, както и празни отговори при stop: DeepSeek V4.1 Flash във Fireworks: празни отговори при stop, 3/9 попадения в кеша.
