校内部署
由学校采购并在校园内部运行硬件，适合重视本地控制、内部集成和长期稳定使用的机构。
| 机构需求 | 独立AI设备 | 智安云科机构级思路 |
|---|---|---|
| 访问 | 个人设备或独立账号 | 统一服务与基于角色的访问控制 |
| 模型 | 逐台设备单独配置 | 获批模型目录，并可规划Gateway/路由层 |
| 知识 | 个人文件和提示词 | 按权限治理的学校知识集合 |
| 评估 | 分散工具与工作流 | 可规划共享的ZYK Assess身份、知识和报告体系 |
| 并发 | 受单台设备限制 | 围绕机构实际需求规划容量，并支持后续扩展 |
| 治理 | 设置和记录分散 | 集中管理身份、日志、内容控制、同意和政策 |
| 持续性 | 依赖本地个别运维人员 | 文档化运维、监控、备份、支持和生命周期规划 |
部署模式
工作负载可以运行在不同位置，学校端体验不必随之改变。
境内托管
按照商业计划设想，在中国境内基础设施上提供私有或逻辑隔离容量。适合试点，或不希望自行承担硬件运维层的机构。实际托管地点及适用要求需按具体项目确认。
混合部署
以本地容量为主，并在部署规则和数据要求允许的情况下结合托管备份、弹性容量或灾难恢复能力。
集团 / 区域架构
未来可在明确学校级数据与政策边界的前提下，为多个校区协调共享容量和治理。
了解集团与区域架构 →基础设施层
用户界面背后，需要哪些机构能力。
模型服务
根据工作负载选择合适的服务技术，运行经批准且可本地部署的语言、推理、编程、Embedding和媒体模型。
AI Gateway
拟议的模型路由层可帮助机构更换或组合获批模型，而不必反复重建用户工作流。
ZYK Knowledge
学校批准的课程、政策、评分标准和运营知识可以独立于模型本身进行治理。
ZYK Control
身份、模型权限、审计、内容控制、数据保留和运维政策可以位于模型层之上。
系统集成
可根据项目范围和准备程度连接SSO、LMS、API、班级名册、数据库及其他学校系统。
持续运维
监控、更新、性能管理、备份、恢复流程和支持共同构成持续服务，而非一次性设备交付。
进阶技术能力
保留实施与研发空间，但不把它们写成已经完成的产品。
模型微调 / LoRA
商业计划与技术工作保留了使用LoRA等方式进行模型定制的实施方向。是否值得采用，应取决于数据权利、可衡量的教育价值、治理风险和维护成本，而不是仅仅因为技术上可行。
媒体推理工作负载
除文本模型外，基础设施方向还包括图像、音频及其他媒体处理或生成工作负载。正式部署前需结合GPU显存、延迟、内容安全和实际场景完成验证。
ZYK AI Sandbox
战略架构保留受控实验环境，用于测试新模型、提示词、Agent和集成，并与生产服务及敏感数据分离，避免实验在未经批准的情况下直接变成机构部署。
多GPU与负载均衡
较大规模部署可探索多GPU推理、排队、工作负载分配和容量池，但架构与对外能力表述都应建立在真实并发和服务水平测试之上。
上述进阶项目属于保留的实施能力或content-v2战略方向。公开商业表述应限于已经完成技术验证、责任边界清晰并符合客户实际需求的部分。
容量与生命周期
先根据真实工作负载确定规模，再逐步演进。
先做试点
通过边界清晰的场景测量并发、模型质量、存储、电力、散热和网络需求，再决定扩容。
有计划地扩展
随着采用程度提升逐步增加GPU、存储或托管容量，避免第一天就过度采购。
持续评估模型
模型质量、效率和适用性变化很快，因此模型评估应成为生命周期管理的一部分。
提前考虑更新换代
服务器和GPU会老化，模型需求也会改变。架构目标是在硬件或模型更新时尽可能保留学校已经建立的机构层能力。
商业计划中的硬件示例和性能目标仅供规划参考。最终规格需结合当期工作负载测试、供应情况、供电与散热条件、网络评估及正式报价确定。