sjzhou4
sjzhou4
@lvhan028 hello，感谢你的指导，我再llama2-70B上使用ntk，发现8K的长度是ok的，但是再长，比如到16k，就会有乱码了，请问这个问题怎么处理，使用q_scaling吗？
你这个需要修改下server的逻辑吧，对有图片进行VIT网络后生成的embedding和ranges只计算一次，然后进行LLM的时候，设置采样，增加种子等，可以提高多样性
嗨，我也发现了类似的问题，我这边简单分析了下，lmdeploy比vllm在vit部分平均增加的耗时是由于lmdeploy需要将vit的feature遍历从gpu到cpu，也就是下面图中的x.cpu()引起的。vllm不需要此环节 
我这边注释掉之后基本上就少了对应的to cpu的时间，而且vit整体的性能我测试来看lmdeploy和vllm是近似的（去掉to cpu的话）。  
但是这里虽然是去掉了to cpu时间，后面还是会进行gpu到cpu同步的，lmdeploy逻辑是这样实现的
@irexyc @fong-git 是的，lmdeploy的to cpu 是不能缺少的，就像 @Dimensionzw 说的那样，lmdeploy和vllm的架构设计有区别的，lmdeploy更多的是在上层进行模版拼接、特征提取等工作，最后把这些inputs信息传递到turomind backend端进行处理。而且像 @irexyc 说的，后面的prefix caching等，也可能会使用内存、甚至硬盘来存储特征信息，进而优化显存的占用，这些都是需要to cpu操作的
原因基本是：lmdeploy在al或者vl模型使用的特征抽取，其实都是用的python去做的，而vllm是用算子kernel实现的，我这边简单测试了下，在vit网络的foward，基本上lmdeploy的性能是vllm的1/3。然后大batch，性能下降更明显
还有就是上面提到的.cpu()的问题，其实这部分的时间在目前al和vl消耗并不大，比如vl上面，256 * n * hidden_size * 2 / 1024 /1024/ 1024 /pcie带宽 * 1000 ms，基本上都在10ms以内了