AMDМайкл Ларабель из Phoronix опубликовал сравнение Ubuntu 26.10 и Ubuntu 26.04 LTS на сервере с процессором AMD EPYC поколения Turin. По геометрическому среднему более 250 тестов предварительная Ubuntu 26.10 оказалась примерно на 3% быстрее. Однако в отдельных нагрузках разница значительно больше: случайные операции ввода-вывода ускорились на 21–30%, а обработка запросов в некоторых тестах llama.cpp – почти на 65%. На момент публикации Ubuntu 26.10 ещё находится в разработке; стабильный выпуск запланирован на 15 октября.
Что сравнивали и что означает средний прирост 3%
Ларабель использовал один сервер Gigabyte MZ33-AR1 с прошивкой Dasharo на базе coreboot и AMD openSIL, 768 ГБ оперативной памяти – 12 модулей по 64 ГБ DDR5-4800 – и NVMe SSD Micron 7450 MAX ёмкостью 3,2 ТБ. Файловая система – ext4. Процессор работал с включённым Boost и настройками amd-pstate-epp powersave, EPP balance_performance.
В тексте Phoronix есть расхождение: автор называет процессор EPYC 9655P и одновременно указывает 64 ядра. В таблице конфигурации стенда записан EPYC 9555P с 64 ядрами и 128 потоками. Это соответствует характеристикам AMD, тогда как EPYC 9655P имеет 96 ядер. Поэтому результаты следует связывать с конфигурацией EPYC 9555P, указанной в таблице тестирования.
Базой сравнения на графиках служит Ubuntu 26.04.1 LTS. Для Ubuntu 26.10 автор взял сборку, близкую к финальной, со свежими пакетами. Таким образом, исследование сравнивает весь программный набор двух систем: вместе с ядром менялись компиляторы, библиотеки и часть приложений.
| Компонент на стенде | Ubuntu 26.04.1 LTS | Ubuntu 26.10 |
|---|---|---|
| Ядро Linux | 7.0.0-34-generic | 7.3.0-8-generic |
| GCC | 15.2.0 | 15.3.0 |
| LLVM | 21.1.8 | 22.1.6 |
| Python | 3.14.4 | 3.14.7 |
| OpenSSL | 3.5.5 | 4.0.1 |
| 7-Zip из репозитория | 26.00 | 26.02 |
| llama.cpp из репозитория | Сборка 8681 | Сборка 10438 |
Около 3% – итог по геометрическому среднему всего набора из более чем 250 тестов. На сводном графике результат вырос с 514,08 до 528,78, то есть примерно на 2,9%. Этот показатель объединяет нагрузки с разным поведением: крупные выигрыши соседствуют с почти неизменившимися результатами и небольшими ухудшениями. Его нельзя трактовать как одинаковое ускорение каждой программы или любой серверной задачи.
Эта серия также не оценивает отдельный эффект сборок amd64v3: их производительность на EPYC автор оставил для другого материала.
Случайное чтение и запись: прирост до 30%
Самый последовательный крупный выигрыш Ubuntu 26.10 показала в случайных операциях fio. Все приведённые ниже тесты выполнялись через io_uring, с одним заданием и файлами в стандартном тестовом каталоге. Для случайных операций размер блока составлял 4 КБ, для последовательных – 2 МБ. Больше IOPS или МБ/с означает лучший результат.
Буферизованный ввод-вывод и Direct I/O – два режима доступа к файлам. Первый использует страничный кэш Linux в оперативной памяти, а второй обычно обращается к накопителю в обход этого кэша; результаты таких тестов нельзя смешивать при оценке скорости SSD.
| Тест fio 3.40 | Ubuntu 26.04.1 LTS | Ubuntu 26.10 | Изменение |
|---|---|---|---|
| Случайное чтение, 4 КБ, с буферизацией, IOPS | 287 000 | 371 667 | +29,5% |
| Случайное чтение, 4 КБ, Direct I/O, IOPS | 469 667 | 595 500 | +26,8% |
| Случайная запись, 4 КБ, с буферизацией, IOPS | 314 333 | 379 667 | +20,8% |
| Случайная запись, 4 КБ, Direct I/O, IOPS | 453 667 | 581 000 | +28,1% |
| Последовательное чтение, 2 МБ, с буферизацией, МБ/с | 5 001 | 5 215 | +4,3% |
| Последовательная запись, 2 МБ, с буферизацией, МБ/с | 2 775 | 2 914 | +5,0% |
Случайное чтение с буферизацией ускорилось на 29,5%, прямое чтение – на 26,8%. Случайная запись прибавила 20,8% с буферизацией и 28,1% в режиме Direct I/O. Разница существенно превышает общий средний прирост и сохраняется при обоих вариантах доступа.
При последовательном чтении и записи выигрыш скромнее: 4,3% и 5,0%. Поэтому вывод «дисковые операции стали на 30% быстрее» без указания нагрузки был бы неточным. Автор связывает улучшения ввода-вывода с переходом на Linux 7.3, но это сравнение дистрибутивов не изолирует влияние одного ядра. Кроме того, fio здесь собирали с оптимизациями -O3 и -march=native.
Локальный TCP: примерно на 20% выше пропускная способность
Сетевые тесты Ethr и xfr тоже показали преимущество Ubuntu 26.10. Во всех приведённых случаях серверный адрес – localhost: клиент и сервер обменивались данными внутри одной машины. Эти результаты характеризуют локальную обработку сетевого трафика, а не скорость физического Ethernet-подключения или интернета.
| Тест на localhost | Ubuntu 26.04.1 LTS | Ubuntu 26.10 | Изменение |
|---|---|---|---|
| Ethr 1.0: TCP, 1 поток, Гбит/с | 52,41 | 62,52 | +19,3% |
| Ethr 1.0: задержка TCP, 64 потока, мкс | 12,36 | 11,69 | −5,4% |
| Ethr 1.0: UDP, 1 поток, пакетов/с | 328 399 | 372 849 | +13,5% |
| xfr 0.9.19: TCP, 1 поток, Гбит/с | 128,79 | 154,13 | +19,7% |
| xfr 0.9.19: QUIC, 1 поток, Гбит/с | 10,90 | 11,82 | +8,4% |
| xfr 0.9.19: QUIC, 128 потоков, Гбит/с | 2,64 | 2,71 | +2,7% |
Оба однопоточных теста TCP показали прирост около 20%. При этом выигрыш QUIC зависит от режима: 8,4% при одном потоке и 2,7% при 128 потоках. Задержка TCP в Ethr снизилась на 5,4% – здесь меньшее значение лучше.
График UDP в Ethr подписан как тест Bandwidth, но результат выражен в пакетах в секунду. Прирост 13,5% относится именно к этой метрике; переводить его в Гбит/с без дополнительных данных нельзя.
PostgreSQL: небольшой прирост, а не ускорение на десятки процентов
В PostgreSQL 18.1 автор проверил режим чтения и записи с коэффициентом масштабирования 100 и тремя уровнями клиентской нагрузки. Ubuntu 26.10 увеличила число транзакций в секунду и снизила среднюю задержку, но разница оказалась заметно меньше, чем в случайных операциях fio.
| Клиенты | TPS, 26.04.1 LTS | TPS, 26.10 | Прирост TPS | Задержка, мс: LTS / 26.10 |
|---|---|---|---|---|
| 500 | 126 149 | 131 484 | +4,2% | 3,964 / 3,804 |
| 800 | 108 501 | 110 379 | +1,7% | 7,373 / 7,248 |
| 1000 | 98 840 | 102 862 | +4,1% | 10,118 / 9,722 |
Пропускная способность выросла на 1,7–4,2%, а средняя задержка снизилась на 1,7–4,0%. Результаты показывают, что крупный прирост в отдельном тесте ввода-вывода не переносится в том же размере на всю работу базы данных.
llama.cpp: до 65% при обработке запроса
Для llama.cpp Ларабель использовал готовые пакеты из репозиториев Ubuntu: сборку 8681 в LTS и сборку 10438 в Ubuntu 26.10. Тесты выполнялись с процессорным backend. Поэтому здесь сравниваются также разные сборки приложения; приписывать весь выигрыш ядру Linux нельзя.
Таблица разделяет генерацию ответа и обработку входного запроса. Числа 128, 512, 1024 и 2048 обозначают размер соответствующей тестовой нагрузки в токенах. Во всех строках больше токенов в секунду означает более высокую производительность.
| Модель и квантование | Тест, токены | 26.04.1 LTS, токенов/с | 26.10, токенов/с | Прирост |
|---|---|---|---|---|
| Llama-3.1-Tulu-3-8B-Q8_0 | Генерация 128 | 41,89 | 44,69 | +6,7% |
| Llama-3.1-Tulu-3-8B-Q8_0 | Обработка запроса 512 | 224,96 | 245,39 | +9,1% |
| Llama-3.1-Tulu-3-8B-Q8_0 | Обработка запроса 1024 | 216,60 | 241,81 | +11,6% |
| Llama-3.1-Tulu-3-8B-Q8_0 | Обработка запроса 2048 | 201,01 | 234,71 | +16,8% |
| granite-3.0-3b-a800m-instruct-Q8_0 | Генерация 128 | 132,45 | 163,14 | +23,2% |
| granite-3.0-3b-a800m-instruct-Q8_0 | Обработка запроса 512 | 1 138,35 | 1 706,76 | +49,9% |
| granite-3.0-3b-a800m-instruct-Q8_0 | Обработка запроса 1024 | 1 022,72 | 1 592,95 | +55,8% |
| granite-3.0-3b-a800m-instruct-Q8_0 | Обработка запроса 2048 | 851,89 | 1 403,50 | +64,8% |
| Mistral-7B-Instruct-v0.3-Q8_0 | Обработка запроса 1024 | 216,97 | 242,05 | +11,6% |
| Mistral-7B-Instruct-v0.3-Q8_0 | Обработка запроса 2048 | 201,75 | 235,07 | +16,5% |
| gpt-oss-20b-Q8_0 | Генерация 128 | 80,81 | 99,32 | +22,9% |
| gpt-oss-20b-Q8_0 | Обработка запроса 512 | 467,89 | 587,17 | +25,5% |
| gpt-oss-20b-Q8_0 | Обработка запроса 2048 | 394,12 | 566,42 | +43,7% |
| DeepSeek-R1-Distill-Llama-8B-Q8_0 | Генерация 128 | 41,38 | 45,40 | +9,7% |
| DeepSeek-R1-Distill-Llama-8B-Q8_0 | Обработка запроса 2048 | 199,30 | 234,83 | +17,8% |
| MiniMax-M2.5-UD-TQ1_0 | Генерация 128 | 34,71 | 40,98 | +18,1% |
| MiniMax-M2.5-UD-TQ1_0 | Обработка запроса 2048 | 73,94 | 85,36 | +15,4% |
Самый крупный разрыв показала granite-3.0-3b-a800m-instruct-Q8_0: обработка запроса ускорилась на 49,9–64,8%, а генерация – на 23,2%. У gpt-oss-20b-Q8_0 обработка запроса на 2048 токенов прибавила 43,7%, генерация – 22,9%. Для остальных опубликованных моделей выигрыш также есть, но его величина зависит от модели и операции.
В отдельной серии с одинаковой версией сервера Lemonade 2026.39.1 и процессорным backend различия гораздо меньше. В пяти опубликованных сценариях с Qwen3-Coder-Next, DeepSeek-Qwen3-8B и Qwen3.5-4B результаты изменились примерно от минус 1,0% до плюс 1,9%. Универсального ускорения любого локального ИИ-сервера на десятки процентов это исследование не показывает.
7-Zip, криптография и обработка сигналов
Разницу между обновлением системы и обновлением приложения хорошо иллюстрирует 7-Zip. Одинаковая версия 26.01, собранная на обеих системах, получила 671 055 и 692 997 MIPS – прирост 3,3%. При использовании архиватора из репозитория результат вырос с 544 232 до 715 099 MIPS, или на 31,4%, но одновременно версия 7-Zip изменилась с 26.00 на 26.02. Это показатели встроенного теста сжатия, а не измеренное время архивирования произвольного набора файлов.
В OpenSSL переход с 3.5.5 на 4.0.1 сопровождался ростом производительности SHA256 на 9,0% и SHA512 на 3,6%. Для ChaCha20-Poly1305 разница составила только 0,3%. В Cryptsetup тест PBKDF2-sha512 показал прирост числа итераций в секунду на 4,2%.
В OCUDU 26.04 пропускная способность одного потока в тесте PUSCH выросла с 341,9 до 382,8 Мбит/с – примерно на 12%, а суммарная пропускная способность PDSCH – со 118 379,8 до 127 722,9 Мбит/с, на 7,9%. Для GNU Radio 3.10.12.0 цепочка из пяти FIR-фильтров ускорилась на 19,0%, одиночный FIR-фильтр – на 5,0%, генератор косинусоидального сигнала – на 4,2%.
Где LTS сохранила преимущество
В научных и инженерных расчётах общего ускорения не получилось. Для RELION 3.1.3 в режиме Basic на CPU время выполнения выросло с 225,81 до 229,28 секунды, для NWChem с задачей C240 Buckyball – с 428,2 до 431,8 секунды. В NAMD 3.0 для ATPase с 327 506 атомами Ubuntu 26.10 показала на 0,6% меньше моделируемых наносекунд в сутки, для STMV с 1 066 628 атомами – на 0,8% меньше. В GROMACS 2025.4 с реализацией MPI CPU и задачей water_GMX50_bare результат снизился на 0,3%.
В OpenRadioss 2026.01.20 установка резинового уплотнительного кольца заняла 41,09 секунды вместо 39,16 – на 4,9% больше. Моделирование падения телефона потребовало 20,02 секунды вместо 18,58 – на 7,8% больше. В OpenFOAM 13 с задачей drivaerFastback время построения сетки увеличилось на 1,7% для малого размера и на 2,6% для среднего; время расчёта – на 4,8% и 0,5% соответственно. Здесь увеличение времени означает ухудшение результата.
Другие изменения преимущественно небольшие. Embree 4.4 с Pathtracer ISPC прибавила 1,4% в сцене Asian Dragon и 0,9% в Asian Dragon Obj, NumPy – 2,6% по итоговому баллу. Обе системы использовали Python 3.14: в PyBench время снизилось с 428 до 425 мс, а в семи опубликованных сценариях PyPerformance 1.14 – примерно на 2,2–4,9%: crypto_pyaes, django_template, gc_collect, go, nbody, regex_dna и tornado_http. Исключение – Sphinx: время увеличилось с 500 до 530 мс, на 6%.
Энергопотребление и срок поддержки
Сводный график мониторинга процессора показывает почти одинаковую среднюю мощность: 212,93 Вт в Ubuntu 26.04.1 LTS и 213,06 Вт в Ubuntu 26.10. Максимальные значения составили 348,69 и 349,78 Вт. Это показатели CPU в данной серии, а не потребление всего сервера из розетки.
Ubuntu 26.10 относится к промежуточным выпускам с девятью месяцами поддержки. Для серверов, которым нужен длительный срок сопровождения, семейство Ubuntu 26.04 LTS сохраняет это преимущество. Карточка Ubuntu Server на COMSS.ru содержит описание серверной редакции и ссылки на загрузку.
Вывод
Для серверов AMD EPYC Turin наиболее заметные преимущества Ubuntu 26.10 в этой серии связаны со случайным вводом-выводом, локальной передачей TCP и отдельными нагрузками готового пакета llama.cpp. Средние 3% скрывают существенно больший выигрыш в этих задачах, но также учитывают небольшие изменения и ухудшения в других тестах. При выборе системы важны результаты конкретного приложения, версии его пакетов и необходимый срок поддержки: один стенд не позволяет обещать такое же ускорение каждому серверу.