推理引擎

大模型应用开发的第一步是让模型运行起来。推理引擎负责加载模型权重、管理显存、处理输入输出，是连接模型和应用的桥梁。与训练引擎不同，推理引擎专注于高效的单次前向传播，关注吞吐量、延迟和资源利用率。

本地推理方案

本地推理让开发者能够在自己的硬件上运行大模型，适合对数据隐私敏感的场景，或者需要低延迟、高并发的应用。主流方案包括桌面应用、服务器框架和云端服务。

Ollama 是最简单的本地推理方案，它封装了模型下载、加载和推理的完整流程，一条命令就能运行模型。ollama run llama3 会自动下载模型文件并启动一个交互式 shell，支持多轮对话。Ollama 的优势在于零配置，适合快速体验和开发调试。它还提供了 HTTP API，可以在应用中通过 REST 调用，默认端口 11434。但 Ollama 的性能优化有限，高并发场景下可能需要更专业的方案。

vLLM 是高性能推理引擎的代表，它引入了 PagedAttention 技术解决显存碎片问题，显著提升吞吐量。传统的推理引擎将 KV cache 连续存储，不同请求的序列长度差异导致显存利用率低。vLLM 借鉴操作系统的分页内存管理，将 KV cache 切分成固定大小的 block，按需分配，显存利用率可以从 20% 提升到 80% 以上。启动 vLLM 服务器：vllm serve meta-llama/Llama-3-8B --tensor-parallel-size 2，--tensor-parallel-size 参数指定 GPU 数量进行张量并行。vLLM 还支持 OpenAI 兼容的 API，可以直接替换 ChatGPT 的 base_url。

Text Generation Inference (TGI) 是 Hugging Face 推出的推理框架，专注于生产环境的稳定性和可观测性。TGI 内置了动态批处理、连续批处理、Flash Attention 等优化，支持流式输出、Token 级别的日志概率、编码器-解码器架构（如 T5）。它的配置更加灵活，通过 --quantize 参数支持 AWQ、GPTQ、BitsAndBytes 等量化方案，可以在不影响太多精度的情况下降低显存占用。TGI 还提供了 Prometheus 指标端点，方便集成监控告警系统。

量化技术

模型量化是降低推理成本的关键技术。FP32/BF16 精度的模型参数占用大量显存，7B 模型需要约 14GB 显存（BF16）。量化将参数从高精度浮点数转换为低精度表示，4bit 量化后显存占用降低到 4GB 左右，而且精度损失通常在可接受范围内。

GPTQ 是一种精准的 4bit 量化方法，通过最小化量化误差的二阶导数来保持模型精度。量化过程需要校准数据集，对每层权重进行迭代优化，计算量大但效果好。AWQ (Activation-aware Weight Quantization) 则认为激活值分布不均匀是量化精度下降的主要原因，只量化约 1% 的显著权重可以保持性能，量化速度比 GPTQ 快得多。BitsAndBytes 提供了动态量化方案，推理时实时将 FP16 权重量化为 8bit 或 4bit，不需要预先量化模型文件，使用方便但推理速度略慢。

选择量化方案需要权衡精度、速度和部署复杂度。对于 7B-13B 规模的模型，4bit GPTQ/AWQ 是性价比最高的选择；更大的模型（70B+）可能需要 8bit 量化来保证可用性；如果显存充足，FP16/BF16 仍然是质量保证的最佳选择。

参数调优

推理引擎的参数配置直接影响用户体验和资源利用率。Temperature 控制输出的随机性，0.1 让模型倾向于选择高概率词，输出更确定；1.0 保持模型原有的分布；0.7-0.9 适合创意生成。Top-p (Nucleus Sampling) 从累积概率达到 p 的最小词集合中采样，典型值 0.9，过滤掉低概率的极端情况。Top-k 只从概率最高的 k 个词中选择，通常与 top-p 配合使用。Max tokens 限制输出长度，防止无限生成，需要根据上下文窗口大小合理设置。

Repeat penalty 是一个容易被忽视的参数，它惩罚重复出现的词，避免模型陷入重复循环。1.0 表示不惩罚，1.1-1.2 是常用范围，过高可能导致输出不连贯。对于代码生成、翻译等需要结构化输出的任务，可以适当提高重复惩罚；对于创意写作，则应该降低。

批处理策略对吞吐量影响巨大。静态批处理等待固定数量的请求后一起处理，延迟高但吞吐量高。连续批处理（Continuous Batching 或 vLLM 的 PagedAttention）允许在生成过程中动态插入新请求，单个请求生成完成后立即释放资源给队列中的请求，显著提升了并发场景下的效率。对于交互式应用（单用户），连续批处理的优势不明显；对于 API 服务（多用户），这是必选项。

微调概述

当通用模型无法满足特定领域需求时，微调是改变模型行为和知识分布的手段。LoRA（Low-Rank Adaptation）冻结基础模型权重，在注意力层旁添加可训练的低秩矩阵，7B 模型只需几十 MB 额外参数。QLoRA 将基础模型量化到 4bit 再训练 LoRA，单张 48GB 显存即可微调 65B 模型。微调适合输出风格定制、领域知识内化、特定任务增强等场景，但知识更新需要重新训练，且无法追溯信息来源。详细的训练数据准备、训练策略（SFT/DPO）、领域实践和评估方法见微调。

服务部署

推理引擎最终需要暴露为服务供应用调用。FastAPI 是构建推理服务的常见选择，它原生支持异步、自动生成 API 文档、类型检查。一个最小的 FastAPI 推理服务包含模型加载、请求验证、推理调用、响应返回几个步骤。生产环境需要考虑请求队列（避免并发过多导致 OOM）、超时控制（长请求占用资源）、健康检查（Kubernetes 存活探针）。

对于高并发场景，可以采用多实例负载均衡。每个 GPU 运行一个推理实例，前面部署 Nginx 或 Kubernetes Service 进行负载均衡。推理服务通常是无状态的，但需要注意模型加载时间较长（几十秒），不能轻易重启。预热机制在服务启动时加载模型并进行一次推理，避免首次请求的冷启动延迟。

监控推理服务的健康状态至关重要。需要关注的指标包括请求延迟（P50、P99）、吞吐量（QPS）、显存使用率、GPU 利用率、错误率。Prometheus + Grafana 是标准方案，vLLM、TGI 等框架内置了 metrics 端点可以直接采集。告警规则应该关注延迟突增（可能是资源竞争）、显存溢出（batch size 过大）、请求失败率上升（模型崩溃）。