校內部署
由學校擁有並安裝於校園的硬件。適合重視本地控制、內部系統整合及可預測長期使用的機構。
| 需求 | 孤立AI裝置 | 機構級ZYK方向 |
|---|---|---|
| 存取 | 個別機器 / 帳戶 | 中央服務配合角色權限 |
| 模型 | 逐台設定 | 獲批准模型目錄及未來Gateway / 路由層 |
| 知識 | 個人檔案及提示詞 | 受治理、按權限存取的校本知識集合 |
| 評估 | 獨立工具及流程 | 可共享ZYK Assess身份、知識及報告架構 |
| 並發 | 受單一裝置限制 | 按機構需求規劃容量並逐步擴展 |
| 治理 | 設定及紀錄分散 | 中央身份、日誌、內容控制、同意及政策管理 |
| 持續性 | 依賴本地操作人員 | 文件化運維、監察、備份、支援及生命周期規劃 |
部署模式
工作負載可以在不同位置運行，而學校面向使用者的體驗保持一致。
受控託管
商業計劃描述的是位於中國境內基礎設施上的私有或邏輯隔離容量，可用於試點或不希望自行管理硬件層的機構。實際部署地點及適用要求須按項目確認。
混合部署
以本地容量為主，並在部署及數據規則允許時加入受控備援、高峰容量或災難復原能力。
集團 / 區域
未來架構可協調跨校共享容量及治理，同時保留清晰的校本數據及政策邊界。
了解集團及區域架構 →基礎設施層
使用者介面背後需要甚麼。
模型服務
按工作負載選擇服務技術，運行獲批准且適合部署的語言、推理、編程、嵌入及媒體模型。
AI Gateway
規劃中的路由層可協助機構更換或組合獲批准模型，而毋須重建使用者工作流程。
ZYK Knowledge
獲機構批准的課程、政策、評分準則及營運知識，可與模型本身分開治理。
ZYK Control
身份、模型權限、審計、內容控制、保留及營運政策可置於模型層之上。
系統整合
SSO、LMS、API、名冊、資料庫及其他系統可按項目範圍及準備程度連接。
持續運維
監察、更新、效能管理、備份、復原程序及支援應成為持續服務的一部分。
進階技術能力
保留研發與實施空間，但不把它們誤寫成現成產品。
模型微調 / LoRA
商業計劃與技術工作保留了以LoRA等方式進行模型客製化的實施能力。是否值得使用，應取決於資料權利、實際教育價值、治理風險及維護成本，而不是因為技術上可以做到。
媒體推理工作負載
除文字模型外，基礎設施方向亦包括圖像、音訊及其他媒體處理／生成工作負載；正式部署前需要按GPU記憶體、延遲、內容安全及使用場景驗證。
ZYK AI Sandbox
策略方向包括把新模型、提示詞、Agent及整合放入受控實驗環境，與正式服務及敏感資料分開，避免測試直接變成生產使用。
多GPU與負載均衡
較大規模部署可探索多GPU推理、排隊、負載分配及容量池，但必須以實際並發與服務水平測試為基礎。
上述進階項目屬已保存的實施能力或content-v2策略方向。公開銷售時應只描述已完成技術驗證、具明確責任邊界並符合實際客戶需求的部分。
容量與生命周期
先按實際工作負載配置，再隨需要演進。
先做試點
先以範圍清晰的工作負載量度並發、模型質素、儲存、供電、散熱及網絡要求，再決定擴展。
有計劃地擴容
隨採用程度增加，再增加GPU、儲存或受控託管容量，避免第一天便過度採購。
持續評估模型
模型質素、效率及適用性變化很快，因此模型評估應成為生命周期管理的一部分。
規劃更新與替換
伺服器及GPU會老化，模型需求亦會改變。ZYK架構方向是讓機構層在更新硬件或模型時仍能保留。
商業計劃中的硬件例子及效能目標只屬參考。最終規格需要根據當期工作負載測試、供應商供貨、供電與散熱評估、網絡檢視及正式報價確定。