如何使用 Kimi Linear 在普通 GPU 上塞下一百万 token

有没有想过为什么在 LLM 中处理长文本这么贵？问题全在 KV-cache。当给模型喂一篇超长文档时，它的"记忆"（缓存）会膨胀到离谱的大小，把你的显存吃得一干二净。MoonshotAI 的人觉得是时候做点什么了，于是推出了 Kimi Linear。这不仅仅是又一个"改进版"模型——而是一次对注意力架构的重新思考，让我们可以在不买服务器集群的情况下处理百万 token 上下文。

普通注意力的问题出在哪里

标准 Full Attention 机制（经典 transformer 中的那种）是个贪吃兽。它的复杂度随文本长度呈二次增长。想要两倍大的上下文？准备好花四倍的资源。Flash Attention 或 DeepSeek 的 MLA（多头潜在注意力）等流行方案有所帮助，但在处理真正超长序列时并不能从根本上解决问题。

Kimi Linear 采用了不同的方法。开发者使用了一种混合方法，结合了 transformer 和类 RNN 结构的优势。

Kimi Delta Attention 的工作原理

该项目的核心是 Kimi Delta Attention（KDA）机制。不深入讲硬核数学的话，它是 Gated DeltaNet 概念的演进。这里的主要技巧是智能"遗忘"。

在标准 RNN 中，记忆受限于固定的 state 大小。KDA 采用一种门控机制，决定哪些过去的信息应该保留在这个压缩 state 中，哪些可以丢弃。这使得模型即使在极长的距离上也能保持高精度，而传统线性模型此时会开始"漂移"，丢失对上下文的追踪。

这在实践中带来了什么

开发者引入了一种架构，其中 KDA 和 MLA（全局注意力）以 3:1 的比例混合。这种组合取得了几个令人印象深刻的结果：

1. 内存节省。 KV-cache 需求降低了 75%。在自有硬件上部署模型时，这一点至关重要。
2. 生成速度。 在 100 万 token 上下文上，token 吞吐量比标准架构提升高达 6 倍。
3. 真正的上下文利用。 在 RULER 上的基准测试表明，模型真正"看到"并利用了全部 128k（最高 1M）token 的信息，而不是装装样子。

下图展示了随着上下文长度增加，Kimi Linear（蓝线）如何在速度上领先：

上手试试

MoonshotAI 毫不吝啬，在 Hugging Face 上发布了模型权重。有基础版本和 Instruct 变体，共 480 亿参数。得益于专家混合（MoE）架构，推理时只有 30 亿参数被激活，使得该模型在其类别中出人意料地轻量。

要开始使用，你需要最新版的 PyTorch 和 fla-core 库。对于用过 transformers 的人来说，代码看起来相当标准：

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "moonshotai/Kimi-Linear-48B-A3B-Instruct"
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype="auto",
    device_map="auto",
    trust_remote_code=True
)
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)

# Обычный чат-шаблон
messages = [
    {"role": "system", "content": "You are a helpful assistant provided by Moonshot-AI."},
    {"role": "user", "content": "Расскажи, в чем преимущество линейного внимания перед обычным?"}
]

input_ids = tokenizer.apply_chat_template(
    messages, 
    add_generation_prompt=True, 
    return_tensors="pt"
).to(model.device)

generated_ids = model.generate(inputs=input_ids, max_new_tokens=500)
response = tokenizer.batch_decode(generated_ids)[0]
print(response)

如果需要投入生产环境，该模型与 vLLM 配合良好。你可以用一条终端命令启动一个 OpenAI 兼容的 API，并指定一个巨大的 max-model-len。

值得下载吗

对于构建 RAG 系统或分析长日志和文档的人来说，这个项目看起来很有前景。

谁绝对应该仔细看看：

• 在处理长上下文时遇到 GPU 内存瓶颈的人。
• 关心实时响应速度（TPOT）的开发者。
• 寻找标准 transformer 替代方案的研究人员。

不利的一面是，该架构相对较新，第三方工具（如量化或特定优化器）的支持可能不会立即到来。但 FLA 库中已有现成的 KDA 内核，这很令人鼓舞。

Kimi Linear 是一个很好的例子，证明算法优化仍然可以带来比单纯堆砌更多算力更大的收益。如果你需要"消化"整个代码库或大量文档——这可能是目前最有趣的工具之一。