vllm的流行到底解决了什么问题。
 
1. 增加kv缓存，加快AI产生速度。我们知道AI运行是计算 每个token 的关系数值，在生成内容中，最新的一个词都是又前面N个词的关系计算获取的来的。但是每个此计算下一个，都会重复计算上一个词的权重关系。为了解决对应问题，加快AI生成速度，我们将前面的词以及相关关系权重数据保存下来。这样只计算最后一个词的关系即可。我们在这里定义了一个固定的v的空间。
2. 实际应用中会出现内存空洞。为了实现显卡缓存使用率的最大化，使用虚拟内存地址空间管理通过页表管理，将哪些参差不齐不用的空间按照常规v的空间，组装连接起来。供新的请求使用，这样就 能反复使用，不浪费内存的大小。这个成为pageAttension
 
 
3.在这种情况下，可能会出现新的问题，重复性请求内容，比如你问一个问题和另外一个人问题前缀一致（尤其是现在通用Agent的定义），那就用一个前缀kv保留相关数据。这样可用共享对应的权重数据，速度也有所提升。随着前缀内容增多,当超过可用缓存情况下就出现了抢占内存
 
 
4.当超过可用缓存情况下就出现了抢占内存,为了加快速度，加快内存释放，修改处理数据方式，原来是 多任务长token计算处理，并行多的情况下，处理结束时间参差不齐，导致部分cuda空闲。为了解决该问题通过，每次批量推送只处理一个token，完毕后立马离场，继续下一个，这样GPU并行使用率就上升了。这个是一个独立的批处理调度器。
 
5. 如果一个用户输入了超长内容，那将内容分段处理。每个块成为chunk，避免了一个请求长期占用。
 
6.量化，为了能够使用较小内存的显卡，将原有的数据精度 进行缩小。
 
以上的所有操作 封装到一起就是GPUworker一个GPUworker 管理一个显卡。
 
7. 当权重数据过大时又2中方式处理
（1）专家权重模式，即需要哪些权重数据，则取到显存中
（2）增加多个显卡同时运行。也又2中模式，一种是张量并行（水平切分），将各个卡个存储一部分权重数据，最终使整个模型加载到现存中，卡中间用高速连接，他们之间通信。第二种是 按流水线方式 垂直切分，每个数据都经过所有显卡。
当多个显卡同时运行，需要上面1-6的管理能力，则出现了EngineCore，对各个显卡工作进行调度。

下面是支持的参数配置
参数名称 参数分类 核心作用 调优建议与注意事项
--model 基础配置 指定要加载的模型名称（如 Hugging Face ID）或本地模型文件夹路径。 启动服务的必要参数，必须确保路径或名称正确。
--max-model-len 基础配置 设置模型允许的最大上下文长度（输入+输出的总 Token 数）。 需与模型本身支持的长度匹配。设置过大且显存不足时，会导致启动时 OOM（显存溢出）。
--gpu-memory-utilization 显存管理 控制 vLLM 实例可占用的 GPU 显存比例（0.0 ~ 1.0），默认通常为 0.9。 剩余显存会分配给 KV Cache。显存充足可尝试调到 0.95；若频繁 OOM 则需调低。
--tensor-parallel-size 并行策略 张量并行（TP）数量。将模型权重切分到多张 GPU 上，用于单机多卡部署。 通常设置为本机使用的 GPU 数量（如 4 卡设为 4）。需确保多卡间通信正常。
--max-num-seqs 调度控制 单次调度迭代中最多并发处理的序列数（请求数）。 调大能提高吞吐量，但会增加延迟和显存压力。交互场景建议 16~64，批量处理可调高。
--max-num-batched-tokens 调度控制 单次迭代中最多处理的 Token 总数（包含 Prefill 和 Decode 阶段）。 调大能加快长文本处理速度，但也更容易触发 OOM。建议从 8192 开始调试。
--quantization 性能优化 指定模型量化方式（如 awq, gptq, fp8），以减小权重显存占用。 显存紧张时的首选。使用 fp8 等量化可大幅降低显存，但可能会带来轻微精度损失。
--kv-cache-dtype 性能优化 指定 KV Cache 的存储数据类型（如 auto, fp8）。 设为 fp8 可将 KV Cache 显存占用减半，非常适合长上下文和高并发场景。
--enable-prefix-caching 性能优化 开启自动前缀缓存（APC）。缓存相同前缀的 KV 块，避免重复计算。 对多轮对话、相同长文档查询场景收益极大。无需传值，加上该 flag 即可开启。