v0.32.2-rc1: サーバーが最初のバイト受信前にダウンロードの停止を検出する機能を追加v0.32.2-rc1: server: detect download stalls before the first byte (#17259)

Ollama has published v0.32.2-rc1, a release candidate that targets a specific reliability problem in its model download path: the server can now detect when a download stalls before the first byte of data arrives. For anyone who runs large language models locally, download reliability is a practical concern, because model files frequently run to several gigabytes and a silently hung transfer can otherwise block a workflow with no clear signal that something has gone wrong.

The change described in this release focuses on stall detection during the earliest phase of a transfer. Ollama already includes mechanisms to notice when an in-progress download stops making progress, but those checks generally depend on data actively flowing. If a connection is established yet no bytes are received—because of a network interruption, an unresponsive mirror, or a proxy that accepts the connection but never returns content—the transfer could previously appear to be waiting rather than failed. By monitoring for the absence of that first byte, the server can now flag the download as stalled sooner and surface the failure earlier, rather than leaving the client to wait indefinitely.

Ollama is an open-source tool that lets users download, manage, and run LLMs on their own hardware through a command-line interface and a local HTTP API. Its distribution model resembles container tooling: models are pulled from a registry as layered artifacts, and the pull and run commands fetch those layers before a model can be used. Because these artifacts are large, the download experience is a meaningful part of the product, and incremental improvements to retry logic, resumability, and failure detection appear regularly in its release notes.

The "-rc1" suffix indicates this is a first release candidate rather than a final, stable build. Release candidates are typically distributed so that users and maintainers can test a fix in real environments before it is promoted to a general release. In practice, this means the stall-detection behavior may still be refined based on feedback, and users seeking maximum stability may prefer to wait for the corresponding stable version. Those who have been affected by hung downloads, however, may find value in testing the candidate directly.

This kind of maintenance work sits within a broader ecosystem of local LLM tooling. Ollama builds on llama.cpp, the underlying inference engine that popularized efficient CPU and GPU execution of quantized models, and it operates alongside tools such as LM Studio, GPT4All, and Jan, all of which aim to make locally hosted models more approachable. Running models locally has grown in appeal for reasons including data privacy, offline availability, cost control, and the ability to experiment without per-token API fees.

Reliable downloading is a prerequisite for all of those use cases. A user cannot benefit from a local model until its weights are fully retrieved, and partial or hung transfers waste both time and bandwidth—especially on metered or slower connections. Earlier stall detection does not by itself make transfers faster, but it can shorten the time before a client recognizes a problem and retries, which tends to improve the overall experience when networks are unstable. It also reduces the ambiguity of a frozen progress indicator, a state that can be difficult for users to distinguish from a very slow but still healthy connection.

As with most point releases in an active project, the practical takeaway is incremental rather than transformative. The fix appears to address a specific edge case that some users likely encountered as an unexplained freeze during a pull operation. Anyone interested in the precise scope of the change can consult the project's release notes and commit history on GitHub, where release candidates are published alongside checksums and platform-specific binaries. Users on stable channels can expect the fix to reach them once the candidate is validated and the corresponding stable release is tagged, at which point the improved detection should apply to routine model downloads without additional configuration.