Fine-tuning file size guard rejects 60 GB despite documented 100 GB limit

The fine-tuning data preparation docs advertise 100 GB for JSONL/Parquet and show check_file() followed by files.upload(..., purpose="fine-tune", check=True). Current Python SDK 2.35.0 at b0c7f91e283a4b674c82be7558e69ddcadc46487 rejects files above 50.1 * 2**30 bytes (about 53.79 decimal GB).

Originally reported by Vinish Reddy Pannala in Fine-Tuning Open Models From Lakehouse Tables, published July 28, 2026, modified August 12. The original SDK version was not stated.

CPU reproduction against the unmodified installed SDK, using a real 3,700-byte, 100-row JSONL and changing only its reported os.stat().st_size:

import os
import tempfile
from pathlib import Path
from unittest.mock import patch
from together.lib.utils import check_file

real_stat = os.stat
with tempfile.TemporaryDirectory() as directory:
    file = Path(directory) / "tiny.jsonl"
    file.write_text('{"text": "local validation fixture"}\n' * 100)
    for size in (3700, 53_794_465_382, 53_794_465_383, 60_000_000_000):
        def controlled_stat(path, *args, **kwargs):
            result = real_stat(path, *args, **kwargs)
            if isinstance(path, str) and path == file.as_posix():
                fields = list(result)
                fields[6] = size
                return os.stat_result(fields)
            return result
        with patch("os.stat", side_effect=controlled_stat):
            report = check_file(file, purpose="fine-tune")
        print(size, report["is_check_passed"])

Output: True, True, False, False. Rejection happens before format parsing. The same threshold is enforced by UploadManager, MultipartUploadManager and both async variants; check=False does not bypass it. I also checked those paths and the public sync/async upload methods with an HTTP transport that aborts at the first request. No real large file, hosted upload, backend acceptance, inference or training was tested.

Could you confirm the intended fine-tuning maximum in bytes and whether this shared guard should also change for eval/batch-api? The SDK uses binary units labeled GB, while the docs do not define that conversion. This concerns the threshold, separately from the Parquet fallthrough fixed in #558 and CLI coverage in #572. I have left the limit unchanged pending clarification.

Start with together.lib.utils.check_file and trace the shared size guard through UploadManager, MultipartUploadManager, and their async variants. Run the supplied boundary reproduction, then compare how fine-tune, eval, and batch-api purposes use the guard. Done means the intended byte limit and affected purposes are confirmed and the boundary behavior is covered consistently.