Chen Xin

@zodiacg > 第一轮之后模型没有保存着中间状态等着你输入下一句。每次添加一轮对话模型都会先计算前面的对话历史，然后继续输出。 在接收新一轮的对话时，历史对话的kvcache完全可以保留， 这样就不用重复计算了，这是推理框架决定的，而不是大模型都这样。 关键的问题在于，多轮多图时，prompt该怎么拼。如果图片token的位置拼在当前轮user的prompt当中，是可以做到不重复计算，但是如果要求拼在开头，那么就会破坏历史，历史的kvcache也就无效了。 很多模型做不到“图文交错”对话。很多模型给的多图多轮对话的例子，都只是在最开始输入了多图。如果不用实例代码给的接口，直接手动拼embedding，然后调transformers的接口，会发现效果真的不怎么行。

@zodiacg > 我指的就是prompt怎么拼。如果我没记错，目前所有大模型提供的api接口时都是要求多轮提交时自带对话历史，并且占用token数，不存在服务器保留session只提交下一轮对话的情况。prefill比输出便宜当然是因为kvcache没错，但这跟你每次提交依然要把所有对话历史拼进去没有冲突。 lmdeploy 就支持interactive的对话，即获取下一轮的输入后可以不对历史的input做prefill。 > images放在一起不等于拼在了开头，internlm-xcomposer恰恰就是做到了图文交错，它会把图像编码后放在文本中出现的位置。所以拼接新一轮次的对话时，必须保留历史图像，否则images与的数量就会不对应。如果把历史的图像不再输入才会破坏输入结构导致kvcache失效 这个你可能没get到我的点。图文交错是指每一轮的prompt都可以有image信息。而不是指图片的token放到user中的位置。类似[deepspeed-visualchat](https://arxiv.org/abs/2309.14327)那个图1。xcomposer我好像没看到说支持 'interleaved text-and-image conversations' 举个例子： 对于这样的历史 `{image}{question1} {answer1}`，如果下一轮有图片， 理想的prompt应该是`{image}{question1} {answer1}{image}{question2}`， 但是按照某些模型的demo会拼成这样 `{image}{image}{question1} {answer1}{question2}`。 前者每一轮的输入不会改变历史prompt结构，kvcache可以复用，就看框架是否支持。后者会破坏历史prompt的结构(因为后一轮的图片放到第一轮了），kvcache没办法复用。

@zengjiechuan Hi jiechuan， Could you please share the new version you build ?

> > @zengjiechuan > > Hi jiechuan， > > Could you please share the new version you build ? > > Hi, irexyc > I have to find it for...

Currently, the `TopDownAffine` can be processed on gpu.

方便的话，可以分享一下 OpenGVLab/InternVL-Chat-ViT-6B-Vicuna-7B 的 inference 代码

@sunjunlishi 你这个是vit的代码吧，我想知道的是 https://huggingface.co/OpenGVLab/InternVL-Chat-ViT-6B-Vicuna-7B 这个code的推理代码用的是哪个。 用 llava.serve.model_worker 加载模型的话，加载模型用的还是load_pretrained_model这个函数。 对 InternVL-Chat-ViT-6B-Vicuna-7B 来讲，我认为会有问题。InternVL-Chat-ViT-6B-Vicuna-7B 里面的vit的权重和InternViT-6B-224px 关于position_embedding的是不一致的。看起来是要用InternVL-Chat-ViT-6B-Vicuna-7B里面的才对，但是这个函数的逻辑，加载LLM的时候会delay_load vision_tower, 最后加载vision_tower的时候实际上加载的vision tower，iamge_preprocessor都是InternViT-6B-224px 里面的。

@czczup 请问具体是哪个脚本？ 如我上面说的，以 https://github.com/OpenGVLab/InternVL/blob/main/internvl_chat_llava/scripts_internvl/eval/mmbench.sh 为例，加载模型用的是这一行 https://github.com/OpenGVLab/InternVL/blob/main/internvl_chat_llava/llava/eval/model_vqa_mmbench.py#L11 加载模型用的函数并没有显示的对 vision_tower 进行 resize_pos_embeddings https://github.com/OpenGVLab/InternVL/blob/0f76e06fd202cbd60fa338afbb51167fb3eda7de/internvl_chat_llava/llava/model/builder.py#L137-L141 然而 InternVL-Chat-ViT-6B-Vicuna-7B 这个模型权重里面，vit 的权重 跟 OpenGVLab/InternViT-6B-224px embeddings layer 不一样 （可以去看下 embeddings.position_embedding 的尺寸）。这难道没有问题么？

我指的不是会报错，而是我认为你们的代码有问题，或者不完整。 而是从目前的[代码](https://github.com/OpenGVLab/InternVL/blob/main/internvl_chat_llava/llava/model/multimodal_encoder/clip_encoder.py#L51-L57)上看，InternVL-Chat-ViT-6B-Vicuna-7B 对应的预处理、vision 是 （336, 336）尺寸的。 而 OpenGVLab/InternViT-6B-224px 这个模型对应的预处理、vision 是 (224 x 224）的。用 load_pretrained_model 这个函数加载的话 最终加载的是 (224 x 224) 这个尺寸的。 mm_projector 和 vision_tower 的权重应该要对应吧。从huggingface的权重来看，vision tower 输入尺寸是336 x 336的，但是目前的代码加载的预处理以及vision是 224 x...

low_cpu_mem_usage=True, 去掉试试