Reading

Crusoe, a Denver-based AI data center developer founded eight years ago, confirmed that it has sold an unfinished data center project in southeastern Wyoming to Google. The site was initially planned in partnership with Blackstone-backed infrastructure company Tallgrass, with ambitions to eventually scale to 10 gigawatts of power capacity.

According to TechCrunch, Google had previously attempted to become a customer for the project but raised concerns about costs and construction timelines under Crusoe’s management. This acquisition marks Google taking direct control of the site's development. While Google did not disclose the purchase price paid to Crusoe, it announced plans to invest $17 billion to develop the data center campus.

The deal underscores the difficulties independent data center developers face in delivering massive projects on time and within budget, citing challenges such as securing equipment, power availability, and growing local community opposition. Notably, Crusoe has not lost all business with Google; the company is still developing another data center for Google near Amarillo, Texas.

Crusoe recently completed a $3.9 billion funding round, valuing the company at $30.9 billion. Its business model involves leasing data center space, renting GPUs, and selling inference compute. Beyond the Wyoming site, Crusoe is building campuses for Oracle and OpenAI in Abilene, Texas, and a separate 900-megawatt campus for Microsoft.

The earliest motivation for building EH was simply laziness. There are too many repetitive operations in a browser: viewing pages, finding content, clicking controls, and switching pages—I wanted the computer to do it for me. When V2EX user niuheishou built the web perception system EH, the first engineering decision he faced was: should the model look, or should the code look?

He initially chose the model. He built a complete set of YOLO annotation tools for himself, designed annotation rules, and manually annotated them one by one. During his most intense three days, he slept only twelve hours, accumulating approximately 2,300 basic training samples. The training results looked good, but problems arose when actually applied to pages: the samples were mostly from fixed browser resolutions and zoom levels, and the bias from his manual annotations was seriously learned by the model. Large elements could be handled roughly, but the boxes for small elements often deviated wildly—a seemingly small error landing on a button could determine exactly what gets clicked.

For the next three full months, he struggled against this jitter in the boxes. He added geometric priors, tried GNN correction, performed morphological dilation; re-annotated, re-trained, and supplemented data under different zooms and resolutions. Each time he felt closer to solving the problem, changing the page state would reveal new biases.

The turning point came from the DOM. He later described his feelings at the time: the browser already knew some things, yet he was still making the model guess again from pixels. After the DOM entered the system, the first thing that changed was annotation—the boxes that used to require painstaking manual drawing could now be generated by code according to unified rules. Inconsistencies in manual annotation decreased, and the work of patching around annotations became much lighter.

But the inherent problems of the model were not solved. The trained model still jittered; increasing the model size and input resolution did not completely eliminate deviations on the page. The question gradually shifted: how much longer must I patch along this path to achieve the stable results I want?

So the prototype began to shift. He broke down his own judgments about the page, writing them out as code line by line—which parts are content, which are controls, under what conditions action can be taken, and under what conditions it should stop. Subjective judgments that previously existed only in his mind gradually became rules that could be executed repeatedly and checked.

This process was slow, but for the first time it showed him another possibility: instead of constantly chasing and correcting deviations in the model's output boxes, he could first clearly articulate his process of understanding the page, and then let the code execute it. After the single-site version finally ran successfully, he faced the next problem—generalizability. One site required about a 200KB JSON configuration file; switching to another site meant continuing adaptation. It took about a month to analyze what could be reused across sites versus what was just site-specific experience, and two more months before the first cross-site reusable engine finally took shape.

The core architecture of NVIDIA Dory 1.0 4B is a shared loop inference block: middle layers form a module that can be applied repeatedly, allowing each token to be processed once, twice, three times, or four times. Each additional loop increases computation without adding any parameters, so the same 3.7 GB GGUF file can run under four different compute budgets without retraining. This effectively turns test-time compute into a load-time setting.

A tutorial by practitioner Sana Hassan at MarkTechPost showcases a reproducible verification method: first reading architecture metadata from the GGUF file header to predict costs for each configuration, then starting a server to verify predictions against actual logs. Dory’s 72 layer entries are divided into 16 input layers, 40 shared recurrent layers, and 16 output layers; the recurrent block accounts for 1.84 billion of the model's 3.98 billion parameters. A token passes through the input block, the recurrent block (once per loop), the output block, and the language model head, meaning four loops apply 2.51 times the parameters of a single loop and read 2.28 times the weight bytes.

KV cache behavior depends on the combination of loop count and cache mode. The per_loop mode retains independent caches for every loop of every attention layer within the recurrent block, growing from 306 MiB at one loop to 816 MiB at four loops for a 4096 context length; the last_loop mode retains only one cache, maintaining 306 MiB regardless of the loop count. This difference has measurable consequences during chunked processing of long prompts: when a prompt is split into small chunks of 16 tokens, the next-token distributions of last_loop and per_loop diverge because early chunks retain only the keys and values from the final loop.

The tutorial exposes the first trap: defaults. The built-in loop count in the GGUF file header is 4, whereas the NVIDIA model card recommends 2. Without explicitly overriding this setting, the server silently runs the most expensive configuration. The second trap is version locking: support for Dory in the llama.cpp upstream remains an open draft PR (number 30306), and no released binary can load this model; it must be built from a specific commit of a specific fork.

Evaluations on 30 paired GSM8K questions show that four loops generate fewer tokens than a single loop—the upper bound of the 95% confidence interval for the median ratio is below 1, meaning the entire interval lies below 1—but decode speed drops significantly. Due to the small sample size, differences in accuracy cannot be distinguished statistically. The author explicitly marks untestable claims: benchmarks on the model card such as SWE-bench, Terminal-Bench, GPQA, 256K context, and NVFP4 pre-training cannot be verified in this tutorial.

Two practical lessons do not depend on specific measurement numbers: always set the loop count explicitly, because the GGUF defaults to four loops; and always pin the fork commit hash, because upstream support has not yet been merged.