Nev-2B (EryriLabs)

Composite (secondary)

6.9 · Composite rank #140

Cost and measurement conditions

$0.0092 per 1,000 decisions (estimated)

ESTIMATE (*est.), base-model market reference through the frozen pricing_v15 module (sha256 dcfcecb0..., the module in force; its base-model references are unchanged since the dae86740... module this row was first priced with - the two later re-freezes each added one hosted-API launch-list key and nothing else): declared base Qwen/Qwen3.5-2B-Base -> deepinfra:Qwen/Qwen3.5-2B USD 0.02/M input, USD 0.1/M output. The author's shim reports usage {calls, permutations, backend} and NO token fields at all, so the input tokens are counted OFFLINE with the author's own prompt code (nev.layout.single_prompts over hev.decider_layout.render_row) at the exact serving settings, and cross-checked against llama-server's own prompt-token counter delta from the measured pass; output tokens are 0, because one readout position per call is restricted to the option letters and nothing is returned as text (the pjev-2b convention and the 9 Oct CoS rule for native option-probability models). Estimated, not charged, and not a quote from the author. COMMON COST BASIS (v1.6.30): cost per 1,000 decisions is computed on the common 1,485 items of this draw, leaving out the 15 very long items (at least 76,358 input tokens as counted by the rows that answered them). They are the 15 items the Jev reference refused with max_tokens_exceeded, which the other rows that did not answer them refused or failed on; their tokens count for no row, whether the row refused or answered them, and a refused item still counts as a wrong answer for Intelligence. This row: USD 0.009234 per 1,000 decisions (0.143x the official cost cap USD 0.064595), against USD 0.009142 over all 1,500 items (v1.6.29).

x2 + 0.15 s (assumption, not measured)

Sandy, the evaluator's own SHARED CPU host (AMD Ryzen 5 3600, 6 cores / 12 threads, Zen 2, AVX2, no AVX-512), NOT a dedicated machine and NOT a GPU: other jobs ran beside it throughout and the 1-minute load average was sampled every 60 s (measurement receipts on file) - over this row's window of 199 samples it ran 6.89 to 35.91, mean 13.06. The author's own two documented processes, unedited: llama-server -m nev-Q8_0.gguf -c 8192 --port 8080 --metrics (llama.cpp b11372, the one build the author names; --metrics is the only addition and changes no model behaviour), and the author's shim PYTHONPATH=python python -m nev.serve --backend llama-server:http://127.0.0.1:8080 --gguf nev-Q8_0.gguf on port 8090, with --backend-arg timeout=900 (the author's own documented flag, raised from the 300 s default because a loaded shared box can otherwise turn an answerable item into a false refusal). llama.cpp chose n_threads=6, its own default; the author passes none. One request at a time from the unchanged runner. Isolation: a user+network namespace (unshare -Urn, loopback only - Sandy permits no privileged unshare -n), and the author's two processes additionally inside bwrap with a cleared environment, a read-only root, tmpfs /home and /tmp and read-only binds of only the GGUF, the llama.cpp build, the venv, its interpreter and the author's own python/ tree, so the sealed item directory does not exist inside that sandbox; the runner stays outside it and the author's code never sees the file. All three cuts were PROVEN before the sealed input was read (only lo, no routes, a name probe and a bare-IP probe both failing, and an ls of the sealed tree failing inside the sandbox) and the network cut was re-proven immediately before the first sealed request, with a synthetic smoke gate passed in between (custody #19428). 1,485/1,500 answered, the 15 refusals all HTTP 502 relaying llama-server's own 400 exceed_context_size_error. Raw p50 7.02 s / p95 15.29 s / max 56.88 s - this is the shared box, not the model, and it is not comparable to the GPU and API rows of this draw.