在本地部署和运行大语言模型（LLM）时，性能是开发者最关心的问题之一。尤其是在资源相对有限的个人电脑上，如何选择模型、配置工具，才能获得流畅的推理体验？本文将以 Apple Silicon Mac（M1/M2/M3 系列芯片）为测试平台，结合 Ollama 这一流行的本地模型运行框架，通过实测数据，为你揭示不同模型在不同配置下的真实推理速度。我们将从环境搭建、基准测试方法讲起，逐步分析量化方式、上下文长度、批处理大小等因素对速度的影响，并提供完整的测试代码和数据分析脚本。无论你是想为自己的项目选型，还是单纯好奇 Mac 跑 LLM 的极限，这篇文章都将提供一份详实、可复现的参考指南。
1. 背景与核心概念：为什么要在 Apple Silicon 上测 LLM 速度？
在深入测试之前，我们有必要厘清几个关键概念和本次测试的意义。
LLM 推理指的是使用已经训练好的大语言模型，根据输入的文本（提示词）生成输出文本的过程。这个过程需要消耗大量的计算资源，尤其是内存带宽和浮点算力。推理速度通常以“每秒生成的令牌数”（Tokens Per Second, TPS）来衡量，这是评估模型实用性的核心指标。
Apple Silicon（M1, M2, M3 系列）芯片采用了统一的内存架构（Unified Memory Architecture, UMA），使得 CPU、GPU 和神经网络引擎（Neural Engine）能够高效地共享同一块内存。这种设计极大地减少了数据搬运的开销，对于内存密集型的大模型推理任务来说，是一个潜在的优势。然而，与顶级 NVIDIA 独立显卡相比，其绝对算力和显存容量仍有差距。因此，在 Mac 上运行 LLM，更像是在“有限预算”下寻求“最佳体验”的优化艺术。
Ollama是一个开源工具，它极大地简化了在本地（尤其是 macOS 和 Linux 上）运行大语言模型的过程。它负责模型的下载、加载、并提供简单的 API 接口。Ollama 针对 Apple Silicon 做了原生优化，能够自动利用 GPU（通过 Metal Performance Shaders）来加速模型计算，是 Mac 用户进行本地 LLM 实验的首选工具。
那么，进行速度测试的价值何在？对于开发者而言，它可以帮助你：
- 模型选型：在效果（能力）和效率（速度）之间找到平衡点。一个 70 亿参数的模型可能比 130 亿参数的模型快一倍，但能力是否够用？
- 配置调优：了解如何设置 Ollama 的参数（如量化等级、上下文长度）来最大化性能。
- 成本评估：在考虑本地部署而非调用云端 API 时，量化评估自身硬件的能力边界。
- 技术验证：验证新的芯片、驱动或 Ollama 版本是否带来了性能提升。
接下来，我们将从零开始，搭建测试环境，设计科学的测试方法，并呈现多组实测数据。
2. 环境准备与版本说明
为了确保测试结果的可复现性，以下是本次基准测试所使用的基础环境。你的实际速度可能因系统负载、散热条件、具体芯片型号（如 M1 Pro vs M3 Max）而有差异，但方法论和相对趋势是通用的。
操作系统与硬件：
- 机型：Apple MacBook Pro (2023)
- 芯片：Apple M2 Max
- 内存：64 GB 统一内存
- 操作系统：macOS Sonoma 14.4.1
核心软件工具：
- Ollama：版本
0.1.34。这是运行模型的核心工具。你可以通过其官网或 Homebrew 安装。 - Python：版本
3.11。用于编写测试脚本和数据分析。 - Python 库：
requests: 用于调用 Ollama 的 API。time: 用于精确计时。pandas和matplotlib: 用于数据处理和可视化（分析阶段使用）。
安装 Ollama： 如果你尚未安装，可以通过以下命令（使用 Homebrew）或从官网下载安装包。
# 使用 Homebrew 安装 brew install ollama # 启动 Ollama 服务（通常安装后会自动启动） ollama serve # 在另一个终端窗口，拉取一个测试模型，例如 Llama 2 7B ollama pull llama2:7b测试模型列表： 我们将测试几个具有代表性的开源模型，覆盖不同的参数量级和量化级别。模型标识符遵循ollama pull <model-name>的格式。
llama2:7b： 70 亿参数，FP16 精度，作为基线。llama2:7b-q4_0： 70 亿参数，4-bit 整数量化（一种常见的量化方法）。llama2:13b： 130 亿参数，FP16 精度。llama2:13b-q4_0： 130 亿参数，4-bit 整数量化。mistral:7b： Mistral 7B 模型，以其高效率著称。mistral:7b-q4_0： Mistral 7B 的 4-bit 量化版。codellama:7b： Code Llama 7B，专注于代码生成。
重要提示：模型性能与 Ollama 版本、macOS 版本和 Metal 驱动紧密相关。建议保持这些组件更新至稳定版本以获得最佳性能。
3. 测试方法论与核心指标拆解
一个严谨的基准测试需要控制变量，并明确定义测量指标。我们的测试将围绕以下几个核心维度展开。
3.1 核心性能指标：Tokens Per Second (TPS)
这是最直观的指标，计算公式为：TPS = (生成的令牌总数) / (生成阶段耗时)
- 生成阶段耗时：特指模型接收完提示词后，开始输出第一个令牌到输出结束的时间。这排除了模型加载、提示词编码（prefill）的时间，专注于“流式生成”的速度，更能反映交互体验。
- 我们通常报告平均 TPS和峰值 TPS（例如，忽略最开始几个令牌的冷启动）。
3.2 关键变量因素
我们将测试以下因素对 TPS 的影响：
- 模型与量化：对比不同大小、不同量化精度的模型。量化通过降低模型权重的数值精度（如从 FP16 到 INT4）来减少内存占用和计算量，通常会显著提升速度，但可能轻微损失模型质量。
- 上下文长度：测试短上下文（如 512 tokens）和长上下文（如 4096 tokens）下的生成速度。上下文越长，模型需要管理的“工作记忆”越大，可能会影响速度。
- 批处理大小：对于某些支持批处理的场景，一次性处理多个请求可以提高硬件利用率。我们将测试批处理大小为 1 和 2 的情况（在 Mac 上，由于内存限制，批处理通常较小）。
3.3 测试脚本设计思路
我们将编写一个 Python 脚本，通过 Ollama 的生成 API 来执行测试。脚本需要：
- 连接本地 Ollama 服务。
- 为每个测试用例（模型+配置）发送特定的提示词。
- 精确记录生成阶段的耗时。
- 统计生成的令牌数。
- 将原始数据（时间戳、令牌数、配置）保存下来以供分析。
4. 完整实战：构建自动化基准测试工具
下面我们一步步构建测试工具并运行基准测试。
4.1 创建项目结构
首先，创建一个新的目录来存放我们的项目。
mkdir apple-silicon-llm-benchmark && cd apple-silicon-llm-benchmark4.2 编写基准测试脚本
创建一个名为benchmark.py的 Python 文件。这个脚本将完成核心的测试逻辑。
# benchmark.py import requests import time import json import argparse from typing import Dict, List, Any # Ollama API 端点 OLLAMA_API_URL = "http://localhost:11434/api/generate" def run_inference_test(model: str, prompt: str, config: Dict[str, Any]) -> Dict[str, Any]: """ 执行单次推理测试，并返回详细计时结果。 """ payload = { "model": model, "prompt": prompt, "stream": False, # 非流式响应，便于一次性获取所有结果和计时 "options": config # 传入模型配置，如温度、top_p等 } start_time = time.perf_counter() # 高精度计时开始 try: response = requests.post(OLLAMA_API_URL, json=payload, timeout=300) # 设置较长超时 response.raise_for_status() result = response.json() except requests.exceptions.RequestException as e: print(f"请求失败 for model {model}: {e}") return None end_time = time.perf_counter() # 高精度计时结束 # 计算耗时和速度 total_duration = end_time - start_time total_tokens = result.get("response", "").count(' ') + 1 # 简易令牌估算（实际应使用tokenizer） # Ollama 响应中通常包含 `eval_count` 字段，代表生成令牌数，更准确。 eval_count = result.get("eval_count", total_tokens) eval_duration = result.get("eval_duration", 0) / 1e9 # 纳秒转秒，如果API提供 # 优先使用 API 返回的评估时间，否则使用总耗时估算 effective_duration = eval_duration if eval_duration > 0 else total_duration tokens_per_second = eval_count / effective_duration if effective_duration > 0 else 0 return { "model": model, "config": config, "total_duration": total_duration, "eval_duration": effective_duration, "eval_count": eval_count, "tokens_per_second": tokens_per_second, "response_preview": result.get("response", "")[:100] + "..." # 预览前100字符 } def main(): parser = argparse.ArgumentParser(description="运行 Ollama LLM 基准测试") parser.add_argument("--model", type=str, required=True, help="模型名称，如 'llama2:7b'") parser.add_argument("--prompt", type=str, default="请用中文简要解释一下量子计算的基本原理。", help="测试用的提示词") parser.add_argument("--num-runs", type=int, default=3, help="每个配置运行次数，取平均值") parser.add_argument("--ctx-size", type=int, default=2048, help="上下文窗口大小") args = parser.parse_args() # 测试配置：我们可以测试不同的 `num_predict` (生成令牌数) 和温度 test_configs = [ {"num_predict": 128, "temperature": 0.1}, # 短生成，低随机性 {"num_predict": 512, "temperature": 0.1}, # 长生成，低随机性 ] all_results = [] for config in test_configs: config["num_ctx"] = args.ctx_size # 设置上下文大小 run_results = [] for i in range(args.num_runs): print(f"运行 {args.model}，配置 {config}，第 {i+1}/{args.num_runs} 次...") result = run_inference_test(args.model, args.prompt, config) if result: run_results.append(result) time.sleep(2) # 运行间隔，避免过热或资源争用 if run_results: # 计算平均 TPS avg_tps = sum([r['tokens_per_second'] for r in run_results]) / len(run_results) config_summary = { "model": args.model, "config": config, "avg_tokens_per_second": avg_tps, "runs": run_results } all_results.append(config_summary) print(f" 配置 {config} 平均 TPS: {avg_tps:.2f}") # 将结果保存为 JSON 文件 timestamp = time.strftime("%Y%m%d-%H%M%S") filename = f"benchmark_results_{args.model.replace(':', '_')}_{timestamp}.json" with open(filename, 'w', encoding='utf-8') as f: json.dump(all_results, f, indent=2, ensure_ascii=False) print(f"\n详细结果已保存至: {filename}") if __name__ == "__main__": main()4.3 编写批量运行与数据分析脚本
为了自动化测试多个模型，我们创建另一个脚本run_benchmarks.py。
# run_benchmarks.py import subprocess import json import pandas as pd import matplotlib.pyplot as plt import os # 定义要测试的模型列表 MODELS_TO_TEST = [ "llama2:7b", "llama2:7b-q4_0", "mistral:7b", "mistral:7b-q4_0", "llama2:13b", "llama2:13b-q4_0", ] def run_benchmark_for_model(model): """使用 benchmark.py 测试单个模型""" print(f"\n{'='*50}") print(f"开始测试模型: {model}") print(f"{'='*50}") # 确保模型已拉取 # subprocess.run(["ollama", "pull", model], check=False) # 运行基准测试脚本 cmd = ["python", "benchmark.py", "--model", model, "--num-runs", "3", "--ctx-size", "2048"] result = subprocess.run(cmd, capture_output=True, text=True) print(result.stdout) if result.stderr: print("STDERR:", result.stderr) return result.returncode def aggregate_results(): """聚合所有生成的 JSON 结果文件""" result_files = [f for f in os.listdir('.') if f.startswith('benchmark_results_') and f.endswith('.json')] all_data = [] for file in result_files: with open(file, 'r', encoding='utf-8') as f: data = json.load(f) for config_summary in data: model = config_summary['model'] config = config_summary['config'] avg_tps = config_summary['avg_tokens_per_second'] all_data.append({ 'Model': model, 'Quantization': 'Q4_0' if 'q4_0' in model.lower() else 'FP16', 'BaseModel': 'Llama2-7B' if '7b' in model and 'llama' in model else 'Llama2-13B' if '13b' in model and 'llama' in model else 'Mistral-7B' if 'mistral' in model else 'Other', 'CtxSize': config.get('num_ctx', 2048), 'GenLength': config.get('num_predict'), 'Avg_TPS': avg_tps }) df = pd.DataFrame(all_data) # 保存为 CSV 以便用 Excel/Numbers 查看 df.to_csv('aggregated_benchmark_results.csv', index=False) print("\n聚合结果已保存至 'aggregated_benchmark_results.csv'") return df def visualize_results(df): """生成简单的对比图表""" if df.empty: print("没有数据可可视化。") return # 按模型和量化分组，取 GenLength=512 的数据进行主要对比 df_main = df[df['GenLength'] == 512].copy() df_main['Model_Label'] = df_main['BaseModel'] + ' (' + df_main['Quantization'] + ')' plt.figure(figsize=(12, 6)) bars = plt.bar(df_main['Model_Label'], df_main['Avg_TPS'], color=['skyblue', 'lightcoral', 'lightgreen', 'gold', 'violet', 'orange']) plt.xlabel('Model (Quantization)') plt.ylabel('Average Tokens Per Second (TPS)') plt.title('LLM Inference Speed on Apple Silicon (M2 Max, ctx=2048, gen=512)') plt.xticks(rotation=45, ha='right') # 在柱子上显示数值 for bar in bars: height = bar.get_height() plt.text(bar.get_x() + bar.get_width()/2., height + 0.5, f'{height:.1f}', ha='center', va='bottom', fontsize=9) plt.tight_layout() plt.savefig('benchmark_chart.png', dpi=300) plt.show() print("图表已保存为 'benchmark_chart.png'") if __name__ == "__main__": # 第一步：运行所有模型的测试（这可能需要数小时，取决于模型大小和数量） # for model in MODELS_TO_TEST: # run_benchmark_for_model(model) # print("\n所有模型测试完成！") # 第二步：聚合和可视化（假设结果文件已存在） print("正在聚合结果并生成图表...") results_df = aggregate_results() print(results_df.to_string()) # 在终端打印表格 visualize_results(results_df)4.4 运行测试与获取原始数据
在运行测试前，请确保 Ollama 服务正在运行，并且你已经拉取了需要测试的模型。
运行单个模型测试：
# 测试 llama2:7b 模型，运行3次取平均 python benchmark.py --model llama2:7b --num-runs 3脚本会自动运行并将详细结果保存为一个 JSON 文件，例如
benchmark_results_llama2_7b_20231027-143022.json。（可选）批量运行： 如果你有足够的时间和磁盘空间，可以取消
run_benchmarks.py中第 45-46 行循环的注释，运行所有模型测试。请注意，拉取和运行 13B 模型需要大量内存和时python run_benchmarks.py
4.5 实测数据结果与分析
以下是在Apple M2 Max (64GB)上运行上述测试脚本得到的近似结果（数据为多次运行平均值，单位：Tokens/Second）。请注意，这是为了示例而简化的数据，你的实际结果会有所不同。
| 模型 | 量化 | 参数量 | 上下文长度 | 生成长度 | 平均 TPS (≈) |
|---|---|---|---|---|---|
llama2:7b | FP16 | 7B | 2048 | 512 | 18.5 |
llama2:7b-q4_0 | Q4_0 | 7B | 2048 | 512 | 42.3 |
mistral:7b | FP16 | 7B | 2048 | 512 | 22.1 |
mistral:7b-q4_0 | Q4_0 | 7B | 2048 | 512 | 48.7 |
llama2:13b | FP16 | 13B | 2048 | 512 | 9.8 |
llama2:13b-q4_0 | Q4_0 | 13B | 2048 | 512 | 24.5 |
关键发现：
- 量化的巨大影响：4-bit 量化（Q4_0）带来的速度提升是颠覆性的。对于 7B 模型，TPS 提升了2.3 倍以上；对于 13B 模型，提升也超过2.5 倍。这意味着在 Apple Silicon 上，使用量化模型是获得流畅体验的必选项。
- 模型架构差异：同参数量级下，Mistral 7B 在 FP16 和 Q4_0 格式下的速度均略高于 Llama 2 7B，这与其更高效的架构设计（如滑动窗口注意力）有关。
- 参数量与速度的权衡：13B 模型即使经过量化，其速度（~24.5 TPS）也仅与 FP16 的 7B 模型（~18.5 TPS）相当，而远低于量化后的 7B 模型（>42 TPS）。对于大多数本地交互场景，量化后的 7B 模型在速度和能力上提供了更好的平衡。
- 上下文长度影响：在额外测试中，将上下文长度从 512 提升到 4096，所有模型的 TPS 会有 10%-25% 的下降，因为需要管理更大的 KV 缓存。但对于生成长度固定的任务，影响相对可控。
5. 常见问题与排查思路
在本地运行 LLM 基准测试时，你可能会遇到以下问题。
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| Ollama 启动失败或无法连接 | 1. Ollama 服务未运行。 2. 端口 11434被占用。3. 防火墙或安全软件阻止。 | 1. 终端运行ollama serve并查看输出。2. 运行 lsof -i :11434查看端口占用，重启服务或杀死占用进程。3. 检查系统防火墙或安全软件设置。 |
| 拉取模型速度极慢或失败 | 1. 网络连接问题。 2. Docker 镜像源问题（Ollama 底层使用容器）。 | 1. 检查网络，尝试拉取小模型（如tinyllama）测试。2. 对于国内用户，可尝试配置 Docker 镜像加速器，但 Ollama 模型拉取不完全走 Docker，网络环境是关键。 |
| 推理速度远低于预期 | 1. 系统内存压力大，频繁交换（Swap）。 2. 芯片过热降频。 3. 运行了其他高性能应用。 4. 使用了未量化的 FP16 模型。 | 1. 关闭不必要的应用，使用活动监视器检查内存压力。 2. 确保 Mac 通风良好，避免高温环境。 3. 在测试时，尽量保持系统空闲。 4.优先使用量化模型（如 :q4_0后缀）。 |
| 提示“内存不足”（OOM） | 1. 模型过大（如尝试运行 70B 模型）。 2. 上下文长度设置过高。 | 1. 根据你的内存大小选择模型。64GB 内存可尝试 13B-34B 量化模型，32GB 内存建议使用 7B-13B 量化模型。 2. 在 Ollama 运行命令或 API 调用中，减小 num_ctx参数值。 |
| 生成的文本质量差或胡言乱语 | 1. 量化导致的信息损失。 2. 提示词不清晰或温度参数过高。 | 1. 尝试更高精度的量化（如q8_0）或 FP16 模型，权衡速度与质量。2. 优化你的提示词，对于确定性任务，将 temperature设为较低值（如 0.1-0.3）。 |
| Metal GPU 未调用或利用率低 | 1. Ollama 版本过旧。 2. macOS 版本或 Metal 驱动问题。 | 1. 升级 Ollama 到最新稳定版：ollama upgrade。2. 确保 macOS 已更新。运行 ollama run llama2:7b时，观察活动监视器中GPU History，应有明显活动。 |
6. 最佳实践与工程建议
基于以上测试和分析，我们总结出在 Apple Silicon Mac 上部署和优化 LLM 推理的实用建议。
6.1 模型选择策略
- 入门与交互首选：量化后的 7B 模型（如
mistral:7b-q4_0,llama2:7b-q4_0）。它们在 ~40-50 TPS 的速度下能提供相当不错的通用和代码能力，响应延迟低，体验流畅。 - 追求更强能力：如果 7B 模型能力不足，且你拥有 32GB+ 内存，可以尝试量化后的 13B 模型（如
llama2:13b-q4_0）。速度在 ~25 TPS，尚可接受，但能力有显著提升。 - 谨慎尝试更大模型：34B 及以上的模型，即使在量化后，对内存要求也极高（>40GB），且速度会降至 10 TPS 以下，仅适合非实时、批处理任务。
- 特定领域任务：对于代码生成，优先选择
codellama:7b或codellama:13b及其量化版本。
6.2 Ollama 配置优化
- 设置合适的上下文长度：通过
OLLAMA_NUM_CTX环境变量或 API 参数设置。除非处理长文档，否则无需设置为最大值（通常为 4096）。较短的上下文（如 2048）能减少内存占用并可能轻微提升速度。# 启动 Ollama 服务时指定上下文大小 OLLAMA_NUM_CTX=2048 ollama serve - 控制并发：Ollama 默认处理单个请求。虽然支持多个并发请求，但在 Mac 上，过多的并发会因内存带宽争用导致所有请求变慢。生产级并发最好在服务器端处理。
- 使用
stream: false进行基准测试：如我们的脚本所示，非流式响应能更准确地测量完整的生成耗时。但在实际交互应用中，使用stream: true可以实现更快的首字响应。
6.3 系统与硬件调优
- 管理内存：使用活动监视器密切关注内存压力。绿色的“内存压力”图表是理想的。如果出现黄色或红色，请关闭其他应用。
- 散热管理：持续高负载运行会导致芯片降频。在凉爽的环境中使用，并确保笔记本进风口和出风口通畅。对于长时间运行的任务，可以考虑使用散热支架。
- 保持更新：定期更新 Ollama 和 macOS 系统。Apple 和 Ollama 团队会持续优化 Metal 后端的性能。
6.4 开发与集成建议
- API 调用超时设置：在代码中调用 Ollama API 时，务必设置合理的超时时间（如 300 秒），防止因模型生成过长文本导致客户端长期等待。
- 错误处理与重试：网络波动或服务重启可能导致请求失败。实现简单的重试机制和友好的错误提示。
- 结果缓存：对于频繁出现的、确定的提示词（如系统指令、常见问答），可以考虑在应用层对模型的输出进行缓存，避免重复计算。
通过本文的实测数据和方法，你可以科学地评估自己 Mac 的 LLM 推理能力，并做出合理的模型选择和配置决策。本地 LLM 正在快速发展，随着工具链的成熟和模型效率的提升，在个人设备上运行强大的 AI 助手将变得越来越普遍和实用。
