我太懂你的痛点了——用Compute Engine SSH手动拉模型不仅费钱，操作起来还麻烦，完全不是长期运行的最优解。Cloud Run的无状态特性确实给Ollama加载模型带来了小挑战，但咱们调整下Dockerfile就能搞定，让模型在部署时自动加载好，不用手动干预。

先聊聊你当前Dockerfile里的几个问题：

• VOLUME ["./ollama/ollama:/root/.ollama"] 这个配置在Cloud Run里根本没用，因为Cloud Run用的是临时文件系统，容器重启后所有本地数据都会丢失，挂载本地目录的逻辑不适用这里。
• 你的ENTRYPOINT命令没写完，而且缺少拉取模型的关键步骤，导致Ollama启动后根本没有可用模型，所以调用v1/models才会返回null。

下面给你两种可行的解决方案，按需选择：

方案一：构建镜像时预拉取模型（推荐，启动更快） #

这种方法是在构建Docker镜像的阶段就把Llama3.1模型下载到镜像里，部署到Cloud Run后，容器启动就能直接用模型，不用再等下载。

修改后的Dockerfile如下：

FROM ollama/ollama

# 安装必要工具（如果不需要可以删掉，Ollama本身已经具备模型拉取能力）
RUN apt-get update && apt-get install -y --no-install-recommends wget git curl && rm -rf /var/lib/apt/lists/*
ENV DEBIAN_FRONTEND=noninteractive
ENV OLLAMA_KEEP_ALIVE=24h
EXPOSE 11434

# 预拉取Llama3.1模型到镜像中
RUN ollama pull llama3.1

# 启动Ollama服务
ENTRYPOINT ["ollama", "serve"]

关键说明： #

• RUN ollama pull llama3.1 这一步会在构建镜像时把模型下载到镜像的/root/.ollama目录，部署后Ollama启动就能直接识别到模型。
• 删掉了没用的VOLUME配置，因为模型已经打包在镜像里了。
• 直接用ollama serve作为ENTRYPOINT，确保服务启动后保持运行状态，符合Cloud Run的要求。

⚠️ 注意：这种方法会让镜像体积变大（Llama3.1 8B版本就有好几G），但好处是Cloud Run容器启动后立刻就能响应请求，没有额外的等待时间。

方案二：容器启动时拉取模型（适合动态切换模型的场景） #

如果不想把模型打包进镜像（比如镜像太大不好管理，或者需要经常切换模型），可以让容器在启动时先拉取模型，再启动Ollama服务。

修改后的Dockerfile：

FROM ollama/ollama

RUN apt-get update && apt-get install -y --no-install-recommends wget git curl && rm -rf /var/lib/apt/lists/*
ENV DEBIAN_FRONTEND=noninteractive
ENV OLLAMA_KEEP_ALIVE=24h
EXPOSE 11434

# 启动时先拉取模型，再启动服务
ENTRYPOINT ["/bin/bash", "-c", "ollama pull llama3.1 && ollama serve"]

关键说明： #

• 容器启动时会先执行ollama pull llama3.1，等模型拉取完成后再启动ollama serve服务。
• 缺点是容器启动时间会变长（要等模型下载），而且Cloud Run的实例销毁后，下次启动还要重新拉取模型（因为临时存储会清空），适合模型需要频繁更新的场景。

Cloud Run配置注意事项 #

不管用哪种方案，部署时都要注意这几个点：

• 资源配置：Llama3.1需要足够的内存支撑，建议至少给Cloud Run实例配置4GB以上内存（8B版本建议8GB+），避免内存不足导致模型加载失败。
• 启动超时：如果用方案二，要把Cloud Run的启动超时时间调长（比如设置为10分钟），防止模型还没拉完就被系统杀死。
• 端口设置：确保Cloud Run的服务端口设置为11434，和Ollama的默认端口一致。

部署完成后，你可以调用https://<你的Cloud Run服务地址>/v1/models，就能看到Llama3.1的模型信息了，再也不会返回null啦。

备注：内容来源于stack exchange，提问作者wayne