README.md

5.7 在你自己的机器上测速：单流、并发、两种量化

这份代码回答三个问题。一个小模型在你的机器上一路能跑多快；同时来好几路请求时，每一路慢多少、总共能出多少 token；同一个模型的两种量化（4-bit 和 8-bit）速度差多少。宣传里的 tok/s 往往只报其中一个数，这份代码把它们放在一张表里。

做法：起一个本地推理服务，同时发 1、4、8、16 路请求（显卡上再加 32 路）。每个请求约 800 token 输入，让模型从 1 往上数数，用 max_tokens 卡在 256 个输出 token，保证每一路的活一样多。记三个数：首 token 延迟、每一路的生成速度、所有路加起来每秒出多少 token。

有两个脚本：

• bench.py：对任何兼容 OpenAI 接口的本地服务测速，llama.cpp 的 llama-server、vLLM 都可以。
• bench_mlx.py：Mac 上的 MLX，直接在 Python 进程里调 mlx-lm 测，输出同样的表。

模型都是 Qwen3.5-2B（后训练版，关闭思考模式）。

需要什么设备

• Apple Silicon Mac：llama.cpp 和 MLX 都能跑，8 GB 内存够用。
• 一张 NVIDIA 显卡：llama.cpp（CUDA 版）和 vLLM 都能跑；vLLM 需要 Linux（或 WSL2），8 GB 显存够用。

安装与运行

cd 5_7_local_speed
uv venv && source .venv/bin/activate       # 没有 uv 就用 python3 -m venv .venv
uv pip install -r requirements.txt         # 只有 httpx

llama.cpp（Mac 或 NVIDIA）。 Mac 上 brew install llama.cpp；NVIDIA 显卡按 llama.cpp 仓库的说明编译 CUDA 版。-np 是服务能同时处理几路，要不小于你测的最大并发：

llama-server -hf unsloth/Qwen3.5-2B-GGUF:Q4_K_M --no-mmproj -ngl 99 -c 65536 -np 16 --port 8080
python bench.py --url http://127.0.0.1:8080 --label "llama.cpp Q4_K_M"
# 停掉服务，换成 Q8_0 再测一遍
llama-server -hf unsloth/Qwen3.5-2B-GGUF:Q8_0 --no-mmproj -ngl 99 -c 65536 -np 16 --port 8080
python bench.py --url http://127.0.0.1:8080 --label "llama.cpp Q8_0"

MLX（Mac）。

uv pip install mlx-lm
python bench_mlx.py --model mlx-community/Qwen3.5-2B-4bit --label "MLX 4bit"
python bench_mlx.py --model mlx-community/Qwen3.5-2B-8bit --label "MLX 8bit"

vLLM（NVIDIA，Linux）。 两种精度：原始的 bf16，和 vLLM 在加载时把权重转成的 FP8：

uv pip install vllm
vllm serve Qwen/Qwen3.5-2B --port 8000 --max-model-len 4096 --language-model-only
python bench.py --url http://127.0.0.1:8000 --label "vLLM bf16" --concurrency 1 4 8 16 32
vllm serve Qwen/Qwen3.5-2B --port 8000 --max-model-len 4096 --language-model-only --quantization fp8
python bench.py --url http://127.0.0.1:8000 --label "vLLM fp8" --concurrency 1 4 8 16 32

每次结果打印成一张表，同时存进 results/。

该看到什么

我们的样例输出在 sample_output/（2026-10-23）。Mac Studio（M3 Ultra）上的结果，每格是“每一路的生成速度 / 所有路加起来”，单位 token/秒：

一张 RTX 5090（32 GB）上的结果，同样是“每一路 / 所有路加起来”：

几个现象：

• 单流速度和总吞吐是两个数。 在 Mac 上，并发从 1 路加到 16 路，每一路都变慢了（MLX 4-bit 从 272 降到 87），但总共出的 token 涨到将近 4 倍（244 到 923）；在显卡上用 vLLM，从 1 路到 32 路总吞吐涨到 18 倍（309 到 5,647）。只报单流速度会低估一台机器能服务多少人，只报总吞吐会让人以为每个用户都能拿到那么快的速度。
• 首 token 延迟随并发上涨。 同时进来的请求要排队做 prefill，16 路时 llama.cpp 的首 token 延迟从 0.17 秒涨到 2.7 秒。
• 4-bit 不一定比 8-bit 快。 单流时 4-bit 快（权重少、读内存少）；在 llama.cpp 上，并发到 4 路以后 Q8_0 反而比 Q4_K_M 快。常见的解释是：并发高了以后瓶颈从读权重转向计算，而 4-bit 权重每次用之前都要先解压，多出来的计算抵掉了少读内存的好处。我们没有单独验证这个解释。
• 推理栈决定了并发时的表现。 在显卡上，单流最快的是 llama.cpp Q4_K_M（每秒 490 token），比 vLLM 还快；但 llama.cpp 的总吞吐到 8 路就停在每秒 880 左右，再加并发只是把每一路摊薄，32 路时每路只剩 39，首 token 延迟涨到 2.6 秒。vLLM 每一路掉得很慢，32 路时每路还有 226–254，总吞吐到每秒 5,600–6,100，首 token 延迟 0.3 秒。一个人用和给一群人提供服务，该选的推理栈不一样。
• 显卡上的 FP8 在每个并发档都比 bf16 快（单流 390 对 323，32 路 6,073 对 5,647），因为要读的权重少了一半，5090 也有原生的 FP8 计算单元。
• 同一个模型，不同推理栈差很多。 同样在 Mac 上、同样 4-bit 左右，MLX 的总吞吐是 llama.cpp 的 2.5 倍左右。我们也试过 mlx-lm 自带的 HTTP 服务（mlx_lm.server，0.32.2 版），单流只有 41–74 token/秒，并发 8 路时直接拒绝连接；所以 MLX 用 bench_mlx.py 在进程里测，这测的是引擎本身。实际部署时，服务层同样会吃掉速度。

这些数字只说明“能跑多快”，不说明量化后质量掉了多少。量化对质量的影响，看公开的评测（正文 5.7 有引用），或者在你自己的任务上跑一遍对比。

换成你自己的数据

换模型：llama.cpp 换 -hf 后面的 GGUF 仓库和量化名，MLX 换 --model，vLLM 换 serve 后面的模型名。换负载：--max-tokens 改输出长度；想测长输入，改 bench.py 里的 FILLER（现在约 800 token）。--concurrency 改成你预计的同时在线人数。最该测的是你实际会用的组合：你会部署的那个推理栈、你会用的量化、你预计的并发。