UCPH self-hosting
Living migration table from EU cloud to on-premises
The AIPLA prototype runs on two layers: the AI Protocol Platform template (application) and Multivac (infrastructure — model access, Ollama hosting, Firestore, BigQuery, Vertex AI RAG Engine, Cloud Storage). The template is cloud-agnostic and portable as-is. The migration target is to swap the Multivac infrastructure layer for UCPH-managed equivalents while keeping the template unchanged.
This page captures the component-by-component swap and what UCPH IT would need to provide. Half of the final handover package.
Status: living document. The component list now reflects what v0.1 actually runs (Firestore, BigQuery, Vertex AI RAG Engine, Cloud Storage — no Postgres in the cloud build); the migration efforts and UCPH equivalents firm up as the Architecture ADRs settle and UCPH IT responds with hosting capabilities.
Migration table
| Cloud component | Role in prototype | UCPH equivalent | Migration effort | Notes |
|---|---|---|---|---|
| Vertex AI (Gemini) | LLM + multimodal | Ollama on UCPH GPU server (Tiers 2–3, ADR-003) | Medium — depends on local-readiness fraction per task class | Capability gap depends on which local models reach the floor; see Evaluation |
| Cloud Run | Backend + frontend hosting (backend runs as a sidecar in the frontend service) | UCPH Kubernetes / VM | Low | Containerised; portable as-is |
| Firestore | Application DB — classes, activities, groups, skill + identity mirror | UCPH-managed Postgres | Medium | The app codes against a Firestore protocol (db/firestore_protocol.py), so the swap is one PostgresFirestoreClient adapter, already scoped as a typed checklist |
| Vertex AI RAG Engine (RagManagedDb) | Curriculum text RAG — chunk / embed / retrieve (ADR-017) | pgvector on UCPH Postgres behind the same retrieval-tool interface | Medium | Retrieval is one ADK tool (VertexAiRagRetrieval); the swap is bounded to that tool. pgvector is the documented target (ADR-010) |
| BigQuery | Anonymised chat logs + telemetry (ADR-005) | UCPH analytics DB (Postgres / ClickHouse) | Medium | Research-scale query surface; schema is group-ID-keyed, no PII |
| Cloud Storage | Chat-uploaded doc artifacts (ADK ArtifactService) + uploaded resources | UCPH NFS or S3-compatible | Low | Path abstraction in app |
| Cloud Logging / Cloud Trace | Operational logs + traces | UCPH ELK or similar | Low | Standard OpenTelemetry shipping |
| Firebase Auth (teachers) + anonymous group JWT (students) | Identity (ADR-001) | UCPH SSO (teachers) + the existing group-JWT path (students — no change) | TBD | Student side is already self-contained (custom JWT, no Firebase identity); only the teacher side rides UCPH SSO |
Self-host model picks — text vs. images
The Evaluation benchmark now pins which local models clear the ≥ 80% floor per tier — and it splits by modality. The key finding: no single open model does both text and figures well, so a self-host tier runs two models, routed by whether the question carries a graph/figure.
- The strong text models (deepseek-v4-flash, qwen3-32b/8b) are architecturally text-only — they cannot accept an image at all.
- The strong vision models (the qwen3-vl line) can do text, but fall 12–36 points below the text specialist at the same tier — every one of them drops under the floor on text. Multimodal training trades away physics/text reasoning.
| Tier | Hardware | Text model | Text | Image (VL) model | Images |
|---|---|---|---|---|---|
| 2 — server / cluster | multi-GPU | deepseek-v4-flash | 91 ± 2 | qwen3-vl-235b-a22b | 95 ± 6 |
| 3 — single GPU | ~1× A100 80 GB | qwen3-32b | 88 ± 6 | qwen3-vl-32b | 88 ± 0 |
| 3 — laptop | single 24 GB GPU | qwen3-8b | 83 ± 3 | escalate figures | (qwen3-vl-8b 63 ✗) |
So a UCPH GPU node serves two local models per tier behind one endpoint, routing figure items to the VL model. The laptop tier is text-only in practice — its VL option (qwen3-vl-8b at 63%) is below the floor, so figure questions there escalate to a bigger tier or a cloud call. Scores are 5-run means on the STX Fysik A benchmark (text n = 33, images n = 8 — the image axis is small, read it as directional). This tightens the migration table’s Vertex/Ollama row: the capability gap is two model slots per tier, not one.
Outstanding questions for UCPH IT
(JB has already pinged them; awaiting response. Populate as answers come in.)
- Do they have GPU-capable hosting for inference? Spec?
- What’s the institutional Kubernetes / container hosting story?
- Do they offer managed Postgres (with pgvector)?
- What’s the policy on cloud-to-on-prem migration timelines for live research projects?
- Is there an existing pattern for student-facing services that already meets data-protection review? (We may be able to piggyback rather than green-field this.)
When to trigger migration
The migration becomes worth doing when:
- UCPH IT confirms hosting availability with timeline
- Local-readiness fraction (per Evaluation) reaches a threshold per task class — likely 70–80% as a working bar
- Steady-state usage justifies fixed infrastructure cost over per-API spend
A July steer sharpens the timeline: the project has told the partner schools that when student data collection begins, it will run on locally installed models at UCPH or another secure location in Denmark, so student data is not sent to external AI services. That binds the migration (at least for the student-data path) to the data-collection start rather than leaving it open-ended.
Until then, GCP EU is the right place to be.