Open Overseas Weights: A Verified Local Deployment Map

Open Overseas Weights: A Verified Local Deployment Map is documented here with numbers verified directly against the HuggingFace API and the raw config.json of the corresponding repository, sampled in November 2026. No benchmark score, price, or repository name is invented; anything the config cannot prove is labelled as needing measurement.

Verified specification

What the numbers actually confirm

The distinction between verified fact and claim matters most for multimodal wording. A vision_config and an image_placeholder in the official config confirm an image-capable conditional-generation architecture; they do not by themselves prove video generation, a specific request payload, or any benchmark result. The HuggingFace tag image-text-to-text describes the input direction. Always treat the official model card as the final source of truth.

Configuration and deployment reality

Memory planning follows the same rule for every trillion-parameter MoE: compute scales with active parameters while memory scales with total parameters. A 1T model at 4-bit still needs roughly 500GB for weights alone, and a 2.78T model is larger still, so these are multi-GPU server workloads rather than single consumer cards. For a single card, look at the lightweight families. The local path is vLLM or SGLang with official weights, and community conversions should be checked for source and quantization label first.

Honest boundaries

On EXAIV the live /models catalog is authoritative: only kimi-k3 is callable today, through the OpenAI-compatible endpoint at https://exaiv.com/api/ai/v1. Integration changes only base_url, api_key and model; streaming and tool calling keep the standard OpenAI format. Prices always follow the live /pricing page and are never hard-coded here. Keep a log of model ID, token counts and latency so a later model swap has the same baseline.

Reading the catalog and the licence

A family overview is only useful when it separates what is callable from what is downloadable. On EXAIV the live /models catalog currently carries exactly the IDs listed above; a model having open weights on HuggingFace does not mean it is exposed through the cloud API. Download counts are 30-day public counters sampled in November 2026 and move continuously, so treat them as relative signals for community size rather than quality scores. The licence line matters just as much: license:mit for GLM-5.3-Flash is a permissive baseline, while other builds in the family carry vendor-specific terms that must be read on the model card before commercial use. Keep the model ID, token counts and latency in a log so a later switch between builds can be compared against the same set of prompts.

Pre-flight checklist before you ship

Six checks keep this kind of article and the integration behind it honest. First, re-read the numbers from the HuggingFace API on the day you publish, because download counters move every week and any figure quoted here is a November 2026 sample rather than a permanent fact. Second, open the live /models catalog and confirm that kimi-k3 is still the callable ID; a catalog change invalidates every instruction that names a model explicitly. Third, open /pricing rather than copying a price into your application or your docs.

Fourth, never hard-code a multimodal request body that you have not validated against the official model card. Config fields prove architecture, not wire format. Fifth, record the model ID, input and output token counts, and latency for a representative set of prompts, then keep that set unchanged so a later swap to another model produces a comparable result. Sixth, read the licence on the model card before commercial use, since license:other means vendor-specific terms rather than a permissive default.

The same discipline applies to local weights. If you download a community conversion, check who published it, whether the conversion source is stated, and whether the quantization label matches the file you intended to fetch. Two files both named Q4_K_M from different publishers are not interchangeable. If a model loads but produces garbled output, suspect the chat template before blaming the weights. Keep the template next to the weights in one folder so the pair can be audited together. That habit costs a few minutes and prevents the most common class of false bug reports.

Scenario selection

FAQ

Related reading

• Claude family overview — callable IDs and endpoint
• GPT family overview — ID families
• Open overseas weights — local open weights
• Claude Code third-party models — support boundary
• pricing — live credit packs

Sources

• HuggingFace model API
• EXAIV live model catalog

Parameter and file data sampled in November 2026 and subject to change.

Terminology and pre-flight checklist

Total parameters, active parameters and the KV cache are three different quantities. Total parameters are all the weights that must be loaded into memory; active parameters are the subset that computes a single token. KV cache is temporary memory that grows linearly with context length, so a 1M window is a ceiling rather than a free default. Quantization lowers the precision of stored weights to shrink files; it does not reduce the parameter count. A vision_config in a config.json describes architecture, not a wire format you may safely invent.

Before shipping anything built on these notes, run six checks. Re-read the numbers from the live source on the day you publish, because download counters move weekly. Open the live /models catalog and confirm the model ID you plan to call is still there. Open /pricing rather than copying a price into your application. Never hard-code a request body you have not validated against the official reference. Record the model ID, input and output token counts, and latency for a representative set of prompts, then keep that set unchanged so a later model swap produces a comparable reading. Read the licence on the model card before commercial use, since vendor-specific terms are not a permissive default. Add exponential backoff for retryable requests, set a timeout, and log the error class so that a 401, a 404 and a 429 never get the same treatment.

Reading the catalog safely

Two cautions apply to every table in this guide. First, a model ID being present in the live /models catalog tells you it is callable at that moment; it does not tell you anything about parameter counts, training data or benchmark results, and none of those are asserted here. Second, a repository name on HuggingFace tells you weights exist for local use; it does not make the model available through the EXAIV API. Keep these two statements separate in your own documentation, because conflating them is the fastest route to an example that looks correct but fails with a 404. When in doubt, copy the ID from the live catalog rather than from a blog post, including this one, and verify with a short request before building anything on top of it. Store the response status alongside the model ID so that a later catalog change is visible in your logs immediately.