gpt4free 如何用 docker-compose-slim.yml 部署 slim 镜像并暴露 1337 端口 Interference API【免费下载链接】gpt4freeThe official gpt4free repository | various collection of powerful language models | opus 4.6 gpt 5.3 kimi 2.5 deepseek v3.2 gemini 3项目地址: https://gitcode.com/GitHub_Trending/gp/gpt4free这篇文章解决一个明确任务在安装了 Docker 的机器上使用 gpt4free 仓库根目录的 docker-compose-slim.yml 部署 g4f 的 slim Docker 镜像让 OpenAI 兼容的 Interference API 通过宿主机 1337 端口访问。根据 README.md 的 Requirements compatibility 一节容器化部署需要 Dockerslim 镜像同时支持 x86_64 和 arm64。所有操作都在docker-compose-slim.yml所在目录仓库根目录执行因为 compose 文件中的卷挂载路径是相对路径。docker-compose-slim.yml 里各配置的作用docker-compose-slim.yml 的完整内容如下services: g4f-slim: container_name: g4f-slim image: hlohaus789/g4f:latest-slim build: context: . dockerfile: docker/Dockerfile-slim volumes: - ./generated_media:/app/generated_media - ./har_and_cookies:/app/har_and_cookies ports: - 8080:8080 - 1337:8080逐项说明image: hlohaus789/g4f:latest-slim是预构建的 slim 镜像build段给出本地构建上下文仓库根目录和构建文件 docker/Dockerfile-slim。两个卷把宿主机目录挂进容器./generated_media和./har_and_cookies。README 的 Configuration customization 一节说明HAR 文件、cookies 和生成媒体会持久化在这些映射目录里容器删除后数据不丢。端口段同时映射了8080:8080和1337:8080两个宿主机端口都指向容器的 8080 端口。容器内进程由 docker/Dockerfile-slim 的CMD [python, -m, g4f, --port, 8080]启动EXPOSE 8080是唯一声明的端口所以 1337 只是同一服务的另一个宿主机入口。README 的 Slim Docker image 一节也写明该映射下 Interference API 走 1337。slim 镜像本身基于python:slim-bookwormDockerfile 采用两阶段构建builder 阶段安装编译工具并预装依赖运行阶段只安装ffmpeg、flac、curl创建一个 UID/GID 为 1000 的g4f用户ARG G4F_USER_ID1000应用代码放在/app并以该用户身份运行。准备持久化目录在仓库根目录执行 README Slim Docker image 一节给出的命令mkdir -p ${PWD}/har_and_cookies ${PWD}/generated_media chown -R 1000:1000 ${PWD}/har_and_cookies ${PWD}/generated_media这里把目录属主改为1000:1000的原因与 docker/Dockerfile-slim 对应镜像以 UID 1000 的g4f用户运行容器内进程需要能读写挂载进来的目录。注意docker-compose-slim.yml挂载的是相对路径./generated_media和./har_and_cookies所以这两个目录必须和 compose 文件在同一个目录。启动容器在docker-compose-slim.yml所在目录执行docker compose -f docker-compose-slim.yml up --build加上--build时Compose 按文件中的build段从 docker/Dockerfile-slim 本地构建镜像再启动不加--build时则直接使用image字段拉取hlohaus789/g4f:latest-slim预构建镜像运行。README 还说明了一点运行特性slim 镜像可以在启动时更新 g4f 包并在需要时装入额外依赖因此首次启动可能比完整镜像多花一些时间拉取内容。如果不想使用 ComposeREADME 的 Slim Docker image 一节给出了等价的docker run命令端口映射与 compose 文件一致docker run \ -p 1337:8080 -p 8080:8080 \ -v ${PWD}/har_and_cookies:/app/har_and_cookies \ -v ${PWD}/generated_media:/app/generated_media \ hlohaus789/g4f:latest-slim验证 1337 端口上的 Interference APIREADME 的 FastAPI / Interference API 与 Interference API (OpenAI-compatible) 两节给出了两个检查入口均针对 slim docker 的 1337 映射默认端点http://localhost:1337/v1Swagger UIhttp://localhost:1337/docs在浏览器打开http://localhost:1337/docs能看到 Swagger 页面说明 API 服务已在 1337 端口对外提供服务。仓库里还有现成的请求脚本 etc/testing/test_interference.py文档示例如下import openai openai.api_key openai.base_url http://localhost:1337 def main(): chat_completion openai.ChatCompletion.create( modelgpt-3.5-turbo, messages[{role: user, content: write a poem about a tree}], streamTrue, ) if isinstance(chat_completion, dict): # not stream print(chat_completion.choices[0].message.content) else: # stream for token in chat_completion: content token[choices][0][delta].get(content) if content ! None: print(content, end, flushTrue) if __name__ __main__: main()该脚本用 openai 客户端向http://localhost:1337发起流式ChatCompletion请求并逐块打印输出仓库中同类的 etc/testing/test_api.py 使用的base_url是http://localhost:1337/v1与 README 给出的默认端点一致。脚本能否收到模型返回内容即是对 1337 端口 API 的一次实际验证。边界与限制docker-compose-slim.yml同时映射了 8080 端口。README 说明 8080 同时承担 GUI/API 服务因此宿主机 8080 和 1337 两个端口都要保持空闲。docker/Dockerfile-slim 运行阶段只安装了ffmpeg、flac、curl未安装 Chrome/Chromium而 README 的 Requirements 一节指出部分 provider 适配器依赖浏览器自动化工具。需要这类 provider 时slim 镜像不是合适的运行环境。README 的 Security 一节给出生产建议使用 HTTPS、认证和防火墙规则保护服务器并限制对 provider 凭据及 cookie/HAR 存储的访问。1337 端口直接暴露 API若部署到非本机网络应按此处理。部署完成的判断依据就是上面两个检查http://localhost:1337/docs可打开 Swagger 页面且指向http://localhost:1337/v1的客户端请求能收到模型返回。【免费下载链接】gpt4freeThe official gpt4free repository | various collection of powerful language models | opus 4.6 gpt 5.3 kimi 2.5 deepseek v3.2 gemini 3项目地址: https://gitcode.com/GitHub_Trending/gp/gpt4free创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考