企业官网建设流程全解析

1. 项目概述：为什么今天还值得花时间搞本地大模型部署？

你是不是也经历过这些时刻：在写代码时想让AI帮你补全函数逻辑，但网页版响应慢得像在等泡面；想用私有数据微调一个专属客服模型，却卡在API调用配额和隐私合规的夹缝里；或者手头只有一台Mac Mini M2、一台Jetson AGX Orin开发板，甚至是一块闲置的RTX 3060显卡，却被告知“本地跑大模型？算了吧，至少得A100集群”。——这些不是幻想，而是我过去18个月在客户现场、开源社区、硬件实验室里反复撞上的真实瓶颈。

“本地大模型部署完全指南”这个标题里的“完全”二字，不是噱头。它意味着不绕开任何一层抽象：从Mac上双击安装Ollama那一刻起，到在Jetson边缘设备上用llama.cpp跑通Qwen2-1.5B的量化推理，再到用vLLM在单机四卡A100上同时服务7个不同LoRA适配器的ChatGLM3-6B实例，最后在M系列芯片Mac上用MLX原生调度Llama-3-8B的KV Cache——这四条技术路径，我全部亲手搭过、压测过、调优过、踩过坑、修过bug，也给超过37家中小团队做过落地陪跑。这不是理论推演，是实打实的工程日志。

核心关键词Ollama、vLLM、llama.cpp、MLX，背后对应的是四类截然不同的部署哲学：Ollama是开发者友好的“开箱即用型”，vLLM是生产级高吞吐的“服务器内核型”，llama.cpp是极致轻量与跨平台的“嵌入式基因型”，而MLX则是苹果生态专属的“硬件亲和型”。它们不是替代关系，而是互补拼图。比如你在MacBook Pro上用MLX跑Llama-3-8B做本地知识库问答，响应延迟稳定在420ms；同时用Ollama管理同一台机器上的Phi-3-mini模型供VS Code插件调用；当需要批量处理10万条客服工单摘要时，把任务切片发给局域网内那台装了vLLM的4卡服务器；而你的边缘IoT网关——一块Jetson AGX Orin——则永远运行着llama.cpp编译的TinyLlama-1.1B量化版，负责实时解析传感器日志。这才是“完全指南”的真实图景：不是教你选一个，而是让你清楚每个引擎在哪种场景下不可替代。

适合谁来读？如果你是独立开发者，想用本地模型提升编码效率，Ollama+LM Studio组合能让你5分钟启动；如果你是AI Infra工程师，正为SaaS产品设计模型服务层，vLLM的PagedAttention内存管理机制和AsyncEngineClient异步接口必须吃透；如果你在做智能硬件，llama.cpp对ARM64/AArch64的深度优化、对Metal/ Vulkan后端的无缝支持，直接决定你的设备能否在2W功耗下持续推理；如果你是苹果生态开发者，MLX对Metal Performance Shaders的底层调用、对M系列芯片NPU的显式调度能力，是你绕不开的性能天花板。这篇文章不预设你的GPU型号或Mac序列号，但会告诉你：当你的显存是6GB、16GB还是40GB，当你的CPU是Intel i5、AMD Ryzen 7还是Apple M3，当你的目标平台是x86_64、aarch64还是arm64-apple-darwin——每一种组合，都有唯一最优解，而这个解，就藏在这四个引擎的参数细节、编译选项和运行时配置里。

2. 四大引擎底层逻辑拆解：不是工具选择，而是架构选型

2.1 Ollama：容器化模型分发协议的重新定义

Ollama常被误认为是“Mac版的Docker”，但它真正的革命性在于重构了模型分发的语义层。传统方式中，“下载模型”意味着下载一个包含完整权重文件的GGUF或Safetensors包，再手动配置环境、编写推理脚本；而Ollama将模型抽象为一个可执行的“镜像”（image），其本质是一个遵循OCI（Open Container Initiative）规范的tar包，内部结构高度标准化：/modelfile定义构建指令，/weights存放量化后的权重，/templates提供系统提示词模板，/params.json声明超参数。当你执行ollama run qwen2:1.5b，Ollama做的远不止是拉取镜像——它会自动检测本地CUDA版本，匹配对应的CUDA kernel patch；若检测到Apple Silicon，则静默切换至Metal后端；若发现模型未量化，则触发内置的llama.cpp量化器进行on-the-fly转换。这种“模型即服务”的封装思想，让Ollama成为本地部署的“最佳入门路径”，但它的代价是牺牲了细粒度控制权。

关键参数解析：OLLAMA_NUM_GPU环境变量控制GPU显存分配比例，默认值为100，但实测在RTX 3060（12GB显存）上设为80更稳，因为Ollama会在显存中预留约2GB用于CUDA上下文管理；OLLAMA_NO_CUDA=1强制禁用CUDA，此时会fallback到llama.cpp的CPU推理路径，适合调试模型兼容性。最易被忽略的是~/.ollama/models/blobs/目录——这里存储所有已拉取模型的SHA256哈希分块，删除某个blob不会影响其他模型，但Ollama不会自动垃圾回收，长期使用后该目录可能膨胀至数十GB，需定期ollama prune清理。

2.2 vLLM：面向高并发服务的内存与计算范式革命

vLLM的核心突破不是更快的kernel，而是PagedAttention内存管理机制。传统Transformer推理中，KV Cache以连续内存块存储，导致长上下文推理时显存碎片化严重——例如处理32K token上下文时，即使实际只用了10%的显存，剩余90%也无法被新请求复用。vLLM将KV Cache划分为固定大小的“page”（默认16个token），每个page可被任意请求的任意layer引用，通过页表（Page Table）实现逻辑连续、物理离散的映射。这使得vLLM在单卡A100上支持128路并发请求时，显存利用率仍能保持在92%以上，而HuggingFace Transformers原生实现通常跌破60%。

vLLM的部署形态决定了其适用边界：它天生为HTTP API服务而生，--host 0.0.0.0 --port 8000启动后，标准OpenAI兼容接口即可调用。但这也意味着它不适合嵌入式场景——其最小依赖包括PyTorch、CUDA Toolkit、NCCL，且必须运行在Linux x86_64环境。值得注意的是，vLLM对多卡的支持并非简单地--tensor-parallel-size 4，而是要求所有GPU处于同一PCIe Root Complex下，否则NCCL通信延迟会飙升。我在测试Titan RTX（24GB）双卡时发现，若两卡分属不同CPU socket，--tensor-parallel-size 2的吞吐反而比单卡低17%，最终改用--pipeline-parallel-size 2（流水线并行）才获得线性加速。另外，vLLM的--max-model-len参数必须严格大于等于你所有请求的最大max_tokens，否则会触发runtime panic，这是新手最容易栽跟头的地方。

2.3 llama.cpp：C++世界里的模型推理原子操作

llama.cpp是四大引擎中唯一用纯C/C++实现的项目，这意味着它没有Python GIL锁、没有CUDA Context初始化开销、没有PyTorch的内存管理抽象层。它的编译产物main二进制文件，就是模型推理的终极原子操作。当你在Jetson AGX Orin上执行./main -m models/qwen2-1.5b.Q4_K_M.gguf -p "请总结以下日志：" -n 256，整个过程不经过任何中间层：CPU直接加载GGUF文件头解析张量布局，Metal/Vulkan驱动直连GPU执行矩阵乘，输出token逐个写入stdout。这种“裸金属”风格带来了极致的确定性——在Orin上，Qwen2-1.5B-Q4_K_M的平均token生成延迟稳定在83ms±2ms，标准差仅为2.4%，而同等配置下Ollama的延迟波动范围达±15ms。

llama.cpp的真正威力在于其量化策略的精细控制。GGUF格式支持超过20种量化类型，从Q8_0（8-bit整数，精度最高）到Q2_K（2-bit主量化+K-quants辅助），每种都对应不同的速度/精度权衡。实测数据显示：在MacBook Pro M3 Max上，Qwen2-1.5B-Q5_K_M比Q4_K_M快1.8倍，但数学推理准确率下降3.2%；而在Jetson Orin上，Q3_K_L比Q4_K_M快2.3倍，且因Orin的DDR5带宽瓶颈，Q4_K_M的实际吞吐反而低于Q3_K_L。这种硬件感知的量化选择，是llama.cpp区别于其他引擎的核心竞争力。另外，llama.cpp的-ngl参数（GPU layer offloading）不是简单的“多少层放GPU”，而是按模型层数精确指定——例如Qwen2-1.5B共28层，-ngl 20表示前20层在GPU执行，后8层回退CPU，这种混合执行模式在显存受限设备上极为实用。

2.4 MLX：苹果芯片专属的软硬协同范式

MLX不是另一个推理框架，而是苹果生态的“操作系统级AI运行时”。它深度绑定Metal Performance Shaders（MPS）和Apple Neural Engine（ANE），其API设计哲学是“让模型代码直接映射到硬件指令”。当你用MLX加载Llama-3-8B时，mlx.core.array创建的张量默认分配在Unified Memory中，CPU/GPU/NPU可零拷贝访问；mlx.nn.Linear层的__call__方法会自动编译为Metal Shading Language（MSL）kernel，并根据当前设备动态选择执行单元——M3 Max上优先调度NPU，M1 Mac mini则fallback至GPU。这种硬件感知调度，使得MLX在M系列芯片上实现了其他框架无法企及的能效比。

MLX的部署约束同样鲜明：它仅支持macOS 13.5+和Apple Silicon，且必须用pip install mlx安装（无conda支持）。最关键的限制是模型格式——MLX原生只接受.safetensors权重，且要求模型架构必须用MLX原生OP重写。这意味着你不能直接加载HuggingFace的PyTorch模型，而必须先用mlx.utils.quantize工具将FP16权重转为4-bit量化格式，再用mlx.nn.Transformer等MLX原生模块重建模型结构。这个过程看似繁琐，但换来的是确定性性能：在MacBook Pro M3 Max上，Llama-3-8B-4bit的token生成速度达142 tokens/sec，而同等配置下Ollama（Metal backend）仅为98 tokens/sec，差距源于MLX跳过了Ollama的OCI容器层和llama.cpp的C API桥接层。另外，MLX的mlx.core.stream允许你显式控制计算流，例如将prompt encoding和token generation分离到不同stream，实现真正的重叠执行（overlap execution），这是其他框架在macOS上无法做到的。

3. 实操全流程：从零开始搭建四套环境并完成基准测试

3.1 Ollama：Mac与Windows双平台极速启动实战

在Mac上安装Ollama，官方推荐brew install ollama，但实测Homebrew安装的版本常滞后于GitHub Release，且更新机制不稳定。更可靠的方式是直接下载最新.pkg安装包：访问https://github.com/jmorganca/ollama/releases，找到ollama-darwin-arm64.pkg（Apple Silicon）或ollama-darwin-amd64.pkg（Intel），双击安装。安装完成后，终端执行ollama --version应返回dev或具体版本号，而非报错command not found——若出现后者，需手动将/usr/local/bin加入PATH，因为Ollama默认安装路径在此。

启动第一个模型只需一条命令：ollama run qwen2:1.5b。但这里有个关键细节：Ollama的模型名qwen2:1.5b并非固定字符串，而是<model-name>:<tag>格式，其中tag可以是latest、q4_k_m、q5_k_m等量化标识。国内用户常遇到ollama pull超时，根本原因不是网络问题，而是Ollama默认从registry.ollama.ai拉取，该域名在国内DNS解析缓慢。解决方案是配置国内镜像源：编辑~/.ollama/config.json，添加"registry": "https://docker.mirrors.ustc.edu.cn"（中科大镜像），或更稳定的"registry": "https://ollama.hf-mirror.com"（HuggingFace镜像）。配置后，ollama pull qwen2:1.5b-q4_k_m速度可从15分钟缩短至90秒。

模型运行后，Ollama默认监听http://localhost:11434，可通过curl测试：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2:1.5b-q4_k_m", "messages": [{"role": "user", "content": "用Python写一个快速排序"}], "stream": false }'

返回JSON中message.content即为模型输出。注意stream: false关闭流式响应，适合调试；生产环境建议设为true并用SSE解析。Ollama的模型存放路径为~/.ollama/models/，其中blobs/存分块哈希，manifests/存镜像元数据。若需迁移模型到另一台Mac，只需打包~/.ollama/models/目录并解压到目标机同路径，无需重新pull。

在Windows上，Ollama提供.exe安装程序，但存在一个隐藏陷阱：Windows Defender会将Ollama进程识别为“潜在不需要的应用”（PUA），默认阻止其网络访问。解决方法是在Defender设置中，将ollama.exe添加到“排除项”，或临时关闭实时保护。此外，Windows版Ollama默认使用DirectML后端而非CUDA，若你的显卡支持CUDA（如RTX 3060），需设置环境变量OLLAMA_CUDA=1并重启Ollama服务（net stop ollama && net start ollama）。

3.2 vLLM：单机多卡与分布式部署的硬核配置

vLLM的安装必须严格匹配CUDA版本。以Ubuntu 22.04 + CUDA 12.1为例，执行：

pip install vllm==0.4.2 --no-cache-dir

注意：vLLM 0.4.x要求PyTorch 2.1+，且必须用--no-cache-dir避免pip缓存旧版本wheel。安装后验证：python -c "import vllm; print(vllm.__version__)"应输出0.4.2。

启动单卡服务最简命令：

python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-1.5B-Instruct \ --tensor-parallel-size 1 \ --dtype half \ --max-model-len 4096 \ --port 8000

关键参数说明：--tensor-parallel-size 1表示单卡，若为A100 40GB则可设为2；--dtype half强制FP16，比auto更稳定；--max-model-len必须≥最大请求长度，否则报错Context length too long。实测发现，若模型实际支持32K上下文，但此处设为4096，则所有请求会被截断，务必确认。

单机多卡部署需确保NCCL正常工作。首先检查NCCL版本：python -c "import torch; print(torch.cuda.nccl.version())"应返回23007（即2.30.7）。若版本不符，需升级PyTorch或设置export NCCL_VERSION=2.30.7。启动命令改为：

python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-1.5B-Instruct \ --tensor-parallel-size 4 \ --dtype half \ --max-model-len 8192 \ --port 8000 \ --host 0.0.0.0

此时vLLM会自动绑定所有4张GPU。压力测试用ab命令：

ab -n 1000 -c 100 'http://localhost:8000/v1/completions' -p payload.json

其中payload.json内容为：

{ "model": "Qwen/Qwen2-1.5B-Instruct", "prompt": "请写一个Python函数计算斐波那契数列第n项", "max_tokens": 256, "temperature": 0.1 }

实测数据显示，在4卡A100上，vLLM的RPS（Requests Per Second）达217，而同等配置下Transformers原生实现仅89，差距源于PagedAttention的显存复用效率。

分布式部署需额外步骤：在主节点（rank 0）执行：

python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-1.5B-Instruct \ --tensor-parallel-size 2 \ --pipeline-parallel-size 2 \ --host 0.0.0.0 \ --port 8000 \ --distributed-executor-backend ray

从节点需预先启动Ray集群：ray start --address='head-node-ip:6379'。vLLM会自动发现Ray集群并分配worker。注意--tensor-parallel-size和--pipeline-parallel-size的乘积必须等于总GPU数，且--pipeline-parallel-size不能为1（否则退化为单机）。

3.3 llama.cpp：Jetson AGX Orin与Mac ARM64交叉编译实战

在Jetson AGX Orin上部署llama.cpp，不能直接make，因为Orin的aarch64架构与x86_64开发机不同。正确流程是交叉编译：在x86_64 Ubuntu主机上，安装aarch64工具链：

sudo apt update && sudo apt install -y g++-aarch64-linux-gnu

然后进入llama.cpp源码目录，执行：

make CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ LLAMA_CUDA=0 LLAMA_METAL=0 -j$(nproc)

生成的main二进制文件即为Orin可用版本。将其复制到Orin的/home/nvidia/llama.cpp/目录，再下载Qwen2-1.5B的GGUF量化模型：

wget https://huggingface.co/Qwen/Qwen2-1.5B-Instruct-GGUF/resolve/main/qwen2-1.5b-instruct-q4_k_m.gguf

启动命令：

./main -m qwen2-1.5b-instruct-q4_k_m.gguf -p "请解释量子纠缠" -n 512 -t 6 -ngl 20

参数详解：-t 6指定6线程（Orin有8核CPU，留2核给系统）；-ngl 20表示20层offload到GPU（Orin GPU为Ampere架构，20层是实测最优值）；-n 512限制最大输出长度。实测在Orin上，此配置下首token延迟（Time to First Token, TTFT）为1.2秒，后续token延迟（Inter-Token Latency, ITL）为83ms，功耗稳定在18W。

在Mac上编译llama.cpp更简单，但需注意Metal后端启用：

make clean && make LLAMA_METAL=1 -j$(sysctl -n hw.ncpu)

编译后main自动支持Metal。运行时若遇Failed to initialize Metal，需检查Xcode Command Line Tools是否安装：xcode-select --install。Mac版llama.cpp的-ngl参数行为特殊：设为-ngl 0表示纯CPU，-ngl 100表示全部层GPU，但实测M3 Max上-ngl 32（Qwen2-1.5B共28层）即可达到峰值性能，更高值无增益。

模型量化是llama.cpp的核心技能。使用llama.cpp/convert-hf-to-gguf.py脚本可将HuggingFace模型转为GGUF：

python convert-hf-to-gguf.py Qwen/Qwen2-1.5B-Instruct --outfile qwen2-1.5b.Q4_K_M.gguf

量化类型选择指南：Q4_K_M平衡速度与精度，Q5_K_M精度更高但慢15%，Q3_K_L适合边缘设备。量化后模型体积对比：FP16原始模型约3.1GB，Q4_K_M为1.4GB，Q3_K_L为0.9GB。

3.4 MLX：M系列芯片原生推理的完整链路

MLX部署必须从模型转换开始。以Llama-3-8B为例，首先从HuggingFace下载原始模型：

git lfs install git clone https://huggingface.co/meta-llama/Meta-Llama-3-8B-Instruct

然后用MLX工具量化：

pip install mlx python -m mlx_lm.convert --hf-path ./Meta-Llama-3-8B-Instruct --mlx-path ./mlx-model --quantize

--quantize参数默认生成4-bit量化，输出目录./mlx-model包含config.json、tokenizer.json和weights.safetensors。注意：MLX不支持GGUF，必须用safetensors。

编写推理脚本run.py：

import mlx.core as mx import mlx.nn as nn from mlx_lm import load, generate model, tokenizer = load("./mlx-model") prompt = "请用Python实现快速排序算法" response = generate(model, tokenizer, prompt=prompt, max_tokens=256, temp=0.1) print(response)

运行命令：

python run.py

首次运行会触发JIT编译，耗时较长（M3 Max约45秒），后续执行则毫秒级响应。MLX的generate函数默认启用stream=True，若需获取完整输出，可设stream=False。

MLX的高级技巧：显式控制计算流。修改run.py：

import mlx.core as mx from mlx_lm import load, generate model, tokenizer = load("./mlx-model") # 创建专用stream stream = mx.create_stream(mx.DeviceType.gpu) # 在指定stream上执行 mx.eval(model, stream=stream) response = generate(model, tokenizer, prompt="...", max_tokens=256, stream=False, stream=stream)

此方式可与其他计算任务并行，提升整体吞吐。MLX还支持ANE调度：在M系列芯片上，设置环境变量MLX_USE_ANE=1可强制使用神经引擎，但实测Llama-3-8B在ANE上速度比GPU慢40%，故默认不启用。

4. 横向性能基准测试：16GB显存、Jetson Orin、M3 Max三平台实测数据

4.1 测试环境与方法论统一

所有测试均采用相同输入Prompt：“请用Python实现一个支持插入、删除、查找的哈希表，并附带时间复杂度分析”，输出长度固定为256 tokens。硬件配置如下：

• 16GB显存平台：Ubuntu 22.04, Intel i7-10700K, RTX 3060 12GB（实际可用显存11.2GB），CUDA 12.1, Driver 535.129.03
• Jetson AGX Orin：Orin NX 16GB模块，JetPack 5.1.2, L4T 35.3.1, 8核Cortex-A78AE CPU, 16GB LPDDR5
• M3 Max平台：macOS 14.5, Apple M3 Max (16-core CPU, 40-core GPU, 128GB unified memory)

模型统一选用Qwen2-1.5B-Instruct，量化格式为Q4_K_M（llama.cpp）、FP16（vLLM）、4-bit（MLX）、Ollama默认（Q4_K_M）。每项测试重复5次，取中位数，排除首次冷启动时间。指标定义：

• TTFT（Time to First Token）：从请求发出到首个token返回的时间（秒）
• ITL（Inter-Token Latency）：后续每个token的平均生成时间（毫秒）
• RPS（Requests Per Second）：每秒处理请求数，用ab工具测试100并发

4.2 16GB显存平台（RTX 3060）性能对比

关键发现：vLLM在RPS上碾压其他方案，得益于PagedAttention的显存高效利用；Ollama的TTFT最高，因其启动时需加载OCI镜像并初始化CUDA context；llama.cpp的ITL最稳定（标准差±1.2ms），适合对延迟敏感场景。显存占用差异显著：vLLM仅用5.1GB，而Ollama需6.3GB，这是因为Ollama的容器层增加了约1.2GB的运行时开销。

4.3 Jetson AGX Orin平台性能对比

Orin平台结果印证了llama.cpp的边缘统治力：ITL比Ollama低38%，功耗低20%，温度低6°C。Ollama在Orin上实际运行的是llama.cpp的CPU模式（因无CUDA支持），故性能全面落后。这解释了为何“Jetson部署llama.cpp”成为边缘AI的标配方案——它不是妥协，而是针对ARM架构的主动优化。

4.4 M3 Max平台性能对比

M3 Max数据揭示了苹果生态的代际优势：MLX的ITL比llama.cpp低20%，能效比高59%。这源于MLX对Unified Memory的零拷贝访问和Metal Shading Language的极致优化。Ollama虽表现不俗，但其OCI容器层和API Server进程引入了约0.3秒的固定开销，这是无法通过参数调优消除的架构性成本。

5. 选型决策树与避坑指南：根据你的硬件和场景精准匹配

5.1 四维决策模型：显存/内存、CPU架构、部署形态、运维能力

我们构建一个四维坐标系来定位你的场景：

• X轴（显存/内存容量）：≤6GB（入门级GPU）、6–16GB（主流工作站）、≥16GB（专业服务器）
• Y轴（CPU架构）：x86_64（Intel/AMD）、aarch64（Jetson/树莓派）、arm64-apple-darwin（Mac）
• Z轴（部署形态）：单机单模型（个人开发）、单机多模型（VS Code插件）、高并发API服务（SaaS后端）、边缘嵌入式（IoT设备）
• W轴（运维能力）：零基础（点选安装）、中级（会改配置文件）、高级（能编译C++、调NCCL）

根据此模型，典型场景匹配如下：

• 场景1：程序员个人提效（RTX 3060 + Windows）
  → 选Ollama。理由：ollama run phi3:mini5分钟启动，VS Code插件直连http://localhost:11434，无需理解CUDA或量化。避坑：关闭Windows Defender实时保护，否则Ollama服务被拦截。

• 场景2：SaaS公司模型服务（4卡A100集群）
  → 选vLLM。理由：PagedAttention支撑128路并发，AsyncEngineClient支持异步批处理，Prometheus监控集成开箱即用。避坑：--max-model-len必须设为业务最大上下文长度，否则请求被截断；NCCL版本必须与PyTorch严格匹配，否则多卡吞吐归零。

• 场景3：智能硬件边缘推理（Jetson AGX Orin）
  → 选llama.cpp。理由：纯C++无依赖，Metal/Vulkan后端对Orin GPU深度优化，Q3_K_L量化可在2W功耗下跑通Qwen2-1.5B。避坑：必须交叉编译，不能在Orin上直接make（编译太慢且易失败）；-ngl参数需实测调优，Orin上20层是Qwen2-1.5B的黄金值。

• 场景4：Mac生态AI应用（MacBook Pro M3 Max）
  → 选MLX。理由：原生Metal支持，Unified Memory零拷贝，能效比碾压其他方案。避坑：必须用safetensors格式，不能直接加载HuggingFace PyTorch模型；首次运行JIT编译耗时长，需预热。

5.2 常见问题速查表与独家修复方案

5.3 进阶技巧：让每个引擎发挥120%性能

• Ollama的隐藏参数：OLLAMA_DEBUG=1开启调试日志，可看到CUDA kernel加载详情；OLLAMA_KEEP_ALIVE=5m防止模型被自动卸载，适合长时间交互场景。
• vLLM的性能调优：`--block-size