如何在内部服务器上部署 27B 模型并控制 Token 成本
在由于安全法规而无法使用外部 API 的情况下,必须将 27B 模型部署在自有服务器上。预算不足以购买昂贵的 H100,而每月的 Token 成本却在滚雪球般不断增加。本文将探讨在本地部署(On-premise)环境中,如何将硬件预算节省 40% 以上并阻止无限循环 Token 浪费的具体实操方法。
降低硬件预算的多 GPU 配置方法
为了在不发生 OOM 的情况下运行 27B 模型,必须准确计算 VRAM 需求量。与其购买一台英伟达 H100 80GB,不如将两张 RTX 4090 24GB 组合起来,打造 48GB 的集成 VRAM。采用这种方式,可以将初始硬件构建成本降低一半以上。
- 将模型权重(基于 FP8 约 28GB)与 KV 缓存(基于 8K 上下文 1GB)相加,确认总共所需的 VRAM 是否不超过 30GB。
- 在没有 NVLink 的环境中,运行 vLLM 时指定
--tensor-parallel-size 2 选项,在 PCIe 带宽内分摊运算。
- 为了承受两张 RTX 4090 产生的 1000W 以上峰值功率,请使用 80 Plus Titanium 认证电源,并通过前置进气风扇防止热节流。
没有必要执着于单台高价设备。将廉价显卡并行组合,对于面临预算压力的基础设施团队来说是一个现实的替代方案。
防止无限循环 Token 消耗的引擎设置
最近的 27B 模型在处理复杂逻辑时,经常无法输出结束 Token,导致进入无限循环直到最大 Token 数。在商业 API 环境中,仅仅这一个现象就会让每月的运营成本膨胀到难以承受的地步。只需在本地服务引擎中调整参数,就能切实地遏制这种浪费。
- 在服务参数中给予
repeat_penalty 1.15 和 presence_penalty 0.1,以抑制重复生成相同句子的现象。
- 在配置文件中的
stop 数组里加入 <|im_end|>、<|eot_id|> 和 \nUser:,强制模型无法独自进行自问自答。
- 应用
temperature 0.2 和 min_p 0.05,将模型约束在不触及低概率 Token 的范围内。
应用这些设置后,平均输出 Token 数将从 4,000 个减少到 800 个。即使包含电费和设备折旧,也能将单台设备的每月运营费用控制在 290 美元左右。
在气隙(Air-gapped)环境中部署权重与管理管道
在与外部网络完全隔离的气隙环境中,稳定管理权重并提供服务的管道是必不可少的。利用 vLLM,即使在公司内部网络中也可以开启速度与商业服务无异的 API 端点。
- 在能联网的堡垒机(Bastion host)上使用
huggingface-cli 接收权重,并使用 --local-dir-use-symlinks False 选项以单文件结构下载。
- 运行 vLLM 时应用
--enable-prefix-caching 和 --gpu-memory-utilization 0.92,以提高 RAG 上下文的可重用性并防止 VRAM 碎片化。
- 常态化监控 Prometheus 端点 (
/metrics),当 vllm:gpu_cache_usage_factor 指标超过 90% 时,立即将 --max-model-len 从 16384 降低至 8192。
在遵守公司安全政策的同时控制成本的唯一方法,终究只有亲自构建并监控各项数值。