Inkling’s Open Weights Still Need a Data Center

Open weights can sound almost physical: download the model, put it on your machines, and the intelligence is yours. Thinking Machines Lab’s first model makes that promise more concrete than most. Inkling’s full weights are public, its architecture is documented, and developers can fine-tune it through the company’s Tinker service.

The download button, however, is the easy part.

Inkling is a 975-billion-parameter multimodal model with 41 billion parameters active for each token. Its official BF16 checkpoint occupies about 1.905 terabytes, while the smaller NVFP4 package is still 592 gigabytes. Thinking Machines says running those versions requires clusters of four to sixteen high-end data-center GPUs, depending on the format and hardware generation.

That distinction matters. Inkling expands access to model weights without turning frontier-scale AI into a workstation product. Teams that do not operate the supported four-to-sixteen-GPU clusters will experience “ownership” through an inference provider, a training API, or a runtime stack that was only partly merged on launch day.

A smaller active model still carries the full weight

Inkling’s architecture is designed to avoid using all 975 billion parameters for every token. According to the official model card, it is a 66-layer, decoder-only sparse Mixture-of-Experts transformer. Each token is routed to six of 256 specialist experts, while two shared experts remain active. That routing brings the active count down to 41 billion parameters.

Mixture-of-Experts routing cuts compute per token, not the distributed checkpoint. In Thinking Machines’ published serving configurations, the wider expert pool remains addressable so the router can select different paths for different tokens. “41 billion active” therefore describes work per token rather than the checkpoint an operator must download.

There is more engineering behind the headline number. Inkling alternates five local-attention layers with one global-attention layer, uses eight key-value heads, and replaces the now-common RoPE position system with relative positional embeddings. Short, four-token convolutions are applied around attention and residual paths. The published configuration file sets a 6,144-wide hidden state and a maximum context of 1,048,576 tokens.

Its multimodal inputs are similarly direct. Images are split into 40-by-40-pixel patches and passed through a four-layer lightweight encoder. Audio is represented through discrete dMel features. Text, image, and audio representations then enter the same decoder stack, which produces text.

Inkling is not merely a large text model with a visual attachment. Its architecture also explains why a spec-sheet reading can mislead: sparse activation helps inference economics while the supported serving configurations still keep the distributed expert pool available to the router.

NVFP4 cuts the package, not the data-center requirement

The public artifacts make that footprint measurable. Summing the safetensor files in the commit-pinned BF16 repository manifest, including its auxiliary tensor file, produces 1,904,755,463,940 bytes. That is 1.9048 decimal terabytes, or 1.7324 tebibytes. The same calculation on the pinned NVFP4 manifest produces 592,005,609,232 bytes, or about 592 gigabytes.

NVFP4 reduces those downloadable tensor files by roughly 68.9 percent, a substantial systems gain that still leaves a 592-gigabyte artifact.

Thinking Machines specifies at least two terabytes of aggregate VRAM for BF16, met by eight NVIDIA B300 GPUs or sixteen H200 GPUs. The NVFP4 version requires at least 600 gigabytes: four B300 GPUs in W4A4 mode, or eight H200 GPUs in W4A16 mode. W4A4 also requires NVIDIA’s SM100-or-newer architecture.

The vendor rounds those minimums in TB and GB without specifying a unit convention, so subtracting the manifest totals would create false precision. Checkpoint size also does not map cleanly to usable runtime memory. KV cache, inference-engine workspaces, batching, and long-context requests all add demands beyond the stored tensor files.

Even moving the files is an infrastructure job. At an ideal one-gigabit-per-second line rate, the BF16 tensors would take about 4.2 hours to transfer and the NVFP4 tensors about 1.3 hours, before protocol overhead or retries. A ten-gigabit link cuts those theoretical times to about 25 and eight minutes. Data-center networks can manage that transfer; it bears little resemblance to downloading a normal software package.

Tinker makes customization accessible, within a narrower window

Thinking Machines is not expecting every developer to assemble that cluster. Its practical answer is Tinker, a managed training service based on LoRA adapters. Tinker trains a comparatively small set of adapter parameters across selected layers rather than rewriting the full base model, and users can download saved checkpoints.

Inkling is available there with 64K and 256K context options. The gap between those options and the model’s advertised one-million-token context is worth stating early. The base architecture may support a million tokens, but the launch-day fine-tuning product does not expose that full window.

As checked at 9:30 p.m. ET on July 15, the Tinker pricing page listed a limited-time 50 percent discount. At 64K, prices per million tokens were $1.87 for prefill, $0.374 for cached prefill, $4.68 for sampling, and $5.61 for training. The 256K option charged $3.74, $0.748, $9.36, and $11.23 respectively.

Those unit prices are easier to understand with a small calculation. Ten million billed training tokens would contribute $56.10 at 64K or $112.30 at 256K. That is not a complete job estimate: a real run can also include repeated passes, sampling, prompt processing, evaluation, and storage. Still, it shows the commercial trade-off. Tinker lowers the hardware threshold by turning infrastructure into usage charges, while longer-context customization roughly doubles the listed per-token rates.

The company’s launch demo shows Inkling writing and running a fine-tuning job that teaches itself to avoid the letter “e.” The demo illustrates the workflow, while the product being sold is a managed LoRA service rather than evidence that a business can cheaply retrain a 975-billion-parameter base model on its own premises.

Runtime support was announced faster than it was merged

The official launch page listed Together AI, Fireworks, Modal, Databricks, and Baseten as providers. As checked at 9:30 p.m. ET on July 15, Baseten’s public model page presented the API identifier thinkingmachines/inkling. Together AI’s day-zero announcement said its serverless service supported the full one-million-token context, although the sample request still contained placeholder values for the model identifier and reasoning-effort parameter.

Self-hosted software support was less settled at that same 9:30 p.m. ET checkpoint. Hugging Face’s Transformers integration had merged. The SGLang and TokenSpeed changes remained open, while the vLLM and llama.cpp changes were drafts. Recipes and pull requests can be enough for expert teams to begin testing, but they are not the same as a stable version in a package manager.

We have seen this gap before. Microsoft’s effort to bring the much smaller GPT-OSS 20B model to Windows 11 showed how much platform integration matters even when the weights are designed for local hardware. TECHi’s look at llama.cpp Flash Attention on Intel Battlemage made the same point from another direction: runtime maturity can determine whether a model’s theoretical efficiency survives contact with real devices.

Inkling starts much farther up the infrastructure ladder. An enterprise can access it quickly through a provider. Running it independently, with predictable throughput and a maintained software stack, is a separate project.

Apache-tagged weights come with another rulebook

Inkling’s model card and the commit-pinned Hugging Face metadata label the weights Apache 2.0. That is an unusually permissive starting point for a model of this scale, and it places Inkling in the broader push toward models that developers can inspect and adapt. TECHi has followed that argument through companies such as Mistral AI and its open-model strategy.

Inkling’s release has an extra layer. The pinned repository tree cited above does not contain a standalone LICENSE file; its metadata links to the Apache 2.0 text and also directs users to a separate Model Acceptable Use Policy. That policy says anyone accessing, downloading, or using the model materials agrees to its conditions. It covers modified versions and makes deployers responsible for downstream compliance.

The restrictions cover illegal activity, weapons, malicious code, privacy violations, deception, some automated consequential decisions, and unlicensed professional advice. Deployers must disclose material limitations and, where relevant, tell users they are interacting with AI. The company also reserves the ability to update the policy, with continued use treated as acceptance of the revision.

The precise description, then, is not “unrestricted Apache open source.” It is Apache-tagged open weights distributed alongside a separate use policy whose own text says downloaders agree to its terms. Legal teams will need to examine how those documents interact before a regulated or long-lived deployment treats the model as a permanently fixed software dependency.

The documentation is useful, but it still shows launch seams

Thinking Machines discloses more technical detail than a typical model announcement. The model card says Inkling was pretrained on 45 trillion tokens spanning text, images, audio, and video, then post-trained across reasoning, coding, tool use, multimodal tasks, chat, and safety. An initial supervised phase used synthetic data from open-weight models including Kimi K2.5, followed by large-scale reinforcement learning across more than 30 million rollouts.

The data account is much less specific. The linked training-data documentation explicitly describes the company’s general practices rather than Inkling’s exact corpus. It mentions public internet data, third-party data, synthetic material, content that may be protected by intellectual-property rights, and possible personal information. It does not name datasets, provide modality percentages, or give Inkling’s knowledge-cutoff date.

Safety disclosure has similar limits. The rendered model card says external red-teaming covered psychological harms, CBRN, cyber, strategic deception, and sabotage. It also acknowledges occasional compliance with harmful requests framed through role-play or indirection, recommends defense-in-depth moderation, and warns against unvalidated medical, legal, or safety-critical use. The visible disclosure omits tester names, sample sizes, thresholds, and raw reports.

The public release materials were not perfectly synchronized at the 9:30 p.m. ET checkpoint. The launch page and model card reported 73.5 percent on MMMU-Pro, while the commit-pinned Hugging Face README cited above reported 73.3 percent. A two-tenths difference is not commercially decisive, but it is a concrete reason to treat the release package as launch-day documentation rather than a single reconciled evidence record.

None of this proves Inkling’s core claims are wrong. It does mean the benchmark hierarchy should not carry the story. The company itself says Inkling is not the strongest model overall. Buyers have firmer evidence in the downloadable weights, configuration, hardware requirements, pricing, and public integration work than in a launch-day race over tenths of a benchmark point.

The buyer takeaway: decide what ownership must include

Inkling offers three different forms of access, and buyers should not blend them together.

API access is the fastest route and leaves infrastructure with Thinking Machines or an inference partner. Managed customization through Tinker gives developers control over data, objectives, and LoRA checkpoints while retaining a service dependency. Self-hosting provides the strongest operational control, but it begins with hundreds of gigabytes of weights, multiple data-center GPUs, and day-zero runtime work.

For research labs and well-funded AI teams, that self-hosted option is meaningful. TECHi covered Mira Murati’s company raising $2 billion in July 2025; Inkling is its first public model artifact a year later, accompanied by a post-training platform, public checkpoints, and a coordinated serving ecosystem.

For teams without Inkling’s stated infrastructure, the immediate benefit of open weights is negotiating leverage and technical visibility rather than effortless local ownership. A company can inspect the configuration, choose among providers, export adapters, or build a self-hosted plan without waiting for a closed-model vendor to grant permission.

The data center remains part of that plan. Inkling makes a frontier-scale model more available and more customizable; its runtimes, documentation, licensing, and long-context training options now have to make that control practical after launch day.

Source note: Technical and commercial details were checked against Thinking Machines Lab’s launch materials, commit-pinned Hugging Face repositories, Tinker documentation, and linked upstream integration records as available at 9:30 p.m. ET on July 15, 2026.