取决于首token延迟，如果是分钟级别，大概率是grouped query attention + 工程优化。
其中，工程优化包括但不限于：flash attention + ring attention, paged attention + distributed kv cache, kv cache offloading/quantization。
我们知道，当序列长度变长，模型推理（prefill阶段）的瓶颈主要在attention的计算上（平方复杂度）。为了加速这一部分，我们可以通过序列并行的方式将计算均匀地分配到不同的GPU上（即ring attention）。
那么，对于百万级别的序列长度，我们到底需要多长的推理时间呢？口说无凭，我这边贡献一组数据。
在8 * 4090 GPUs的环境下，测试llama-7b规模下ring attention的前向时间（包括通信），其中head num=32, head dim=128, kv head num=4, batch size=1。
单层attention前向计算的时间（ms）和序列长度的关系如下：
| 长度 | 16k | 32k | 64k | 128k | 256k | 512k | 1m |
|---|---|---|---|---|---|---|---|
| 时间 | 5.22 | 14.40 | 42.74 | 134.27 | 487.04 | 1828.51 | 7074.37 |
可见，当序列长度为512k时，32层attention的计算时间大约为60秒。当序列长度为1m，计算时间也不会超过4分钟。对于更大的模型，使用更好的硬件资源和工程实现，首token的延迟应该可以控制在分钟级别。
不过，不知道是不是因为gemini-1.5发布在前（支持1M甚至10M的窗口+多模态），大家似乎严重低估了kimi chat实现200万长度无损上下文的难度，这个问题下的很多回答甚至还是贬低为主。无论如何，moonshot团队敢于将窗口长度扩充到200万，这确实可以称得上是一个“登月工程”。
最后，期待超长序列大模型可以解锁更多有趣的应用。目前官方所展示的一些任务，例如一次处理500个文件，完全可以通过取巧的方式（例如分块）解决，并没有发挥出超长序列的能力。一个有趣的例子，是gemini-1.5论文里所展示的in-context learning的能力，即让模型阅读语法书来解决卡拉曼語的翻译任务。