学校第一次准备接入大模型时，很容易从两个极端开始争论：一边认为数据留在校内才安全，应该立即买服务器；另一边认为调用云端 API 最省事，几行代码就能用上最强模型。两种说法都只讲对了一半。

本地模型和云端 API 不是两种信仰，而是两种技术与治理安排。真正的选择题不是“哪个更先进”，而是“这项具体业务要处理什么数据，需要多强的能力，谁来维护，故障以后怎么办”。如果这些问题还没说清，先买硬件或先充值都可能走弯路。

先分清：本地和 API 到底差在哪里

本地部署通常是把开放权重模型下载到学校控制的电脑或服务器上，由校内设备完成推理。输入和输出可以不经过互联网，模型版本、访问入口和日志也由学校自己管理。它的代价是硬件、安装、更新、监控和故障处理都要有人承担。

云端 API 则由供应商运行模型，学校的应用通过网络发送请求并接收结果。模型能力、算力扩容和底层更新主要由供应商负责，学校按调用量或合同付费。与此同时，输入内容会离开校内环境，数据如何处理、保存多久、在哪个区域处理，需要根据服务条款和实际配置逐项确认。

还有一种容易被混淆的情况：界面装在学校服务器上，背后仍然调用云端模型。这只能算校内部署了应用入口，不能算数据全程本地。判断时要沿着一次请求真正经过的节点去看。

第一道门不是算力，而是数据敏感度

可以先把准备输入模型的内容分成三档。第一档是公开或低风险材料，例如已经公开的政策、无个人信息的教案框架、虚构练习题。这类任务有较大的云端选择空间。

第二档是经过处理的校内材料，例如去掉姓名和班级后的学生共性错题、只保留字段结构的统计表、删除联系方式的活动报名模板。它们能否使用云端服务，仍要看学校制度、供应商的数据条款和处理目的，但至少可以先通过最小化、去标识化降低风险。

第三档是可识别学生或家庭的信息，包括姓名、照片、学号、健康情况、评价记录、家庭困难情况、账号和行为日志等。对这些内容，不能因为某个产品声称“不用于训练”就直接上传。训练用途只是数据处理中的一个问题，传输、存储、访问、删除、跨境和第三方分包同样要核查。没有明确授权和制度依据时，最稳妥的做法往往是不用模型处理，或在严格受控的本地环境中重新设计任务。

本地部署并不会自动变得安全

“数据不出校”很重要，但服务器放在校内并不等于安全工作已经完成。如果模型接口直接暴露在校园网，任何设备都能调用；如果所有教师共用一个账号，出了问题无法追溯；如果日志完整记录了提示词，敏感信息仍会长期留在磁盘和备份里。

本地方案至少要回答：谁能登录，哪些网段能访问，每名用户有多少调用额度，日志记录到什么程度，模型和应用如何更新，磁盘坏了怎样恢复，管理员离职后权限如何交接。还要对上传文件做类型和大小限制，避免模型入口变成任意文件堆放处。

以 Ollama 为例，官方文档说明本地运行时提示和数据由本机处理，也提供关闭云端功能的配置。但学校仍需确认自己使用的界面、插件、联网搜索和模型下载环节有没有额外外连。一个组件本地，不代表整条链路都本地。

云端 API 也不能只看“模型排名”

选择 API 时，模型回答质量当然重要，但学校还要读数据控制说明。不同供应商、不同产品线甚至不同接口，训练使用、日志保留和应用状态保存都可能不同。以 OpenAI API 为例，官方说明默认不使用 API 输入输出训练模型，但常规滥用监控日志可保留最多 30 天，部分接口还会保存应用状态；符合条件的组织可以申请更严格的数据保留控制。这里的重点不是替某个供应商背书，而是说明“不训练”不能代替完整的数据审查。

还要检查账号体系、项目密钥隔离、预算上限、调用日志、服务可用地区、模型版本固定方式和供应商退出方案。不要把一把全校通用的 API Key 写在前端或发给教师个人使用。密钥应该只保存在受控的服务端，由学校自己的应用完成身份认证、额度管理和审计。

六个维度放在一张表里比较

选型会议如果只讨论“能不能跑”，结论通常会偏向某台设备或某个模型。把下面六个维度同时摆出来，更容易看见真实成本。

不要先问买什么卡，先做真实任务测试

本地模型需要多少硬件，没有一个脱离任务的统一答案。同一模型在不同量化、上下文长度和并发数下，速度与内存占用都会变化。Ollama 官方文档也说明，模型文件可能占用几十到数百 GB，内存不足时请求会排队。对学校而言，最有意义的测试不是单人问一句“你好”，而是模拟一节课里二三十名学生在几分钟内集中提交。

可以选三类真实任务：一段中文教学材料摘要、一次带图片的信息识别、一项需要较长上下文的资料整理。分别记录首字等待时间、完整响应时间、失败率、答案质量和资源占用。云端 API 用同样任务测试网络延迟、限流和费用。只有在相同任务下比较，硬件和调用成本才有意义。

如果本地小模型只能完成分类、抽取和固定格式生成，也不必把它看作失败。稳定完成这些边界清楚的任务，可能比勉强承担复杂推理更有价值。

多数学校更适合从混合方案起步

混合方案不是两套系统都买齐，而是按任务分流。公开资料整理、教学创意和复杂多模态生成，可以在审查过的云端 API 上进行；校内知识检索、固定字段抽取和低风险日常问答，可以交给本地模型；涉及敏感个人信息的任务则优先改造数据、限制场景，必要时完全不接入大模型。

应用入口可以保持一致，后端根据业务选择模型。教师看到的是同一个校内门户，管理员却能为不同功能设置数据规则、模型路由、预算和权限。这样既不会让教师自己挑供应商，也能在某个 API 不可用或本地服务器维护时切换方案。

但“自动路由”必须可解释。每个功能旁边应写清会把什么数据发到哪里，不能让系统在教师不知情时把本地任务转到云端。

先做一个月试点，再决定长期投入

试点不必覆盖全校。先选一个数据风险低、价值清楚的场景，例如教师对公开资料进行摘要，或学生在课堂上比较无个人信息的模型回答。确定十到二十条典型任务，分别用一个本地候选模型和一个云端 API 运行。

一个月里记录五件事：实际使用人数、成功率与等待时间、教师节省或增加的步骤、模型错误类型、总费用与运维时间。试点结束后再决定是扩大云端额度、采购本地设备，还是暂时停止某类功能。没有使用数据时，三年硬件规划和年度 API 预算都只是猜测。

最后的判断，不是二选一

《中华人民共和国个人信息保护法》要求个人信息处理具有明确、合理目的，并与处理目的直接相关，采取对个人权益影响最小的方式。这个原则比“本地还是云端”的标签更重要：无论模型放在哪里，都应只处理完成任务所必需的数据。

本地模型给学校更多控制，也带来更多责任；云端 API 提供更强能力和弹性，也要求更仔细地审查数据条款、密钥和费用。成熟的选型不是找到一个永远正确的答案，而是让不同任务进入合适的通道，并且每条通道都有人负责、可以审计、能够退出。

参考资料

• 中华人民共和国个人信息保护法

• Ollama 官方文档：FAQ

• OpenAI API 官方文档：Data controls