本地大模型部署怎么选？先看工作负载，再选运行框架

团队讨论本地大模型时，最常见的开场是“我们要不要买一台 GPU 服务器”。这其实把问题问晚了半步。先要弄清楚准备让模型做什么、每天大致有多少人使用、一次任务允许等多久、哪些数据不能离开内网。用途不同，最后需要的机器和运行方式可能差很多。

“本地”先说清楚部署边界

有的团队只想让研发在笔记本上试试模型；有的想在办公室工作站上处理少量内部文档；还有的需要为多个部门提供持续服务，并把调用纳入统一身份、监控和变更管理。它们都可以被称为本地运行，却不是同一种部署。个人验证通常看启动速度和易用性，部门试点要看稳定性与并发，内网服务还要考虑高可用、访问控制、资源隔离和补丁升级。

在早期试用里选一个易安装的桌面运行工具，往往能更快回答“模型对这类任务有没有帮助”。当团队开始讨论共享服务，再考虑将模型服务放到专用工作站或机房；若请求量、延迟目标和并发都已明确，才值得评估更偏服务端的推理栈。先把使用规模说清楚，可以避免把概念验证的配置直接当成生产架构。

内存不是只看模型参数

模型文件的大小给出了大致的权重存储需求，却不是整台机器的内存预算。量化位宽会影响权重占用，运行时还需要上下文缓存、推理工作区和操作系统资源；上下文越长、同时处理的请求越多，缓存开销通常也越高。估算时可以先用“参数量 × 每参数位数 ÷ 8”理解权重的理论下限，再留出其他部分，最后用目标机器实测冷启动、长文本和并发。这个粗算适合筛选候选项，不能替代实际压测。

量化能让更大的模型进入有限显存，但模型大小变小不代表任务质量不变。对于需要依据内部资料作答、输出固定结构或调用工具的场景，应把量化版本放到同一组任务样本上比较。响应速度、回答质量和可用上下文需要一起评估；单看显存恰好装得下，容易低估真实运行成本。

运行框架要跟设备和服务方式匹配

在个人电脑上做第一轮验证，可以从安装门槛较低的运行工具开始。Ollama 的官方快速开始提供 macOS、Windows 与 Linux 的安装方式，并说明本地模型可以通过终端或本地 API 调用；llama.cpp 更适合希望控制 GGUF 模型、量化和跨硬件运行细节的团队。两者的目标和操作方式不同，选型时应先按设备与使用人群试跑，而不是只按社区热度排序。

Apple Silicon 设备还可以评估 Apple 开源的 MLX 与 MLX-LM，它们围绕苹果芯片提供本地机器学习与语言模型工具链。需要 NVIDIA GPU、多用户服务或更高吞吐时，vLLM 是常见的服务端候选，提供兼容多种接口的在线推理服务；但具体模型支持、显存占用、工具调用能力与部署方式仍要按实际版本核对。框架名称本身不能代替一次可重复的基准测试。

从一项任务开始算账

选型会上，与其争论“本地一定更安全”或“云端一定更方便”，不如拿一项真实任务把边界画出来：输入会包含哪些资料，输出由谁检查，哪些操作不允许模型执行，网络断开时业务要不要继续。随后用代表性样本分别测本地与现有方案的响应时间、稳定性、任务质量、维护投入和数据流向。模型运行在企业机器上，并不自动意味着周边日志、检索、更新和监控都不会访问外部服务。

较稳妥的路径通常是先在受控设备上验证一个窄任务，再决定是否需要共享推理服务。进入试点后，记录模型名称与版本、量化方式、运行时版本、机器配置和测试结果；如果这些信息都说不清，后续升级或回滚就很难复现。下一步可以继续看[本地大模型安装与测试](/resources/practices/local-llm-installation-testing-acceptance)，再把通过验收的模型接入具体业务。

宜天信达在企业智能体项目中，可结合客户的数据边界、既有算力和实际使用量评估本地模型部署方式。项目初期先用一项有明确验收条件的任务做小范围验证，比直接按峰值采购完整集群，更容易形成可信的投入判断。

官方资料

Ollama 快速开始；llama.cpp 项目说明与模型运行文档；Apple MLX-LM 项目；vLLM 在线服务文档。