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

一、什么是 vLLM？

人工智能产业的蓬勃发展催生了丰富多样的推理模型，为解决特定领域的问题提供了高效的解决方案。DeepSeek 的爆火就是极佳的范例。然而，对于个人用户而言，如何有效地利用这些模型成为一个显著的挑战——尽管模型触手可及，但其复杂的部署和使用流程却让人望而却步。

针对这一现象，在大型语言模型（LLM）领域，vLLM（访问官网 https://docs.vllm.ai/en/latest/ 了解更多）应运而生。通过便捷的模型接入方式，vLLM 让用户能够轻松地向模型发起推理请求，从而大大缩短了从模型到应用的距离。vLLM 不仅降低了技术门槛，也拉近了普通用户与前沿 AI 技术之间的距离，使得更多人享受到 LLM 带来的便利和创新体验。

围绕 vLLM 展开的各种商业活动也日益活跃。与众多大语言模型不同的是，DeepSeek 免费提供了可供用户交互的界面。个人用户可以无门槛直接使用，但对于企业而言，稳定性、数据隐私、不参与模型训练参数收集等能力至关重要。为此，企业往往选择基于 vLLM 自建推理应用服务。与个人用户对 LLM 的推理需求不同，企业级应用更加注重 vLLM 的大规模部署及其作为产品基础形成对外提供服务的能力。然而，在规模化使用 vLLM 的过程中，企业面临着一系列挑战。

二、规模化部署 vLLM 的难点

包括 DeepSeek 在内的 LLM 具备以下三大特点，各自带来不同挑战：

大规模参数量：LLM 之所以被称为“大”语言模型，很大程度上是因为其拥有极其庞大的参数规模，导致模型的体积通常可达数十至数百 GB。这种巨大的模型体积在服务启动时带来了模型文件下载、GPU 加载漫长的问题，需要设计专门的加速机制来应对。同时也额外增加了日常的模型上传、下载、调试和发布等产品迭代流程的额外时间成本。
高效推理能力：除了克服大镜像大模型带来的冷启动问题，LLM 还必须满足实时性要求极高的交互需求，能够在数秒甚至毫秒级别内返回推理结果，并确保每轮对话都能持续稳定高效地进行。这依赖 vLLM 与内嵌模型的交互能否合理利用缓存数据，维持对话的连续性和响应的速度。
上下文理解：在多数应用场景中，LLM 通过对话提供推理服务，因此服务必须确保每行对话之间的连贯性。避免每次对话被分配到不同的后端资源导致上下文信息丢失。LLM 同时需要稳定的长连接，为用户提供一个持久的交互窗口。这意味着底层系统必须能够有效地管理和协调众多底层资源生命周期，确保对话的连贯性和稳定性。

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

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

“不可能三角”

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

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

vLLM 集群的“不可能三角”关乎整个服务架构的稳固性，基础不牢则地动山摇。一个完整的企业级产品不仅要求具备强大的资源基座，还需在此之上搭建日常的开发迭代、模型管理、推理过程指标可观测性、运维等一系列琐碎但不可或缺的功能。这些全部能力叠加在一起才能足够支撑一个企业级产品。

DevOps

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

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

面对这些挑战，企业不仅需要强大的技术支持以实现 vLLM 的高效运作，还需制定合理的策略来平衡“不可能三角”之间的关系，确保规模化 vLLM 部署下的应用对外服务能力。

三、FC GPU 预留实例闲置计费

正所谓“打蛇打七寸”，针对 DeepSeek 以及众多 LLM 的特性，函数计算 (FC) 提供了通用性的解决方案——GPU 预留实例闲置计费，精准解决了性能、成本与稳定性之间的平衡难题：

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

FC GPU 预留实例的闲置计费功能不仅提升了 LLM 服务的性能，降低了成本，还确保了系统的稳定性。这种综合优势使得企业在面对复杂的业务需求和技术挑战时，能够更加从容地提供高质量的服务。

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

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

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

四、部署方式

FC 提供了一套简便的 vLLM 服务框架与模型解耦的部署流程。由于 vLLM 自身支持 server 端口及路径要求，因此可以直接接入 FC 使用 GPU 预留实例，开箱即用，无需特殊配置。以下是详细的部署流程：

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

4. 选择显卡：对于大语言模型，推荐使用 Ada 系列的 GPU — fc.gpu.ada.1 卡型，并使用整卡显存以支撑大体积的 LLM 模型。