Intern-S2 is a 397B mixture-of-experts model fully open-sourced by Shanghai AI Laboratory in September 2026. Its headline strength is long scientific tasks: biomolecular interaction design, materials structure generation, competition and advanced mathematics long-horizon reasoning, and agent execution. For individuals and small teams the realistic path is not hosting 397B locally but using the free API. Institutions with compute can load HuggingFace weights for private deployment. Researchers can stack the Memory Decoder pluggable memory module to attach domain knowledge on top of a frozen base, with no retraining. This SOP gives the shortest path from zero to working: pick a route, claim quota, send the first request, run local inference, write prompts for long scientific tasks, mount the memory module, and ship to production while avoiding ten pitfalls.
Boundary note: steps are compiled from official README and release docs as of September 2026; commands and UI follow the official documentation. The Preview build is scheduled to shut down on 2026-10-31, so use official addresses for production.
This guide targets Chinese technical practitioners, including individuals and small teams, who want a working integration without reading every document. Where a command is uncertain, follow the official README.
Which path should you take
Not everyone needs the same path. Sort yourself into three buckets by compute and goal.
Bucket one, individual developers and small teams. You have no GPU fleet and do not want to maintain an inference cluster. Your goal is to validate ideas quickly and wire the model into your product. Take the free API: the web playground is five minutes away, and the API opens a free quota to all users, with higher quota on request. Zero ops, zero hardware cost.
Bucket two, universities, labs, and enterprises with compute. You own eight or more A100 or domestic cards, your data cannot leave the network, and you need private deployment or further development. Take HuggingFace weight inference with transformers, or ModelScope weights, on your own cluster. Note 397B is unfriendly locally and needs large memory or multi-card sharding.
Bucket three, researchers who need the model to become a domain expert. You hold private corpora in biology, materials, or mathematics, and you want the model to remember that knowledge long term without retraining the base. On top of the API or local weights, stack the Memory Decoder memory module to attach domain knowledge.
One line: validate ideas on the API, keep data on-prem with local weights, and gain durable domain memory with the memory module.
Cost reality: hosting 397B at full BF16 is roughly 800 GB of weights, so even an 80 GB card needs about ten of them before counting activation and intermediate state. For an individual that is a house-sized GPU budget, which is why the free API is not a compromise but the only sensible entry. Conversely, if your data must never leave the network, the API is off the table and local weights become mandatory regardless of cost.
Access methods at a glance
The table contrasts the three paths on barrier, compute, audience, and links.
| Method | Path | Barrier | Compute | For whom | Links |
|---|---|---|---|---|---|
| Free API | Web playground and coded calls | Register and claim free quota | No local compute | Individuals, small teams, quick validation | chat.intern-ai.org.cn; internlm.intern-ai.org.cn/api/strategy |
| HuggingFace weights | transformers load | Can write inference code | Large memory, multi-card | Institutions with compute, private use | huggingface.co/internlm/Intern-S2-397B |
| GitHub and ModelScope | Source and domestic weights | Can deploy | Large memory, multi-card | Domestic compliance, further dev | github.com/InternLM/Intern-S1; modelscope.cn/models/Shanghai_AI_Laboratory/Intern-S2-397B |
Routing advice: start on the free API to prove the scenario, then consider local weights once compute is justified. The memory module is mostly application-based for now, so define the task clearly on the API first.
Treat the table as a starting filter, not a commitment: most teams should begin on the free API, measure real latency and cost on their own workloads, and only move to local weights when the data or scale argument is concrete. The memory module sits on top of either route and does not change this decision.
Free API step by step
This is the most actionable section. Goal: get endpoint and key in ten minutes and send the first request.
Never commit the key to source control; if it appears in a repo, revoke and rotate it immediately, because free quotas are attractive targets for abuse.
Step 1, register and claim quota. Open the web playground at chat.intern-ai.org.cn and log in. The quota policy and application entry sit at internlm.intern-ai.org.cn/api/strategy: a free quota is open to all users, and higher quota needs a separate application. Claim the free one first; apply only when you need more.
Step 2, create a key. In the API console create an API key, copy and store it safely. The key shows only once, and you must revoke it immediately if it leaks.
Step 3, get endpoint and key. Set the key as an environment variable to avoid hardcoding it in code:
export INTERN_S2_API_KEY="your-key"The endpoint and exact path follow the official docs; below we use the placeholder https://chat.intern-ai.org.cn/...
Step 4, send the first request with Python. The minimal runnable snippet uses only requests:
import os
import requests
api_key = os.environ.get("INTERN_S2_API_KEY")
endpoint = "https://chat.intern-ai.org.cn/..." # follow official docs
resp = requests.post(
endpoint,
headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"},
json={"model": "intern-s2", "messages": [{"role": "user", "content": "Explain molecular docking in one sentence"}]},
)
print(resp.json())A returned response means the link works. After that, swap the messages for your long scientific task.
The response follows the standard chat schema; the model output sits in choices, and a 4xx usually means a key or quota problem while a 5xx usually means server-side throttling, which you handle with backoff. For streaming, set stream to true and read chunks incrementally instead of waiting for the full reply. Log the request id so you can trace failures with the provider.
HuggingFace inference minimal example
Institutions with compute load weights with transformers for multimodal QA. The skeleton below has two caveats: 397B needs large memory or multi-card sharding, and a single card barely moves; the repo uses custom code, so trust_remote_code=True is required, following the official README.
from transformers import AutoModel, AutoTokenizer
model = AutoModel.from_pretrained(
"internlm/Intern-S2-397B",
trust_remote_code=True,
torch_dtype="auto",
device_map="auto", # multi-card sharding
)
tokenizer = AutoTokenizer.from_pretrained(
"internlm/Intern-S2-397B", trust_remote_code=True
)
inputs = tokenizer("Describe the binding site in this molecular structure image", return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=512)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))Practical notes: confirm total cluster memory first and estimate whether BF16 weights fit; if not, use multi-card device_map or quantization; for domestic accelerators watch framework and operator compatibility. Slow inference is normal, so set timeouts and retries for long tasks.
For a single node, prefer device_map="auto" with accelerate so layers spread across cards. If memory is still short, apply 4-bit or 8-bit quantization, understanding that it trades some accuracy for fit. Benchmark one representative prompt before batching, because long-context generation dominates latency and you should size the queue from measured numbers rather than guesses.
Prompt recipes for long scientific tasks
Intern-S2 shines at long-horizon reasoning and tool calling. The key is to break the task into goal, constraints, steps, and verification. Two copy-paste templates follow.
Template one, protein binder and molecular design:
You are a computational biologist. Task: design a binder for target protein [PDB ID].
Steps: 1) list key residues of the binding pocket and interaction types; 2) propose three candidate sequences with reasoning;
3) for each sequence assess binding affinity, solubility, and immunogenicity risk; 4) retrieve literature to cross-check with tools;
5) give the best candidate and next experimental step.
Constraints: every step cites verifiable evidence, and mark uncertainty explicitly.Template two, materials structure generation:
You are a materials scientist. Task: design a crystal structure that meets [target band gap / conductivity / stability].
Steps: 1) set chemical constraints on element composition; 2) generate candidates and self-consistency check against physical rules;
3) call a compute tool to estimate properties; 4) compare three candidates and explain trade-offs; 5) output a synthesizable path.
Constraints: every number cites a source or estimation method, no fabrication.How to use long reasoning plus tool calling: split the big task into steps, let the model reason first then call a tool at each step (retrieval, compute, lookup), feed the tool result back into the next step to form a loop, and finally ask it to output the reasoning chain to the conclusion, not just the answer. This sharply reduces factual drift on long tasks.
A third recipe is long mathematical reasoning: split a proof or calculation into sub-goals, ask the model for a lemma and justification at each step, and require a final summary. Intern-S2 is strong at competition and advanced math long-horizon reasoning; the trick is to ask for the full reasoning chain, not just the final answer. When the loop calls tools, persist each tool result and the model's interpretation of it, so you can audit where the chain diverged if the conclusion is wrong.
Mounting the Memory Decoder
The Memory Decoder is the pluggable memory module of Intern-S2 (such as Intern-MemDec-4B). Its core selling point is attaching domain knowledge on a frozen base, with no retraining, turning a general model into a domain expert at low cost. Conceptually, you prepare domain corpora, generate memory parameters, and mount them at designated layers of the base, taking effect together at inference.
In practice the memory module is mostly application-based for now. The exact application entry, mount method, and parameter format follow the official README, so do not copy third-party tutorials. Suggested path: define the domain task clearly on the free API first, accumulate enough corpora and an evaluation set, then apply to the official channel for the memory module, and after receiving mount instructions wire it into your own or authorized environment. The memory module is not a cure-all: corpus quality decides memory quality, and you still need an evaluation set to verify after mounting.
From an engineering view the value of the memory module is hot-swappability: one frozen base can switch expert identity by mounting different domain memories, and because the base stays frozen you avoid the training and regression cost of full fine-tuning. The trade-off is that the memory module itself must be maintained and iterated as corpora evolve, and you should version it like any other model artifact.
Productionizing and pitfalls
Ten pitfalls are most common when putting Intern-S2 into production. The quick-reference table gives symptom and fix for each.
| Pitfall | Symptom | Fix |
|---|---|---|
| Free quota rate limit | High-frequency calls throttled | Add backoff retry, stagger calls, apply for higher quota |
| 397B memory blowup | Single card OOM, will not start | Multi-card sharding, quantization, or switch to API |
| Long context truncation | Long doc cut, info lost | Chunk, front-load summary, keep key context |
| Memory module not applied | Domain knowledge will not attach | Validate on API first, then apply for module |
| Preview shutdown | Links dead on 2026-10-31 | Migrate to official address, watch announcements |
| Domestic accelerator fit | Operator or framework mismatch | Test operator coverage, use compatible backend |
| Official-flavored benchmarks | Metric gaps from reality | Build own eval set, accept on real tasks |
| Long task timeout | Inference too long, client drops | Server-side async, poll result, sensible timeout |
| Concurrency limit | Requests crowd each other | Rate-limit queue, cap concurrency |
| Key leak protection | Key in repo gets abused | Env vars plus secret manager, revoke on leak |
Production notes: the free API fits validation and prototypes; for live service mind rate limits, timeouts, keys, and logs; local weights need memory and concurrency monitoring; long scientific tasks should be asynchronous, with results stored and polled.
For domestic compliance, keep weights and data inside the approved accelerator pool and document the exact software stack so audits reproduce. Pin the model and memory-module versions in your deployment manifest, because silent upstream changes can shift scientific outputs in ways that matter for regulated work.
Also sample cost and latency for every long task and build your own evaluation set, accepting on real tasks rather than official leaderboards. For scientific tasks, factual correctness must be backed by reproducible experiments or literature cross-checks, never by the model's own claim alone. Add basic observability: record prompt tokens, output tokens, latency, and error rate per route, and alert when the free quota approaches its ceiling so prototypes do not silently break in production.
FAQ
Q1: How can an individual use it at zero cost?
Take the free API. Register at chat.intern-ai.org.cn to claim a free quota open to all users, with higher quota on request. Validate ideas in the web playground, then wire the API with Python, at zero hardware cost.
Q2: Can it run locally?
397B is unfriendly locally. A single card barely moves; it needs large memory or multi-card sharding and trust_remote_code. Individuals and small teams should skip local and prefer the free API; institutions with compute can consider HF weights or domestic private deployment.
Q3: What is the difference between API and HF weights?
The API is zero-ops, pay by quota, and fits quick validation. HF weights need your own compute to deploy, keep data on-prem, and allow further development, but ops and memory cost sit with you. Route choice depends on compute and compliance.
Q4: What does the memory module do, and how to apply?
It attaches domain knowledge on a frozen base, turning a general model into a domain expert with no retraining. It is mostly application-based now, and the exact entry and mount follow the official README. Define the task and corpora on the API first, then apply.
Q5: Versus GPT and Claude, what scenes fit?
Intern-S2 is strong at long scientific tasks (biomolecular, materials structure, competition math, agent execution) and domestic compliance scenes. General chit-chat and ecosystem maturity lag behind closed models, but scientific reasoning and data on-prem are its home turf. For regulated industries, the data-on-prem and open-weight posture is the deciding factor even when a closed model scores higher on a generic benchmark.