破解 vLLM + DeepSeek 规模化部署的“不可能三角”

1. 大规模参数量：LLM 之所以被称为“大”语言模型，很大程度上是因为其拥有极其庞大的参数规模，导致模型的体积通常可达数十至数百 GB。这种巨大的模型体积在服务启动时带来了模型文件下载、GPU 加载漫长的问题，需要设计专门的加速机制来应对。同时也额外增加了日常的模型上传、下载、调试和发布等产品迭代流程的额外时间成本。

2. 高效推理能力：除了克服大镜像大模型带来的冷启动问题，LLM 还必须满足实时性要求极高的交互需求，能够在数秒甚至毫秒级别内返回推理结果，并确保每轮对话都能持续稳定高效地进行。这依赖 vLLM 与内嵌模型的交互能否合理利用缓存数据，维持对话的连续性和响应的速度。

3. 上下文理解：在多数应用场景中，LLM 通过对话提供推理服务，因此服务必须确保每行对话之间的连贯性。避免每次对话被分配到不同的后端资源导致上下文信息丢失。LLM 同时需要稳定的长连接，为用户提供一个持久的交互窗口。这意味着底层系统必须能够有效地管理和协调众多底层资源生命周期，确保对话的连贯性和稳定性。

在构建和运营大规模显卡集群以支持 vLLM 时除了需要解决上述的 LLM 推理的性能及稳定性以外，还要关注成本。其中的主要难点在于底层显卡资源利用率的精确管控，资源使用的均衡性，以及显卡本身的高昂费用：

1. 资源利用与波峰波谷管理：vLLM 业务对显卡集群的资源消耗呈现出明显的波峰和波谷特性。为了确保在业务高峰时段有足够的计算能力，企业通常会提前购买足量的显卡来覆盖峰值需求。然而，在非高峰时段（波谷），大部分显卡将处于空闲状态，造成资源浪费。这种时间上的使用不均，不仅增加了硬件闲置的成本，也降低了投资回报率。
2. 资源使用不均衡与服务质量：即使在业务高峰期，显卡资源的使用也可能出现不均衡的情况。调度策略不当可能导致某些服务器的显卡、内存和 CPU 资源过度挤兑，而其他服务器则较为空闲。这种负载不均衡现象会影响整体的服务质量，降低用户体验。
3. 云服务选择困境：使用云端提供的弹性计算资源虽然可以缓解本地显卡资源的波峰波谷问题，但现有的云服务选项要么 GPU 实例费用昂贵，要么面临冷启动慢的问题，又或者无法满足实时弹性的要求。这使得企业在选择采用云服务时陷入两难境地。

4. 自购显卡的额外开销：自行采购显卡不仅初期投入大，而且由于市场上不同类型的显卡供应不稳定，导致资源供给不可预期。此外，显卡资源相对紧缺的情况下，企业可能需要额外支出用于囤积显卡，进一步增加了成本负担。

总结上述的各项问题，都可以将其归类为“不可能三角”：性能、成本与稳定性三者难以同时满足。具体来说：

• 性能与稳定性的优先：为了确保 LLM 模型的高性能推理与对话的稳定性，企业可能需要提前扩容显卡资源，并优化调度算法，这涉及到人力、物力等多方面的投入，导致系统成本难以降低。
• 成本与服务质量的优先：当注重成本控制和服务质量时，推理性能可能会受到影响。例如，采用按量推理的方式虽然可以节省成本，但业务的冷启动时间会被庞大的模型体积放大至不可接受的程度。

• 性能与成本的优先：在追求高性能推理和低成本的情况下，系统的稳定性可能会受到挑战，如提前购置的 GPU 数量不足导致资源过分挤兑以及突发流量带来的资源压力。

为了高效管理和优化 vLLM 服务，企业在日常开发与运维中需应对以下几个关键领域：

• 模型与框架迭代：随着 vLLM 技术的发展，框架本身的迭代升级是必不可少的。而模样也同样需要持续改进和更新，以适应变化的需求。随着模型数量和类型的增加，版本控制、更新部署由于大体检而变得更加复杂。
• vLLM 服务器管理：规模化系统需要管理、调度和监控大量 vLLM 服务器，确保每个节点高效运行并能快速响应推理请求。同时，vLLM 集群需要具备足够的弹性来应对流量波动，并保持低延迟和高吞吐量。对于 vLLM 的生命周期管理也是一大难题。

• 版本控制与兼容性：确保不同版本之间的兼容性和可追溯性，便于回滚和修复问题，这对企业的技术栈提出了更高的要求。

1. 性能优化：通过预先启动 vLLM 服务实例，确保 vLLM 框架及模型已部署完毕。当请求到来时，服务能够立即唤醒并执行，从而避免了框架与大模型加载带来的延迟。同时，FC 的产品特性保证每次请求都能得到高效复用集群级别缓存，确保在高吞吐、高并发情况下依然保持快速响应。
2. 成本控制：FC GPU 闲置预留实例支持灵活的计费模式，当预留实例处于闲置状态时，企业只需支付少量费用即可保留特定数量的 vLLM 服务实例。活跃时按照正常活跃价格收费。为了进一步降低成本，企业可以使用定时预留功能，根据业务需求动态调整资源池大小，按需管理，确保资源利用的最大化。
3. 稳定性保障：FC 采用自主研发的调度算法，结合显存数据管理和调度机制，确保模型到显卡、请求到 vLLM 容器、vLLM 容器到显存池之间的高效调度，使得系统能够在负载高峰期依然保持稳定运行。同时，FC 可维持最长 24 小时的长链接，并天然支持 WebSocket 调用方式，确保用户界面不中断，为持续对话提供稳定的交互基础。

FC 也天然支持高效的开发与运维能力，提供日常迭代、模型管理、多维度可观测指标、仪表盘以及运维流程，确保企业级产品的完整性和可靠性。除此之外，在请求调用方面，FC 也提供多样的请求导入机制：

• 实例分配：FC 能够根据实际需求，将请求智能地分配到适当数量的 vLLM 实例上，确保资源的最佳利用。
• 灵活的并发度调节：支持动态调整并发处理能力，以应对不同负载情况下的性能需求。
• 定时触发任务：允许设置定时任务，确保在特定时间点自动执行预定操作，提高自动化水平。
• 同步与异步调用：提供同步和异步调用形式，满足不同应用场景的需求，优化用户体验。
• 多种调用形式支持：除了标准的 HTTP 调用外，还支持 WebSocket 长连接等多样化的调用方式，增强服务的灵活性和响应速度。

这些特性使得企业可以专注于业务逻辑的创新，而不必担心底层技术实现的复杂性。

1. 上传 vLLM 镜像：使用官方提供的 vLLM Docker 镜像，无需对镜像进行任何修改，将该镜像上传至阿里云容器镜像服务（ACR）。

2. 创建函数：登录阿里云控制台，进入函数计算 3.0 管理页面，开始创建一个新的 GPU 函数，并选择适合的运行环境和配置。

3. 配置启动命令：（为了保证服务的稳定性，需添加 --enforce-eager 参数以关闭急切模式）。

python3 -m vllm.entrypoints.openai.api_server --enforce-eager --model ${NAS中的模型路径} --trust-remote-code --served-model-name ${LLM模型} ...其他参数配置... --port ${函数暴露端口}

更多参数配置可参考 vLLM 官方文档，根据具体需求调整配置。

python3 -m vllm.entrypoints.openai.api_server --model /prod/models --trust-remote-code --served-model-name Qwen/Qwen-14B-Chat --gpu-memory-utilization 0.9 --max-model-len 4096 --port 8080

5. 完成函数创建：按照上述步骤完成所有配置后，点击“创建”按钮，等待系统完成初始化。

6. 指定模型挂载路径：为了实现模型的集中管理和更新，我们强烈建议用户将模型存储在 NAS 中。NAS 可以自动挂载到 FC 函数的 vLLM 服务实例中，从而实现模型的无缝集成。

7. 配置预留实例并开启闲置计费：创建所需数量的预留实例并按需配置定时预留。

8.（可选）绑定自定义域名：通过绑定自定义域名，实现直接通过该域名进行 HTTP 调用，对外提供推理服务。

如果您希望进一步包装 vLLM，可以将自定义域名轻松嵌入到上层服务中并封装调用。企业无需关心底层 vLLM 实例的启动、调度、负载均衡以及亲和性等细节，FC 能够确保服务的高效与稳定运行。

对于不需要观察 vLLM 实例的用户，可以直接使用基于 FC 的模型应用平台（CAP）进一步抽象部署过程，使您能够快速、轻松地将vLLM应用部署上线，大大节省了时间和精力

通过 FC GPU 预留实例的闲置计费功能，企业用户能在充分利用 vLLM 的强大功能的同时找到成本、性能、稳定的最佳平衡点，并保持开发和运维的高效性。无论是将 FC vLLM 函数直接对外提供服务，还是深度集成到现有系统中，或是通过 CAP 还是魔搭来简化部署，都能找到满足您业务需求的最佳实践。