Conversation
Summary of ChangesHello @hiworldwzj, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly expands the LightLLM framework's capabilities by integrating the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces support for the qwen3-omni-thinker model, a significant undertaking that adds numerous files for the new model's architecture, including its audio and visual components. While the overall structure is sound, I've identified several areas for improvement. My review includes a critical bug fix in configuration handling, high-severity issues related to type correctness and device handling, and several medium-severity suggestions to enhance code clarity, remove dead code, and align with best practices. Addressing these points will improve the robustness and maintainability of the new model's integration.
I am having trouble creating individual review comments. Click here to see my feedback.
lightllm/utils/config_utils.py (28-29)
There is a potential bug in the config retrieval logic. If thinker_config exists but does not contain the requested key, value will be overwritten to None, potentially discarding a valid value found in a higher-level config. The logic should be revised to prioritize thinker_config without incorrectly nullifying a previously found value.
lightllm/models/qwen3_omni_moe_thinker/qwen3_omni_audio.py (85-87)
The method is type-hinted to return a torch.Tensor, but it returns a tuple (hidden_states,). To match the type hint and expected behavior, you should return hidden_states directly.
return hidden_states
lightllm/models/qwen3_omni_moe_thinker/model.py (111)
The first argument to ValueError is a boolean expression image_cnt == image_id, which will result in an error message like (False, 'invalid image tag num: ...'). This is likely not the intended behavior. The error message should probably be just the formatted string.
raise ValueError(f"invalid image tag num: {image_cnt} vs {image_id}!")
lightllm/models/qwen3_omni_moe_thinker/audio_process.py (179-184)
The device is hardcoded to "cuda" when converting the final tensors, but the method signature includes a device parameter that defaults to "cpu". This inconsistency can lead to unexpected behavior. The device parameter should be used to allow for flexibility in device placement.
input_features = torch.from_numpy(np.asarray(padded_inputs["input_features"], dtype=np.float32)).to(
device=device, dtype=torch.bfloat16
)
attention_mask = torch.from_numpy(np.asarray(padded_inputs["attention_mask"], dtype=np.float32)).to(
device=device, dtype=torch.int32
)
lightllm/models/qwen3_omni_moe_thinker/model.py (139)
Similar to the image tag check, the first argument to ValueError here is a boolean, which is likely not intended. The error message should probably be just the formatted string.
raise ValueError(f"invalid audio tag num: {audio_cnt} vs {audio_id}!")
lightllm/models/qwen3_omni_moe_thinker/model.py (165)
This print statement appears to be for debugging purposes. It should be removed or replaced with a proper logging call (e.g., logger.debug(...)) for production code.
lightllm/models/qwen3_omni_moe_thinker/layer_weights/meta_weights/code2wav_conv_ne_xt.py (123)
It's a best practice to avoid using names of built-in functions like input as variable names. This can cause confusion and potential bugs. Consider renaming it to something like residual here and on line 140.
residual = hidden_states
lightllm/models/qwen3_omni_moe_thinker/layer_weights/meta_weights/code2wav_causal_trans_conv_net.py (34)
The assignment to pad is redundant because the variable pad is not used afterward. This can be simplified.
self.right_pad = self.left_pad
lightllm/models/qwen3_omni_moe_thinker/layer_infer/transformer_layer_infer.py (15)
The return statement at the end of an __init__ method is redundant as it implicitly returns None. It can be removed for cleaner code.
lightllm/common/basemodel/layer_weights/base_layer_weight.py (36-40)
The logic to safely access self.layer_num_ can be simplified by using getattr with a default value. This is more concise and idiomatic Python.
layer_num = getattr(self, "layer_num_", None)
assert attr.verify_load(), f"Loading {attr_name} of layers {layer_num} fails."lightllm/models/qwen3_omni_moe_thinker/qwen3_omni_visual.py (369)
This print statement seems to be for debugging. It can produce a large amount of output and should be removed or replaced with a proper logger call for production code.
lightllm/server/audioserver/model_infer/model_rpc.py (34)
The model's data type is hardcoded to bfloat16, which ignores the data_type provided in kvargs. For consistency and flexibility, consider converting the model to the specified data type from the arguments.
lightllm/server/visualserver/model_infer/model_rpc.py (88-92)
The model's data type is hardcoded to bfloat16, which ignores the data_type from kvargs. It would be more robust to use the provided data_type to set the model's precision.
lightllm/models/qwen2_vl/triton_kernel/get_mrope_position_ids.py (31)
This line is commented out and appears to be unused. To improve code clarity, it's best to remove such dead code.
lightllm/utils/config_utils.py (87-88)
Using a bare except: is generally discouraged as it can hide unexpected errors. It's better to catch only the specific exceptions you anticipate, such as KeyError, IndexError, or AssertionError.
except (KeyError, IndexError, AssertionError):
pass
No description provided.