能否将所有的kv缓存存到faiss向量数据库里

[Minami-su]

能否将所有的kv缓存存到faiss向量数据库里，以节省gpu显存达到无限上下文长度，具体可以参考https://github.com/Victorwz/LongMem

[guyan364]

你好，目前 kv cache 都在 cpu 内存中。如果指每个 memory unit 的代表向量，确实是随着上下文长度线性增加，但是大小并不大，对于 mistral-inf-llm 推理 1M token 占用显存 2G。查询 topk 的过程可以使用 faiss, 但是在大多数情况下没有必要。目前推理 passkey（128k），将 chunk size 调整至 512（节省 FFN 显存）peak memory usage 小于 18G。 由此我们目前没有计划加入 faiss 的支持。

[Minami-su]

你好，目前 kv cache 都在 cpu 内存中。如果指每个 memory unit 的代表向量，确实是随着上下文长度线性增加，但是大小并不大，对于 mistral-inf-llm 推理 1M token 占用显存 2G。查询 topk 的过程可以使用 faiss, 但是在大多数情况下没有必要。目前推理 passkey（128k），将 chunk size 调整至 512（节省 FFN 显存）peak memory usage 小于 18G。 由此我们目前没有计划加入 faiss 的支持。

但是好像把kv缓存存到faiss里就能实现无限上下文？然后基本无GPU显存开销？

[guyan364]

因为我看longmem是这么做的，他除此之外还多了一个残差网络

faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。

[Minami-su]

因为我看longmem是这么做的，他除此之外还多了一个残差网络

faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。

你好，目前 kv cache 都在 cpu 内存中。如果指每个 memory unit 的代表向量，确实是随着上下文长度线性增加，但是大小并不大，对于 mistral-inf-llm 推理 1M token 占用显存 2G。查询 topk 的过程可以使用 faiss, 但是在大多数情况下没有必要。目前推理 passkey（128k），将 chunk size 调整至 512（节省 FFN 显存）peak memory usage 小于 18G。 由此我们目前没有计划加入 faiss 的支持。 能否给出peak memory usage 小于 18G相应的config？

[Minami-su]

model: type: inf-llm path: Qwen1.5-7B-Chat block_size: 128 n_init: 128 n_local: 4096 topk: 16 repr_topk: 4 max_cached_block: 32 exc_block_size: 512 score_decay: 0.1 fattn: true base: 1000000 distance_scale: 1.0

max_len: 2147483647 chunk_size: 512 conv_type: qwen 这是我的config，在运行bash scripts/infinitebench.sh时峰值已经超过了24g显存

[guyan364]

model: type: inf-llm path: Qwen1.5-7B-Chat block_size: 128 n_init: 128 n_local: 4096 topk: 16 repr_topk: 4 max_cached_block: 32 exc_block_size: 512 score_decay: 0.1 fattn: true base: 1000000 distance_scale: 1.0

max_len: 2147483647 chunk_size: 512 conv_type: qwen 这是我的config，在运行bash scripts/infinitebench.sh时峰值已经超过了24g显存

qwen1.5 没有使用 group kv，local kv 以及 global remainder 大小为 mistral 的 4 倍。对于 mistral-7b，只需要设置 chunk size 为 512 即可。对于显存大于 18G 的 GPU，可以使用 torch.cuda.set_per_process_memory_fraction 限制显存使用进行测试。

[Minami-su]

因为我看longmem是这么做的，他除此之外还多了一个残差网络

faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。 faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢

[Minami-su]

model: type: inf-llm path: Qwen1.5-7B-Chat block_size: 128 n_init: 128 n_local: 4096 topk: 16 repr_topk: 4 max_cached_block: 32 exc_block_size: 512 score_decay: 0.1 fattn: true base: 1000000 distance_scale: 1.0 max_len: 2147483647 chunk_size: 512 conv_type: qwen 这是我的config，在运行bash scripts/infinitebench.sh时峰值已经超过了24g显存

qwen1.5 没有使用 group kv，local kv 以及 global remainder 大小为 mistral 的 4 倍。对于 mistral-7b，只需要设置 chunk size 为 512 即可。对于显存大于 18G 的 GPU，可以使用 torch.cuda.set_per_process_memory_fraction 限制显存使用进行测试。

嗯好的，明白，我把qwen转成mistral架构就行了

[Minami-su]

因为我看longmem是这么做的，他除此之外还多了一个残差网络

faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。 faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢

这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入

[Minami-su]

因为我看longmem是这么做的，他除此之外还多了一个残差网络

faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。 faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢

这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入

唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里

[guyan364]

存本身就是向量所以不会存在建立速度比较慢

这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入

唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里

感谢提议！之后我会测试性能，如果可行，会作为一个 option 发布。

[Minami-su]

存本身就是向量所以不会存在建立速度比较慢

这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入

唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里

感谢提议！之后我会测试性能，如果可行，会作为一个 option 发布。

同样非常感谢你！