Technical Preview
Independent research by Lucas RibeiroSome models have many specialized parts, but activate only a few at each step. Keeping them all on a graphics card takes a great deal of memory.
Horizon RunMap stores the parts compactly, computes without keeping expanded copies and controls what stays on the card; an intact source remains in computer memory.
Research, reports and sources
01 / The idea
A GPU does the AI calculations. Its memory, called VRAM, holds the model weights — learned numbers that guide the response — and temporary space for the computation. Some models have many specialized parts, called experts, although only a few are activated at each step.
If the weights do not fit on one card, keeping them entirely on GPUs requires more capacity. Another option is to bring them from computer RAM when needed, but that movement can also affect response time. The example below shows the capacity arithmetic before discussing the solution.
In MoE models, a selection of experts works on each token while the complete parameter set needs storage. Compare BF16 scale with each project’s published representation.
GLM-5.3744 billion total parameters · 40 billion active per token
16 bits · 2 bytes per parameter
Calculated scenario reserving 20%–30% of total memory and using complete servers. Context and workload guide final sizing.
FP8 · 8 bits
The vLLM recipe describes FP8 weights and FP8 KV cache for up to 1 million context tokens. Concurrency is tuned to the memory budget.
FP8 is the default checkpoint; Z.ai also publishes a separate BF16 version.
The comparison assumes all weights reside in GPU memory, ideally distributed across devices. Weights ≈ total parameters × bits ÷ 8. Each B200 provides a nominal 180 GB; each server groups 8 GPUs, totaling 1.44 TB. GB and TB use decimal units.
Minimum GPUs = weights ÷ 180 GB, rounded up. Servers with headroom = weights ÷ (1.44 TB × 0.80) through weights ÷ (1.44 TB × 0.70), always rounded up. The reserve is a planning assumption selected for this comparison.
Calculations use rounded published parameter counts rather than actual file sizes. Scales, mixed-precision tensors, buffers, KV cache (context memory) and parallel layout contribute to the execution budget. GPU count and response speed are separate dimensions.
For GLM-5.3, we use Z.ai’s stated 744 billion total and 40 billion active parameters. The vLLM recipe describes approximately 743/39 billion; this difference leaves the rounded GPU counts unchanged in this comparison.
B200 system capacity · NVIDIA ↗Frontier models show the scale of the memory and infrastructure challenge motivating Horizon RunMap. OLMoE and Qwen are the models used to investigate storage, transfer and execution on available hardware. Applying the architecture at larger scales requires separate validation; the rates below belong to the identified campaign.
Offers recorded on 2026-09-10, per platform or instance tier. The purchase and rental figures below have their own scope; a multi-server deployment also depends on networking and contracted services.
USD 6.69–6.99 / GPU-hour
Published-offer estimate
1 GPU × USD 6.69 to 6.99/GPU-hour × 1 hourLambda (opens in new tab)Primary source · Checked Sep 10, 2026
USD 6.79 / GPU-hour
Published-offer estimate
1 Runpod Secure Cloud B200 × USD 6.79/GPU-hour × 1 hourRunpod (opens in new tab)Primary source · Checked Sep 10, 2026
USD 38,534.4
Hypothetical
8 GPUs × USD 6.69/GPU-hour × 720 hours = USD 38534.40Lambda (opens in new tab)Primary source · Checked Sep 10, 2026
USD 390,000
Published-offer estimate
1 advertised eight-GPU HGX B200 platform × USD 390000/platformITCT Shop (opens in new tab)Primary source · Checked Sep 10, 2026
NVIDIA (opens in new tab)Primary source · Checked Sep 10, 2026
NVIDIA (opens in new tab)Primary source · Checked Sep 10, 2026
Lambda (opens in new tab)Primary source · Checked Sep 10, 2026
Runpod (opens in new tab)Primary source · Checked Sep 10, 2026
ITCT Shop (opens in new tab)Primary source · Checked Sep 10, 2026
GPU capacity, platform acquisition, rental, networking, electricity, cooling and operations are separate cost planes. This is not a complete quote, total cost of ownership or purchase recommendation.
02 / The solution
Horizon compacts routed experts while keeping the model's other parts outside that compression. The router selects which experts to use; custom kernels compute with their compact weights and scales.
Execution works with experts resident on the GPU. When memory is limited, the runtime can also keep the quantized source in RAM and bring over needed copies. The comparison below shows the capacity difference for the same model.
Non-routed parts stay outside the compression; selectively used experts receive a smaller representation.
Expert weights and scales use distinct formats: compact weights and FP16 scales.
The router chooses experts; the custom kernel combines their weights and scales with FP16 activations.
With room available, experts stay on the GPU. When needed, the runtime keeps the quantized source in RAM and brings over copies on demand.
03 / Architecture
The model combines non-routed parts executed in FP16 with experts whose weights are compact and whose scales are FP16. The router selects experts for each step; the custom kernel uses their activations and returns the result to the rest of the model.
The main execution path
In the measured configurations, compression is selective. It reduces routed experts while weights in the other parts follow the FP16 path.
Attention, embeddings and other components do not enter expert compression.
Weights stay compact on the GPU. Scales determine how those values are interpreted during computation.
The router selects which experts work on this piece of the response.
The custom kernel reads compact weights and scales, uses FP16 activations and returns the result to the rest of the model. It does not keep an entire expanded expert on the GPU.
When the weights and execution space fit on the GPU, all compact experts can stay resident. The kernel works without fetching experts during the response.
In the partial-residency flow shown, the source of expert weights in RAM stays complete and immutable. A copy passes through bounded pinned host staging before transfer to the GPU. Eviction discards the GPU copy, with no transfer back or source writeback.
Residency is not activation: the cache may keep experts that this step does not use. This diagram explains organization; the campaign below measures partial and complete residency while preserving executor differences.
Optional cache contract · resident-qpacked-cache-v1 · ADR 0009. Original scope: experimental, default-off P0 Qwen. The executors measured below are described by their specific contracts.
The complete qpacked set stays in process RAM, with validated identity and layout.
A temporary pinned arena prepares transfer. It becomes reusable only after completion.
The qpacked row reaches temporary GPU storage; readers still see the previous generation.
After routed-group completion, one transition publishes the new complete cache generation.
Readers use a valid generation. An evicted copy is reused only after its consumers retire; the source is not rewritten.
Capacity is fixed before requests. Insufficient staging or spare capacity rejects startup; failures before publication preserve the previous generation.
Earlier profiles have a different contract: offload-qpacked materializes FP16/BF16 execution slots from a quantized source. In the qpacked cache described here, experts remain compact. The kernel converts the values needed during computation without retaining a complete expanded expert slot. That conversion does not recover information lost during quantization.
Read decisions, sources and limits (English) ↓04 / Results
The execution, memory and speed figures below come from a published RTX 5070 campaign covering OLMoE and Qwen configurations. Each result identifies its model, executor and measurement conditions.
The same principle was measured with all specialized copies on the card and with only some of them on the card.
The cards show different models and computation paths. Read each rate with its own model, memory and setup; they are not a direct model-to-model comparison.Full residency
The compact parts stayed on the graphics card during generation.
Computation path: compact experts computed in groups
64/64 experts per layer · Grouped T3
61.26 tokens/s
Decode after the first token
Whole-device peak memory · 5.99 GiB
Inspect this resultFull residency
The compact parts stayed on the graphics card during generation.
Computation path: compact experts computed in groups
64/64 experts per layer · Grouped T3
62.07 tokens/s
Decode after the first token
Whole-device peak memory · 6.01 GiB
Inspect this resultPartial residency
Some copies stayed on the graphics card while others were brought over when needed.
Computation path: compact experts computed together
39/60 experts per layer · top4-fused-v1
19.95 tokens/s
Decode after the first token
Whole-device peak memory · 8.99 GiB
Inspect this resultHighest measured residency for each model · RTX 5070 · 36 responses of 128 tokens per configuration. OLMoE and Qwen use different executors; each card describes its own run.
468
measured responses · campaign volume
Public measurement under contract · Independent reproduction not attempted
36 responses of 128 tokens per configuration · 12 prompts × 3 blocks · 39 warmups excluded from rates.
Decode divides the sum of tokens after the first by the sum of internal generation times. It is a pooled, time-weighted rate. First-token wait and response duration are request means, with internal boundaries specific to each executor.
Observed relative block spread: 0.27%–4.78%. This is observed variation, not a confidence interval. Recorded maximum temperature: 58 °C.
The consolidation recorded matching token sequences between repetitions of each configuration. This observation describes within-configuration consistency; quality evaluation and output comparisons across configurations have their own scope. Other-stage time is calculated as the remainder of controller duration.
Tokens are small pieces of text, not always whole words.
05 / Memory and movement
Keeping more parts on the graphics card uses memory and can reduce transfers. The recorded configurations show how memory, movement and response times changed together. Each result identifies its computation path.
36 responses per configuration · 128 tokens per response · 3 blocks
Hardware · NVIDIA GeForce RTX 5070, as recorded in the campaign; shared Windows desktop.
Post-first-token decode · tokens/s
Pooled rate: Σ(tokens − 1) / Σ(internal decode time). Excludes first-token wait; not a mean of individual rates.
Measurements after warmup, with fixed prompts. Research scope
Resident experts per layer · discrete measurements, without interpolation or cross-model comparison.
The table includes every configuration. On narrow screens, scroll the table sideways.
| Model / executor | Resident experts per layer | Pooled post-first-token decode (tokens/s) | Internal TTFT — mean (s) | Internal 128-token response — mean (s) | Peak VRAM¹ (GiB) | Source |
|---|---|---|---|---|---|---|
| OLMoE 0924PRODUCT-core scalar | 30/64 | 23.00 | 6.17 | 11.69 | 4.11 | JSON |
| OLMoE 0924PRODUCT-core scalar | 40/64 | 27.69 | 4.49 | 9.07 | 4.62 | JSON |
| OLMoE 0924PRODUCT-core scalar | 50/64 | 31.50 | 3.62 | 7.65 | 5.15 | JSON |
| OLMoE 0924PRODUCT-core scalar | 60/64 | 35.01 | 3.00 | 6.63 | 5.67 | JSON |
| OLMoE 0924Grouped T3 | 64/64 | 61.26 | 0.75 | 2.82 | 5.99 | JSON |
| OLMoE 0125PRODUCT-core scalar | 30/64 | 23.04 | 6.07 | 11.58 | 4.15 | JSON |
| OLMoE 0125PRODUCT-core scalar | 40/64 | 27.12 | 4.53 | 9.21 | 4.62 | JSON |
| OLMoE 0125PRODUCT-core scalar | 50/64 | 31.22 | 3.59 | 7.66 | 5.15 | JSON |
| OLMoE 0125PRODUCT-core scalar | 60/64 | 35.44 | 2.97 | 6.55 | 5.67 | JSON |
| OLMoE 0125Grouped T3 | 64/64 | 62.07 | 0.70 | 2.74 | 6.01 | JSON |
| Qwentop4-fused-v1 | 20/60 | 15.22 | 9.42 | 17.76 | 7.11 | JSON |
| Qwentop4-fused-v1 | 30/60 | 17.17 | 7.51 | 14.90 | 8.08 | JSON |
| Qwentop4-fused-v1 | 39/60 | 19.95 | 5.80 | 12.17 | 8.99 | JSON |
¹ Driver-observed VRAM over the whole worker, including preparation, warmup and shared desktop use. Not process-exclusive or decode-only VRAM.
allenai/OLMoE-1B-7B-0924-Instruct7f1c97f440f06ce36705e4f2b843edb5925f4498artifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0924-Instruct7f1c97f440f06ce36705e4f2b843edb5925f4498artifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0924-Instruct7f1c97f440f06ce36705e4f2b843edb5925f4498artifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0924-Instruct7f1c97f440f06ce36705e4f2b843edb5925f4498artifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0924-Instruct7f1c97f440f06ce36705e4f2b843edb5925f4498artifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0125-Instructb89a7c4bc24fb9e55ce2543c9458ce0ca5c4650eartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0125-Instructb89a7c4bc24fb9e55ce2543c9458ce0ca5c4650eartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0125-Instructb89a7c4bc24fb9e55ce2543c9458ce0ca5c4650eartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0125-Instructb89a7c4bc24fb9e55ce2543c9458ce0ca5c4650eartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
allenai/OLMoE-1B-7B-0125-Instructb89a7c4bc24fb9e55ce2543c9458ce0ca5c4650eartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
Qwen/Qwen1.5-MoE-A2.7B-Chatec052fda178e241c7c443468d2fa1db6618996beartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
Qwen/Qwen1.5-MoE-A2.7B-Chatec052fda178e241c7c443468d2fa1db6618996beartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
Qwen/Qwen1.5-MoE-A2.7B-Chatec052fda178e241c7c443468d2fa1db6618996beartifacts/residency-executors-39-20260911-01/consolidation-01/summary.jsonCampaign extract with original identifiers and source text in English. The full bundle and raw observations have separate availability.
06 / Follow a response
A response is built one small piece of text at a time. The model selects parts for each step, and Horizon coordinates where those parts are kept and how they are used.
From input to response: follow how the work is organized. The next diagram shows what happens to expert copies. See hits, misses and eviction
Text is split into tokens and processed by the model.
Routing chooses experts at each routed layer.
A GPU copy can be used when present. On a miss, it arrives from RAM through staging.
Layer calculations contribute to the next output. The process repeats.
07 / Back to the workshop
Now the workshop helps visualize the mechanism: the GPU is the workbench, RAM is the warehouse and experts are tools. A copy may be ready, need to be brought over or make room for another; the source remains intact.
The GPU does the calculations. VRAM is the memory workspace it uses.
RAM keeps the complete, immutable source of the expert weights.
Experts are parts of the model. Each step uses a selection of them.
Imagine a workshop: the workbench has limited room and tools stay in storage. Here, each tool represents a set of model calculations.
In every situation, the compact experts remain stored in RAM. This is the immutable source.
Hit
RAMSource intactGPUCopy availableThe requested expert already has a ready copy on the workbench. Computation uses that copy.
The source stays intact; this lookup needs no new transfer of the expert.
Miss
RAMSource intactGPUCopy receivedThe requested copy comes from RAM through transfer staging. It becomes usable when transfer finishes and the new complete cache state is published.
The source stays ready in RAM, including after the transfer.
Eviction
RAMSource intactGPUCopy releasedWhen it can safely be released, the copy leaves the workbench. Its location is reused only after the computations using that copy finish.
The source stays ready for another copy; weights do not need to return to the CPU.
08 / Model behavior
To use less graphics-card memory, Horizon keeps expert weights compact and uses custom routines to compute with them. Other parts of the model follow a higher-precision path. This change can affect responses, so we tested whether the model still follows instructions.
In the measured qpacked architecture, routed expert weights remain compact INT4 in RAM and GPU memory. Kernels use FP16 activations. Other model components stay outside this INT4 quantization.
Stored format, computation format and accumulation precision are separate decisions. Compact weights are converted inside the kernel when needed; the complete expert does not occupy a persistent expanded slot.
01 / Store
INT4
Weights of routed experts stay compact in RAM and on the GPU. Attention, embeddings and other components remain outside this quantization.
Expert weights: INT4 · scales: FP16
Understand the formats →02 / Compute
W4A16
Kernels are GPU computation routines. Horizon’s kernels use compact weights and convert the values needed during each operation, without retaining a complete expanded expert.
Compact weights → custom kernel + FP16 activations → output
Explore the computation path →03 / Organize
RAM → GPU
RAM keeps the complete source. The GPU uses copies of all experts or a subset, depending on the space reserved. The source stays ready after eviction.
Immutable source · disposable GPU copies
See hits, misses and eviction →W4: routed expert weights in INT4, with FP16 scales. The GPU cache retains that compact format.
A16: FP16 activations. Kernels convert weights during computation, with FP32 accumulation stages and explicit rounding. W4A16 alone does not describe all arithmetic.
Attention, embeddings, routing and other components stay outside INT4. In this campaign, non-routed weights are materialized in FP16 from the BF16 checkpoint.
IFEval gives the AI written requests, such as including a required word or using a set format, then checks each response. This published run completed all 541 requests, so we can inspect how often the model followed every instruction in a request.
247 of 541 responses satisfied every instruction under loose evaluation.
Score from the published OLMoE run, separate from the other RTX 4060 computer.
All 541 requests were completed, and every response can be inspected. The score shows how often this configuration met the written requirements in this test.
| Evaluation | Passed / evaluated | Accuracy |
|---|---|---|
| Prompts · strict | 217/541 | 40.11% |
| Prompts · loose | 247/541 | 45.66% |
| Instructions · strict | 433/834 | 51.92% |
| Instructions · loose | 474/834 | 56.83% |
IFEval checks requirements such as required words, section counts and formatting. A prompt passes when all its instructions pass. Instruction-level scores count each requirement separately. Strict checks the response directly; loose applies predefined presentation adjustments.
Horizon’s 45.66% sits numerically between two published IFEval figures for OLMoE 0924: 45.29 and 48.1. This is an encouraging reference point for the compact-expert configuration.
External references, evaluated under separate contracts. The later table does not specify the IFEval variant; these figures contextualize the result rather than establish a matched BF16 comparison.
OLMoE-1B-7B-0924-Instruct · 64/64 experts per layer · Grouped T3 · INT4 expert sources / FP16 activations. Greedy decoding, no input truncation, up to 1,280 new tokens per prompt. All 541 prompts are included in the scores.
467/541 responses ended naturally at EOS; 74/541 reached the token limit. All 11 execution shards completed, with zero recorded per-request fallback, cache misses/fills or expert H2D transfers.
The benchmark measures instruction following. Factual correctness and quality equivalence to a matched BF16 run are separate evaluation questions.
E1 · standalone benchmark · verified and published under its contract. Independent reproduction of generation: not attempted.
Revision · 7f1c97f440f06ce36705e4f2b843edb5925f4498
The bundle contains the original responses, prompts, per-instruction scores, frozen evaluator sources, licenses and a CPU verifier. With the pinned Python dependencies installed, the verifier recalculates all four scores offline, without a model or GPU.
SHA-256 · 9dcdb178a5469ca57c74c1e72ed2956cc94539b16607fdee7771b3b5442c8ed2An earlier study gave the same 120 requests to Horizon and the original BF16 model. It checked whether each response followed the required structure and ended normally.
Conformity here means a completed, non-empty response containing one strict JSON object and ending naturally at EOS. It measures the requested format and termination; answer correctness was not graded.
This study is separate from IFEval and the performance campaign.
The 8 losses are 8/29 of the cases where BF16 conformed (8/120 overall). All eight Horizon outputs fail strict JSON parsing; three also reached the token cap. These are format or termination regressions, with no verdict on answer correctness.
A shared failure is not a regression attributed to Horizon. Of the 86 divergences without a quality direction, 82 fail conformity in both arms and 4 conform in both with different JSON values. Different wording or content alone does not establish worse quality.
| Classification | Pairs / 120 |
|---|---|
| Identical output tokens | 16 |
| Horizon conformity gain | 7 |
| Horizon conformity loss | 8 |
| Different outputs; neither conforms | 82 |
| Different JSON values; both conform | 4 |
| Equivalent JSON values | 3 |
19/120 pairs have observable parity: 16 identical token sequences and 3 equivalent JSON values under the frozen numeric tolerance. Parity alone does not establish correctness.
120/120 requests completed in each arm. All 120 Horizon records show zero fallback, cache misses/fills and expert transfers to the GPU.
| Observation | BF16 | Horizon |
|---|---|---|
| Natural EOS | 59 | 54 |
| Reached 128-token cap | 61 | 66 |
| Empty responses | 0 | 0 |
OLMoE-1B-7B-0924-Instruct, identical prompt order and tokenizer input hashes, greedy decoding, up to 128 new tokens. Horizon: c64, all experts resident, Grouped T3, INT4 expert sources and FP16 activations. Reference: original BF16 checkpoint values through Transformers/Accelerate with the recorded CPU/GPU placement.
This E3 comparison describes this model, prompt set and configuration. The performance campaign above is a separate experiment. Answer correctness, longer outputs and general quality preservation require their own evaluation.
Revision · 7f1c97f440f06ce36705e4f2b843edb5925f4498
Inspect all 120 pairs and audit material →
Extract the ZIP, inspect the Python files, then run: python -B verify-bundle.py . — Python 3.10+, no packages, GPU or model required. It checks the original response hashes and recalculates all 120 paired classifications and the summary.
The original publication failed because its sanitizer misread JSON escape characters. This successor corrects that post-processing in CPU, with unchanged scoring and all 240 original generations preserved. Generation validation and this bundle’s verification passed. No new generations were run; independent reproduction has not been attempted.
Artifact lineage and hashes ↓olmoe-0924-fidelity-v2 · E3 · SHA-256
8105c554260e54974990560cfeca65b9302e9c7480663dad2a0bf1d8c8a939b209 / Applications
For organizations and individuals, the potential is to run AI models locally on a computer or infrastructure they control. Requests, documents and responses can stay in that environment instead of passing through an external inference service.
By reducing the memory required by experts, Horizon may make a smaller setup viable for the same application. If it meets the required speed and quality, purchase, rental and total infrastructure cost may fall. That gain needs to be evaluated for each model and workload.
Data under your control
An organization can work with internal documents on its own infrastructure; an individual can use files on their own computer. Local inference can keep requests and responses in that environment, with access and storage defined by its operator.
Discuss local applications →Right-sized infrastructure
Compact experts may make it possible to use existing cards or rent a smaller setup. Memory, speed, RAM and operations all enter the comparison to see whether infrastructure actually costs less for that model and workload.
See measured memory and speed →To inspect a complete run, the public app offers IFEval on validated setups. Explore the app →
10 / Next questions
Horizon has demonstrated its architecture in measured configurations and a complete instruction-following evaluation. Useful next tests include more hardware and models, longer requests, concurrent use and the full operating cost of a deployment.
The recorded results retain their exact model, precision, executor, hardware and workload contracts. The earlier BF16 study measures format and termination separately; factual correctness, matched quality equivalence and production operation need separate evaluation.
Answer correctness has not been graded. The instruction test checks whether stated requirements were followed, not whether every answer was factually right.
The rates record how Horizon operated in the published configurations. A performance comparison with another runtime is a separate research question: it requires comparable checkpoint, precision, hardware, prompts and generation settings.
H2D is the volume transferred from the host to the GPU. The explorer shows the total recorded over measured responses. Hits, misses and per-miss cost require their own counters and timings; that volume alone does not determine those measurements.
The performance extracts support integrity and aggregate consistency checks. The IFEval bundle supports recomputing all four metrics from 541 original responses. The earlier behavioral bundle supports recalculating all 120 pair classifications. Reproducing the full experiment also requires sufficient code, environment details and raw observations. The audit block describes the shared material and code availability.
How can storage precision, execution precision, residency and data movement be coordinated without requiring the entire MoE parameter set to occupy GPU memory in expanded form?
Full residency and offloading are operating regimes of this architecture. The measurements describe how the system operates within each recorded configuration.
Selective compression, custom W4A16 kernels and controlled expert residency integrated in a runtime.
Memory, transfers and timing recorded for the published OLMoE and Qwen configurations.
Recorded operating points, with each configuration’s executor identified.
OLMoE 0924 instruction following in IFEval and output conformity in a separate BF16 comparison.
Each measurement belongs to its stated model, precision, executor, hardware and workload. The contribution is the implemented architecture and the evidence recorded for it.
The performance campaign includes OLMoE 0924, OLMoE 0125 and Qwen. Each configuration uses 12 prompts in three blocks, with 128-token responses.
Short checks and historical series use different conditions and remain separate from this campaign. Each set of files identifies its execution conditions.
Unknown (UNKNOWN) means absent or unmeasured information. Unsupported (UNSUPPORTED) means the platform or dependency cannot provide the observation.
Download this edition’s audit guideThis edition’s guide in English.
11 / Engineering
Lucas Ribeiro conceived and developed Horizon independently, without outside investment and using limited hardware. The work spans the research question, architecture, custom execution, runtime, tests, recorded experiments, documentation and public evaluation app.
The journey began with NeuronMap research and grew into its own runtime. Reused code has recorded provenance; the technical reports show the engineering decisions and the conditions of each measurement.
Problem · A step activates a few experts, but the full set of weights must remain accessible.
Engineering decision · Distinguish storage, residency and execution; declare capacity per layer and profile.
How to interpret · This decision makes the space reserved for experts explicit in each configuration.
Technical notes · backend contracts ↓Problem · Replacing a copy in use must preserve the authority of weights and cache readers.
Engineering decision · Keep the source in RAM immutable, prepare new copies in temporary GPU locations and make the new cache state visible all at once, after transfer completion.
How to interpret · Calculations receive a complete set of copies ready for use, while the source in RAM remains intact.
Technical notes · ADR 0009 ↓Problem · OLMoE c60 and c64 change residency and executor together.
Engineering decision · Keep the recorded results available, separate Grouped T3 and place the contract beside the measurement.
How to interpret · The reading considers both changes together. The three block rates show recorded variation; isolating the causal effect of residency requires a different experimental design.
Selected campaign report ↓This is the research presentation: Horizon’s architecture, technical decisions and execution records.
Technical review
The reviewer brief brings together architecture, measurements, limits and related work. The prompt asks readers to reconstruct the complete system before assessing it and to report which sources they accessed.
For agents: llms.txt · claims.json · architecture.json
12 / Contact
I welcome conversations about applications, research, partnerships and professional opportunities. LinkedIn is the direct contact path; GitHub offers a complementary technical profile.
The performance edition contains curated extracts from the completed campaign. You can check file integrity and consistency between each extract and the aggregate dataset.
Edition · technical-preview-residency39-v3
node verify-evidence-edition.mjs --directory .PASS confirms 19 file hashes and agreement of 13 aggregate copies. The checker uses only local files, without installing dependencies or running models.
Verification covers file integrity and consistency of this edition’s aggregates. Experiment reproduction and recomputation from raw observations require the full material and a separate procedure. Hashes check files against the supplied manifest; publisher authentication is a distinct check.
The runtime source code remains private by the author’s decision. This presentation shares the architecture, engineering decisions and documented results. Downloads include extracts, a report, technical notes and a verifier.
Inspect the current edition and two historical extracts ↓All 541 original responses, per-instruction scores and the frozen evaluator are available in a separate bundle. Its verifier recomputes the four metrics on CPU.
Explore the benchmark and audit →The 240 original responses and 120 pair classifications are in a separate bundle, with a manifest, report and Python verifier that recalculates the analysis.
Open comparison responses and audit →