LLM推理优化：量化压缩与成本控制实战

推理优化是从原型走向生产级 LLM 应用的分水岭。训练虽然占据了大部分研究关注度，但服务的经济学本质由推理时的吞吐量、延迟和内存效率决定。从权重精度到请求调度的每一层栈，都提供了降低成本、改善用户体验的杠杆。

Quantization and Weight Compression

训练后量化将模型权重从 FP32 或 BF16 降至 INT8、INT4 或 FP8 格式。目标是减轻内存带宽压力，并提高 GPU 可并发服务的请求数量。带 scale map 的 INT8 量化通常能将困惑度保持在原始模型个位百分比的范围内，而 INT4 分组量化可将内存占用减少近 75%，代价是在推理密集型任务中出现轻微退化。

自托管时，必须在量化后用自己的评估套件验证准确性。Oxlo.ai 等平台通过提供预量化优化版本（如 DeepSeek R1 671B MoE 和 Llama 3.3 70B）来抽象这一复杂性。由于 Oxlo.ai 处理了服务基础设施，你无需耗费工程周期来维护自定义量化流水线。

# Example: Loading a quantized model locally with transformers
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype="bfloat16"
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.3-70B-Instruct",
    quantization_config=bnb_config,
    device_map="auto"
)

Continuous Batching and Request Scheduling

静态批处理强制请求等待直到达到固定批次大小，这引入了不必要的延迟。连续批处理（又称飞行批处理）动态地将新请求插入 GPU 空出的插槽中。这保持了计算单元的饱和状态，并减少了 incoming 请求的首 token 时间。

实现生产级连续批处理调度器需要自定义推理引擎（如 vLLM 或 TensorRT-LLM）。如果不运行自己的 GPU 集群，这一复杂性由提供商承担。Oxlo.ai 在其集群中调度请求，热门模型无冷启动问题，因此你可以在不管理编排层的情况下获得高级批处理的延迟优势。

KV 缓存是自回归生成过程中的主要内存消费者。对于长上下文模型，它可能超过权重本身的大小。优化手段包括：

• Page-based caching：以固定块而非连续张量分配缓存内存，减少碎片化。