Inkling 2 Small Open Weights: License, GPU Memory, and API Options
Inkling 2 Small weights are available under Apache 2.0. Compare the 500GB NVFP4 deployment floor, Tinker serving limits, and hosted inference options.
“Small” is an easy word to misread on a model card. Inkling 2 Small activates 17 billion parameters, but contains 594 billion in total. Its official NVFP4 deployment guidance starts at 500GB of aggregate GPU memory. The new opportunity is access to downloadable weights and customization, not a sudden laptop-sized coding model.
Thinking Machines announced Inkling 2 Small on November 5 and added a November 12 update confirming the weight release. This article examines the deployment and access decision as of November 13, 2026. It does not report a local installation or inference benchmark.
Key takeaway
- Inkling 2 Small’s official weights are available under Apache 2.0.
- The creator lists 594B total parameters and 17B active, with text/image input and text output.
- Official starting memory requirements are 500GB for NVFP4 and 800GB for MXFP8 checkpoints.
- The model’s 1M context capacity is not every host’s serving limit: Tinker currently lists 256K for serverless inference.
- No exact SandBase Inkling listing was found in the November 13 catalog check.
What the open-weight release changes
The official Hugging Face model card now provides the artifact and license information needed to consider self-hosting. That is a different situation from a provider merely announcing plans to release weights later.
The creator’s repository captured November 13. Use the original model card for parameter counts, license, and checkpoint requirements.
Downloadable weights let a team investigate runtime behavior, control a serving stack, and evaluate customization without depending entirely on one inference endpoint. They do not remove operating costs. Someone still has to acquire capacity, select a supported runtime, observe failures, and maintain the application boundary around the model.
Apache 2.0 is the license stated on the repository. Hosted services have their own service terms and billing conditions; do not treat an open-weight license as a promise that every hosted deployment is free or unconstrained. Read the license and the chosen service agreement for the route you actually use.
Active parameters are not the memory budget
A mixture-of-experts model can activate a fraction of its total parameters for each token. That does not mean the inactive parameters vanish from the deployment. The full model and the runtime still have to fit across the serving system, with additional resources needed for the actual workload.
| Official checkpoint guidance | Minimum aggregate GPU memory | Example configurations in the model card |
|---|---|---|
| NVFP4 | 500GB | 2× B300 or 4× H200 |
| MXFP8 | 800GB | 4× B300 or 8× H200 |
These are the creator’s starting configurations, not throughput measurements or guarantees at a particular concurrency. Prompt length, KV cache, batching, runtime implementation, and hardware interconnect affect the capacity left for serving users. Do not buy a cluster from the active-parameter count alone.
The model card names vLLM, SGLang, TokenSpeed, and Unsloth as local-inference options. Follow the linked recipe for the chosen checkpoint and hardware. A generic serve command in a model-directory widget is not a complete deployment procedure and does not prove that an arbitrary installed runtime version supports the checkpoint correctly.
Before committing capacity, make the acceptance target explicit: number of simultaneous requests, input lengths, maximum waiting time, and the behavior when capacity is exhausted. A model that loads successfully but cannot sustain the intended workload has passed only the first part of the deployment test.
The release chronology matters
The Thinking Machines launch post began with Tinker access and a plan to open weights after external testing. Its November 12 update confirms that the weight-release milestone happened. An article that still says “weights next week” is now stale.
The official announcement captured November 13. The initial launch and later weight release are separate milestones.
The same source describes limitations, including verbosity, difficulty choosing tools when many skills are available, and no audio input. Those are useful evaluation targets. An application that relies on a very large tool menu should test tool selection explicitly instead of assuming a coding score covers that behavior.
For visual coding, evaluate both the generated code and the rendered artifact. Ask whether the model uses screenshot evidence to make the right correction, whether the correction introduces unrelated changes, and whether it stops when the stated requirement is met. These are proposed checks; this article has not executed them on Inkling.
Model capacity and hosted service limits are different
The base model card describes up to 1M tokens of context. The Tinker pricing page, retrieved November 13, lists a 256K serverless context limit for Inkling 2 Small and notes beta conditions for serverless inference. Do not write “1M on Tinker” by copying the model’s maximum into a service table.
| Route | What the reader should verify |
|---|---|
| Self-hosted weights | Memory, runtime recipe, context allocation, concurrency |
| Tinker serverless | Current serving limit, access conditions, inference tariff |
| Another hosted provider | Its own model identifier, limits, cache tariff, and terms |
| SandBase | Exact catalog listing and documented route before assuming access |
Cloudflare’s Inkling documentation is one example of a separately documented hosted route. Its model identifier is @cf/thinkingmachines/inkling-2-small; paid access is required. A Cloudflare request is neither a Tinker request nor a SandBase request.
Cloudflare’s page captured November 13 documents its own serving product. Where provider metadata conflicts, this article uses the creator’s 17B active-parameter count.
This separation prevents a common integration mistake: combining the cheapest price from one host, the largest context limit from another, and a code example from a third into a fictional service that nobody actually offers.
What an API evaluation costs
Tinker’s serverless table lists $0.30 per million input tokens, $0.03 for cached input, and $1.00 for output. For a hypothetical uncached request with 10,000 input and 2,000 output tokens:
10,000 / 1,000,000 × $0.30 + 2,000 / 1,000,000 × $1.00 = $0.005
That estimate covers model inference only. It is not a measured cost per successful coding task and does not include fine-tuning, retries, tools, or local infrastructure. Training prices are separate from inference prices; a downloadable checkpoint does not make training free.
For a self-hosting comparison, start with utilization. A cluster reserved all month but busy for only a few hours has a very different cost per accepted task from one serving a stable queue. Add operational labor and failure recovery before deciding that owning the weights automatically makes the hosted alternative expensive.
Which route should a team choose?
Choose a hosted evaluation first when the immediate question is whether the model can solve your workload. It isolates task quality from runtime configuration and hardware provisioning. Confirm that the hosted limit actually fits the test inputs, and avoid drawing conclusions about the full model capacity from a smaller service window.
Consider self-hosting when control, customization, or predictable sustained utilization justifies operating the cluster. Before deployment, pin the checkpoint revision and runtime recipe, define resource limits, and preserve a small regression suite. Changing weights and serving implementation at the same time makes regressions hard to attribute.
Keep an existing model when the team’s real constraint is a single workstation or when there is no clear benefit from customization. For an already listed alternative, GLM-5.3-Flash on SandBase is a separate model to evaluate, not a substitute name for Inkling. Our Qwen4 preview guide covers another current access decision with very different lifecycle constraints.
Keep training and serving experiments separate
Inkling’s customization positioning creates a second decision after inference quality: whether adapting the model improves a specific task enough to justify the training work. First establish an unchanged baseline. Keep the evaluation examples outside the training set and retain the original checkpoint as a control.
Then compare the customized checkpoint against the baseline using the same runtime and serving configuration. If output improves after simultaneously changing the prompt, runtime, and weights, the experiment cannot identify which change helped. Record the checkpoint revision and renderer alongside the task results, and budget sampling and training separately from final inference. These are recommended experimental controls, not a claim that this article trained a model.
A modest, well-defined adaptation goal is easier to assess than a promise to make every aspect of the model better. For example, a team can test whether its own document-extraction schema becomes more reliable while checking that unsupported answers still trigger an explicit abstention.
FAQ
Are the weights actually available now?
Yes. The official repository is available and the creator’s launch post records the November 12 release update.
Can I run it on a normal laptop because only 17B parameters are active?
The official checkpoint requirements do not support that conclusion. NVFP4 starts at 500GB aggregate GPU memory in the creator’s guidance.
Does every API provide 1M context?
No. Model capacity and provider serving limits are separate. Tinker’s current serverless table lists 256K.
Does it accept audio?
The official launch post says it does not. The model card describes text and image inputs and text output.
Next step: test workload quality through a documented host, then size a local deployment only if owning the serving stack has a concrete benefit.
Found this useful? Share it