GPT-5.4 mini 和 nano 昨天刚发，我连夜测了一下，说说真实感受

ofox
5 阅读1分钟

昨晚刷到 OpenAI 又发新模型了——GPT-5.4 mini 和 nano。说实话看到名字的时候我内心毫无波澜，毕竟这两年 OpenAI 的命名已经让人麻木了。但仔细一看参数：nano 每百万 token 才 $0.20，mini 比 GPT-5 mini 快 2 倍以上，SWE-Bench 直接干到 54.4%——这就有点东西了。

于是连夜把两个模型都跑了一遍，分享一下真实体验。

先说结论

指标GPT-5.4 nanoGPT-5.4 miniGPT-5 mini（旧）
输入价格$0.20/1M$0.75/1M$0.40/1M
输出价格$1.25/1M$4.50/1M$1.60/1M
上下文窗口200K400K128K
SWE-Bench Pro-54.4%45.7%
首 token 延迟~150ms~300ms~600ms
适合场景分类/提取/子任务通用编码/推理可以退休了

一句话总结：nano 是目前性价比最高的 "干活模型"，mini 是 "又快又聪明的主力"。GPT-5 mini 基本可以淘汰了。

为什么要关注这俩小模型？

不是所有场景都需要请出 GPT-5.4 这尊大佛的。我日常开发中 70% 的 AI 调用都是这些：

  • 从用户消息里提取结构化数据
  • 判断一段文本的情感/意图分类
  • 做 Agent 里的子任务分发
  • 批量处理日志/文档的摘要

这些任务用 GPT-5.4 简直是杀鸡用牛刀，账单看了心疼。nano 出来之后，同样的活儿成本直接砍到原来的 1/10。

实测：3 个典型场景跑分

场景 1：JSON 结构化提取

从一段客户反馈里提取关键信息，这是最常见的需求。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.openai.com/v1"  # 国内可用聚合接口替代
)

prompt = """从以下客户反馈中提取信息，返回 JSON：
- sentiment: positive/negative/neutral
- product: 提到的产品名
- issue: 核心问题（一句话）
- urgency: high/medium/low

反馈：用了你们的语音机器人三天了，识别率还行但是转人工的逻辑有问题，
客户说了好几次"转人工"都没反应，这个比较急需要尽快修复。"""

# 用 nano 跑
response = client.chat.completions.create(
    model="gpt-5.4-nano",
    messages=[{"role": "user", "content": prompt}],
    response_format={"type": "json_object"}
)

print(response.choices[0].message.content)

返回结果：

{
  "sentiment": "negative",
  "product": "语音机器人",
  "issue": "转人工逻辑异常，用户说转人工无响应",
  "urgency": "high"
}

nano 的表现：完全准确，耗时 0.8 秒，花费约 0.0001。同样的任务用GPT−5.4要0.0001。同样的任务用 GPT-5.4 要 0.003，贵了 30 倍但结果一模一样。

场景 2：代码生成——写一个 FastAPI 中间件

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[{
        "role": "user",
        "content": "写一个 FastAPI 中间件，功能：记录每个请求的耗时，超过 2 秒的打 warning 日志，支持排除 /health 路径"
    }]
)

mini 生成的代码：

import time
import logging
from fastapi import Request
from starlette.middleware.base import BaseHTTPMiddleware

logger = logging.getLogger(__name__)

class RequestTimingMiddleware(BaseHTTPMiddleware):
    def __init__(self, app, exclude_paths: list[str] | None = None, slow_threshold: float = 2.0):
        super().__init__(app)
        self.exclude_paths = exclude_paths or ["/health"]
        self.slow_threshold = slow_threshold

    async def dispatch(self, request: Request, call_next):
        if request.url.path in self.exclude_paths:
            return await call_next(request)

        start = time.perf_counter()
        response = await call_next(request)
        duration = time.perf_counter() - start

        if duration > self.slow_threshold:
            logger.warning(
                f"Slow request: {request.method} {request.url.path} "
                f"took {duration:.2f}s"
            )
        else:
            logger.info(
                f"{request.method} {request.url.path} - {duration:.2f}s"
            )

        response.headers["X-Process-Time"] = f"{duration:.4f}"
        return response

# 使用
# app.add_middleware(RequestTimingMiddleware, exclude_paths=["/health", "/ready"])

说实话这代码质量相当不错：用了 perf_counter 而不是 time.time()，异常路径排除、自定义阈值都考虑到了，还加了个 X-Process-Time header。mini 在代码生成上真的接近 GPT-5.4 正式版水平了。

场景 3：多模型 Agent 编排（mini + nano 配合）

这是我觉得最有意思的用法——用 mini 做 "大脑"，nano 做 "手脚"：

import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(api_key="your-api-key")

async def plan_tasks(user_request: str) -> list[str]:
    """mini 负责拆解任务"""
    resp = await client.chat.completions.create(
        model="gpt-5.4-mini",
        messages=[{
            "role": "system",
            "content": "将用户请求拆解为独立的子任务列表，每个任务一行，不要编号"
        }, {
            "role": "user",
            "content": user_request
        }]
    )
    return resp.choices[0].message.content.strip().split("\n")

async def execute_task(task: str) -> str:
    """nano 负责执行单个子任务"""
    resp = await client.chat.completions.create(
        model="gpt-5.4-nano",
        messages=[{
            "role": "system",
            "content": "简洁地完成以下任务，直接给出结果"
        }, {
            "role": "user",
            "content": task
        }]
    )
    return resp.choices[0].message.content

async def main():
    tasks = await plan_tasks("帮我分析这段 Python 代码的性能问题并给出优化建议")
    print(f"拆解为 {len(tasks)} 个子任务")

    # 并发执行所有子任务
    results = await asyncio.gather(*[execute_task(t) for t in tasks])

    for task, result in zip(tasks, results):
        print(f"\n### {task}")
        print(result)

asyncio.run(main())

这个模式的妙处在于：mini 理解能力强，负责规划；nano 便宜快速，负责执行。一个复杂请求拆成 5 个子任务并发跑，总成本可能还不到 $0.001，延迟也就 1-2 秒。

踩坑记录

坑 1：nano 的 JSON 模式偶尔翻车

nano 在开启 response_format: json_object 时，大概有 5% 的概率输出的 JSON 会多一个尾部逗号。解决办法：

import json

def safe_parse(text: str) -> dict:
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        # 处理尾部逗号
        cleaned = text.rstrip().rstrip(",").rstrip()
        if not cleaned.endswith("}"):
            cleaned += "}"
        return json.loads(cleaned)

坑 2：mini 的 400K 上下文不是随便用的

虽然 mini 支持 400K context，但实测发现超过 200K token 后响应质量明显下降，特别是在长文档的中间部分提取信息时容易遗漏。建议还是控制在 100K 以内。

坑 3：国内直连的延迟问题

直连 OpenAI API 在国内的延迟大概在 2-5 秒的首 token 时间，这对于追求低延迟的场景是不可接受的。我后来改用了兼容 OpenAI 协议的聚合接口（比如 ofox.ai），走国内节点后首 token 延迟降到了 300ms 左右，体验完全不同：

# 只需要改 base_url，其他代码完全不用动
client = OpenAI(
    api_key="your-ofox-key",
    base_url="https://api.ofox.ai/v1"
)

和竞品的横向对比

模型价格（输入/1M）编码能力推理能力延迟
GPT-5.4 nano$0.20★★★★★★极快
GPT-5.4 mini$0.75★★★★★★★★快
Claude Haiku 4.5$0.80★★★★★★★☆快
Gemini Flash-Lite$0.075★★★★★☆极快
DeepSeek V3¥1.0★★★★★★★★中等

nano 在这个价位段几乎没有对手——Gemini Flash-Lite 虽然更便宜但推理能力差一截，DeepSeek V3 能力强但价格和延迟都高不少。

小结

GPT-5.4 mini/nano 的发布其实透露了一个很明确的信号：OpenAI 在把 AI 推向 "子任务时代"。以后的 AI 应用不会只用一个大模型解决一切，而是像微服务一样——大模型做编排，小模型干活。

对于开发者来说，现在最值得做的事就是把现有的 AI 调用分一下层：哪些是必须用大模型的，哪些可以换成 nano 省钱。我把自己项目里 60% 的调用换成了 nano，月账单直接从 150降到了150 降到了 40 左右。

这波模型降价潮还没完，接下来 Claude 和 Gemini 肯定会跟进。开发者的好日子，来了。

avatar
文章
阅读
粉丝