能跑,但输出不对WindowsLinuxmacOS最后更新 2026年11月6日

Local LLM outputs gibberish? Wrong chat template — not VRAM

The output is gibberish or it never stops talking

作者 Jakub Rusinowski

错误信息

<|im_start|>assistant<|im_end|> <|im_start|>user I I I the the of of<|endoftext|>assistantassistant
你遇到的是哪一种?
如果你看到原因是前往
Tags such as <|im_start|> or [INST] appear in repliesThe template does not match the model familyFix 2, then Fix 3
The model answers, then writes a fake user turn and keeps goingThe stop token is missing or wrongFix 3: right TEMPLATE, right stop token
It works in LM Studio but not in Ollama, or the reverseEach tool resolved the template differentlyFix 1, or Fix 4 in LM Studio
Word salad from the first token, with no tags at allThe file itself is damaged or unsupportedFix 6: verify the file

何时出现

The model loads fine, VRAM usage looks normal — but the output is wrong: leaked template tags like <|im_start|> or [INST] in the reply, answers that ignore your question, the model talking to itself in fake user/assistant turns, refusing to stop generating, or fluent-looking text degenerating into word salad. Most common right after downloading a community GGUF from Hugging Face, importing a model into a hand-written Modelfile, or converting your own fine-tune.

  • Importing a GGUF from Hugging Face whose template Ollama could not match to one it knows.
  • Copying a Modelfile written for a different model family.
  • Serving a fine-tune you converted yourself with the base model's template, or with none.
  • Using an older GGUF file made before chat templates were embedded in the file.

实际原因

Chat models don't see your message alone — the runtime wraps it in the model's chat template, the exact scaffolding of special tokens it was trained on. Llama 3 expects <|start_header_id|> headers, Qwen/ChatML models expect <|im_start|> markers, Gemma expects <start_of_turn>, and older Alpaca-style tunes expect "### Instruction:" blocks. Feed a model the wrong scaffolding and it's reading a foreign language: it leaks tags, misses its stop token, and produces nonsense. The weights are fine; the wrapper is wrong. (True VRAM problems announce themselves differently — crashes and OOM errors, not fluent gibberish. Genuinely corrupted downloads are the rarer look-alike, covered below.)

如何修复

  1. 1

    Pull from the official library instead of wiring the GGUF by hand最常见的修复方法

    Official Ollama library models (ollama pull llama3.1, qwen2.5, gemma3, …) ship with the correct template and stop tokens baked in — template gibberish essentially only happens with manually imported GGUFs and hand-written Modelfiles. If a hand-wired model misbehaves and the same model exists in the library, pulling the official version is the 30-second fix. Keep the manual route for models that genuinely aren't in the library (like your own fine-tunes).

    bash
    ollama rm my-broken-import
    ollama pull qwen2.5:7b   # template + stop tokens included
    生效了吗?Replies end cleanly with no tags, and ollama show <model> --template prints the family's template.
    检查哪些模型适配你的硬件find a model + quant that fits your hardware, with templates included打开显存检查器 →
  2. 2

    Diagnose it: compare the template against the model family

    Confirm the mismatch instead of guessing. Every model family's correct template is visible on any properly configured model of that family, and on the model's Hugging Face card (tokenizer_config.json → chat_template). Thirty seconds of comparison tells you exactly which scaffolding your Modelfile should carry.

    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. 3

    Fix the Modelfile: right TEMPLATE, right stop token

    When you must hand-write it (imported GGUF, converted fine-tune), copy the template from a same-family library model verbatim — never type it from memory; one missing newline or token matters. The stop parameter must match the family too: <|eot_id|> for Llama 3, <|im_end|> for ChatML/Qwen, <end_of_turn> for Gemma. Then recreate and retest.

    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
    生效了吗?After ollama create, a short test prompt gets a single answer that stops by itself, with no tags and no invented user turn.
  4. 4

    LM Studio: set the Prompt Format to match the model

    LM Studio reads the template embedded in GGUF metadata, and modern GGUFs carry the right one — but older or hand-converted files carry none, and LM Studio falls back to a guess. If output shows leaked tags, open the model's settings (My Models → gear icon → Prompt tab) and pick the correct format (ChatML for Qwen-family, Llama 3 for Llama-family, Gemma for Gemma) instead of the wrong autodetect. The moment tags stop appearing in output, you've got the right one.

    生效了吗?Replies stop leaking tags and end on their own after the change, across a few different prompts.
  5. 5

    Fine-tune you converted yourself? Match the training template exactly

    A converted fine-tune must be served with the template it was trained on — which follows the base model family. This is the single most common reason a fine-tune that evaluated well 'comes out broken' in Ollama: the behavior is in there, the wrapper is hiding it. The GGUF conversion guide's Modelfile section walks the whole flow.

  6. 6

    Template correct but still gibberish? Verify the file itself

    If the scaffolding checks out and output is still word salad, you're in the rarer failure class: a corrupted or truncated download, a broken experimental quant, or a GGUF too new/old for your runtime. Compare the file's size against the source repo listing (a partial download is smaller), re-download, prefer Q4_K_M-or-higher quants from reputable uploaders, and update Ollama/LM Studio — brand-new architectures need current runtime versions.

    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
    生效了吗?The file's size matches the repository listing exactly, or its SHA-256 matches the hash shown on the file's page on Hugging Face.

如果以上都没用

If the template is right and the model still rambles or loops, the cause has moved to the generation settings, which have their own page. If a converted fine-tune behaves differently from the original, compare its training chat format with the template you serve before suspecting the weights.

上报问题时请附上这些信息
  • Output of ollama show <model> --template and --parameters
  • The model's source: library tag, or Hugging Face repo and file name
  • A short prompt and the exact output, including any leaked tags
  • Your Ollama or LM Studio version
同样影响: Linux · Apple

相关内容

常见问题

Why is my local LLM outputting gibberish but not crashing?

Because nothing is broken mechanically — the model is answering a malformed conversation. A wrong chat template feeds the model scaffolding tokens it wasn't trained on, so it produces leaked tags, ignored questions, and nonsense. Memory problems crash with errors; template problems generate fluent garbage.

What are <|im_start|> and <|eot_id|> appearing in my output?

Special chat-template tokens leaking into text. <|im_start|>/<|im_end|> belong to ChatML-family models (Qwen and many fine-tunes); <|eot_id|> and <|start_header_id|> belong to Llama 3. Seeing them in a reply is the definitive symptom of a template/stop-token mismatch.

How do I find the correct chat template for my model?

Two authoritative sources: ollama show <same-family-library-model> --template for a known-good copy, or the chat_template field in tokenizer_config.json on the model's Hugging Face repo. Copy exactly — whitespace and newlines are part of the format.

Could gibberish mean my GPU or the download is faulty instead?

Sometimes — that's the second suspect. A truncated/corrupted GGUF or an extreme low-bit quant also produces nonsense. Distinguish them: template problems show structured symptoms (leaked tags, fake turns, no stopping), file problems show unstructured word salad from the first token. Verify file size against the source and re-download to rule it out.

Why does the same GGUF work in LM Studio but produce garbage in Ollama?

Each runtime resolves the template independently: LM Studio read the GGUF's embedded template while your hand-written Ollama Modelfile overrode it with the wrong one (or vice versa). The weights are provably fine — align both tools on the same, correct template and the difference disappears.