小团队共享本地大模型:3 到 10 人的容量、权限与成本 - 小团队共享本地大模型

小团队共享本地大模型:3 到 10 人的容量、权限与成本

一个人用一块显卡很简单。当三到十个人的团队想共用一个模型时,问题就变了:每多一个用户要多少内存?怎样防止外人使用?两个人同时提问会怎样?这一切要花多少钱?这篇关于 小团队共享本地大模型 的文章,用可以核对的算术、我们的参考价格,以及 Ollama 和 Open WebUI 文档里写明的行为,逐个回答这些问题。它不是案例研究:我们没有可以报告的客户部署,也不会编造。

核对说明:并发行为来自 Ollama 的 FAQ,基于角色的访问控制来自 Open WebUI 项目页面,均在 2026-10-30 读取。内存数字由前文各指南里的模型大小和 KV 缓存大小推算,是估计值,实际使用还会有运行开销。价格是 2026-10-30 的参考价。本文没有对团队服务器做压力测试,所以不提供速度数据,文中内容也不构成法律意见。

要点速览(更新于 2026-10-30)

  • 每个并行用户都要有自己的上下文内存:Ollama 文档说明并行请求会让上下文大小按并行请求数增加,所以四个人以 8K 上下文使用,KV 缓存大约是一个人的四倍。
  • 按我们的推算,14B 的 Q4_K_M 模型四人各 8K 约需 14.6GB,24GB 显卡比较宽裕;32B 模型四人约需 27.7GB,要用 32GB 或更大的显卡。

  • 在模型前面加账号和角色(Open WebUI 提供基于角色的访问控制和用户组),不要把推理端口暴露到网络,并为团队长大后换专用服务软件或云服务预留退路。

小团队共享本地大模型:服务器要做什么

共享服务器有四件事要做:把模型放进内存;同时服务多个请求,而不是让一个人卡住其他人好几分钟;知道是谁在使用;防止数据泄露给不该看的人。单用户部署只做第一件。

多数小团队用不上集群,只需要一台足够强的机器、一个带账号的网页界面,以及清晰的规则。图中的结构就能满足很大一部分场景:浏览器访问处理账号的网页界面,可选的网关增加日志和密钥,推理服务把请求排队交给显卡。

团队共享大模型服务的结构:浏览器经带账号的网页界面和网关到推理服务和 GPU
图 1:小团队共享服务的结构

如果你还没搭好单用户版本,请先看 Open WebUI 教程和 API 服务教程。对需要审计、合规和服务合同的组织,企业私有部署指南是更好的起点。

内存如何随用户增长

模型权重只加载一次并共享,但每个活跃的对话都需要自己的 KV 缓存。Ollama 的 FAQ 把这个效果说得很清楚:对同一个模型的并行请求处理,会让上下文大小按并行请求数增加,它举的例子是 2K 上下文加 4 个并行请求变成 8K,并分配额外内存。所以 N 个用户的内存大约是权重加上 N 倍的单用户 KV 缓存。如何计算 KV 缓存,见上下文长度指南;下表用 f16 缓存的大小来计算:Llama 3.1 8B 每个 token 128KiB,Qwen2.5-14B 192KiB,Qwen2.5-32B 256KiB。

模型(Q4_K_M) 权重 每人 8K 的 KV 四人合计 总量(推算) 适合的显存
8B 级 4.9GB 约 1GB 约 4GB 约 8.9GB 12GB 显卡
14B 级 8.6GB 约 1.5GB 约 6GB 约 14.6GB 16GB 偏紧,24GB 宽裕
32B 级 19.7GB 约 2GB 约 8GB 约 27.7GB 32GB 或更大
8B、14B、32B 模型在四人使用、每人 8K 上下文时的显存估算柱状图,带 16、24、32GB 参考线
图 2:四人同时使用的显存估算(推算)

有两点要注意。估算不包括运行开销和计算缓冲,所以要留出几 GB 的余量。而且不是所有用户都在同一时刻活跃:人们要阅读回答、要思考,所以同时发生的请求通常比账号数少。如果内存放不下,请求就会排队,或者每个用户的上下文必须缩短。队列满时 Ollama 会返回 503 错误,OLLAMA_MAX_QUEUE 变量可以调整队列长度。减少内存的办法包括换小一点的模型、缩短上下文和量化缓存,详见显存计算器指南。

为 3 到 10 人选硬件

合适的机器取决于你需要的模型。写草稿、做总结和问答,8B 到 14B 的模型往往够用,16GB 或 24GB 的显卡可以服务少数几个用户。需要更强的推理或编程帮助时,32B 级模型在多人同时使用时需要 32GB 或更多。两块显卡可以分担一个模型,见双显卡指南,但会增加复杂度。

档位 参考价(元) 内存 适合
RTX 5060 Ti 16GB 整机 10,853 16GB 显存 8B 到 14B 模型,2 到 4 个活跃用户
二手 RTX 3090 整机 14,299 24GB 显存 14B 模型,多个用户
RTX 4090 整机 33,214 24GB 显存 容量和 3090 相同,带宽更高
Mac Studio M5 Max 128GB 41,749 128GB 统一内存 大模型,同时使用的人较少
DGX Spark 128GB 42,500 128GB 统一内存 大模型,同时使用的人较少
RTX 5090 工作站 65,737 32GB 显存 32B 模型,多个用户
企业一体机 32B 档 150,000 视厂商而定 需要服务合同和合规
从 RTX 5060 Ti 整机到企业一体机的参考整机价格柱状图
图 3:团队服务器的参考价格档位

内存容量不等于速度。统一内存的机器能装下大模型,但内存带宽低于高端显卡,通常意味着每个用户的回答更慢;我们没有实测,所以不给出速度。价格是参考价,工作站和一体机这两行的来源较少,请只当作数量级。想比较整机,见一体机选购指南。

账号、角色和网络访问

推理端口绝不应该被团队直接访问。让模型服务只监听本机或私有接口,只暴露网页界面。Open WebUI 介绍了基于角色的访问控制和用户组,由管理员定义角色和权限,所以可以把管理员和普通用户分开。具体的注册和审批设置请查看它当前版本的文档,并且除非你想让陌生人创建账号,否则关闭开放注册。

再加上一些基本的做法。如果服务经过的不只是可信的有线网络,就使用 HTTPS,系统侧的做法见远程部署指南。给每个人单独的账号,绝不要共用密码,这样有人离开时才能收回权限。管理员账号只用于管理,不用于日常聊天。备份网页界面的数据,因为聊天记录和设置都在那里,并保持系统和软件更新。

数据和内容的规则

只有团队就“什么能放进去”达成一致,共享服务器才算私密。写一页纸的规定:哪些数据可以粘贴(比如公开文档和内部草稿),哪些不行(客户个人信息、凭证、有保密条款的合同),谁能看日志,聊天记录保留多久,有问题找谁。要记住,本地服务器仍然会把提示词和回答存在磁盘上,能访问这台机器就等于能看到对话。隐私指南讲了哪些内容留在本地、哪些不会。

关于个人数据和员工监控的规则因国家和合同而异,我们不能提供法律意见。如果团队处理受监管的数据或客户数据,把它放进任何 AI 系统之前,不管是本地还是云端,都请先问负责合规的人。

公平与排队

没有限制的话,一个人粘贴一份很长的文档就会拖慢所有人。设置合理的最大上下文,让并行请求数保持在内存允许的范围内,并告诉团队长任务放在不忙的时候。如果你的网关支持按用户限速,请使用;一些网页界面提供插件挂钩来实现,请查看该项目当前的功能。最初几周要观察队列,因为实际的使用模式比任何计划都更有教育意义。

一个算例(假设情景)

假设一个六人团队想要一个用于写作和总结的共享助手。这只是对算术的演示,不是真实部署的报告。六个账号不等于六个同时的请求;假设团队预计最多三个人同时等待回答。14B 的 Q4_K_M 模型权重约 8.6GB。三个并行请求、每人 8K 上下文,KV 缓存约为 3 × 1.5GB,即 4.5GB,所以在开销之前总共约 13.1GB。16GB 显卡偏紧;24GB 显卡则留有余地,可以用更长的上下文,或者再放一个小的嵌入模型。二手 3090 整机的参考价约 14,299 元,5060 Ti 16GB 整机约 10,853 元,差别是几千元换来的从容。

再假设团队以后想用 32B 模型处理更难的任务。权重约 19.7GB,加上三个用户各 8K 约 6GB,大约共 25.7GB。这就放不进 24GB 显卡了,也正是需要缩短每人上下文、换用更小的量化、或者更换硬件的地方。购买前做这个计算,可以避免团队部署里最常见的后悔:机器演示时没问题,但到了第二个、第三个用户就不行。

四周上线计划

不要第一天就向所有人宣布。第一周,只和两位志愿者一起安装和测试,设置上下文和并行参数,并在两人同时提出很长的问题时观察显存,确认负载下的内存使用。第二周,为试用小组添加账号,关闭开放注册,并写好一页纸的数据规定。第三周,扩大到全团队,观察队列并收集意见,调整最大上下文。第四周,复盘大家实际用它做什么,判断是否值得换更大的模型或再加一台机器,并定下下次复盘的日期。保留一份简单的变更记录,这样更新后出了问题能追溯。

谁来负责这台服务器

共享服务器需要一个负责人。指定一个人负责更新、备份、人员离开时的账号回收和答疑,再指定一个备份人选。没有这些,服务就会衰败:模型一直没更新,磁盘被旧模型占满,没人知道谁能重启它。提前决定维护期间怎么办,并告诉团队服务什么时候不可用。如果没有人愿意担任这个角色,这本身就是有用的信息:也许托管的云服务虽然有取舍,却更适合你的团队。

何时换成 vLLM 或云服务

Ollama 和 llama.cpp 适合几个人的团队。当更多用户同时到来,或者你需要最大限度地利用每块显卡时,专用的服务软件,比如我们vLLM 与 SGLang 入门里介绍的 vLLM,就是为批处理大量请求设计的。代价是配置更多,工作流以 Linux 优先。另一条路是敏感工作留在本地,把不敏感的重任务交给云 API,本地与云端对比讨论了这种取舍。如果一开始就基于兼容 OpenAI 的 API 搭建,迁移会容易得多,因为客户端只需要改一个基础地址。

常见错误

  • 只按一个用户来估算容量。 每个并行用户都要有自己的 KV 缓存。
  • 共用一个密码。 你没法单独收回某个人的权限。
  • 暴露模型端口。 只有网页界面或网关应当可以访问。
  • 一直开着开放注册。 找到地址的人都能创建账号。
  • 只按内存容量选择。 容量不等于速度,请用自己的工作负载测试。
  • 没有数据规定。 用户会把方便的东西都粘进去。

常见问题

多少人可以共用一块显卡?

取决于模型、上下文长度,以及大家实际同时发请求的频率。按我们的估算,14B 模型四个用户约 14.6GB,但我们没有对任何配置做过压力测试。

每个用户都需要单独的显卡吗?

不需要。权重是共享的,每个活跃对话只增加自己的 KV 缓存。限制来自内存,而不是账号数。

太多人同时提问会怎样?

请求会排队等待内存释放;队列满时 Ollama 返回 503 错误,可以用 OLLAMA_MAX_QUEUE 调整。

本地服务器自动就是私密的吗?

提示词留在你的硬件上,但也会存在那里,所以访问控制、备份和数据规定仍然重要。

应该用 Open WebUI 吗?

它是常见的选择,它的基于角色的访问控制和用户组适合小团队;具体设置请查看当前版本的文档。

什么时候该换成 vLLM 或云服务?

当请求经常排队、需要更好的显卡利用率,或者团队超出一台机器的能力时。

和我们聊聊

正在为团队规划共享服务器?欢迎到社区描述你的场景,或者发邮件到 admin@microaione.com。

参考资料:Ollama FAQ 中的并发说明、Open WebUI 项目、Open WebUI 文档、英伟达 GeForce RTX 5090。

类似文章