Llama模型系统化测试指南：量化、工具调用与微调评估

在本地部署和评测 Llama 系列模型时，很多团队最容易忽略的环节并不是模型下载，而是测试。所谓 The Llama Tests，可以理解为围绕 Llama 模型展开的一组系统性验证：从量化选型、工具调用、微调评估到推理性能，每一步都要有可重复的测试方法。没有测试的模型接入，等于把不确定因素直接带进生产环境。模型文件能载入、能回复一句话，并不代表它在你预期的场景中可靠；真正的问题往往出现在量化后质量、工具调用格式、微调失效这类“看起来不难，实际反复出问题”的地方。

这篇文章会围绕 Llama 模型在本地推理场景下的测试方法展开。读者可能是正在接入开源大模型的算法工程师、后端开发者，也可能是需要为团队做模型选型的测试开发。文章不会只讲概念，会给出可直接使用的环境准备方式、量化对比脚本、工具调用测试用例、LlamaFactory 微调评估流程，以及一套常见问题排查链路。完成阅读后，你可以把文中流程改造成自己的模型测试方案，在接入 Llama 模型时至少做到“跑得起来、测得清楚、修得动”。

1. 为什么 Llama 模型接入前要先做一组系统化测试

1.1 Llama 模型测试的三条主线

Llama 模型从下载到生产可用的路径，可以拆成三条主线：推理链路、能力表现、工程可靠性。

推理链路决定模型能不能在目标环境里运行起来。这部分要验证的包括：模型文件是否完整、量化格式是否被推理框架支持、显存或内存是否够用、依赖版本是否正确。很多问题都出在这一层，比如 llama.cpp 某个版本只支持特定 GGUF 量化格式，llama-cpp-python 的 wheel 包与 Python 版本不对应，CUDA 版本不匹配导致无法加载 GPU 版本。

能力表现决定模型在你的业务场景中“好不好用”。这包括基础问答质量、指令遵循能力、长文本处理能力，以及近年来很受关注的工具调用能力。工具调用测试尤其特殊，因为模型是否调用工具，不仅要看输出是否符合 JSON 格式，还要看参数是否正确、调用时机是否正确。

工程可靠性决定模型能否长期稳定运行。单次推理通过不代表并发场景稳定，内存占用会随上下文长度增长，显存不足时可能出现 OOM，长时间运行后速度可能退化。这些都需要通过重复请求、长上下文、并发测试来暴露。

这三条主线不能混在一起测。模型加载不起来，谈不上能力测试；能力测试不稳定，性能测试结果也没有意义。所以测试要有顺序：先打通链路，再做能力验证，最后做工程压测。

1.2 测试结果如何影响部署决策

系统化测试最终要产出可量化的结论。比如：

• 在 8GB 显存环境下，Q4_K_M 量化模型能否连续处理 50 轮对话而不 OOM。
• 同一件事在 Q4_K_M 与 Q8_0 下，回答的格式准确率相差多少。
• 使用 LlamaFactory 微调后，测试集上的指令遵循准确率是否真的提升。
• 工具调用成功率是否达到业务要求，达不到时是加示例还是换量化档位。

这些结论会直接决定部署方案。如果 Q4_K_M 的工具调用成功率明显低于 Q8_0，那就需要评估显存成本与准确率的取舍。如果微调后基础能力下降，就需要检查数据格式、训练轮次或参数设置。如果并发测试不通过，就不能贸然启动多路请求，需要先加限流、排队或换更大的显存实例。

2. 搭建 Llama 测试环境：llama.cpp 与 Python 绑定的版本匹配

2.1 测试环境的目标：先跑通最小推理链路

测试 Llama 模型，最常用的本地推理方案是 llama.cpp。它体积小、CPU 和 GPU 都能运行、GGUF 量化格式支持好，并且提供 Python 绑定 llama-cpp-python。测试环境的第一步，是跑通“加载模型 -> 输入 prompt -> 得到输出”的最小链路。

推荐的环境结构如下：

llama-tests/ ├── models/ # 存放 GGUF 模型文件 ├── scripts/ │ ├── quant_eval.py # 量化效果测试脚本 │ ├── tool_call_test.py # 工具调用测试脚本 │ └── perf_test.py # 性能测试脚本 ├── data/ │ ├── eval_prompts.json # 评估 prompt 集 │ └── tool_cases.json # 工具调用测试用例 └── logs/ # 测试日志

这个目录结构不需要完全照搬，但建议从第一天就按“模型、脚本、数据、日志”分开存放。后续测试时，日志和结果便于归档，模型文件不会因为误操作而反复下载。

2.2 编译 llama.cpp 与安装 llama-cpp-python

llama.cpp 的安装有两种路径：一是直接编译原生程序，二是通过 Python 包。作为测试流程，建议两者都准备。原生程序用于跑量化评估和基准性能；Python 绑定用于写自动化测试脚本。

先编译 llama.cpp：

git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release cmake --build . --config Release -j $(nproc)

这里GGML_CUDA=ON表示启用 CUDA 后端。如果你的机器只有 CPU，可以去掉这个参数。编译完成后，重点检查build/bin目录下是否生成了llama-cli、llama-server、llama-bench等可执行文件。

接着安装 Python 绑定。需要先创建虚拟环境，避免依赖污染：

python -m venv .venv source .venv/bin/activate pip install llama-cpp-python

如果你的环境需要使用 GPU，常见做法是在安装时指定额外索引或设置环境变量。例如，通过专用预编译索引安装支持 CUDA 的版本：

CMAKE_ARGS="-DGGML_CUDA=on" pip install llama-cpp-python

也可以直接使用预编译 wheel 包。此时要注意 wheel 名称中的标签，下面单独说明。

2.3 验证 Python 绑定版本与 CUDA/Python 版本的对应关系

llama-cpp-python 的预编译 wheel 名称中通常会包含 Python 版本和 CUDA 版本信息。比如某个文件名中出现cp313，说明它对应 Python 3.13；出现cu128，说明对应 CUDA 12.8。如果你的环境是 Python 3.11 + CUDA 12.4，却安装了一个cp313的包，导入时大概率会报错或找不到llama_cpp模块中的符号。

安装前先确认三件事：

安装后，用一段最小代码验证能否真正加载模型：

from llama_cpp import Llama llm = Llama( model_path="models/llama-3-8b-instruct.Q4_K_M.gguf", n_ctx=4096, n_gpu_layers=-1, verbose=False, ) output = llm( "用一句话解释什么是量化。", max_tokens=128, temperature=0.7, ) print(output["choices"][0]["text"])

这里的关键参数是n_ctx和n_gpu_layers。n_ctx控制上下文长度，测试环境可以先设 4096，生产环境再按业务对话轮次评估。n_gpu_layers=-1表示尽可能将所有层加载到 GPU，显存不足时可以改成部分层数，例如 20，让部分层留在 CPU。

注意：pip show只能说明包安装了，不能说明包能正常用。如果首次加载模型时卡住或崩溃，优先检查 wheel 标签中的cp与cu系列是否匹配当前环境。

3. 量化测试：k-quant 算法选型与效果评估

3.1 从全精度到量化，为什么测试不能只看显存占用

Llama 原始权重通常是 FP16 或 BF16，推理时显存占用很高。量化把权重从较高精度映射到较低精度，例如从 16 bit 到 4 bit，目的是降低显存占用和推理带宽。模型越小，部署越容易，但量化会带来信息损失，直接表现为回答质量下降、格式不稳定、逻辑出错。

所以量化测试不能只看“能不能加载”，要通过同一组问题对比不同量化级别的输出质量。测试对象一般是 GGUF 模型，而 GGUF 量化中最常遇到的就是 k-quant 系列。

3.2 常见 k-quant 量化级别对比

k-quant 是一组以张量重要性为参考的非均匀量化方法。它并不是简单地把每个权重都压到相同 bit 数，而是结合权重对模型输出整体影响的敏感度，分配不同的量化精度。常见的 GGUF 量化级别包括：

这里要注意“K_M”“K_S”这类后缀。K_M 表示中等大小，K_S 表示更小体积。同一基座模型，不同后缀由模型内部张量的量化计划决定，不能只看文件名里的数字。

3.3 量化测试的最小脚本与结果判读

量化对比测试的核心思路是：准备一组有确定答案或明确格式要求的 prompt，分别加载不同量化级别的模型，记录输出，再按规则打分。

先准备评估 prompt 集。建议使用 JSON 文件保存：

[ { "id": "math_01", "category": "math", "prompt": "一个长方形的长是 8，宽是 6，面积是多少？只输出数字。", "expected": "48" }, { "id": "extract_01", "category": "extract", "prompt": "从这句话中提取日期：项目计划在2025年6月30日发布。只输出日期。", "expected": "2025-06-30" }, { "id": "format_01", "category": "format", "prompt": "把下面内容输出为 JSON，包含 name 和 age 两个字段：张三，25 岁。", "expected": "JSON object" } ]

然后写一个脚本，对同一个模型的不同量化文件分别执行：

import json from llama_cpp import Llama model_paths = [ "models/llama-3-8b-instruct.Q4_K_M.gguf", "models/llama-3-8b-instruct.Q5_K_M.gguf", "models/llama-3-8b-instruct.Q8_0.gguf", ] with open("data/eval_prompts.json", "r", encoding="utf-8") as f: cases = json.load(f) for model_path in model_paths: print(f"\n==== {model_path} ====") llm = Llama(model_path=model_path, n_ctx=4096, n_gpu_layers=-1, verbose=False) for case in cases: output = llm(case["prompt"], max_tokens=256, temperature=0.2) text = output["choices"][0]["text"].strip() print(f"{case['id']}: {text}") del llm

在这个脚本中，temperature=0.2是为了减少随机性，让对比结果更稳定。判读时不要只看回答内容是否一样，要按“是否满足预期格式”来打分。比如“只输出数字”的用例，如果模型输出了一段解释再带出数字，即使在文本上包含正确答案，也应该记作格式失败。

实际测试中，同一模型在不同量化级别上的格式稳定性通常会有差异。Q8_0 的格式稳定性一般高于 Q4_K_M，但显存占用和速度也更高。最终选型要以业务容忍度为标准：如果你的场景需要严格 JSON 输出，那么量化级别就不能盲目选最低档。

3.4 量化测试的常见坑

量化测试看起来只是换文件，实际有几个容易踩的坑。

第一个坑：直接用不同来源的 GGUF 对比。不同发布者制作 GGUF 的量化方式、校准数据、元信息可能不一致。对比时尽量使用同一个发布来源、同一基座版本的 GGUF 文件，否则差异无法归因于量化级别。

第二个坑：忽略 prompt 格式差异。同一模型的不同量化文件通常要求相同的模板，但如果你用的是其他模型生成的对话模板，会导致输出质量明显下降，误判为量化损失。测试前先确认模型对应的 system prompt 和模板。

第三个坑：只测单条回答，不测统计结果。单个 prompt 输出好坏不能说明量化级别优劣。至少要准备 20 到 50 条覆盖不同类别的用例，统计通过率，才能得出可靠结论。

4. 工具调用测试：验证 Llama 是否真的会调用工具

4.1 工具调用测试的边界：会写 JSON 不等于会调用

工具调用是 Llama 模型在 Agent 场景中的核心能力。模型需要识别“当前问题需要调用工具”，产出包含工具名称和参数的结构化输出，再由你的代码解析并执行真实函数。

这里最容易出现的误判是：模型输出了一段 JSON，你就认为它“会调用工具”。实际上工具调用测试要覆盖更完整的一条链路：模型是否知道何时调用、是否选了正确的工具、参数是否匹配工具定义、调用返回结果后模型能否继续回答。

4.2 设计一组工具调用测试用例

工具调用测试用例应该包括：不需要调用工具的普通问题、需要调用单工具的问题、需要调用多工具的问题、参数缺失或含有多余信息的问题。

下面是一组可以落地的用例：

[ { "id": "tool_no_call_01", "description": "普通问题，不应该调用工具", "prompt": "解释一下什么是量子纠缠。", "expected_action": "no_call" }, { "id": "tool_call_weather_01", "description": "查询北京天气，调用 get_weather", "prompt": "北京现在天气怎么样？", "expected_action": "call", "expected_tool": "get_weather", "expected_params": {"city": "北京"} }, { "id": "tool_call_time_01", "description": "查询时间，调用 get_current_time", "prompt": "现在北京时间几点？", "expected_action": "call", "expected_tool": "get_current_time", "expected_params": {} } ]

“不需要调用工具却调用”和“需要调用工具却不调用”都属于失败。所以在写测试用例时，要明确预期行为，而不是只会检查是否包含某个函数名。

4.3 测试脚本：从 prompt 到函数执行的回环验证

工具调用测试最重要的一步是真正执行工具，而不是只解析输出。以天气查询工具为例，先定义工具：

def get_weather(city: str): weather_map = { "北京": "晴，25摄氏度，微风", "上海": "多云，28摄氏度，东南风3级", } return weather_map.get(city, "暂无天气数据")

然后，在测试脚本中把工具定义注入 prompt，让模型生成结构化调用结果。由于不同模型对工具调用的格式要求不同，下面给出一种通用思路，实际需要按 llama.cpp 的版本和模型模板调整：

import json from llama_cpp import Llama tool_schema = { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } } } llm = Llama(model_path="models/llama-3-8b-instruct.Q4_K_M.gguf", n_ctx=4096) prompt = """你是智能助手。如果需要查询天气，请调用 get_weather 工具。 工具定义： {json.dumps(tool_schema, ensure_ascii=False)} 当前问题：北京现在天气怎么样？ 请给出你的回答。""" output = llm(prompt, max_tokens=512, temperature=0.2) text = output["choices"][0]["text"] print(text)

这里的关键是“工具定义”要以足够规范的文本进入上下文。如果模型输出中包含明显的 JSON 片段，下一步就是解析 JSON，根据name字段执行函数，再把执行结果回填给模型，让模型生成面向用户的最终回答。这个“模型调用 -> 工具执行 -> 结果回填 -> 模型总结”的闭环，才是真正完整的工具调用测试。

llama.cpp 在不同版本中逐步完善了工具调用支持，但不同版本的约束差异很大。测试时不要只依赖一种 prompt 格式，应该针对模型和框架版本准备至少两套格式，比如一套纯文本描述，一套 JSON Schema 描述，然后比较哪种格式更稳定。

4.4 工具调用失败时的失败模式与修正方向

工具调用测试中最常见的失败模式有这几类：

• 模型直接回答“我不知道天气”，不调用工具。原因可能是工具描述不够清晰，或者模型本身工具调用能力弱。
• 模型生成 JSON 但字段名与工具定义不一致。例如把city写成location。这时需要检查 prompt 中的工具定义是否足够明确，以及是否提供了少样本示例。
• 模型在普通问题上也强行调用工具。通常是因为工具描述过于宽泛，比如工具描述里写了“当用户提出任何问题时可调用”，模型就会误用。
• 调用参数类型错误。比如工具要求city是字符串，模型却生成数组。这种情况要降低temperature，并在参数描述中注明“必须是字符串”。

注意：工具调用测试必须区分“模型能力问题”和“提示词模板问题”。换 prompt 后成功率提升，不代表模型本身差，而可能只是之前的格式不符合模型预期。排查时先换 prompt，再换量化级别，最后才评价模型能力。

5. 微调评估测试：用 LlamaFactory 验证微调前后效果

5.1 LlamaFactory 在测试流程中的定位

LlamaFactory 是一个用于大模型微调的开源工具，支持 LoRA、QLoRA、全参微调等多种方案。当基础 Llama 模型在业务场景表现不足时，团队通常会先收集数据，再用 LlamaFactory 做微调。这时就需要一套“微调前后对比”的评估流程，确认微调确实带来了提升。

微调测试不能只看训练 loss。loss 下降只说明模型在训练数据上拟合更好，不代表目标任务表现更好。更可靠的方式是准备一个与业务分布一致的测试集，在微调前后分别跑一遍，统计指标变化。

5.2 微调后评估的最小流程

使用 LlamaFactory 微调，通常需要准备一套数据集。以指令微调为例，数据格式可以使用 Alpaca 风格：

[ { "instruction": "判断这句话的情感倾向。", "input": "这个产品太差了，下次不会回购。", "output": "负面" } ]

然后通过 LlamaFactory 命令行启动训练。下面是常见的训练命令示例，具体参数需要根据模型大小和显卡情况调整：

llamafactory-cli train \ --model_name_or_path meta-llama/Llama-3-8B-Instruct \ --dataset_dir data \ --dataset sentiment_dataset \ --finetuning_type lora \ --output_dir outputs/llama3-sentiment-lora \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --learning_rate 1e-4 \ --lora_rank 8 \ --lora_alpha 16 \ --save_strategy epoch \ --logging_steps 10

训练完成后，不能直接用 LoRA 文件和原始模型比较。需要先导出合并后的模型权重，或者使用支持 LoRA 的推理方式加载。LlamaFactory 也提供导出命令：

llamafactory-cli export \ --model_name_or_path meta-llama/Llama-3-8B-Instruct \ --adapter_name_or_path outputs/llama3-sentiment-lora \ --template llama3 \ --export_dir outputs/llama3-sentiment-merged \ --export_size 4

导出后，将合并模型转换成 GGUF 或在原框架里测试，再和微调前的模型跑同一组评估 prompt。

5.3 用测试集对比微调前后结果

微调评估要有一个明确的评分标准。以情感分类为例，评估脚本可以这样写：

import json from llama_cpp import Llama eval_cases = [ {"input": "这家餐厅的服务很好，菜也好吃。", "label": "正面"}, {"input": "等了一个小时还没上菜，体验很差。", "label": "负面"}, {"input": "味道一般，服务还行。", "label": "中性"}, ] model_paths = [ "models/llama-3-8b-instruct.Q4_K_M.gguf", "models/llama-3-sentiment.Q4_K_M.gguf", ] for model_path in model_paths: llm = Llama(model_path=model_path, n_ctx=4096, n_gpu_layers=-1) correct = 0 for case in eval_cases: prompt = f"请判断情感倾向，只输出“正面”“负面”或“中性”。\n输入：{case['input']}" output = llm(prompt, max_tokens=8, temperature=0) answer = output["choices"][0]["text"].strip() if answer == case["label"]: correct += 1 print(f"{case['input']} -> 预测: {answer}, 真实: {case['label']}") print(f"准确率: {correct / len(eval_cases):.2%}")

这个脚本只是一个起点。真实评估需要至少 50 到 100 条样本，且样本不能和训练数据重叠。准确率之外，还要关注模型是否在微调后失去原有通用能力，比如变得只会分类、无法做普通问答。因此测试集里也要包含通用指令用例，防止“灾难性遗忘”。

5.4 微调评估中的常见误判

微调评估最常见的问题是把“训练集准确率”当成模型效果。训练集里的表现不能代表泛化能力，必须用独立测试集。

第二个问题是测试 prompt 不统一。微调前使用 A 模板，微调后使用 B 模板，准确率变化就无法解释。所有对比测试必须使用同一套 prompt 模板、同一个采样温度、相同的上下文长度。

第三个问题是没有把 LoRA 适配器正确加载。如果只加载了原始模型，微调后的评估结果自然没有提升。

第四个问题是忽略量化后效果。使用 LlamaFactory 做微调时通常得到的是全精度或半精度权重，但下游部署经常转成 4 bit GGUF。微调提升可能在生产环境和基础模型对比时被量化损失抵消。正确的做法是：先在同一量化档位下对比微调前后效果，再决定是否需要调整量化级别。

6. 性能与稳定性测试：从单次推理到压测

6.1 需要采集的指标

性能测试要采集的不仅仅是首 token 延迟。建议至少记录以下指标：

单次推理的这些指标只能反映最低性能。要评估部署可行性，还需要做多轮、多并发、长上下文的稳定性测试。

6.2 性能测试脚本

llama.cpp 自带了llama-bench，适合快速测试基础性能。例如：

./build/bin/llama-bench \ -m models/llama-3-8b-instruct.Q4_K_M.gguf \ -ngl 999 \ -n 128 \ -t 8

-ngl 999表示把全部层放到 GPU，-n 128表示生成 128 个 token，-t 8表示使用 8 个 CPU 线程。输出会给出 prompt processing 和 generation 两个阶段的性能。

但llama-bench只是原生程序，不能完全代表 Python 应用中的表现。因此还需要在 Python 侧写一个简单的链路测试：

import time from llama_cpp import Llama llm = Llama(model_path="models/llama-3-8b-instruct.Q4_K_M.gguf", n_ctx=8192) def run_case(prompt, max_tokens=256): start = time.time() output = llm(prompt, max_tokens=max_tokens, temperature=0.7) elapsed = time.time() - start text = output["choices"][0]["text"] token_count = len(text) return { "elapsed": elapsed, "token_count": token_count, "tok_per_sec": token_count / elapsed, "text": text[:50] } prompts = ["什么是大语言模型？"] * 5 for i, prompt in enumerate(prompts): result = run_case(prompt) print(f"round {i}: {result['tok_per_sec']:.2f} tok/s, elapsed {result['elapsed']:.2f}s")

这段脚本可以继续扩展成“每轮输出长度相同、温度相同、重复 N 次”的形式，用来观察速度是否随轮次退化。

6.3 稳定性测试重点

稳定性测试的重点是找出资源泄漏和上下文长度问题。要特别注意以下几个方面：

• 长时间连续请求后，显存是否持续增长。如果每轮请求后显存不释放，通常意味着上下文管理或历史消息拼接存在问题。
• 同一 prompt 在相同参数下是否会出现不稳定输出。如果温度设为 0，输出应该相对稳定。如果仍然明显波动，需要检查量化模型或采样参数。
• 长上下文的性能退化。把历史对话累积到 4096、8192 token 时，首 token 延迟会明显增长，这属于正常现象，但如果超过业务可接受范围，就需要限制上下文长度或使用摘要压缩。
• 并发请求时是否发生线程安全或 OOM。llama-cpp-python 在单个Llama实例上的并发访问需要额外小心，测试过程中如果出现崩溃，优先查看日志中的段错误和 CUDA 错误。

注意：稳定性测试失败时，先复现最小场景。例如每次只加一轮历史消息，观察显存增量。不要在大并发场景下同时排查，否则很难定位是哪一层导致的问题。

7. 常见问题排查：Llama 测试链路中的高频故障

7.1 安装与导入类问题

现象是执行import llama_cpp时报错，例如找不到.so文件、ImportError: libcuda.so.1，或者undefined symbol。

排查顺序先确认 Python 版本。使用python --version查看解释器版本，再通过pip show llama-cpp-python查看安装的 wheel 标签。如果标签是cp313，而当前 Python 是 3.10，包就不应该正常安装。如果确实安装了，可能是因为 pip 没有匹配到正确的二进制，选择了源码编译或错误标签。

再确认 CUDA 版本。nvidia-smi显示的 CUDA 版本是驱动支持的版本，不等于 PyTorch 或 llama.cpp 使用的 CUDA Runtime 版本。如果 wheel 标签是cu128，而驱动只支持 CUDA 11.8，通常会报找不到 CUDA 库。

处理建议是先卸载重装，再指定正确的安装方式：

pip uninstall llama-cpp-python -y CMAKE_ARGS="-DGGML_CUDA=on" pip install llama-cpp-python --force-reinstall --no-cache-dir

如果只需要 CPU 测试，也可以先安装纯 CPU 版本：

CMAKE_ARGS="-DGGML_CUDA=off" pip install llama-cpp-python --force-reinstall --no-cache-dir

7.2 量化与精度类问题

现象是 Q4_K_M 模型加载后回答明显乱码，或者同一个问题换 Q8_0 后质量明显更好，怀疑是量化级别导致模型退化。

排查时先排除 GGUF 文件损坏。重新计算文件哈希，与下载来源的哈希值比对。接着确认模型是否是指令版。如果是 Base 模型，普通对话模板不适用，输出就可能像乱码。还需要确认n_ctx是否过小，上下文不足时，长 prompt 会截断输入，导致回答对不上问题。

量化精度问题需要做统计对比，不能只看一两个例子。准备至少 20 条结构化输出用例，统计格式正确率，再决定是否上调量化级别。

7.3 工具调用与微调评估类问题

工具调用测试出现“不调用”“调用错误工具”“参数格式错误”时，处理顺序如下：

1. 把temperature调低到 0，排除随机性影响。
2. 在 prompt 中补充少样本示例，例如给出“查询北京天气”对应的正确 JSON 输出。
3. 把工具描述简化，避免过长的参数描述干扰模型决策。
4. 换一个对话模板，检查系统提示是否在流式输出中被忽略。

LlamaFactory 微调后效果不理想，优先检查数据格式是否与模板匹配，训练轮次和learning_rate是否适合任务，以及评估时是否使用了独立的测试集。如果数据量很少，比如只有几十条，建议先提高数据质量，再调整训练参数。

8. 可复用的 Llama 测试清单与实践建议

8.1 测试前置环境检查清单

每次开始 Llama 测试前，可以先过一遍下面的清单：

8.2 测试执行顺序建议

推荐按下面的顺序执行测试，不要跳步：

1. 加载测试：模型能否完成一次最小推理。
2. 量化对比：在多个量化级别下跑同一组评估集，确定质量基线。
3. 能力测试：完成工具调用、指令遵循、格式化输出等专项用例。
4. 微调对比：如果涉及微调，用同一测试集评估微调前后效果。
5. 性能测试：记录首 token 延迟、生成速度、显存占用。
6. 稳定性测试：重复请求、长上下文、并发场景。

每一步的结果都要记录。建议用一个简单的 CSV 或表格记录模型路径、量化级别、测试集版本、通过率和性能数据。后续对比方案时，这份记录比任何口头结论都有用。

8.3 下一步扩展方向

完成基础测试后，可以根据业务需要继续扩展。

• 如果在工具调用测试中频繁失败，可以尝试为模型增加工具调用少样本集合，或者使用专门针对 function calling 微调过的模型。
• 如果显存紧张，测试重点可以放在不同 k-quant 档位的质量损失趋势上。不要一次性测完所有档位，先测 Q4_K_M 和 Q8_0，确认差距后可接受，再细化到 Q5_K_M。
• 如果使用 LlamaFactory 微调，建议把评估脚本接入训练流程，在每次 epoch 后自动跑同一组用例，持续观察指标变化。
• 如果模型要作为 Agent 底座，建议把工具调用测试用例扩展到多轮对话：模型第一轮调用工具，拿到结果后，第二轮继续追问，验证模型能否结合工具结果继续决策。

Llama 模型测试并不需要一次性做到极致，但要保证每个阶段都有明确的验证标准。先让链路跑通，再逐步把能力测试、量化对比、微调评估和稳定性压测补充进来。这样无论模型是开源社区的现成权重，还是团队内部微调后的专用模型，都能在接入生产前得到一份可靠的测试结论。