Inkling 2 Small: What You Can Use Before Open Weights

Inkling 2 Small gives developers something they can evaluate before deciding whether to operate a model themselves. Thinking Machines launched it on November 5 with hosted inference and fine-tuning through Tinker, while a full weight release remained conditional on external testing. The practical opportunity is to learn whether adaptation improves a recurring task before making a hosting commitment. Launch announcement

That is a useful order of decisions. A downloadable checkpoint can matter for control and deployment, but it does not establish that the model performs your task well. Equally, a promising hosted demonstration does not prove that the eventual self-hosted version will fit your infrastructure or cost less to run.

At launch, the provider offered a playground, sampling and fine-tuning. It intended to release full weights under Apache 2.0 after external safety testing, with downloadable checkpoints following that release. “Available” therefore described several different stages. November 5 release

This distinction prevents two premature commitments. One is waiting for a download before doing any evaluation, even when an approved hosted trial could answer the first question. The other is building a delivery plan around a download date that remains conditional.

Write the dependency explicitly in a project plan. A proof of concept may require only hosted sampling. A product that must run in a particular environment may require portable weights and a supported serving stack. Those projects can rationally make different decisions about the same launch.

Do not turn a general platform export feature into model-specific availability. Tinker’s checkpoint documentation describes mechanisms for saving and exporting supported artifacts. A mechanism existing in the platform does not establish that a particular newly announced model is already downloadable.

The model card describes a mixture-of-experts model with 594 billion total parameters and 17 billion active parameters. It accepts text and images and produces text. The launch documentation excludes audio support for this model.

Mixture-of-experts means that only a subset of the model’s expert components participates in processing a given token. Active parameters help describe that computation; total parameters describe a different aspect of the model. Neither number, alone, is a complete hardware plan.

A buyer should therefore resist reading “17B active” as “a 17B model to load.” Serving also involves weight representation, runtime support, working memory, request length and concurrency. Training introduces its own requirements. The question is whether a specific supported configuration meets the intended workload, not whether one headline number looks small enough.

Hosted evaluation lets a team postpone that infrastructure decision while testing usefulness. It does not eliminate the decision if external deployment is a hard requirement. Keep a separate feasibility track with the expected request pattern, latency target and operating budget.

The text-output distinction matters too. A system that examines an image and writes code to create a visual artifact is different from a native image-generation API. For example, a model might inspect a screenshot and propose interface changes, while a browser or renderer creates the resulting pixels. Assess the whole tool chain when judging the outcome.

A model-family specification can be broader than a particular hosted configuration. The Inkling card states support for up to one million tokens of context. Tinker’s current table lists a 64K standard training configuration, a 256K extended configuration and 256K serverless inference. The serverless offering is labelled beta, with production use directed to a waitlist. Model card, Tinker models and pricing

Those details were retrieved November 10 and should not be read as a historical snapshot of every launch-day account. They demonstrate why an application needs the selected service’s contract, even when the underlying model has a larger advertised capacity.

The same provider table lists $0.30 per million uncached prefill tokens, $0.03 cached prefill and $1 sampling. Checkpoint storage is separate. Source: Tinker pricing, retrieved November 10. These are service prices, not a quote for an entire training project.

A trial budget needs to account for the process that uses those units: preparing examples, evaluating the baseline, trying adaptations, reviewing failures and selecting an artifact. A low sampling rate does not make an unfocused training exercise inexpensive.

Keep the exact model string and configuration in the experiment record. Avoid using a friendly family name as the only identifier. When a result changes, the team needs to know whether it changed the data, model, context configuration, prompt or evaluation method.

Start with an ordinary prompt and representative examples. The purpose is to identify a repeated failure that adaptation could plausibly address. If the model already meets the acceptance standard, the team may gain little by creating a custom variant to maintain.

Consider a developer building a screenshot-review assistant. The desired output might contain the observed interface problem, the relevant region and a suggested correction in a fixed schema. A useful baseline separates visual understanding from output formatting. Did the model notice the right issue but produce the wrong structure, or did it misunderstand what was visible?

Those failures suggest different interventions. A clearer instruction or a schema constraint may address formatting. Additional task context may resolve ambiguity. Training examples become more interesting when the desired judgement is consistent but difficult to communicate repeatedly through a prompt.

Use examples that represent the workload, including cases where no change is required. An assistant evaluated only on defective screenshots may learn to invent defects. A task set containing acceptable examples checks whether it can leave good work alone.

Save the initial prompt and outputs. Without that baseline, improvements are easy to remember selectively. The team may compare a polished later result with its memory of an unusually poor first attempt. The screenshot evaluation guide provides a useful starting point for separating visible evidence from inferred behaviour.

An adaptation dataset should make the desired behaviour legible. For the screenshot-review example, each record would pair an authorised image with the expected observation and output format. The record should identify why the answer is correct, especially where two reviewers might otherwise disagree.

Avoid training only on idealised examples. Include ordinary variation in layout, image quality and task wording. Include ambiguous inputs where the appropriate response is a narrow clarification or a statement that the evidence is insufficient. That teaches the decision boundary rather than merely the most common answer.

Hold back examples before iterating on the model. A held-out set is material that the adaptation process does not train on and that the team uses to test generalisation. Repeatedly inspecting and tuning to the same small evaluation set can make it another training signal in practice, even if it never enters a training file.

Keep related examples together when splitting. Near-identical screenshots of the same page should not appear on both sides of the split if the intended test is whether the model handles unfamiliar pages. Otherwise, the evaluation may reward recognition of a template rather than the judgement the product needs.

Write a disagreement policy. If reviewers disagree about whether an output passes, resolve the rubric before treating the label as ground truth. More data does not fix an inconsistent definition of success.

Fine-tuning is one way to improve a workflow. Better instructions, retrieval of relevant facts and more reliable tools may also address the failure. Compare these interventions against the same acceptance criteria so the team can identify what actually helped.

Thinking Machines itself identifies limitations in concision and tool selection, particularly around large skill collections. That makes tool clarity a sensible part of a local trial. A custom model should not become a way to conceal a confusing integration. Reported limitations

Compare the cost of maintaining each approach. A prompt change may be easy to inspect and reverse. A retrieval system needs reliable documents and access control. A custom model needs versioned training material and regression evaluation. The retrieval-versus-fine-tuning cost guide examines that wider accounting problem.

The right choice can be a combination. What matters is retaining enough experimental discipline to distinguish the contribution of each change. If the prompt, tools and model are all altered together, an apparent improvement may be difficult to reproduce.

Select the outcome that matters to the product. For a structured review assistant, that might be accepted observations per submitted image, unsupported claims, schema failures and reviewer correction time. A fluent answer can pass a superficial impression test while failing the task’s central requirement.

Run the baseline and candidate on the same held-out material, with comparable settings and an explicit attempt budget. Preserve failures as well as successes. When possible, hide model identity during human review so enthusiasm for the new version does not influence grading.

Look at the distribution of errors. An average can hide a regression on a small but important category. A candidate that improves common layouts while becoming unreliable on small text might be unsuitable for the intended product, even if its overall pass rate rises.

Do not choose a winner solely because it completes more examples. Include the consequences of errors and the effort required to correct them. A model that asks for clarification in an ambiguous case may be more useful than one that always produces a finished-looking answer.

If portable weights are essential, identify what would count as readiness: an accessible artifact, applicable licence, compatible runtime, documented resource requirements and a successful evaluation in the intended environment. A hosted result can justify investigating that path, but cannot certify it in advance.

Do not assume that external deployment will reproduce every hosted characteristic. The serving configuration, numerical representation, context management and tools may differ. Retest the acceptance criteria after a deployment change rather than carrying a hosted score forward unchanged.

Budget for operation as well as setup. Someone must own monitoring, capacity, updates and incident response. These responsibilities may be worthwhile when control or workload economics justify them. They remain real responsibilities even when the weights themselves can be obtained without a licence fee.