[Feat](Mooncake) Supports multiple input suffixes for global_segment_size

[Liziqi-77]

What this PR does / why we need it?

• global_segment_size and local_buffer_size use constants for unified management.
• Newly added support for input formats ending with GB, MB, KB, and B, while being compatible with existing input methods.

Does this PR introduce any user-facing change?

• Users can use new input methods
• The documentation has also been modified

How was this patch tested?

• vLLM version: v0.11.0
• vLLM main: vllm-project/vllm@83f478b

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

[gemini-code-assist]

Code Review

This pull request introduces a useful feature to support multiple input suffixes (GB, MB, KB, B) for size configurations like global_segment_size and local_buffer_size. The implementation is mostly solid and includes good test coverage. I've identified a few issues that should be addressed to improve correctness and maintainability. Specifically, the documentation contains an invalid JSON example, a type hint is incorrect, and a parsing function should be generalized to improve its reusability and error reporting. My detailed comments provide suggestions to resolve these points.

[gemini-code-assist]

The example value for global_segment_size is not valid JSON. It appears to be demonstrating multiple possible formats in one line, which will cause a parsing error for users who copy this configuration. Please provide a single, valid example. The other formats can be explained in the documentation text below the code block.

Suggested change

	"global_segment_size": "1GB/1024MB/1048576KB/1073741824B" or 1073741824
	"global_segment_size": "1GB"

[gemini-code-assist]

The type hint for global_segment_size is updated to int | str. However, since the value is immediately parsed by _parse_global_segment_size which returns an int, the attribute on the MooncakeStoreConfig instance will always be an int. To accurately reflect the attribute's type after initialization, this hint should remain int. This will also maintain consistency with local_buffer_size, which is also parsed but its type hint correctly remains int.

Suggested change

	global_segment_size: int | str
	global_segment_size: int

[gemini-code-assist]

To improve error message clarity, the parsing function should be made aware of the parameter it's parsing. This will allow it to produce more specific error messages (e.g., for local_buffer_size instead of a generic one). This change is part of a refactoring to make _parse_global_segment_size more generic. I've suggested renaming it to _parse_size and passing the parameter name as an argument in a separate comment.

Suggested change

	global_segment_size=_parse_global_segment_size(
	config.get("global_segment_size", DEFAULT_GLOBAL_SEGMENT_SIZE)
	),
	local_buffer_size=_parse_global_segment_size(
	config.get("local_buffer_size", DEFAULT_LOCAL_BUFFER_SIZE)
	),
	global_segment_size=_parse_size(
	config.get("global_segment_size", DEFAULT_GLOBAL_SEGMENT_SIZE),
	"global_segment_size"
	),
	local_buffer_size=_parse_size(
	config.get("local_buffer_size", DEFAULT_LOCAL_BUFFER_SIZE),
	"local_buffer_size"
	),

[gemini-code-assist]

The function _parse_global_segment_size is now used for both global_segment_size and local_buffer_size, but its name and error messages are specific to global_segment_size. This is misleading and can produce confusing error messages (e.g., an error about global_segment_size when local_buffer_size is invalid). I suggest refactoring this function to be more generic by renaming it to _parse_size and passing the parameter name as an argument to be used in error messages.

def _parse_size(value, name: str) -> int:
    """
    Parse storage size strings with support for units: GB, MB, KB, B
    
    Args:
        value: Input value (int, str, or other convertible types)
        name: Name of the parameter being parsed (for error messages)
        
    Returns:
        int: Size in bytes
        
    Raises:
        ValueError: For invalid format, missing number, or negative values
        TypeError: For unsupported input types
    """

    if isinstance(value, int):
        return value
    elif not isinstance(value, str):
        try:
            return int(value)
        except (TypeError, ValueError) as e:
            raise TypeError(f"Unsupported type for {name}: {type(value)}") from e
    # Clean input string
    cleaned_input = value.strip().lower()
    if not cleaned_input:
        raise ValueError(f"{name} cannot be empty.")

    UNIT_MULTIPLIERS  = {
        'gb': 1024 ** 3,  # 1 GB = 1024^3 bytes
        'mb': 1024 ** 2,  # 1 MB = 1024^2 bytes
        'kb': 1024,       # 1 KB = 1024 bytes
        'b': 1            # 1 B = 1 byte
    }
    # Check for unit suffixes
    for unit, multiplier in UNIT_MULTIPLIERS.items():
        if cleaned_input.endswith(unit):
            number_part = cleaned_input[:-len(unit)].strip()
            if not number_part:
                raise ValueError(f"Missing numeric value before unit '{unit}' in: '{value}'")
            return _convert_to_bytes(number_part, multiplier, value)
    # Handle unit-less input (bytes)
    return _convert_to_bytes(cleaned_input, 1, value)

[LCAIZJ]

Should users be allowed to input "1G" instead of "1GB"?

[Liziqi-77]

G is the colloquial form or abbreviation of GB. Would it be more appropriate to use the standard form here?

[LCAIZJ]

It's okay to have examples

[LCAIZJ]

Can a regular expression be used instead of looping through the units?

[Liziqi-77]

Modified

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.