Trefon.
L2 Inferencja / optymalizacja

Ten sam model, szybciej i taniej.

Większość problemów z inferencją to nie problemy z modelem. To pamięć, batching, cache i planowanie. Profiluję stos, który uruchamiasz, zmieniam to, co naprawdę go ogranicza, i pokazuję przed i po na Twoim obciążeniu.

Opisz swój problem Zobacz opis wdrożenia

+31%

dekodowanie po strojeniu produkcyjnym

262K

kontekstu na jednej karcie 24 GB

16×

mniej przechwyceń grafów CUDA

§01 objaw

Jak to zwykle wygląda.

Przepustowość staje w miejscu.

Jedno zapytanie działa. Dziesięć równoległych i kolejka nigdy się nie opróżnia. GPU jest zajęte, ale nie użyteczną pracą.

Kontekst zjada kartę.

Długie prompty mieszczą się tylko przy krótkim kontekście albo serwer spada na CPU i opóźnienia się załamują. Limitem jest cache KV, nie wagi.

Rachunek rośnie razem z sukcesem.

Każdy nowy klient dodaje tokeny. Koszt serwowania rośnie szybciej niż przychód, a obniżka, której potrzebujesz, jest w stosie, nie w umowie.

§02 co zmieniam

Gdzie ucieka czas i pamięć.

  1. 01

    Najpierw pomiar

    Test obciążeniowy na Twoich promptach, długościach kontekstu i współbieżności. Znajduję rzeczywiste wąskie gardło, zanim cokolwiek zmienię: prefill, dekodowanie, przepustowość cache KV, planowanie albo host.

  2. 02

    Cache KV

    Cache decyduje o tym, ile kontekstu się mieści i jak szybko działa dekodowanie. Skwantyzowany cache, stronicowana alokacja, ponowne użycie prefiksu: wybieram kombinację, na którą pozwala Twój budżet dokładności.

  3. 03

    Kwantyzacja

    Wagi i cache skwantyzowane do najniższej precyzji, która nadal zalicza Twoje ewaluacje. Mierzone na Twoich zadaniach, nie na leaderboardzie.

  4. 04

    Planowanie i batching

    Ciągły batching, dzielony prefill, dekodowanie spekulatywne, grafy CUDA. Cel: mniej martwych przerw i więcej tokenów na sekundę z karty.

  5. 05

    Warstwa serwowania

    API zgodne z OpenAI, podmiana modelu na gorąco, health checks i metryki, żeby Twoje narzędzia dalej działały, a zespół mógł to obsługiwać.

§03 zmierzone dowody

Liczby z moich własnych przebiegów.

fig. 01 Szybkość dekodowania wg kontekstu, tok/s
4K
  • tbq4_0 55,3
  • planar3_0 53,9
32K
  • tbq4_0 51,5
  • planar3_0 50,6
262K
  • tbq4_0 77
  • planar3_0 ~47
RTX 4090, Qwen3.6-27B, włączone MTP i flash attention. Wiersz 262K: konfiguracja pod maksymalną szybkość.

62 → 82tok/s

dekodowanie po moim strojeniu produkcyjnym (+31%)

4,125bity

na wartość KV, cache TBQ4

16×

mniej przechwyceń grafów CUDA niż upstream

≤300MiB

przypiętej RAM na checkpointy, zamiast 4,7 GB

Źródło: README mojego forka i moje commity w llama.cpp-turboq-mtp; Qwen3.6-27B, jedna RTX 4090.

§04 co dostajesz

Co dostajesz.

  • Zmierzoną bazę: przepustowość, opóźnienia i pamięć na Twoim obciążeniu
  • Dostrojony stos serwujący jako konfigurację i infrastrukturę jako kod
  • Raport przed/po z liczbami i przyczyną różnicy
  • Runbook, który Twój zespół obsłuży beze mnie

Matematyka pod spodem.

Wszystkie artykuły
§05 odpowiedzi

O co pytają najczęściej.

O ile można przyspieszyć inferencję?

To zależy od tego, co Cię ogranicza. Na moim stosie strojenie dekodowania i cache KV podniosło szczytowe dekodowanie z 62 do 82 tok/s, +31%, i zmniejszyło liczbę przechwyceń grafów CUDA 16×. Stos z oczywistym wąskim gardłem zwykle zyskuje więcej; dobrze dostrojony mniej. Przegląd daje liczbę, zanim zdecydujesz się na wdrożenie.

Czy kwantyzacja pogarsza jakość?

Może, dlatego się ją mierzy. Kwantyzuję do najniższej precyzji, która nadal zalicza Twoje ewaluacje, i raportuję różnicę. 4-bitowy cache nie jest darmowy jakościowo; to wymiana, którą powinieneś zobaczyć, a nie zgadywać.

vLLM, llama.cpp czy TensorRT-LLM?

Ten, który pasuje do Twojego sprzętu i obciążenia. Uruchamiam llama.cpp na produkcji na 4090 i czytam kernele; silnik wybieram po teście obciążeniowym, nie przed.

Czy da się zoptymalizować hostowane API?

Tylko na brzegach: kształt promptu, cache, routing między modelami, dyscyplina kontekstu. Jeśli nie kontrolujesz stosu serwującego, największe zyski zwykle są w tym, co wysyłasz, a nie w silniku.

Ile to trwa?

Przegląd to tydzień do dwóch. Wdrożenie strojenia ustalamy potem, zwykle dwa do czterech tygodni, zależnie od tego, jak dużo stosu się zmienia.

Rachunek za serwowanie rośnie szybciej niż przychód?

Opisz swój problem

30-minutowa rozmowa techniczna z inżynierem, który to buduje. Bez działu sprzedaży, bez slajdów.