你想让 AI 同时读长文、看图片、听音频，还希望它能在自己的机器上运行。麻烦在于，模型越大，通常越难部署，生成一次的成本也越高。Thinking Machines 新发布的 Inkling-Small，选择了一条折中路线：模型共有 276B（2760亿）参数，但处理每个 token——模型读写文字时使用的基本单位——只激活其中 12B。
这不等于一台普通电脑就能轻松运行。它真正值得看的地方，是用很大的总容量，换取相对较小的单次计算规模，并从发布之初就提供开放权重和本地部署入口。需要先说明：现有供稿没有给出或验证其上下文窗口长度，因此标题方向中的“百万上下文”目前不能作为事实报道。
大仓库，不必每次全开
Inkling-Small 采用稀疏 MoE（Mixture of Experts，混合专家）架构。可以把它理解成一个拥有许多专业小组的机构：整体人手很多，但每项任务只叫来相关小组，而不是让所有人同时开会。
官方 Hugging Face 模型页显示，它是一个 42 层、仅解码器的 Transformer。模型共有 256 个专家模块；每处理一个 token，会调用其中 6 个，另外还有 2 个共享专家始终参与。总参数代表模型整体能容纳多少结构与信息，激活参数则更接近一次生成实际动用的计算规模。Inkling-Small 的关键数字因此不是单独的 276B，而是“276B 总参数、12B 激活参数”这组搭配。
模型还混合使用局部与全局注意力层。注意力可以粗略理解为：模型阅读当前内容时，决定应该回看哪些位置。供稿只披露了这种混合设计，没有提供更细的分配方式或效果对比。
Small，说的是每次动用多少
本刊在 7 月 17 日介绍过同一团队的 Inkling：975B 总参数、41B 激活参数。Inkling-Small 把规模降到 276B 总参数和 12B 激活参数，关注点也更靠近高效 MoE 与本地运行。这里的“Small”是相对命名。276B 的完整权重依然很大，只是每次参与计算的部分明显小于模型总量。
官方模型页将它定义为通用多模态模型。多模态指模型能处理不止一种信息形式。Inkling-Small 接受文本、图片和音频输入，统一生成文本；图片由分层图块编码器处理，音频则转成离散 token，再与其他输入投射到同一个内部空间中。页面展示了图片问答和图片描述的调用示例，但这些部署示例不能当作能力评测。
开放权重之后，工具链已经跟上
Thinking Machines 已在 Hugging Face 提供 Inkling-Small 的开放权重与使用入口。官方页面给出了 Transformers、vLLM、SGLang 和 Docker 的运行方式。Transformers 可直接加载模型；vLLM 与 SGLang 属于推理服务工具——把模型生成能力包装成应用可以调用的接口；Docker 则提供容器化运行路径。
模型支持 BF16 与 NVFP4 两种数值格式。本地量化就是用较低精度保存权重，以减少内存或显存占用。它能降低部署门槛，但通常要在体积、速度和能力损失之间取舍。官方页面给出了支持格式，却没有在供稿中提供不同精度下的系统性质量比较。
一名 Reddit 用户还在 DGX Spark GB10 上测试了量化版本 Inkling-Small（UD-Q2_K_XL，effort=max）。在其单次任务中，模型思考约 6 分钟后开始生成代码；同一用户测试的 Qwen3.6-27B 约思考 38 秒。这个数字只能说明本地量化实测已经出现，不能据此判断谁普遍更快或更好：两者的模型、量化版本和推理配置不同，测试也没有标准化。
为什么值得继续看
Inkling-Small 把三个方向放到了一起：稀疏 MoE 提供“大总容量、小激活量”的计算折中；原生多模态让文本、图片和音频进入同一模型；开放权重与常见部署工具则让外部开发者可以真正下载、量化和测试，而不只是在云端体验。
它是否能把这些设计转化成稳定的能力、速度和成本优势，仍要看后续评测。但至少现在，围绕这款模型的讨论已经从架构数字走向了可运行的软件和真实机器上的尝试。
局限与未知
- 供稿没有给出或验证“百万上下文”，也没有说明上下文窗口的 token 上限，不能把百万级长文处理能力写进结论。
- 276B 总参数、12B 激活参数及架构细节目前来自官方 Hugging Face 模型页这一处信源，尚缺独立交叉验证。
- 现有用户实测是不同配置下的一次非标准化对比，不能外推为通用的速度或代码能力排名。