Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update TensorRT-LLM #1274

Merged
merged 2 commits into from
Mar 12, 2024
Merged

Update TensorRT-LLM #1274

merged 2 commits into from
Mar 12, 2024

Conversation

kaiyux
Copy link
Member

@kaiyux kaiyux commented Mar 12, 2024

  • Model Support
    • Support VILA (see “LLaVA and VILA” section in examples/multimodal/README.md)
  • Features
    • Support loading Gemma from Hugging Face
    • Add support to context chunking to work with KV cache reuse
    • Support auto parallelism planner for high-level API and unified builder workflow
    • Enable multi-LoRA for BART LoRA
  • API
    • [BREAKING CHANGE] Remove model parameter from gptManagerBenchmark and gptSessionBenchmark
  • Bug fixes
  • Performance
  • Infra
    • TensorRT dependency is updated to 9.3.
    • Base Docker image for TensorRT-LLM is updated to nvcr.io/nvidia/pytorch:24.01-py3
    • Base Docker image for TensorRT-LLM backend is updated to nvcr.io/nvidia/tritonserver:24.01-py3

@Shixiaowei02 Shixiaowei02 force-pushed the kaiyu/update branch 2 times, most recently from a3cbbf6 to df77e19 Compare March 12, 2024 09:04
return new_network


def find_solution(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, previously, almost 1 year ago, we also wrote a python/cpp separately to find pipeline partitions upon ONNX IR and cpp IR (where we can have more accurate memory estimation).

Since Tensor-LLM now uses its own memory-pool to mange memory allocation. I guess the esitmation will be better now.

The method we used (I also wrote a solver with dyanmical programming) is multi-level graph based.

The problem of performaning solver upon ONNX IR graph is that you cannot always garantee the same topological order in frontend and backend. I guess you will have the same problem.

Obviously one could start with 2-device partition, the answer is naive. (that was initial reason why I used dynamic programming), then extend the solution to 4, 8 or many devices mesh.

However, iterating the nodes is time consuming, so we have to do it in cpp backend with heuristic search.

I wonder how did you managed to run into these problems ? And what is the compile time you have , for example 1000 nodes of graph ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants