人工智能产业的蓬勃发展催生了丰富多样的推理模型，为解决特定领域的问题提供了高效的解决方案。DeepSeek 的爆火就是极佳的范例。然而，对于个人用户而言，如何有效地利用这些模型成为一个显著的挑战——尽管模型触手可及，但其复杂的部署和使用流程却让人望而却步。
针对这一现象，在大型语言模型（LLM）领域，vLLM（
访问官网 https://docs.vllm.ai/en/latest/ 了解更多
）
应运而生。通过便捷的模型接入方式，vLLM 让用户能够轻松地向模型发起推理请求，从而大大缩短了从模型到应用的距离。vLLM 不仅降低了技术门槛，也拉近了普通用户与前沿 AI 技术之间的距离，使得更多人享受到 LLM 带来的便利和创新体验。
围绕 vLLM 展开的各种商业活动也日益活跃。与众多大语言模型不同的是，DeepSeek 免费提供了可供用户交互的界面。个人用户可以无门槛直接使用，但对于企业而言，稳定性、数据隐私、不参与模型训练参数收集等能力至关重要。为此，企业往往选择基于 vLLM 自建推理应用服务。与个人用户对 LLM 的推理需求不同，企业级应用更加注重 vLLM 的大规模部署及其作为产品基础形成对外提供服务的能力。然而，在规模化使用 vLLM 的过程中，企业面临着一系列挑战。
包括 DeepSeek 在内的 LLM 具备以下三大特点，各自带来不同挑战：
-
大规模参数量：
LLM 之所以被称为“大”语言模型，很大程度上是因为其拥有极其庞大的参数规模，导致模型的体积通常可达数十至数百 GB。这种巨大的模型体积在服务启动时带来了模型文件下载、GPU 加载漫长的问题，需要设计专门的加速机制来应对。同时也额外增加了日常的模型上传、下载、调试和发布等产品迭代流程的额外时间成本。
-
高效推理能力：
除了克服大镜像大模型带来的冷启动问题，LLM 还必须满足实时性要求极高的交互需求，能够在数秒甚至毫秒级别内返回推理结果，并确保每轮对话都能持续稳定高效地进行。这依赖 vLLM 与内嵌模型的交互能否合理利用缓存数据，维持对话的连续性和响应的速度。
-
上下文理解：
在多数应用场景中，LLM 通过对话提供推理服务，因此服务必须确保每行对话之间的连贯性。避免每次对话被分配到不同的后端资源导致上下文信息丢失。LLM 同时需要稳定的长连接，为用户提供一个持久的交互窗口。这意味着底层系统必须能够有效地管理和协调众多底层资源生命周期，确保对话的连贯性和稳定性。
在构建和运营大规模显卡集群以支持 vLLM 时除了需要解决上述的 LLM 推理的性能及稳定性以外，还要关注成本。其中的主要难点在于底层显卡资源利用率的精确管控，资源使用的均衡性，以及显卡本身的高昂费用：
-
资源利用与波峰波谷管理：
vLLM 业务对显卡集群的资源消耗呈现出明显的波峰和波谷特性。为了确保在业务高峰时段有足够的计算能力，企业通常会提前购买足量的显卡来覆盖峰值需求。然而，在非高峰时段（波谷），大部分显卡将处于空闲状态，造成资源浪费。这种时间上的使用不均，不仅增加了硬件闲置的成本，也降低了投资回报率。
-
资源使用不均衡与服务质量：
即使在业务高峰期，显卡资源的使用也可能出现不均衡的情况。调度策略不当可能导致某些服务器的显卡、内存和 CPU 资源过度挤兑，而其他服务器则较为空闲。这种负载不均衡现象会影响整体的服务质量，降低用户体验。
-
云服务选择困境：
使用云端提供的弹性计算资源虽然可以缓解本地显卡资源的波峰波谷问题，但现有的云服务选项要么 GPU 实例费用昂贵，要么面临冷启动慢的问题，又或者无法满足实时弹性的要求。这使得企业在选择采用云服务时陷入两难境地。
-
自购显卡的额外开销：
自行采购显卡不仅初期投入大，而且由于市场上不同类型的显卡供应不稳定，导致资源供给不可预期。此外，显卡资源相对紧缺的情况下，企业可能需要额外支出用于囤积显卡，进一步增加了成本负担。
总结上述的各项问题，都可以将其归类为“不可能三角”：性能、成本与稳定性三者难以同时满足。具体来说：
vLLM 集群的“不可能三角”关乎整个服务架构的稳固性，基础不牢则地动山摇。一个完整的企业级产品不仅要求具备强大的资源基座，还需在此之上搭建日常的开发迭代、模型管理、推理过程指标可观测性、运维等一系列琐碎但不可或缺的功能。这些全部能力叠加在一起才能足够支撑一个企业级产品。
为了高效管理和优化 vLLM 服务，企业在日常开发与运维中需应对以下几个关键领域：
面对这些挑战，企业不仅需要强大的技术支持以实现 vLLM 的高效运作，还需制定合理的策略来平衡“不可能三角”之间的关系，确保规模化 vLLM 部署下的应用对外服务能力。
正所谓“打蛇打七寸”，针对 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 模型。
5. 完成函数创建：按照上述步骤完成所有配置后，点击“创建”按钮，等待系统完成初始化。
6. 指定模型挂载路径：为了实现模型的集中管理和更新，我们强烈建议用户将模型存储在 NAS 中。NAS 可以自动挂载到 FC 函数的 vLLM 服务实例中，从而实现模型的无缝集成。
