Three results,and the tests behind them.
Every figure on this page carries how it was arrived at: measured on named hardware, modeled from measured inputs, derived from published specifications, or reported by a customer.
up to 80%+ lower projected monthly inference costCustomer result. Projected monthly inference spend on Score, self-hosted, against the customer's previous hosted-API spend for the same record-processing workload. Accuracy judged against the original model on the same record set.
A medical records AI platform moved from a hosted API to Score.
2.7× more completed coding tasks per hour under peak loadPI coding agent, 100K-token context, Gemma 4-31B self-hosted. Scaled from 1× to 4× concurrent load on each platform: H100-SXM completion time rose from 142s to 1,434s; 2S Xeon 6960P running Score rose from 311s to 529s. Tasks per hour compared at 4× load.
Same coding agent, same 100K context, four times the concurrent load, one two-socket server.
3.9× more tokens per dollar in the named hardware comparisonQwen3-235B at 64K context, measured throughput. 8×H100-SXM: 132 TPS, $14.40/h, 33,000 tokens/$. 5× 2S Gen6 Xeon: 156 TPS, $4.40/h, 127,636 tokens/$. Assumes H100-SXM $320K/8 GPU/10.2 kW amortized over 3 years, Gen6 Xeon $35K/2 sockets/1.56 kW over 6 years, PUE 1.56, $0.14/kWh.
Five two-socket Xeon servers matching the throughput of one 8×H100 node, all costs included.
What happens when more people use the system at once.
PI coding agent, 100K context, Gemma 4-31B self-hosted
- H100-SXM, completion time
- 2S Xeon 6960P + Score, completion time
| Concurrent load | H100-SXM | 2S Xeon 6960P + Score |
|---|---|---|
| 1× | 142s | 311s |
| 4× | 1,434s | 529s |
Same agent, same 100K-token context, scaled from 1× to 4× concurrent load on each platform. The H100 exceeds its HBM budget past concurrency 2 and begins evicting KV cache; the Xeon holds every session cached. Curves are fitted to the two measured load points on each platform and shown across the measured range only.
Completion time from single load to four times load. Performance drops sharply after two simultaneous long-context sessions.
Completion time across the same load increase, on one two-socket server. Every session stays in memory.
What the same work costs, measured against what you pay today.
Each figure is an internal benchmark against a named baseline, with hardware, power and amortization all counted. Hover any figure for the exact configuration.
3.9× more tokens per dollarQwen3-235B at 64K context, measured throughput. 8×H100-SXM: 132 TPS, $14.40/h, 33,000 tokens/$. 5× 2S-GNR: 156 TPS, $4.40/h, 127,636 tokens/$. Assumes H100-SXM $320K/8 GPU/10.2 kW amortized over 3 years, Gen6 Xeon $35K/2 sockets/1.56 kW over 6 years, PUE 1.56, $0.14/kWh.
5× 2S Gen6-Xeon nodes matching the throughput of one 8×H100 system
11-17× lower cost than a foundation-model APISame coding benchmark, identical passing criteria. 4-socket Xeon running MiniMax M2.7 versus Claude Sonnet 4.6. Advantage widens with concurrency: 10.9× at 1 concurrent task, 17.1× at 16.
for identical coding-benchmark outcomes
17.1× cheaper for batch and overnight runsProduction-branch testing, 32 batch tasks, Claude Sonnet 4.6 versus MiniMax M2.7 self-hosted on Xeon with Score-SDK. Both Claude and DeepInfra can serve 32-way concurrency under premium contracts, completing in 60-80s; the Xeon run trades wall-clock for cost.
32 batch tasks: $1,920 on the Claude API versus $112 self-hosted on Xeon
4-6× additional savings versus hosted open-weight APIs4.3× at 1 concurrent task, 6.7× at 16, on the same coding benchmark.
self-hosted on Xeon + Score-SDK versus DeepInfra
~10-turn coding agent (Sonnet 4.6 class), pricing $3/M in, $15/M out. [GTM] p.4 Published provider prices. Reusing context alone removes most of the repeat cost; Score extends the same idea into ordinary server memory.
Same math, same order, every run.
Full BF16 precision scored 93% on the AIME 2025 set against 87% at FP8 and 80% at FP4 on the same model, which is where the 6-13% figure comes from. A fixed execution order means the same input gives the same output, run after run.
Cheaper inference usually means quantized weights. Ours doesn't.
6-13% more accurate than the quantized hosted alternatives, with no throughput penalty.
| Precision | Provider | Correct | Accuracy |
|---|---|---|---|
| BF16 | Score-SDK | 28/30 | 93% |
| FP8 | DeepInfra | 26/30 | 87% |
| FP4 | DeepInfra | 24/30 | 80% |
Score-SDK retains full BF16 precision. Hosted providers commonly serve quantized weights to raise throughput, which costs accuracy.
Same input, same output, whatever else the machine is doing
| Run | Score-SDK | GPU baseline |
|---|---|---|
| batch 1 | a4f2…91c | a4f2…91c |
| batch 4 | a4f2…91c | a4f2…91c |
| batch 8 | a4f2…91c | 7b19…33e |
| batch 16 | a4f2…91c | c082…5da |
| batch 32 | a4f2…91c | 1e67…ab4 |
Why this matters
Determinism is a compliance requirement in financial and clinical workflows, an auditor needs the same answer twice. It is also a cost lever: drifting outputs trigger extra reasoning loops, which lengthen completion time and can produce wrong results in multi-agent chains.
What it costs you
Nothing. Deterministic execution on a GPU generally means giving up roughly half your inference throughput. Score executes in deterministic order by construction, at full throughput, with no flag to set.
Illustrative representation of output-signature stability under rising batch pressure. Score-BLAS, Score-NN and Score-CCL execute reductions in a fixed order independent of load. GPUs can be configured for deterministic execution, but typically lose around 50% of inference throughput when they are. Score has no such trade-off.
What changed for the customers who moved.
Some customers can be named and some cannot, a consequence of working with regulated data. Where we cannot name them, we still publish the numbers and say exactly what was measured.
A Gemini-API record-processing pipeline cut from $4,000 to $750, while accuracy went up
Before: hosted API
Records sent to a third-party endpoint
After: Score, on-prem
Records never leave the environment
| Measure | Before (hosted API) | After (Score, on-prem) |
|---|---|---|
| Monthly pipeline cost | $4,000 | $750 |
| Accuracy | 67% | 73% |
| Data residency | Leaves | Stays |
Customer-verified result, name withheld at the customer's request. Accuracy is judged accuracy against the original model on the same record set. Source: Score Labs technical introduction, July 2026, §5.1.
“Score Labs showed us that we did not have to trade quality for control or cost. We achieved better results than our previous model approach while reducing projected inference expense by more than 80%. Just as important, we now have a path to keep sensitive information within infrastructure we control and continuously improve the system around the needs of our customers.”
Founder & CEO, a medical records AI platform
accuracy, versus the original model
lower monthly cost
Confidential internal knowledge search at 6× lower cost than buying GPUs
lower cost than a GPU build-out
confidential data never left
Watch complete benchmark runs.
Real sessions captured end to end: same prompts, same models, same passing criteria, against a GPU or hosted-API baseline.
Deterministic, repeatable output in live Cursor sessions
The same coding session run repeatedly produces identical output, at full throughput. GPU output varies under higher load and batching.
- Hardware
- Score on Xeon versus a GPU baseline
- Workload
- Live Cursor coding sessions, repeated
8 concurrent coding sessions versus 2 on GPU
Score-SDK holds eight concurrent Cursor-like coding sessions on a single CPU server where the GPU baseline manages two.
- Hardware
- One CPU server versus a GPU baseline
- Workload
- Eight concurrent coding sessions
3× more concurrent knowledge-search sessions
Six concurrent RAG knowledge-search sessions on Score versus two on the GPU baseline.
- Hardware
- Score on Xeon versus a GPU baseline
- Workload
- Six concurrent knowledge-search sessions
Every figure, with how it was arrived at.
If a number appears anywhere on this site, it appears here with its model, workload, hardware and comparison basis. Full test configurations are available on request.
| Claim | Basis | Model, workload, hardware and comparison basis | Source | Published |
|---|---|---|---|---|
| up to 70% less to run the same AI workloads | Derived | Context caching alone removes 66.3% (Amazon Bedrock), 70.9% (Anthropic) and 73.9% (Google Vertex AI) of the bill on a ten-turn coding agent. Self-hosting on Xeon with Score-SDK, on the same coding benchmark with identical passing criteria, measured 10.9-17.1× lower cost than Claude Sonnet 4.6. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| up to 80%+ lower projected monthly inference cost | Customer result | Customer result. Projected monthly inference spend on Score, self-hosted, against the customer's previous hosted-API spend for the same record-processing workload. Accuracy judged against the original model on the same record set. | prototype.html, customer-approved, name withheld | Jul 2026 |
| 2.7× more completed coding tasks per hour under peak load | Measured | PI coding agent, 100K-token context, Gemma 4-31B self-hosted. Scaled from 1× to 4× concurrent load on each platform: H100-SXM completion time rose from 142s to 1,434s; 2S Xeon 6960P running Score rose from 311s to 529s. Tasks per hour compared at 4× load. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 3.9× more tokens per dollar in the named hardware comparison | Measured | Qwen3-235B at 64K context, measured throughput. 8×H100-SXM: 132 TPS, $14.40/h, 33,000 tokens/$. 5× 2S Gen6 Xeon: 156 TPS, $4.40/h, 127,636 tokens/$. Assumes H100-SXM $320K/8 GPU/10.2 kW amortized over 3 years, Gen6 Xeon $35K/2 sockets/1.56 kW over 6 years, PUE 1.56, $0.14/kWh. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 4-6× better CapEx and OpEx | Derived | System-level comparison at matched throughput. DDR5 costs 4-6× less per GB than HBM3; see the full CapEx/OpEx model in the cost calculator. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 8-16× more concurrent agents on the same hardware | Derived | Derived from memory capacity: a 2-socket x86 server addresses up to 6 TB of DDR5 versus 640 GB of HBM3 on an 8×H100 node. Long-context agents (100K-256K tokens) are memory-bound, so cached-session count scales with addressable memory. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 100% deterministic, the same answer every time | Measured | Score-BLAS (GEMM), Score-NN (kernels) and Score-CCL (collectives) execute reductions in a fixed order independent of load. GPUs typically lose ~50% inference throughput when configured for deterministic execution; Score-SDK has no such penalty. | Score Labs GTM benchmark deck, rev 1.4; Score Labs technical introduction, July 2026 | Jul 2026 |
| 2.7× more coding tasks per hour at 4× peak load | Measured | 48-core Xeon 6960P. Completion time on the H100 explodes by more than 10× past concurrency 2 due to HBM limits and KV-cache eviction. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 11-17× lower cost than a foundation-model API | Measured | Same coding benchmark, identical passing criteria. 4-socket Xeon running MiniMax M2.7 versus Claude Sonnet 4.6. Advantage widens with concurrency: 10.9× at 1 concurrent task, 17.1× at 16. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 17.1× cheaper for batch and overnight runs | Measured | Production-branch testing, 32 batch tasks, Claude Sonnet 4.6 versus MiniMax M2.7 self-hosted on Xeon with Score-SDK. Both Claude and DeepInfra can serve 32-way concurrency under premium contracts, completing in 60-80s; the Xeon run trades wall-clock for cost. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 4-6× additional savings versus hosted open-weight APIs | Measured | 4.3× at 1 concurrent task, 6.7× at 16, on the same coding benchmark. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 2-3× saved by dropping the foundation-model premium | Derived | Open-weight models at comparable quality to frontier APIs. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 3.9× more tokens per dollar | Measured | Qwen3-235B at 64K context, measured throughput. 8×H100-SXM: 132 TPS, $14.40/h, 33,000 tokens/$. 5× 2S-GNR: 156 TPS, $4.40/h, 127,636 tokens/$. Assumes H100-SXM $320K/8 GPU/10.2 kW amortized over 3 years, Gen6 Xeon $35K/2 sockets/1.56 kW over 6 years, PUE 1.56, $0.14/kWh. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 4.1× CapEx + OpEx difference per node | Modeled | Same model as tokens-per-dollar above. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| $25-35K to serve 12 concurrent coding agents | Modeled | System-level CapEx for the hardware required to hold 12 concurrent cached sessions of a 230 GB model. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| $50K-$675K per year, for ten engineers | Modeled | $2-$27 per session × 10 tasks per engineer per day × 10 engineers × ~250 workdays. Every turn re-sends the system prompt, skill files and accumulated history; fewer than 5% of tokens are genuinely new. | Score Labs GTM benchmark deck, rev 1.4; Artificial Analysis (third party) | Aug 2026 |
| 88-96.8% of coding-agent context is re-sent every turn | Third party | Artificial Analysis measurement of context reuse across leading coding agents. | Score Labs GTM benchmark deck, rev 1.4; Artificial Analysis (third party) | Aug 2026 |
| 15× less context-processing compute | Modeled | Modeled 20-turn coding session: turn 1 processes 100K new tokens, subsequent turns add 3-5K each. Without caching every turn recomputes the full accumulated context. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 10× prefill compute reduction | Modeled | Cached context is processed once and reused across subsequent turns, so per-turn prefill drops to the 1-2K of genuinely new tokens. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 4-6× lower $/GB than HBM | Derived | DDR5/LPDDRx sits on separate modules and scales independently of the compute die, so capacity is not bounded by package area the way HBM is. | Score Labs GTM benchmark deck, rev 1.4; Score Labs technical introduction, July 2026 | Aug 2026 |
| 6-13% more accurate than quantized hosted alternatives | Measured | AIME 2025, 30 questions, Gemma 4-31B. BF16 93% vs FP8 87% vs FP4 80%. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 2-4× Score-BLAS versus SGLang and oneDNN | Measured | 3D-tiled compute distribution maximising register and on-chip-cache reuse; extends GEMM to FP8 / MXFP4 / NVFP4 with in-place dequantization not natively supported in hardware. | Score Labs technical introduction, July 2026 | Jul 2026 |
| 100× Score-CCL versus Meta Gloo | Measured | Distributed synchronization and collectives benchmark. Scales MiniMax M2.7 and Kimi K2.7 linearly from one node to four; extends to 16+ nodes. | Score Labs technical introduction, July 2026 | Jul 2026 |
| 30-90% faster than the nearest CPU alternatives | Measured | Score-BLAS and Score-NN kernels combined with proprietary caching. | Score Labs technical introduction, July 2026 | Jul 2026 |
| 95 vs 42 tok/s MiniMax-M2.7 at batch 8 | Measured | SGLang ships day-0 GPU support but de-prioritizes CPU: MiniMax-M2.7 (native FP8), gpt-oss (mxfp4) and Gemma-4 do not run on its CPU path at all. | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
| 1S → 4S near-linear distributed scaling | Measured | Next release targets 8S scaling plus GLM 5.2 (753B-A40B) and Kimi K3 (2.8T-A50B). | Score Labs GTM benchmark deck, rev 1.4 | Aug 2026 |
Benchmarks are run across a rotation of open and licensed models and hardware configurations, never a single named model, so results reflect production variance rather than a best-case demo. Full methodology available on request. Measured: run on the named hardware. Modeled: computed from measured inputs. Derived: from published specifications. Customer result: reported by the customer and approved for publication. Dates are when each figure was published in the cited source. Test configurations are available on request.
Benchmark your workload.
Send us a real workload. We run it on your models, your context lengths and your concurrency, and hand you the numbers either way.