# Kairos / OpenWorkload: One Workload, One Cluster Decision **SYNTHETIC SAMPLE | Illustrative decision memo | September 18, 2026** All inputs are invented. No customer, employer, vendor quote or measured benchmark is represented. This demonstrates method, not delivered savings. ## Decision Should a batch document-classification workload retain its cluster, shrink it, or move to elastic capacity? **Provisionally choose A: four tuned always-on workers in the existing private environment.** Its modeled recurring cost falls by **$8,640/month (47.8%)**, while retaining single-worker-loss capacity under the assumptions below. Do not resize until the performance and security gates pass. ## Synthetic Inputs And Boundaries - **Demand:** 72,000 accepted classifications/day; 30-day month; 18-hour deadline after batch arrival. Same frozen model, document mix and quality rule. - **Fit:** independent shards, model fits one GPU, one GPU/worker and separate failure domains. Linear scaling and equivalent GPU performance are assumptions. This is batch inference, not interactive serving or multi-node training. - **Performance:** baseline 1,000 accepted documents/active GPU-hour; A/B hypothesis 1,500 through batching/length bucketing, without changing the model. Includes steady-state I/O and retries; excludes cold start. Quality and speed equivalence are unmeasured, including on B's different provider. - **Billing:** baseline/A $3.00 per GPU-hour; B $3.60. Storage $600/month for each; networking $200/month baseline/A, $800 B. B books all four slots for 14 hours/day, including one hour of cold start/data staging. No failure credits. Rates include host CPU/RAM; B assumes immediate capacity at batch arrival. - **Transition allowance:** A 40 engineering hours, B 80, each at an invented $150/hour internal labor cost; baseline zero. Spread once across three months for comparison; not a Kairos fee. - Capacity is releasable with no minimum commitment. Otherwise removed GPU hours represent reusable capacity, not cash savings. Taxes, support, licenses, ongoing staffing and dual-running are excluded; replace with actual costs. ## Decision Table All results are modeled from `inputs.json`; dollars are USD. | Metric | Baseline | A: Tuned | B: Elastic | |---|---:|---:|---:| | GPU workers | 8 | 4 | 4 | | Billed GPU-hours/day | 192 | 96 | 56 | | Processing hours available before stop/deadline | 18 | 18 | 13 | | Productive GPU-hours/day needed | 72 | 48 | 48 | | Productive time / billed GPU time | 37.5% | 50.0% | 85.7% | | Capacity/day with one worker lost at start | 126,000 | 81,000 | 58,500 | | Meets demand with that worker loss? | Yes | Yes | No | | Recurring compute/month | $17,280 | $8,640 | $6,048 | | Recurring compute + storage + network/month | $18,080 | $9,440 | $7,448 | | Nominal recurring cost/1,000 accepted documents | $8.37 | $4.37 | $3.45 | | One-time transition allowance | $0 | $6,000 | $12,000 | | First-three-month cost / 3 | $18,080 | $11,440 | $11,448 | This is allocation efficiency, **not measured GPU SM utilization**. Unit costs assume full delivery; B is not failure-qualified. Worker-loss capacity does not prove node/zone resilience. ## Transparent Arithmetic And Sensitivity For each option, with workers `n`, billed hours/day `h`, rate `p`, throughput `q`: ```text monthly volume = 72,000 * 30 = 2,160,000 accepted documents compute = n * h * 30 * p recurring = compute + storage + network productive GPU-hours/day = 72,000 / q productive-time ratio = (72,000 / q) / (n * h) processing window = min(h, 18) - warmup single-worker-loss capacity = (n - 1) * q * processing window cost per 1,000 = recurring / (2,160,000 / 1,000) transition = engineering hours * 150 first-three-month cost / 3 = (3 * recurring + transition) / 3 ``` - A saves $8,640/month, or 47.8%, versus the modeled baseline before transition. - A needs at least 1,333.34 accepted documents/GPU-hour with one worker lost (threshold rounded up to 0.01 precision). - A at 20% lower throughput delivers 64,800 documents with one worker lost: 7,200 short. - B needs 17 billed hours/day to survive that worker loss, including warmup. Booking all four slots for that window costs $8,744/month, not $7,448. - A's first-three-month total is $34,320; B's original 14-hour plan is $34,344, just $24 more and still fails the worker-loss gate. ## Security And Recommendation Gates | Option | Hypothetical architecture tradeoff | Evidence required before change | |---|---|---| | Baseline | Existing data boundary; idle capacity does not establish safety. | Verify identity scope, tenant isolation, private storage access and audit coverage. | | A | Same provider/region; denser batching must preserve tenant separation. | Verify short-lived identities, least-privilege access, approved images, encryption and tenant-separated queues/logs. Test cross-tenant denial. | | B | New provider/control-plane boundary and temporary staging. | Also approve region/subprocessors, private connectivity, key control, retention/deletion and endpoint exposure before confidential-data transfer. | These are review requirements, not verified controls or compliance findings. 1. **Performance/platform owners:** benchmark A's accepted outputs, wall time, retries, queue time, GPU counters and I/O. Preserve quality; complete full batches within the deadline with a worker lost at start. Validate correlated failures separately. Stop if memory, staging or scaling assumptions fail. 2. **Security owner:** approve the controls above; trial synthetic data first. Architecture review is not a penetration test or compliance certification. 3. **Budget owner:** confirm the complete bill and releasable capacity. Keep the baseline until gates pass; cost rollback/dual-running separately. Reconsider B only with security approval and a resilient booking schedule. Kairos provides independent AI infrastructure advisory: a decision memo, supporting analysis, prioritized recommendations and a readout. Benchmark execution, implementation and compute are separately scoped. No quote, capacity reservation, savings guarantee or engagement commitment is offered.