Rozliczanie za sekundę wyjaśnione: dlaczego 20 sekund sandboxa kosztuje $0.00055

„Rozliczane za sekundę” to jedno z tych zdań, które brzmią na kompletne, a nimi nie są. Stoi za nim kilka decyzji, od których zależy rachunek: co jest mierzone, kiedy zegar startuje i się zatrzymuje, czy jest minimum, jak traktowane są ułamki centa i kiedy pieniądze faktycznie schodzą z salda.

Ten wpis spisuje nasze odpowiedzi wraz z rachunkami dla sandboxów do kodu. Cel jest prosty: żebyś mógł przewidzieć rachunek co do centa, zanim cokolwiek uruchomisz, i rozpoznał moment, w którym rozliczanie za sekundę to zły model dla twojego obciążenia.

Jednostka: zarezerwowane vCPU i RAM

Cena sandboxa to cena zasobów, które rezerwuje jego taryfa:

• $0.040 za vCPU-godzinę
• $0.013 za GiB RAM na godzinę

Taryfa small (0.5 vCPU, 1 GB) kosztuje więc 0.5 × 0.040 + 1 × 0.013 = $0.033 za godzinę, czyli około $0.0000092 za sekundę. Największa, max (8 vCPU, 16 GB), kosztuje $0.528 za godzinę.

Mierzymy rezerwację, nie zużycie. Sandbox czekający na kolejne polecenie kosztuje na sekundę tyle samo co ten, który kompiluje projekt. Mierzenie rzeczywistego CPU wyglądałoby na papierze uczciwiej, ale ceny nie dałoby się znać z góry, a moc i tak jest dla ciebie trzymana. Ruch wychodzący nie jest rozliczany.

Zegar: od utworzenia do usunięcia

Sandbox efemeryczny jest rozliczany od chwili utworzenia do chwili usunięcia. Wlicza się w to czas bezczynności, zanim usunie go limit bezczynności, domyślnie 300 sekund.

Stąd bierze się większość niespodzianek. Skrypt działający dwie minuty w sandboxie, którego nikt nie usunął, rozliczany jest za siedem: dwie pracy i pięć czekania na limit. Rozwiązanie jest nudne: usuwaj sandbox, gdy skończysz (blok with w SDK robi to sam), albo zmniejsz limit bezczynności.

Minimum: 60 sekund na sandbox

Każdy sandbox efemeryczny jest rozliczany za co najmniej 60 sekund życia. Uruchomienie microVM, podpięcie dysku i sieci, a potem rozebranie wszystkiego kosztuje tyle samo, czy kod w środku działa sekundę, czy pięćdziesiąt.

Minimum stosowane jest raz, gdy sandbox się kończy, i tylko jeśli jego łączny czas życia był krótszy niż 60 sekund. Nie ma dodatkowego minimum za godzinę ani za polecenie.

Naliczanie i obciążenie: mikrodolary i pełne centy

Oto część, o której „za sekundę” zwykle milczy. Host sandboxów zapisuje użycie w godzinnych przedziałach, po jednym na sandbox. Raz na minutę zadanie rozliczeniowe pobiera zamknięte przedziały, wycenia je i obciąża saldo.

Wycena odbywa się w milionowych częściach dolara. Obciążenie — w pełnych centach. To, co zostaje poniżej centa, pozostaje na koncie i dolicza się do kolejnego obciążenia; nic nie jest zaokrąglane w górę ani per sandbox, ani per godzinę.

Przy małej skali to ma znaczenie. Sto 20-sekundowych sandboxów nalicza 100 × $0.00055 = $0.055. Obciążenie wynosi pięć centów, a pół centa czeka na kolejną partię. Gdyby każdy sandbox zaokrąglano do centa, ta sama praca kosztowałaby dolara.

Warto znać jeszcze dwie właściwości:

• Każdy przedział jest obciążany dokładnie raz. Zapis użycia i obciążenie trafiają do jednej transakcji bazy danych, z kluczem „sandbox + godzina”. Ponowne uruchomienie ani zgubione potwierdzenie nie obciążą dwa razy.
• Awarie opóźniają obciążenia, ale ich nie gubią ani nie dublują. Jeśli rozliczenia nie mogą połączyć się z hostem sandboxów, nic nie jest potwierdzane, przedziały czekają i zostają obciążone po powrocie połączenia.

Konsekwencja: panel może być do godziny w tyle za bieżącą liczbą. Bieżącą wartość zwraca GET /sandboxes/{id}/usage: billed_usd i estimated_total_usd dla sandboxa do tej chwili.

Sandboxy persistent: za rozpoczętą godzinę, z limitem

Sandboxy persistent zachowują dysk między sesjami, do 30 dni. Są rozliczane za każdą rozpoczętą godzinę: 61 minut to dwie godziny. W zamian miesiąc kalendarzowy (UTC) nigdy nie kosztuje więcej niż 730 godzin minus 25%.

Dla taryfy standard ten limit wynosi $36.14 miesięcznie zamiast $48.18. Dopóki sandbox persistent jest wstrzymany, w ogóle nie jest rozliczany.

Gdy kończy się saldo

Saldo nigdy nie schodzi poniżej zera. Nowe sandboxy są odrzucane z 402 insufficient_balance. Działające już sandboxy efemeryczne kończą się na swoim limicie bezczynności lub TTL. Persistent są wstrzymywane po 24 godzinach bez doładowania i same wznawiają pracę, gdy dodasz środki. Snapshoty wstrzymanych sandboxów są trzymane 14 dni. Potem sandbox jest usuwany, a jego id odpowiada 410 sandbox_deleted.

Jeśli sandboxy tworzy za ciebie agent AI, ustaw limit dzienny i miesięczny. Po jego osiągnięciu zwracane jest 429 budget_exceeded z czasem resetu, na co program może zareagować.

Gdzie rozliczanie za sekundę przegrywa

Rozliczanie za sekundę jest świetne dla pracy mierzonej w sekundach i minutach. Im dłuższa praca, tym gorzej wypada.

Punkt przełomu leży mniej więcej tam, gdzie obciążenie działa dłużej niż kilka godzin dziennie. Dalej płacisz za elastyczność, z której nie korzystasz, a serwer wynajmowany miesięcznie jest wyraźnie tańszy za godzinę. Uczciwie patrząc, rozliczanie za sekundę to cena za brak konieczności planowania mocy, a nie rabat.

Szybki szacunek

Cena taryfy za godzinę × sekundy, które sandbox przeżyje ÷ 3600, z progiem 60 sekund. Jeśli nie usuniesz go sam, dolicz limit bezczynności. Dla persistent zaokrąglaj każdą sesję w górę do pełnych godzin i zatrzymaj się na limicie miesięcznym.

Wszystkie zasady, limity i API budżetu są w limitach i rozliczeniach sandboxów; wywołania wspomniane wyżej — w dokumentacji SDK. Jeśli zastanawiasz się, co właściwie wynajmujesz na sekundy, odpowiada na to microVM Firecracker w prostych słowach, a czego agenci AI naprawdę potrzebują od infrastruktury wyjaśnia, dlaczego model rozliczeń tak bardzo się liczy, gdy maszyny tworzą programy, a nie ludzie.