本地大模型部署：从 Ollama 到 vLLM 的选型路径
本地部署大模型的门槛已经不高，但“能跑起来”和“能稳定提供服务”是两件事。选型时真正需要先回答的是：你要的是个人试用、离线开发，还是面向多人并发的服务。
先估算显存需求
模型能否运行，主要取决于显存能否容纳权重和推理过程中的缓存。一个粗略的估算方式是：参数量乘以每个参数的字节数。FP16 下每个参数约 2 字节，8-bit 量化约 1 字节，4-bit 量化约 0.5 字节。
例如 7B 模型在 4-bit 量化下，权重约 3.5GB，再加上上下文缓存和运行时开销，通常需要 6–8GB 显存才比较从容。参数量越大，上下文越长，额外开销越明显。
- 7B 模型：4-bit 量化约 4GB 权重，适合 8GB 显存起步。
- 14B 模型：4-bit 量化约 8GB 权重，建议 12–16GB 显存。
- 32B 模型：4-bit 量化约 18GB 权重，通常需要 24GB 显存。
- 70B 模型：多卡或大内存统一内存方案更现实。
Ollama：个人与开发环境
Ollama 把模型下载、运行和本地接口封装成简单命令，适合个人电脑、开发机和小规模内部试用。它支持 macOS、Linux 与 Windows，模型切换方便，也提供兼容 OpenAI 的本地接口。
局限在于并发和吞吐不是它的设计重点。如果只是自己用或做原型，它足够；如果要给团队提供稳定服务，应尽早评估更专业的推理引擎。
vLLM：面向并发服务
vLLM 通过更高效的显存管理和批处理提升吞吐，适合在 GPU 服务器上部署面向多用户的模型服务。它提供兼容 OpenAI 的接口，接入现有应用的成本较低。
代价是部署复杂度更高：需要处理 GPU 驱动、模型格式、并行策略和服务监控。它更适合有运维能力的团队，而不是个人快速试用。
托管平台：不想维护 GPU 的选择
如果目标是快速验证某个开源模型，按调用计费的托管平台可以省去硬件和运维。它适合低频调用、模型对比和临时需求，但长期高频使用时需要重新核算成本。
选择时要注意模型版本、冷启动延迟、数据是否会被留存，以及是否支持私有部署作为后续退路。
硬件之外的两个现实问题
第一是模型质量。能在本地跑起来的小模型，并不一定能在你的任务上达到可用效果。部署前应先用真实数据做一轮评估，再决定是否投入硬件。
第二是维护成本。模型更新、量化方案、驱动兼容和监控都需要持续投入。如果团队没有相应的人力，托管平台或商业 API 往往更划算。
