Skip to main content
Optiscale
Log inContact us
Solutions
HPC Cluster Design · CPU supercomputersAI Supercomputer · GPU training & inference clustersParallel Storage · Spectrum Scale · Lustre · BeeGFS · VASTInterconnect · InfiniBand · RoCE fabricsSchedulers · Slurm · KubernetesApplication Workload · Reference diagrams by workloadSizing Calculator · 5-minute sizing + 5-year TCO
Products
Luxe Vision · Unified monitoring across heterogeneous resourcesLuxe Ray · Heterogeneous resource operations & unified controlLuxe Vantage · Usage & billing built on the AI/HPC schedulerLuxe Orbit · Heterogeneous software provisioning & parallel managementLuxe Series Overview · The unified 4-layer storyRequest a Live Demo · Vision · Ray · VantageRequest a Closed PoC · Orbit — 1:1 environment setup
Services
Architecture Consulting · Workload definition → specification designImplementation & PM · Vendor integration & project managementPerformance Tuning · Architecture & configuration optimization plus code-level performance gainsManaged Operations · Multi-year operations contracts
Resources
TCO Calculator · On-premises vs. the three major cloudsSelf-Check · 8-question workload assessmentApplication Workload Library · 6 workload diagramsWhite Papers · In-depth technical white papersBlog · Tech Notes · Engineering blogNewsletter · Biweekly infrastructure updates
BLOGIndustry

The RFP Price-Weighting Trap — Why 30% Is the Right Number

What happens when the price weighting in a public-sector RFP exceeds 50%. Designing a scorecard that yields infrastructure built to survive five years of operations.

Consulting Team··7 min read

A Common Failure, in One Line

> "They came in with the lowest bid, but after a year of operation, GPU utilization was stuck at 30%."

We've heard this sentence in more than half of the public-sector HPC/AI infrastructure projects we've seen. The cause is a single thing — an RFP scorecard where the price weighting is 50% or higher.

When Price Weighting Is Too High

1. Bidders cut specs to hit the lowest price. - Downgrading memory per GPU node, swapping the fabric from IB to cheap RoCE, reducing storage NSDs. 2. They hide operating costs. - Five-year maintenance gets left out, or FTE estimates are unrealistic. 3. The verification stage gets weaker. - Vague acceptance criteria become the seeds of later disputes.

The Weighting We Recommend (assuming five years of operations)

| Item | Weight | Notes |
|------|------|------|
| Technical evaluation | 60% | Specs, architecture, performance, scalability |
| Price (5-year TCO) | 30% | CapEx + OpEx combined |
| Company trust | 10% | References of similar scale, financial soundness |

The key is evaluating price on 5-year TCO. Comparing CapEx alone hides the inefficiency of the operations phase.

Questions Buyers Ask Often

Q. Isn't 30% too low?

When a cheap proposal comes in, it automatically earns at least one more point. Even at 30% there is enough separation. Raise it to 50% and the technical score loses its discriminating power, so price ends up deciding.

Q. Our organization's policy is 50% — what do we do?

If you can't cut the top-level category (price) down to 30%, restore discriminating power by adding qualitative items inside the technical evaluation (opinionated architectural reasoning, whether the bidder has operations-automation tooling, post-deployment support SLA).

State All Acceptance Criteria in the RFP

As important as the scorecard are the acceptance criteria.

- HPL efficiency ≥ 95% theoretical - NCCL all-reduce ≥ 94% peak (at a specified node count) - IOR write ≥ X GB/s - Metadata ops ≥ Y/s - Post-deployment SLA: 4-hour first response / 24-hour resolution

If these criteria aren't in the RFP, disputes will follow.

Tooling

/resources/rfp-template includes the 30% weighting model plus acceptance-criteria templates.

The RFP Price-Weighting Trap — Why 30% Is the Right Number | Optiscale