On-premise
School-owned hardware installed on campus. Appropriate where local control, internal integration and predictable long-term use are priorities.
Private AI infrastructure
The difference between an AI machine and an institutional AI service.
A powerful workstation can run a model. A school-wide service also needs identity, permissions, shared knowledge, predictable capacity, model governance, backups, monitoring, integration and a support model that survives staff turnover.
| Requirement | Isolated AI device | Institutional ZYK approach |
|---|---|---|
| Access | Individual machine/account | Central service with role-based access |
| Models | Configured per machine | Approved catalogue and potential gateway/routing layer |
| Knowledge | Personal files and prompts | Governed school knowledge collections with permissions |
| Assessment | Separate tools/workflows | Potential shared ZYK Assess identity, knowledge and reporting |
| Concurrency | Limited by one device | Capacity planned around institutional demand and expandable over time |
| Governance | Scattered settings and records | Central identity, logging, filtering, consent and policy controls |
| Continuity | Depends on local operator | Documented operations, monitoring, backups, support and lifecycle planning |
Deployment models
Choose where workloads run without changing the school-facing experience.
Managed hosting
Private/logically isolated capacity on China-based infrastructure as described in the business plan. Useful for pilots or institutions that do not want to operate the hardware layer themselves. Actual hosting location and applicable requirements must be confirmed per project.
Hybrid
Local primary capacity combined with managed backup, overflow or disaster-recovery capability where the deployment and data rules permit it.
Group / regional
A future architecture can coordinate shared capacity and governance across campuses while retaining defined school-level data and policy boundaries.
Explore group and regional architecture →Infrastructure layers
What sits behind the user interface.
Model serving
Approved locally deployable language, reasoning, coding, embedding and media models using serving technology selected for the workload.
AI Gateway
A proposed routing layer can help institutions change or combine approved models without rebuilding user workflows.
ZYK Knowledge
Institution-approved curriculum, policy, rubric and operational knowledge can remain governed separately from the model itself.
ZYK Control
Identity, model permissions, audit, filtering, retention and operational policies can sit above the model layer.
Integration
SSO, LMS, APIs, rosters, databases and other systems can be connected according to scope and readiness.
Operations
Monitoring, updates, performance management, backups, recovery procedures and support form part of the ongoing service model.
Advanced technical capability
Preserve implementation and R&D options without presenting them as finished products.
Model fine-tuning / LoRA
The business plan and technical work preserve model-customisation approaches such as LoRA. Whether they are appropriate should depend on data rights, measurable educational value, governance risk and maintenance cost—not merely technical possibility.
Media inference workloads
Beyond text models, the infrastructure direction includes image, audio and other media processing or generation workloads. Production use requires validation against GPU memory, latency, content-safety and use-case requirements.
ZYK AI Sandbox
The strategic architecture preserves a controlled environment for evaluating new models, prompts, agents and integrations away from production services and sensitive data, so experimentation does not silently become institutional deployment.
Multi-GPU & load balancing
Larger deployments may explore multi-GPU inference, queuing, workload distribution and capacity pools, but architecture and claims should be based on measured concurrency and service-level requirements.
These advanced items are preserved implementation capabilities or content-v2 strategic directions. Public commercial claims should be limited to elements that have completed technical validation, have clear responsibility boundaries and match the customer's actual requirements.
Capacity & lifecycle
Size for the workload you have — then evolve.
Pilot first
Use bounded workloads to measure concurrency, model quality, storage, power, cooling and network requirements before scaling.
Expand deliberately
GPU, storage and managed capacity can be increased as adoption grows rather than overbuying infrastructure on day one.
Evaluate models continuously
Model quality, efficiency and suitability can change quickly. A model-evaluation process should be part of lifecycle management.
Plan replacement
Servers and GPUs age; model requirements change. ZYK's architecture aims to preserve institutional layers when hardware or models are refreshed.
Hardware examples and performance targets in the business plan are indicative. Final specifications require current workload testing, supplier availability, power/cooling assessment, networking review and a current quote.