q yao

https://github.com/Dao-AILab/fast-hadamard-transform/blob/f134af63deb2df17e1171a9ec1ea4a7d8604d5ca/setup.py#L40 These flags might help.

TP8 with bf16 nccl all_reduce might have low precision.

引擎内部是按照 dllm 的方式进行计算与解码的，你提的问题主要是下面的因素导致的： - 为了保证性能，引擎内部计算和外部接口是异步的，在外部接口接收输入时内部可能已经完成了数个 block 的解码，所以每次拿到的token数量会超出预期 - 输出尚未完全解码额定 block会破坏流式输出的接口结构，因此我们只有在一个 block 完全解码后才会把它输出。 如果有这方面需求，暂时可以改这里 https://github.com/InternLM/lmdeploy/blob/7e3869ec375a124d8ad3bb73e9aac416cbce9dfb/lmdeploy/pytorch/engine/engine.py#L841 加 log，看 msg.all_ids 的值，可以看到从输入起到当前参与计算的 token。

多 lora 是支持的，不过要在加载模型时都指定好，不支持运行时动态添加 如果特定模型 lora 支持失效可以向我们汇报

读 json 文件的时候出错了，可以检查一下模型完整性

看 Log 报错的地方就是在读模型路径下的 model.safetensors.index.json https://github.com/InternLM/lmdeploy/blob/7e3869ec375a124d8ad3bb73e9aac416cbce9dfb/lmdeploy/pytorch/weight_loader/model_weight_loader.py#L72 可以试试看单独用 json.load 读这个文件。我这边本地无法复现这个问题

Environment Please run lmdeploy check_env to collect necessary environment information and paste it here. You may add addition that may be helpful for locating the problem, such as Which model...

感谢汇报 这确实算是一个 bug。ModelInputs.split 是用来处理超长 prefill 的分块计算的，max_kv_seqlen 的初始值应该是历史长度+当前轮 q_seqlen。不过从 self.history_lengths 可能涉及到一次 host-device 同步，不算最好的解决方案，从原本的 max_kv_seqlen 和 max_q_seqlen 进行换算会比较好。我们会尽快修复，或者如果你有这个意向的话也欢迎提 PR。 另外这个值目前主要的用处是 attention 的 grid 以及 kv cache 的一些资源分配，超量分配会造成少量的浪费，但是不会对精度和性能造成太多影响。