Czy lokalny model udźwignie agenta? Wywoływanie narzędzi na modelach open-source

Szybka odpowiedź

Tak, ale z zastrzeżeniami. Model otwarty klasy ~30B uruchomiony lokalnie dobrze radzi sobie z kilkoma dobrze opisanymi narzędziami i krótką pętlą: wybierz narzędzie, wypełnij argumenty, przeczytaj wynik, odpowiedz. Benchmarki pokazują, że pojedyncze wywołania nie są już problemem nawet dla modeli 8B. Problemem są długie, wieloturowe zadania, w których model sam planuje kolejne kroki: tam wyniki mniejszych modeli spadają o połowę. Dlatego agent na modelu lokalnym potrzebuje walidacji argumentów, limitu kroków, bezpiecznika pętli i zgody człowieka przed akcjami ze skutkiem. Tak budujemy agentów w pimento, na modelach z rodzin Qwen, Gemma, GLM i Mistral serwowanych na naszych GPU NVIDIA Blackwell.

Co model musi umieć w pętli agenta

„Tool calling” brzmi jak jedna umiejętność, a to kilka różnych:

1. Decyzja, czy w ogóle wołać narzędzie. Na pytanie „dzień dobry” agent nie powinien odpytywać bazy klientów.
2. Wybór właściwego narzędzia spośród kilku lub kilkudziesięciu.
3. Wypełnienie argumentów zgodnie ze schematem: typy, wymagane pola, formaty dat, identyfikatory.
4. Odczytanie wyniku i decyzja, co dalej: kolejne narzędzie, pytanie do użytkownika czy odpowiedź.
5. Zatrzymanie się, kiedy zadanie jest skończone albo nie da się go wykonać.

Punkty 1-3 to pojedyncze wywołanie. Punkty 4-5 to pętla, a w niej błędy się kumulują. Model, który trafia w 90% pojedynczych kroków, w zadaniu z dziesięcioma zależnymi krokami może zawieść częściej, niż zadziała. O tym, czym jest agent i czym różni się od zwykłego chatbota, piszemy w tekście Agentic AI w praktyce.

Co mówią benchmarki

Najczęściej cytowanym rankingiem wywołań funkcji jest Berkeley Function Calling Leaderboard (BFCL), dziś w wersji V4. Oprócz prostych wywołań (pojedyncze, wielokrotne, równoległe) mierzy zapytania od prawdziwych użytkowników („live”), zadania wieloturowe, rozpoznawanie sytuacji, w których żadne narzędzie nie pasuje, a od V4 także scenariusze agentowe: wyszukiwanie w sieci i zarządzanie pamięcią.

Wybrane wiersze z rankingu w wersji z 12 kwietnia 2026 r.:

Z tej tabeli wynikają trzy rzeczy.

Pojedyncze wywołania są rozwiązane. Kolumna prostych wywołań jest wyrównana: 85-90% niemal u wszystkich, od 8B do największych modeli zamkniętych. Jeśli Twój agent to „zrozum pytanie, zawołaj jedno narzędzie, sformułuj odpowiedź”, mały model lokalny wystarczy.

Różnice robi wieloturowość. W zadaniach wieloturowych rozrzut jest ogromny: od ok. 10% do ok. 68%. Najlepszy otwarty model, GLM-4.6, jest tu na poziomie najlepszego zamkniętego, ale to duży model MoE. Modele, które łatwo zmieścić na jednym GPU, osiągają 30-48%.

Tryb wywołań ma znaczenie. BFCL testuje część modeli dwa razy: przez natywny format wywołań (FC) i przez instrukcję w prompcie. DeepSeek-V3.2-Exp ma w prostych wywołaniach 34,85% w trybie FC i 85,52% w trybie promptowym z myśleniem. To ten sam model. Różnica bierze się z formatu i sposobu parsowania, czyli z tego, jak model jest serwowany.

Jedno zastrzeżenie: ranking nie nadąża za premierami. W wersji z kwietnia 2026 r. nie ma np. Gemmy 4 ani nowszych generacji Qwena, choć oba mają już natywną obsługę narzędzi. Traktuj BFCL jako mapę rodzin modeli, nie jako wyrok dla konkretnej wersji.

Drugi ważny benchmark to τ-bench (Sierra), który symuluje rozmowę agenta z użytkownikiem w sklepie i liniach lotniczych, z prawdziwymi regułami biznesowymi. Autorzy wprowadzili miarę pass^k: prawdopodobieństwo, że agent rozwiąże to samo zadanie w k próbach z rzędu. W oryginalnej pracy nawet GPT-4o rozwiązywał mniej niż 50% zadań, a pass^8 w domenie sklepu był poniżej 25%. Następca, τ²-bench, dodaje scenariusze, w których także użytkownik musi wykonywać akcje. Wniosek dla wdrożeń jest prosty: średnia skuteczność ukrywa niestabilność, a w produkcji liczy się to, czy agent działa za każdym razem.

Serwowanie: gdzie najczęściej coś się psuje

Częsta przyczyna problemu „model nie umie wołać narzędzi” leży w serwowaniu, nie w modelu. Model generuje wywołanie w swoim formacie (tagi XML, JSON w specjalnych tokenach, składnia pythonowa), a serwer musi je rozpoznać i zamienić na pole tool_calls w API zgodnym z OpenAI. Jeśli parser nie pasuje do modelu, wywołanie ląduje jako zwykły tekst i agent „nic nie robi”.

W vLLM tool calling włącza się flagami --enable-auto-tool-choice i --tool-call-parser, a parser musi pasować do rodziny modelu:

Nazwy parserów zmieniają się między wersjami vLLM, a nowe modele dostają nowe parsery, więc sprawdzaj dokumentację wersji, którą faktycznie uruchamiasz, i kartę modelu. Do tego kilka rzeczy, które warto wiedzieć:

• tool_choice="required" i nazwana funkcja są w vLLM realizowane przez structured outputs. Dokumentacja wprost mówi, że to gwarantuje wywołanie poprawne składniowo, a nie trafne.
• Tryb strict. Przy tool_choice="auto" argumenty są ograniczane schematem tylko wtedy, gdy narzędzie ma strict: true. Bez tego model generuje wywołanie swobodnie, a serwer tylko wyciąga je z tekstu. Schematy pod tryb strict: additionalProperties: false, wszystkie pola wymagane, pola opcjonalne jako dopuszczające null.
• Wywołania równoległe działają różnie w różnych rodzinach. Dla Llamy 3 vLLM ich nie obsługuje, dla Llamy 4 tak.
• llama.cpp (llama-server) obsługuje narzędzia po uruchomieniu z flagą --jinja. Dla części rodzin ma natywne formaty, dla pozostałych format ogólny, który zużywa więcej tokenów. Dokumentacja ostrzega przed agresywną kwantyzacją cache KV (np. -ctk q4_0), bo wyraźnie pogarsza wywołania.
• Gemma 4 ma w szablonie czatu własne tokeny deklaracji i wywołań narzędzi. Google w przewodniku po function calling przypomina rzecz oczywistą, którą łatwo zgubić: model niczego nie wykonuje sam, wykonuje Twój kod, więc to on ma walidować nazwę funkcji i argumenty.

Ogólniej o tym, czym serwować modele i ile pamięci potrzebują, piszemy w przewodniku ile VRAM potrzeba do lokalnego LLM.

Jak projektujemy agenta pod model lokalny

Duży model zamknięty wybacza dużo: niejasne opisy narzędzi, dwadzieścia narzędzi w kontekście, długi plan. Model lokalny wybacza mniej, więc projekt agenta musi zdjąć z niego część pracy. Zasady, które się przy tym sprawdzają:

1. Mało narzędzi naraz. Każde narzędzie w kontekście to kolejna okazja do pomyłki. Jeśli agent ma ich dużo, warto podzielić je na grupy i najpierw wybrać grupę.
2. Opisy pisane dla modelu. Nazwa narzędzia mówi, co robi. Opis mówi, kiedy go użyć, a kiedy nie. Przykład argumentów w opisie pomaga bardziej niż długi akapit.
3. Schematy bez dwuznaczności. Enumy zamiast wolnego tekstu, jeden format dat, identyfikatory zamiast nazw.
4. Walidacja w kodzie. Każdy argument jest sprawdzany przed wykonaniem. Błąd walidacji wraca do modelu jako czytelny komunikat, a nie jako wyjątek z serwera.
5. Deterministyczny kod tam, gdzie się da. Jeśli kolejność kroków jest stała, to nie model ją planuje. Model wypełnia luki, które wymagają rozumienia języka.
6. Budżet kroków i bezpiecznik pętli. Agent, który woła to samo narzędzie trzeci raz z tymi samymi argumentami, jest zatrzymywany.
7. Zgoda człowieka przed skutkami. Czytać agent może sam. Wysłać pismo, zmienić dane czy wpisać termin może dopiero po „Zatwierdź”. Brak decyzji oznacza odmowę.
8. Dziennik audytu i zestaw testowy. Każdy krok trafia do dziennika. Każda nowa wersja modelu, promptu albo narzędzi przechodzi zestaw testów zbudowany z prawdziwych rozmów, uruchamianych kilka razy, żeby widzieć niestabilność, a nie tylko średnią.

Część z tych zasad to też bezpieczeństwo. Agent z narzędziami jest celem prompt injection, a lokalny model nie jest na nie odporniejszy od chmurowego. Więcej w tekstach o bezpieczeństwie agentów i MCP i o OWASP Top 10 dla aplikacji LLM.

Kiedy lokalny model wystarczy, a kiedy nie

Jeśli dane nie mogą opuścić firmy, alternatywą dla małego modelu nie jest chmura, tylko większy model otwarty na własnym serwerze. GLM-4.6 czy duże modele Qwen MoE są w BFCL blisko czołówki, ale wymagają odpowiednio więcej pamięci GPU. Jak dobieramy model i sprzęt do agenta, opisujemy na stronie Agenci AI.

Warto też pamiętać o kontekście biznesowym. Gartner przewiduje, że ponad 40% projektów agentowych zostanie anulowanych do końca 2027 r. z powodu kosztów, niejasnej wartości albo słabej kontroli ryzyka. Agent na modelu lokalnym, który robi jedno zadanie dobrze i przewidywalnie, ma większą szansę przetrwać niż ambitny agent do wszystkiego.

Lista kontrolna przed wdrożeniem agenta na modelu lokalnym

1. Spisz narzędzia i oznacz, które tylko czytają, a które mają skutki.
2. Wybierz 2-3 modele kandydujące z rodzin, które dobrze wypadają w BFCL, i sprawdź ich kartę modelu pod kątem formatu narzędzi.
3. Uruchom je z właściwym parserem i szablonem czatu. Sprawdź na kilku przykładach, że wywołania trafiają do tool_calls, a nie do treści.
4. Zbuduj zestaw testowy z 30-100 prawdziwych zadań z oczekiwanym przebiegiem.
5. Uruchom każde zadanie kilka razy. Mierz odsetek zadań rozwiązanych za każdym razem, nie tylko średnią.
6. Dodaj walidację argumentów, budżet kroków, bezpiecznik pętli i zatwierdzanie akcji ze skutkiem.
7. Włącz dziennik audytu każdego kroku i przeglądaj błędy co tydzień.
8. Przy każdej zmianie modelu, parsera albo wersji serwera powtórz testy.

Źródła

• Berkeley Function Calling Leaderboard (BFCL) V4
• BFCL V4, Part 1: Web Search (opis kategorii agentowych)
• Yao i in.: τ-bench, A Benchmark for Tool-Agent-User Interaction in Real-World Domains (2024)
• Barres i in.: τ²-Bench, Evaluating Conversational Agents in a Dual-Control Environment (2025)
• vLLM: Tool Calling
• llama.cpp: Function calling
• Google AI for Developers: Function calling with Gemma 4
• Gartner: Over 40% of agentic AI projects will be canceled by end of 2027 (2025)