[Trace][Core] Add traces from Splitwise, make CLI params more intuitive

[nitinkedia7]

Changelog

1. Add traces from Splitwise. There are two traces (code and conversation) with arrival times. Trace lengths are approximately 1h each.
2. Change TraceReplayRequestGenerator to read columns num_prefill_tokens,num_decode_tokens,arrived_at instead of PromptTokenCount,GeneratedTokenCount,Time. This makes the newly added traces compatible with TraceRequestLengthGenerator which ignores arrival times and only focuses on lengths.
3. Consolidate max_tokens parameter only in the places it is absolutely required.
4. Improved defaults of parameters to make them more intuitive notably setting scale_factors to 1.

Test Plan

The below command which runs splitwise_conv trace works with Llama-3-8B.

python -m vidur.main \
--time_limit 300 \
--replica_config_model_name "meta-llama/Meta-Llama-3-8B" \
--replica_config_tensor_parallel_size 1 \
--replica_config_num_pipeline_stages 1 \
--cluster_config_num_replicas 4 \
--replica_config_device a100 \
--replica_config_network_device a100_dgx \
--replica_scheduler_config_type sarathi \
--sarathi_scheduler_config_chunk_size 512 \
--sarathi_scheduler_config_batch_size_cap 512 \
--random_forrest_execution_time_predictor_config_prediction_max_prefill_chunk_size 16384 \
--random_forrest_execution_time_predictor_config_prediction_max_batch_size 512 \
--random_forrest_execution_time_predictor_config_prediction_max_tokens_per_request 16384 \
--request_generator_config_type trace_replay \
--trace_request_generator_config_trace_file ./data/processed_traces/splitwise_conv.csv \
--trace_request_generator_config_prefill_scale_factor 1 \
--trace_request_generator_config_decode_scale_factor 1 \
--trace_request_generator_config_time_scale_factor 1 \
--trace_request_generator_config_max_tokens 16384 \
--metrics_config_output_dir ./simulator_output/sim_8b_splitwise_conv \
--no-metrics_config_write_json_trace \
--metrics_config_enable_chrome_trace \
--metrics_config_keep_individual_batch_metrics \
--metrics_config_store_plots

---

PR Checklist (Click to Expand)

Thank you for your contribution to Vidur! Before submitting the pull request, please ensure the PR meets the following criteria. This helps Vidur maintain the code quality and improve the efficiency of the review process.

PR Title and Classification

Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

• [Bugfix] for bug fixes.
• [CI/Build] for build or continuous integration improvements.
• [Doc] for documentation fixes and improvements.
• [Model] for adding a new model or improving an existing model. Model name should appear in the title.
• [Profiling] For changes on the profiling module.
• [Core] for changes in the core simulator logic
• [Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.

Code Quality

The PR need to meet the following code quality standards:

• Pass all linter checks. Please use make format to format your code.
• The code need to be well-documented to ensure future contributors can easily understand the code.
• Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of Vidur. It helps user understand and utilize the new features or changes.

Notes for Large Changes

Please keep the changes as concise as possible. For major architectural changes (>500 LOC), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.

Thank You

Finally, thank you for taking the time to read these guidelines and for your interest in contributing to Vidur. Your contributions make Vidur a great tool for everyone!