docs: Update Llava guide to PyTorch backend with Qwen2.5-VL

[faradawn]

Rewrite the multimodal deployment tutorial to use the TensorRT-LLM PyTorch backend (LLM API) instead of the deprecated TensorRT engine-build workflow, and update the example model from Llava-1.5-7B to Qwen2.5-VL-7B-Instruct. The guide now configures the model through model.yaml and serves it directly without building separate visual and LLM engines, and points to the multimodal LLM API docs for image request formatting.

[greptile-apps]

Greptile Summary

This PR rewrites the Llava1.5 TensorRT-LLM deployment guide to use the modern PyTorch/LLM API backend with Qwen2.5-VL-7B-Instruct, replacing the deprecated trtllm-build + visual engine workflow. The guide is significantly shorter and simpler as a result.

• Removes the multi-engine build flow (trtllm-build, build_visual_engine.py, fill_template.py) in favor of a single model.yaml config pointing directly at a HuggingFace checkpoint.
• Replaces the old Llava1.5 model with Qwen2.5-VL-7B-Instruct and updates the inference request example to the Triton generate endpoint.
• Defers the multimodal (image+text) request format to external documentation links rather than providing an inline example.

Confidence Score: 4/5

Documentation-only change that simplifies the deployment workflow; two concrete usability gaps need addressing before this guides users successfully end-to-end.

The HF_TOKEN is never wired into the container, silently breaking downloads for gated models. The model.yaml snippet gives no indication of whether it replaces the file or patches existing keys, risking loss of required default configuration.

Popular_Models_Guide/Llava1.5/llava_trtllm_guide.md — the docker run command and the model.yaml edit instruction both need clarification.

Important Files Changed

Filename	Overview
Popular_Models_Guide/Llava1.5/llava_trtllm_guide.md	Tutorial rewritten to use PyTorch/LLM API backend; HF_TOKEN propagation into the container is not handled, and the model.yaml snippet is ambiguous about whether it is a full-file replacement or a targeted field update.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Host: docker run with HF cache mount] --> B[Interactive container session]
    B --> C[git clone TensorRT-LLM]
    C --> D[Edit model.yaml\nmodel: Qwen/Qwen2.5-VL-7B-Instruct\nbackend: pytorch]
    D --> E[launch_triton_server.py\n--model_repo=.../llmapi/]
    E --> F{Server Ready?}
    F -->|Yes| G[curl /v2/models/tensorrt_llm/generate\ntext-only prompt]
    F -->|No| H[Check logs]
    G --> I[For image+text: see external docs]

Loading

_{Reviews (2): Last reviewed commit: "docs: Update Llava guide to PyTorch back..." | Re-trigger Greptile}

[greptile-apps]

Missing volume mount breaks the workflow

The docker run command mounts only ~/.cache/huggingface, but the subsequent steps require access to the cloned TensorRT-LLM/ directory. If users follow the natural reading (clone on the host, then run Triton inside the container), the TensorRT-LLM/ path will not exist inside the container and the launch_triton_server.py command will fail. If the intent is to clone inside the running container, the guide should say so explicitly — but the --rm flag means the clone is discarded on container exit, making the workflow non-reproducible across sessions. A -v /path/to/TensorRT-LLM:/TensorRT-LLM mount (matching the git clone location on the host) needs to be added to the docker run command, or the guide must explicitly state that steps 2–4 are all performed inside a single interactive container session.

[greptile-apps]

Unversioned git clone risks reproducibility

Cloning from main without a branch or tag pin means the directory layout (triton_backend/all_models/llmapi/, triton_backend/scripts/launch_triton_server.py) and the model.yaml schema could change at any commit, silently breaking the tutorial. Adding --branch <release-tag> (e.g. the same tag that matches the <xx.yy> container version) would make the guide self-consistent and reproducible.