能否将所有的kv缓存存到faiss向量数据库里
Minami-su opened this issue · comments
能否将所有的kv缓存存到faiss向量数据库里，以节省gpu显存达到无限上下文长度，具体可以参考https://github.com/Victorwz/LongMem
你好，目前 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 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显存开销？
因为我看longmem是这么做的，他除此之外还多了一个残差网络
faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。
因为我看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？
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显存
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 限制显存使用进行测试。
因为我看longmem是这么做的，他除此之外还多了一个残差网络
faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。
faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢
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架构就行了
因为我看longmem是这么做的，他除此之外还多了一个残差网络
faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。
faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢
这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入
因为我看longmem是这么做的，他除此之外还多了一个残差网络
faiss 向量库的建立速度比较慢，适用于大规模向量查询，批量向量插入。我认为不适用于 streaming 的 chat 场景。
faiss 向量库的建立速度比较慢，建立速度比较慢主要是embedding模型对文本转换向量时的转换速度影响，而kv缓存本身就是向量所以不会存在建立速度比较慢这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入
唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里
存本身就是向量所以不会存在建立速度比较慢
这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入
唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里
感谢提议！之后我会测试性能，如果可行，会作为一个 option 发布。
存本身就是向量所以不会存在建立速度比较慢
这里就直接舍去了embedding模型，单纯的把faiss作为向量储存库到磁盘里，使用q向量作为查询与faiss向量储存库里的kv缓存做相似度计算采取topk，完全不会速度慢因为没有额外embedding模型引入
唯一区别就是kv缓存由gpu内存，变成在faiss磁盘里
感谢提议！之后我会测试性能，如果可行，会作为一个 option 发布。
同样非常感谢你！