Start / Poradniki / Rozwiązywanie problemów / Windows

Lokalny LLM wypisuje bełkot? Zły szablon czatu, nie brak VRAM-u

WindowsLinuxmacOS

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 10 lipca 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

<|im_start|>assistant<|im_end|> <|im_start|>user I I I the the of of<|endoftext|>assistantassistant

Kiedy się pojawia

Model ładuje się bez problemu, zużycie VRAM-u wygląda normalnie — ale wyjście jest złe: w odpowiedzi przeciekają znaczniki szablonu w rodzaju <|im_start|> czy [INST], odpowiedzi ignorują pytanie, model rozmawia sam ze sobą w udawanych turach użytkownika i asystenta, nie chce przestać generować albo płynnie wyglądający tekst zamienia się w sieczkę. Najczęściej zaraz po pobraniu społecznościowego GGUF-a z Hugging Face, po zaimportowaniu modelu do ręcznie napisanego pliku Modelfile albo po konwersji własnego fine-tuna.

Co się właściwie dzieje

Modele czatowe nie widzą samej twojej wiadomości — środowisko uruchomieniowe opakowuje ją w szablon czatu danego modelu, czyli dokładnie to rusztowanie ze znaczników specjalnych, na którym model był trenowany. Llama 3 oczekuje nagłówków <|start_header_id|>, modele Qwen i ChatML — znaczników <|im_start|>, Gemma — <start_of_turn>, a starsze tuny w stylu Alpaki — bloków „### Instruction:”. Podaj modelowi niewłaściwe rusztowanie, a będzie czytał w obcym języku: przepuści znaczniki, przegapi swój token zatrzymania i wyprodukuje bzdury. Wagi są w porządku, zepsute jest opakowanie. Prawdziwe problemy z VRAM-em zgłaszają się inaczej — awariami i błędami OOM, a nie płynnym bełkotem. Rzadszym sobowtórem są faktycznie uszkodzone pobrania, o czym niżej.

Jak to naprawić

1. Pobieraj z oficjalnej biblioteki, zamiast podpinać GGUF-a ręcznie Najczęstsze rozwiązanie

Modele z oficjalnej biblioteki Ollamy (ollama pull llama3.1, qwen2.5, gemma3 i tak dalej) mają poprawny szablon i tokeny zatrzymania wbudowane na stałe — bełkot z szablonu praktycznie zdarza się wyłącznie przy ręcznie importowanych GGUF-ach i własnoręcznie pisanych plikach Modelfile. Jeśli ręcznie podpięty model wariuje, a ten sam model istnieje w bibliotece, pobranie oficjalnej wersji załatwia sprawę w trzydzieści sekund. Drogę ręczną zostaw dla modeli, których w bibliotece naprawdę nie ma — na przykład własnych fine-tunów.

bash
ollama rm my-broken-import
ollama pull qwen2.5:7b   # template + stop tokens included
Sprawdź, co zmieści się na twoim sprzęcie — znajdź model i kwantyzację pasujące do twojego sprzętu, z gotowymi szablonami
Otwórz kalkulator VRAM →

2. Zdiagnozuj to: porównaj szablon z rodziną modelu

Potwierdź niedopasowanie, zamiast zgadywać. Poprawny szablon każdej rodziny widać w dowolnym poprawnie skonfigurowanym modelu z tej rodziny oraz na karcie modelu na Hugging Face (tokenizer_config.json → chat_template). Trzydzieści sekund porównywania mówi dokładnie, jakie rusztowanie powinien nieść twój plik Modelfile.

bash
# What template is my model actually using?
ollama show my-model --template

# What SHOULD a model of this family use?
ollama show llama3.1 --template
ollama show qwen2.5 --template

3. Popraw plik Modelfile: właściwy TEMPLATE, właściwy token zatrzymania

Kiedy musisz napisać go ręcznie (zaimportowany GGUF, przekonwertowany fine-tune), skopiuj szablon z modelu tej samej rodziny z biblioteki, znak w znak — nigdy nie przepisuj go z pamięci; znaczenie ma każdy brakujący znak nowej linii i każdy token. Parametr stop też musi pasować do rodziny: <|eot_id|> dla Llamy 3, <|im_end|> dla ChatML i Qwena, <end_of_turn> dla Gemmy. Potem utwórz model ponownie i przetestuj.

bash
# Modelfile for a ChatML/Qwen-family GGUF
FROM ./my-model.gguf
TEMPLATE """<|im_start|>system
{{ .System }}<|im_end|>
<|im_start|>user
{{ .Prompt }}<|im_end|>
<|im_start|>assistant
"""
PARAMETER stop <|im_end|>

# apply:
ollama create my-model-fixed -f Modelfile

4. LM Studio: ustaw Prompt Format pasujący do modelu

LM Studio odczytuje szablon zaszyty w metadanych GGUF-a i nowoczesne pliki niosą ten właściwy — ale starsze albo ręcznie konwertowane nie niosą żadnego, więc LM Studio zgaduje. Jeśli w wyjściu widać przeciekające znaczniki, otwórz ustawienia modelu (My Models → ikona koła zębatego → zakładka Prompt) i wybierz właściwy format: ChatML dla rodziny Qwen, Llama 3 dla rodziny Llama, Gemma dla Gemmy. W chwili, gdy znaczniki przestają się pojawiać, masz ten właściwy.

5. Konwertowałeś własny fine-tune? Odwzoruj dokładnie szablon z treningu

Przekonwertowanego fine-tuna trzeba serwować z tym szablonem, na którym był trenowany — a ten idzie za rodziną modelu bazowego. To najczęstszy powód, dla którego fine-tune z dobrymi wynikami w ewaluacji „wychodzi zepsuty” w Ollamie: zachowanie tam jest, tylko opakowanie je zasłania. Cały przebieg opisuje sekcja o pliku Modelfile w poradniku o konwersji do GGUF.

6. Szablon poprawny, a bełkot został? Zweryfikuj sam plik

Jeśli rusztowanie się zgadza, a wyjście dalej jest sieczką, jesteś w rzadszej klasie awarii: uszkodzone albo obcięte pobranie, wadliwa eksperymentalna kwantyzacja lub GGUF zbyt nowy bądź zbyt stary dla twojego środowiska. Porównaj rozmiar pliku z listingiem w repozytorium źródłowym (niepełne pobranie jest mniejsze), pobierz ponownie, wybieraj kwantyzacje Q4_K_M i wyższe od porządnych wydawców oraz zaktualizuj Ollamę lub LM Studio — całkiem nowe architektury wymagają aktualnych wersji środowiska.

bash
# Size sanity check vs the Hugging Face repo listing
ls -lh my-model.gguf

# Update the runtime (new model support lands fast)
ollama --version

Dotyczy także: Linux · Apple

Powiązane

Model, który mieści się na większości zestawów:
Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego mój lokalny LLM wypisuje bełkot, ale się nie wysypuje?

Bo mechanicznie nic nie jest zepsute — model odpowiada na źle sformułowaną rozmowę. Zły szablon czatu podaje mu tokeny rusztowania, na których nie był trenowany, więc produkuje przeciekające znaczniki, ignoruje pytania i pisze bzdury. Problemy z pamięcią kończą się awarią i komunikatem błędu; problemy z szablonem — płynnym śmieciem.

Czym są <|im_start|> i <|eot_id|>, które pojawiają się w wyjściu?

To specjalne tokeny szablonu czatu, które przeciekły do tekstu. <|im_start|> i <|im_end|> należą do rodziny ChatML (Qwen i wiele fine-tunów), a <|eot_id|> oraz <|start_header_id|> do Llamy 3. Zobaczenie ich w odpowiedzi to rozstrzygający objaw niedopasowanego szablonu i tokenu zatrzymania.

Jak znaleźć właściwy szablon czatu dla mojego modelu?

Są dwa wiarygodne źródła: ollama show <model-z-biblioteki-tej-samej-rodziny> --template daje pewną kopię, a pole chat_template w pliku tokenizer_config.json w repozytorium modelu na Hugging Face — oryginał. Kopiuj dokładnie; spacje i znaki nowej linii są częścią formatu.

Czy bełkot może zamiast tego oznaczać wadliwe GPU albo uszkodzone pobranie?

Czasem tak — to drugi podejrzany. Obcięty lub uszkodzony GGUF i skrajnie niskobitowa kwantyzacja także dają bzdury. Rozróżnisz je po objawach: problem z szablonem ma strukturę (przeciekające znaczniki, udawane tury, brak zatrzymania), a problem z plikiem to bezładna sieczka od pierwszego tokenu. Porównaj rozmiar pliku ze źródłem i pobierz ponownie, żeby to wykluczyć.

Dlaczego ten sam GGUF działa w LM Studio, a w Ollamie produkuje śmieci?

Bo każde środowisko rozstrzyga szablon niezależnie: LM Studio odczytało szablon zaszyty w GGUF-ie, podczas gdy twój ręcznie napisany plik Modelfile nadpisał go błędnym — albo odwrotnie. Wagi są dowodnie w porządku; ustaw w obu narzędziach ten sam, poprawny szablon, a różnica zniknie.