Analiza / Opinia
Jeden nagłówek HTTP w żądaniu do Workers AI zmienia rachunek za agenta
Cloudflare opisał 16 kwietnia, jak skaluje Kimi K2.5 i Llamę 4 na Workers AI: rozdzielił fazy prefill i decode na osobne klastry GPU, co według ich danych obniżyło p90 czasu między tokenami ze 100 ms do 20–30 ms. Wagi Kimi K2.5 ważą 560 GB i wymagają ośmiu H100, a KV cache trzyma się dzięki Mooncake na NVMe. Dla dewelopera agenta zostaje z tego jedno: nagłówek `x-session-affinity`, który kieruje żądanie tam, gdzie prefiks promptu już siedzi w cache, i pozwala płacić mniej za powtarzane tokeny wejściowe.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Analiza / Opinia · 4 min ·
Cloudflare opisał 16 kwietnia, jak utrzymuje pod produkcyjnym ruchem duże modele open-source na Workers AI: Kimi K2.5 Moonshota i Llamę 4. Tekst jest po części reklamą infrastruktury, po części dość konkretną listą decyzji architektonicznych. Dla dewelopera, który wysyła zapytania do API Workers AI z agenta, z całej tej maszynerii zostaje jedna praktyczna rzecz: nagłówek HTTP, dzięki któremu za te same tokeny wejściowe drugi raz nie zapłacisz pełnej ceny.
Agentowy ruch: długie wejście, krótkie wyjście
Workers AI od kilku miesięcy hostuje Kimi K2.5, model open-source z ponad bilionem parametrów. Cloudflare pisze, że od startu przyspieszył go trzykrotnie. Ważniejsze jest jednak, na jaki rodzaj ruchu silnik jest optymalizowany. W agentowym użyciu klient wysyła ogromną liczbę tokenów wejściowych: długi prompt systemowy, listę narzędzi, opisy MCP, całą historię poprzednich tur. Generuje przy tym stosunkowo niewiele wyjściowych. Każda kolejna tura dosyła to wszystko od nowa, bo model nie pamięta poprzedniej rozmowy.
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.
