<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Spliced research</title><link href="https://splicedso.github.io/"/><link rel="self" href="https://splicedso.github.io/feed.xml"/><id>https://splicedso.github.io/</id><updated>2026-10-25T13:53:13Z</updated><author><name>Spliced</name></author><entry><title>Calibration doubles 2-bit accuracy, and 4-bit is still cheaper per answer</title><link href="https://splicedso.github.io/research/lattice-v0/"/><id>https://splicedso.github.io/research/lattice-v0/</id><updated>2026-10-25T00:00:00Z</updated><summary>Calibration doubles 2-bit accuracy at the same size, 21% to 42% on GSM8K. 4-bit is still cheaper per correct answer: a 2-bit token costs more energy.</summary></entry><entry><title>Per correct answer, how a model is served matters as much as its size</title><link href="https://splicedso.github.io/research/joules-per-correct-answer/"/><id>https://splicedso.github.io/research/joules-per-correct-answer/</id><updated>2026-10-25T00:00:00Z</updated><summary>Measured per correct answer, a 7B serving eight requests beats a 1.5B serving one, on two machines. Serving matters as much as size.</summary></entry><entry><title>Reading the prompt: what prefill costs, and when it dominates</title><link href="https://splicedso.github.io/research/prefill/"/><id>https://splicedso.github.io/research/prefill/</id><updated>2026-10-24T00:00:00Z</updated><summary>Reading the prompt: a prompt token costs about 40 times less than a generated one, yet at an 8000-token prompt prefill is 40% of a request's energy. Caching the prefix saves exactly that.</summary></entry><entry><title>The 8-bit cache does not win even when it fits an extra sequence</title><link href="https://splicedso.github.io/research/longest-contexts/"/><id>https://splicedso.github.io/research/longest-contexts/</id><updated>2026-10-24T00:00:00Z</updated><summary>A prediction that failed: at 65536 tokens an 8-bit cache fits a third sequence where f16 fits two, and still costs 1.58 times as much. The context long enough to force the batch down also erases what batching saves.</summary></entry><entry><title>The memory-bound regime: when a long context caps the batch</title><link href="https://splicedso.github.io/research/memory-bound/"/><id>https://splicedso.github.io/research/memory-bound/</id><updated>2026-10-24T00:00:00Z</updated><summary>When a long context caps the batch: a 12 GB card fits only 8 sequences of a 7B at 8k or 16k tokens. An 8-bit cache buys at most one batch doubling, and here that never pays for its 1.5 times penalty.</summary></entry><entry><title>Our first model: a distilled draft model, and what it did not fix</title><link href="https://splicedso.github.io/research/spliced-drafter/"/><id>https://splicedso.github.io/research/spliced-drafter/</id><updated>2026-10-24T00:00:00Z</updated><summary>Our first model: a 0.5B draft distilled from a 7B on one machine. Held-out loss 6% lower, acceptance about 3% higher. Real and small, and a higher confidence threshold did not help.</summary></entry><entry><title>A long context does not spend the batching saving, where the cache still fits</title><link href="https://splicedso.github.io/research/batching-and-context/"/><id>https://splicedso.github.io/research/batching-and-context/</id><updated>2026-10-24T00:00:00Z</updated><summary>Does a long context spend the batching saving? Not while the cache fits: batch 8 keeps 72 to 76% of its energy saving at 4096 tokens, against 75 to 79% at 64. Note 8's 60 times needs memory to run out.</summary></entry><entry><title>What a long context costs, and what an 8-bit KV cache does not save</title><link href="https://splicedso.github.io/research/context-depth/"/><id>https://splicedso.github.io/research/context-depth/</id><updated>2026-10-24T00:00:00Z</updated><summary>What a long context costs per token: 1.3 times at 16k on an RTX 5070 Ti, up to 1.9 times on an M5 Pro, too little to explain the datacenter's 60 times. An 8-bit KV cache saves no energy at batch 1 on either.</summary></entry><entry><title>Small models pay more per weight, on a discrete GPU too</title><link href="https://splicedso.github.io/research/model-width-on-nvidia/"/><id>https://splicedso.github.io/research/model-width-on-nvidia/</id><updated>2026-10-24T00:00:00Z</updated><summary>Note 6's width sweep on an RTX 5070 Ti. Small models pay up to 2.2 times more energy per weight, more than on the Mac for the 4-bit formats; Q4_0 is cheapest at every width; Q5_K_M beats Q6_K throughout.</summary></entry><entry><title>Same result, second tool: speculative decoding through llama-server</title><link href="https://splicedso.github.io/research/speculative-second-tool/"/><id>https://splicedso.github.io/research/speculative-second-tool/</id><updated>2026-10-24T00:00:00Z</updated><summary>Notes 7 and 9 repeated through llama-server, the program real deployments use. Every finding holds. Also why the same run could not run on our RTX machine.</summary></entry><entry><title>The same token, plugged in, and under batching</title><link href="https://splicedso.github.io/research/batching-without-a-step/"/><id>https://splicedso.github.io/research/batching-without-a-step/</id><updated>2026-10-24T00:00:00Z</updated><summary>An RTX 5070 Ti Laptop GPU on AC, and a batch sweep on CUDA. Plugging in buys 34 to 46% more speed for 23 to 33% more energy per token, and with the GPU at its ceiling from batch 1 the second request saves 43%.</summary></entry><entry><title>One flag fixes speculative decoding's energy problem</title><link href="https://splicedso.github.io/research/speculative-threshold/"/><id>https://splicedso.github.io/research/speculative-threshold/</id><updated>2026-10-24T00:00:00Z</updated><summary>A draft confidence threshold removes speculative decoding's energy penalty on every task tested. At about 0.5, speculation on prose becomes a free 1.3x speed-up.</summary></entry><entry><title>Tokens per megawatt-hour</title><link href="https://splicedso.github.io/research/tokens-per-megawatt-hour/"/><id>https://splicedso.github.io/research/tokens-per-megawatt-hour/</id><updated>2026-10-24T00:00:00Z</updated><summary>Every MLPerf LLM result with measured wall power. A B200 server buys 2.7 times the tokens per joule of an H100 NVL one, and the roofline says it must batch 58 or more sequences per weight pass.</summary></entry><entry><title>Faster is not cheaper: the energy of speculative decoding</title><link href="https://splicedso.github.io/research/speculative-decoding/"/><id>https://splicedso.github.io/research/speculative-decoding/</id><updated>2026-10-24T00:00:00Z</updated><summary>Speculative decoding with a draft model and with n-gram copying, on code, prose and edits. It can be faster and more expensive at once; copy-based drafting on an edit costs 32% of plain decoding.</summary></entry><entry><title>Small models pay more per weight</title><link href="https://splicedso.github.io/research/model-width/"/><id>https://splicedso.github.io/research/model-width/</id><updated>2026-10-24T00:00:00Z</updated><summary>Five formats across four model sizes. A weight in a 0.5B model costs up to 1.6 times one in a 7B; Q4_0 is cheapest at every width; the Q5_K_M against Q6_K order flips with width.</summary></entry><entry><title>The cost of unpacking</title><link href="https://splicedso.github.io/research/kernel-energy/"/><id>https://splicedso.github.io/research/kernel-energy/</id><updated>2026-10-24T00:00:00Z</updated><summary>Each format's matrix-vector kernel measured alone. Q4_0 and Q4_K read identical bytes at identical speed; Q4_K's unpacking costs 40% more chip energy. Explains note 2's largest residual and corrects its roof.</summary></entry><entry><title>Two machines, one token</title><link href="https://splicedso.github.io/research/two-machines/"/><id>https://splicedso.github.io/research/two-machines/</id><updated>2026-10-24T00:00:00Z</updated><summary>The study on an RTX 5070 Ti Laptop GPU. Q4_0 wins on both machines and a 4-bit token costs the same whole-machine energy on both; one Mac finding does not transfer.</summary></entry><entry><title>Does it hold? A model five times larger, and a second runtime</title><link href="https://splicedso.github.io/research/scale-and-runtime/"/><id>https://splicedso.github.io/research/scale-and-runtime/</id><updated>2026-10-24T00:00:00Z</updated><summary>The format study at 7B, where every finding replicates and the hardware is used better, and in MLX, where repeat runs do not yet agree, so only claims that survive both passes are made.</summary></entry><entry><title>Where the joules go: a roofline and an energy model for decode</title><link href="https://splicedso.github.io/research/roofline-and-energy-model/"/><id>https://splicedso.github.io/research/roofline-and-energy-model/</id><updated>2026-10-24T00:00:00Z</updated><summary>A decode roofline from measured bandwidth, and a validated energy model whose residuals isolate the cost of unpacking each format. Two wrong first attempts, kept in.</summary></entry><entry><title>Fewer bits is not fewer joules</title><link href="https://splicedso.github.io/research/formats-and-batching/"/><id>https://splicedso.github.io/research/formats-and-batching/</id><updated>2026-10-24T00:00:00Z</updated><summary>Eight quantization formats and batch sizes 1 to 8, energy at the chip and at the board. Chip-only measurement misranks F16 by 2x; batch 2 saves 1% per token and batch 8 saves 72%.</summary></entry></feed>
