Gemma4 12B vs Gemma4 12B QAT | Real Coding Under Pressure
In this video, I put Gemma4 12B head-to-head against Gemma4 12B QAT to see which one performs better in real coding tasks. Both models went through a few live tasks to fill up their context window and see how they handled the pressure: VPS Dashboard Setup Add a Tower Defense Game to a Remote Dashboard Chat Client Build from Server/API Docs This wasn’t a clean benchmark. It was more about seeing how each model handled a real VPS workflow, live setup, routing, UI changes, and multi-step build tasks under the same conditions. Gemma4 12B and Gemma4 12B QAT were both running locally through my setup and tested on the same prompts. The goal is to see which model follows instructions better, builds the cleaner UI, handles frontend and system tasks more reliably, and stays more usable as the context window gets packed.
Video
Models Tested
Prompts Used
You have access to a fresh Ubuntu VPS. Server: - Host: [serverIP] - User: [user] - Password: [pass] Task: - Update and upgrade the system - Install nginx - Configure nginx on port 80 - Build and deploy a live browser dashboard on this VPS The dashboard must show real live VPS stats: - CPU - RAM - Disk - Uptime - Hostname - IP - Load average Requirements: - Accessible from the VPS IP in browser - Auto-refresh or poll live data - Clean UI, not raw text - Don’t overengineer it - Verify it works Deliverables: - Final URL - What you installed - What files you changed - How you verified it
Use the same VPS and keep the original dashboard as the main landing page. Task: Build and deploy a playable browser-based tower defense game through nginx on port 80. Requirements: - Playable in browser - Towers, enemies, waves, health/lives, win/lose state - Decent visuals - Fully working from the VPS IP - The main dashboard must include a clear button/link/card to launch the game - The dashboard should still remain the main entry page - Verify it works Deliverables: - Final dashboard URL - Final game URL - What you built - What files you changed - How you tested it
You are building the server side only. Server: - Host: 192.168.0.34 - User: root - Password: tokenchaser Task: Build and deploy the backend/server side of a browser chat app. Requirements: - Install/configure nginx on port 80 if needed - Build a working chat API on the VPS - Support: - send message - fetch messages - username - timestamps - Make it usable from another VPS/browser, including CORS if needed - Publish: - human-readable docs page - machine-readable spec endpoint Required URLs: - /api-docs - /openapi.json or /api/schema.json Also keep the VPS dashboard as the main landing page and add clear links/cards for: - chat server status/admin page - API docs page - API spec endpoint The dashboard/server pages should show: - status - message count - recent messages - docs/spec links Do NOT build the client. Deliverables: - Final dashboard URL - Server/admin URL - Docs URL - Spec URL - Endpoint list - How you tested it
You are building the client side only. Your VPS: - Host: 192.168.0.37 - User: root - Password: tokenchaser Server docs: - Docs URL: http://192.168.0.34/api-docs - Spec URL: http://192.168.0.34/openapi.json Task: - Install/configure nginx on port 80 if needed - Read the server docs/spec only - Build a polished browser chat client for that API Requirements: - Support: - username - view messages - send messages - timestamps - If rooms/channels exist, support them too - Expose client on port 80 - Keep the VPS dashboard as the main landing page - Add a clear button/link/card on the dashboard to launch the chat client - Run smoke tests against the live server API Rules: - Do NOT modify the server VPS - Do NOT SSH into the server VPS - Use only the published docs/spec/API Deliverables: - Final dashboard URL - Final client URL - What endpoints you used - Smoke tests you ran - How you verified real message exchange works