Active infrastructure
Kraken local AI environment
A multi-node, mixed-generation environment supporting local models, research, documentation, software work, and agent coordination.
Projects
Systems that prove the work is real.
Kraken publishes projects by status: active, developing, proposed, or research. A concept is not presented as a finished product.
Active development
Web operations reference architecture
The permanent website design, monitoring, analytics, SEO, release, and maintenance system that will become a client-service foundation.
Active program
Technology collaboration and hardware partnerships
Evaluation hardware, development systems, loans, engineering collaboration, and lifecycle reuse of servers, GPUs, storage, networking, power, and rack equipment.
Founding and research
Project KATIA
Technology, resources, partnerships, and support concepts for separated children, families, and important adults.
Policy development
Katia’s Law
A policy initiative examining prevention, coordination, assistance, and accountability gaps in international parental child abduction and family separation.
Public evidence
Build journal
Sanitized records of meaningful work, decisions, tests, results, limitations, and next steps.
Engineering record
Measured results, published honestly.
Selected sanitized results from the Kraken engineering record. Every item below is backed by real measurements in the build journal and internal evidence store; none are marketing claims.
Long-context validation on 16 GB cards
Multi-needle recall certified at 80K and 128K tokens on a single Tesla P4 (3/3 correct retrievals, 80–81 °C peak, 44–55 W under load). The 196K attempt was documented as a model/runtime training-context cap, not a hardware failure — the boundary is published rather than hidden. On the 4× P100 node, a 35B-A3B model loads at 524K context and a 27B model is validated at 196K with real inference.
Multi-GPU engineering on 4× Tesla P100
A 64 GB P100 node (2× Xeon Gold 5122, 187 GiB RAM) runs measured model comparisons — 30B-A3B at ~50 tok/s vs ~31 tok/s for a larger alternative — and hosts a 284B-parameter deployment plan with 524K-context KV planning across all four cards. Along the way we found that a naive scheduler claimed ~150 GiB for a workload that measured ~51 GB — a 3× overestimate, documented and corrected for.
Thermal and lifecycle automation
P4 lanes idle-unload after 15 continuous quiet minutes (VRAM returns to ~7 MiB, GPU drops to its lowest power state) and auto-wake on demand with exact identity restoration and GPU-binding verification. A latent bug that had silently disabled unloads was found and fixed. Fans run at full duty only under load, auto-quieting to ~5,500–6,700 RPM at idle.
Heterogeneous fleet, one registry
A single lane registry manages Quadro M4000, RTX 3060/3080/3080 Ti/2080, Tesla P4, Tesla P100-16GB, and P102-100 accelerators across multiple nodes. No node is considered production-ready until host-level and container-level GPU visibility both pass fleet-wide validation.
Autonomous agent architecture, gated
Specialized agents produce, challenge, validate, and repair one another's work through a defined PLAN → IMPLEMENT → CHECK → AUDIT → REPAIR → REVALIDATE → IMPROVE cycle. Inter-agent transport uses the A2A v1.0 protocol with per-peer tokens, anti-loop caps, and signed outbound webhooks; a read-only validator agent holds veto power. The orchestration prototype was verified end-to-end in dry-run with zero API calls.
Negative results are published too
A community inference fork promising speedups was A/B-tested on a live lane: ~4.8 tok/s vs ~41 tok/s stock — roughly 8.5× slower. The rollout was stopped and the lane restored. A Qwen3.6-35B build produced blank tokens on P100 (chat-template incompatibility) and was rejected. What failed, what we changed, and what we learned are all recorded.