Czy mogę transkodować wideo za pomocą FFmpeg na VPS z dedykowanym vCPU bez GPU?

Które enkodery działają na CPU i co zmieniają presety?

Preset to wymiana szybkości na rozmiar: wolniejszy preset zużywa więcej CPU, żeby przy tej samej jakości uzyskać mniejszy plik. Ma go każdy enkoder programowy FFmpeg. Samą jakość ustawia się osobno, przez CRF. Najpierw wybierz jakość, potem najwolniejszy preset, na jaki pozwala termin.

Jak FFmpeg wykorzystuje vCPU VPS-a?

FFmpeg i jego enkodery ustalają liczbę wątków na podstawie liczby wykrytych CPU, a na VPS jest to liczba vCPU. Ogólna opcja threads domyślnie przyjmuje auto, a -filter_threads (skalowanie, nakładki i inne filtry) domyślnie przyjmuje liczbę dostępnych CPU. x265 buduje własne pule wątków, po jednej na węzeł NUMA, o rozmiarze zależnym od liczby CPU, i domyślnie uruchamia przetwarzanie równoległe wavefront; jego dokumentacja podaje, że koszt kompresji WPP w większości testów jest poniżej 1%.

Ta wartość domyślna jest właściwa dla jednego kodowania naraz. Kilka kodowań równolegle próbowałoby użyć każdego vCPU i spędzałyby czas na przełączaniu zamiast na kodowaniu. Podziel wątki ręcznie: na Fell 8 dwa zadania po -threads 4 każde, albo cztery zadania po -threads 2. Zasada wątek kontra rdzeń jest wyjaśniona w czy dedykowany vCPU to rdzeń czy wątek.

Pojedyncze kodowanie też nie skaluje się w nieskończoność. Wątki klatek i plasterków mają limity związane z rozdzielczością, więc plik 720p zyskuje na 16 wątkach mniej niż plik 4K.

Co zmieniają dedykowane rdzenie przy długim kodowaniu?

Kodowanie to CPU na 100% przez cały czas trwania pliku, czyli profil obciążenia, przed którym ostrzegają plany współdzielone. Według badania Cobaltfell z 2 listopada 2026, 29 z 51 hostów, które przyjmują kryptowaluty bez sprawdzania tożsamości, nie sprzedaje żadnego planu, którego CPU nazywa dedykowanym. Dwa z nich zapisują limit wprost: regulamin Spartan Host zabrania używania ponad 50% przydzielonych rdzeni dłużej niż godzinę, a polityka fair use Advin Servers ogranicza użycie CPU do 75%. Partia filmów narusza oba. Ogólny przypadek opisano w czym różni się współdzielony vCPU od dedykowanego.

W Cobaltfell: Pełne obciążenie jest dozwolone tak długo, jak wymaga tego Twoja praca: bez kredytów CPU, bez okna burst i bez throttlingu po kilku minutach przy 100%. vCPU to jeden wątek sprzętowy procesora hosta. Twoje są przypięte jeden do jednego do Twojego VPS i nigdy nie są pożyczane innemu klientowi, a dwa wątki jednego fizycznego rdzenia trzymają się razem, więc każde 2 vCPU tworzą jeden pełny rdzeń, którego nie dzieli żaden sąsiad. Bez sąsiada zabierającego cykle wartość speed=, którą drukuje FFmpeg, utrzymuje się od pierwszej minuty partii do ostatniej, więc czas trwania kolejki można wyliczyć z góry.

Wideo jest duże, więc dysk i transfer liczą się tak samo jak rdzenie. Źródło i wynik dzielą NVMe planu (Pamięć NVMe w każdym planie): Fell 8 mieści 320 GB NVMe, a Fell 16 640 GB NVMe. Każdy VPS otrzymuje jeden adres IPv4 i IPv6 /64 na porcie 1 Gbit/s. Miesięczny transfer Twojego planu liczy tylko dane wychodzące, a jego przekroczenie samo w sobie nigdy nie dolicza opłaty.

Jak zmierzyć czas kodowania na VPS przed zobowiązaniem?

Zakoduj jedną minutę prawdziwego źródła z każdym kandydatem ustawień i odczytaj wartość speed=: 1x to czas rzeczywisty, 2x to dwa razy szybciej. -f null - wyrzuca wynik, więc test mierzy enkoder, a nie dysk. -benchmark dodaje na końcu zużyty czas CPU.

# which software encoders this ffmpeg build has
ffmpeg -hide_banner -encoders | grep -E 'libx264|libx265|libsvtav1'

# 60 seconds of your own file, video only, output discarded
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx264 -preset medium -crf 23 -f null -
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx265 -preset medium -crf 28 -f null -
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libsvtav1 -preset 8 -crf 35 -f null -

# the same H.264 test held to 4 threads, to plan parallel jobs
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx264 -preset medium -crf 23 -threads 4 -f null -

Który plan pasuje do jakiego zadania transkodowania?

O planie decyduje praca do wykonania na godzinę, a nie pojedynczy plik. Tabela podaje punkty wyjścia, nie czasy: Nasze własne wyniki YABS i Geekbench 6, wraz z mierzonym przez nas steal time, zostaną opublikowane z datą, gdy tylko nasza pierwsza maszyna testowa zostanie dostarczona. Do tego czasu nie podajemy żadnych własnych wartości wydajności. Ceny każdego planu są wymienione w ile kosztuje VPS z dedykowanymi rdzeniami.

Inne hosty, które sprzedają dedykowane rdzenie do długich kodowań, są uszeregowane w który jest najlepszym dostawcą VPS z dedykowanym CPU w 2026.

Kiedy GPU jest lepszym narzędziem do wideo?

GPU jest lepszym narzędziem przy wielu jednoczesnych transmisjach na żywo w czasie rzeczywistym albo gdy przepustowość kodowania liczy się bardziej niż jak najmniejszy plik. Enkodery sprzętowe takie jak NVENC, Quick Sync i VAAPI działają na karcie graficznej lub zintegrowanym GPU, a FFmpeg korzysta z nich tylko wtedy, gdy to sprzęt jest obecny. VPS w Cobaltfell go nie ma, więc jego mocną stroną jest kodowanie programowe: wolniejsze na strumień, ale z pełnym zestawem presetów i wydajnością kompresji enkoderów programowych.

Dla bibliotek na żądanie, nocnych partii zadań i archiwów kodowanie na CPU na dedykowanych rdzeniach to prostsza konfiguracja. Dla platformy na żywo z dziesiątkami jednoczesnych kanałów sprzęt GPU to właściwy zakup. To samo pytanie CPU czy GPU w przypadku modeli językowych omówiono w czy mogę uruchomić Ollama na VPS bez GPU.