UnverifiedRTX 4070 12GB (Ada sm_89) + RTX 5070 12GB (Blackwell sm_120), layer-split via llama.cpp on Ryzen 5800XT Zen 3, 128 GB DDR4, Docker Desktop WSL2CUDA

ggml-org/gpt-oss-120b-GGUF :: gpt-oss-120b-mxfp4-00001-of-00003.gguf MXFP4 @ RTX 4070 12GB (Ada sm_89) + RTX 5070 12GB (Blackwell sm_120), layer-split via llama.cpp on Ryzen 5800XT Zen 3, 128 GB DDR4, Docker Desktop WSL2

Name: ggml-org/gpt-oss-120b-GGUF :: gpt-oss-120b-mxfp4-00001-of-00003.gguf (MXFP4) on RTX 4070 12GB (Ada sm_89) + RTX 5070 12GB (Blackwell sm_120), layer-split via llama.cpp on Ryzen 5800XT Zen 3, 128 GB DDR4, Docker Desktop WSL2 — inference benchmark
Creator: gotcontext.ai
License: https://creativecommons.org/licenses/by/4.0/

Submitted May 2026https://gotcontext.ai/benchmarks/runs/QzEU9S3gIsI

Decode

5.3tok/s

PP speed (tok/s)

—

Context

64ktokens

Batch

4096parallel

Top 94% for this config16 runs

Flash Attn

Raw benchmark output

llama-server --no-mmap -ngl 999 --n-cpu-moe 32 --batch-size 4096 --ubatch-size 4096 --tensor-split 0.55,0.45 --parallel 1

Not enough data yet to compare this combination. Submit more runs for this hardware + model to see a comparison.

Build diagnostics

Your build is within the typical range for this hardware. No obvious configuration issues detected.

Reproducibility recipe

Copy this to repeat or submit a similar build:

model: "ggml-org/gpt-oss-120b-GGUF :: gpt-oss-120b-mxfp4-00001-of-00003.gguf"
quant: "MXFP4"
hardware: "RTX 4070 12GB (Ada sm_89) + RTX 5070 12GB (Blackwell sm_120), layer-split via llama.cpp on Ryzen 5800XT Zen 3, 128 GB DDR4, Docker Desktop WSL2"
context_length: 65536
batch_size: 4096

Notes from submitter

Official seed run — gotcontext.ai lab rig (RTX 4070 Ada + RTX 5070 Blackwell, layer-split, Ryzen 5800XT, 128GB). Sweep across 4 iterations: --cpu-moe (all experts CPU) = 4.6 tok/s, --n-cpu-moe 35 (1 layer GPU) = 5.0, --n-cpu-moe 32 (4 layers GPU) = 5.3 (current stable), --n-cpu-moe 30 (6 layers GPU) = OOM-killed mid-decode. Each expert layer ~1.6 GB at MXFP4 and always lands on CUDA1 regardless of --tensor-split (CUDA1 ~93% full, CUDA0 ~36%). carteakey.dev's --n-cpu-moe 21 number was on single 24GB RTX 3090 (unsplit pool absorbs larger contiguous allocations). Ctx reduced 131K→65K to free ~1.2 GB VRAM for extra GPU expert layers. First load reads 60 GB from disk into DRAM (1-3 min). PCIe-bound by per-token expert streaming over DDR4.

Discussion

No questions yet. Ask the first one.

See all ggml-org/gpt-oss-120b-GGUF :: gpt-oss-120b-mxfp4-00001-of-00003.gguf benchmarks Submit your build

Those are our numbers. Get yours.

Paste one of your own docs below and see your real compression ratio live — free, no signup.

Your text

# Service Operations Runbook: Payments API

## Purpose and scope

This runbook covers the payments-api service: what it does, how it is deployed, what its dependencies are, and what to do when it misbehaves. It is written for the on-call engineer. Every procedure here assumes you have production read access and the ability to trigger a deploy through the standard pipeline. Nothing in this document requires direct database write access, and no procedure here should be improvised under pressure: if the situation is not covered, page the service owner rather than inventing a fix at 3am.

The payments-api accepts charge requests from the checkout frontend, validates them against the pricing catalog, forwards them to the payment processor, and records the outcome in the orders database. It is the only service permitted to talk to the processor. Average traffic is steady during business hours with a daily peak around 19:00 UTC and a weekly peak on Friday evenings.

## Architecture and dependencies

The service runs as three replicas behind the regional load balancer. Each replica is stateless; all persistent state lives in the orders database and the idempotency-key store. The service depends on four things: the orders database (primary and one read replica), the idempotency-key store, the pricing catalog service, and the external payment processor. Of these, only the processor is outside our control.

Dependency failure behavior is deliberate and asymmetric. If the pricing catalog is unreachable, the service serves prices from its local cache for up to ten minutes and emits a degraded-mode metric. If the idempotency store is unreachable, the service refuses new charges entirely, because accepting a charge without idempotency protection risks double-billing, and double-billing is strictly worse than downtime. If the processor times out, the charge is recorded as pending and a reconciliation job resolves it within the hour.

## Deployment

Deploys go through the standard pipeline: merge to main, automated tests, staging deploy, a thirty-minute soak with synthetic checkout traffic, then production rollout one replica at a time. The pipeline aborts automatically if the error rate on the new replica exceeds the old baseline. A full rollout takes about twenty minutes. Rollback is the same pipeline in reverse and takes about six minutes; the on-call engineer can trigger it without approval.

## Monitoring and alerts

Three alerts page the on-call engineer. High charge failure rate fires when more than two percent of charge attempts fail over five minutes; the usual causes are a processor incident or a bad deploy, in that order. Idempotency store unavailable fires immediately on connection failure. Reconciliation backlog fires when pending charges older than ninety minutes accumulate, which usually means the reconciliation job is stuck rather than the processor being slow.

2,912/12,000 chars

Compressed

Compressed text will appear here…