等 AI 回复的时候，真正决定体验好坏的往往不是总耗时，而是「第一个字什么时候蹦出来」。同样十秒的生成，流式输出让人第一秒就有事可看，非流式则让人对着一屏空白干等。首字延迟（Time to First Token）值得单独拿出来优化，因为它优化的不是模型本身，而是整条链路和你的使用方式。
流式输出：体感优化的第一杠杆
流式不会让模型变快，但会让用户更早看到进展：同样的总耗时，「等十秒看到整段」和「十秒里每一秒都有新内容」是两种完全不同的体验。接入时先确认流式真正生效：客户端请求里开启 stream 参数只是第一步，链路上的代理和网关也必须支持分块转发——任何一环为了省事做了整体缓冲，流式就被悄悄退化成了非流式，而页面上看不出任何报错。
一句话记：用户对「开始响应」的敏感度远高于「总时长」，能用流式就别攒完整段再吐。
并发与超时：别让排队拖慢首字
首字延迟的另一大来源是排队。同一时刻发起过多请求，限流与上游排队会把每个请求的首字时间一起拖长——批量任务并不是并发越高越好，超出某个临界点后，所有请求一起变慢。合理的做法是从小并发起步逐步上调，盯着两个指标：429 出现的频率和首字时间的曲线，一旦首字时间明显抬升，就退回上一档。
超时与重试同样影响首字：给请求设一个贴合业务的超时时间，失败快速重试或切换，比死等一个慢节点更有效。如果交互形态允许，把「开始生成」和「生成完成」拆开处理——先立刻给出状态反馈，内容随后补上，接口没变快，但等待焦虑会小很多。
模型与路由：首字速度的硬底子
不同模型的首字速度差异很大：参数更小的模型、为速度优化的档位通常出字更快；复杂推理模型则要在「深度思考」上先花一段时间。对延迟敏感的场景，选型时应该把首字速度当作与能力、价格并列的一等指标，而不是等上线后再抱怨慢。另一个实用思路是组合拳：用快模型先出首稿或做前置判断，需要深度时再交给更强的模型精修。
路由层面，AIGC微风 已按模型自动调度到可达的最优上游，你能控制的是选对模型档位、避开高峰时段跑大批量压测。全部可用模型与实时价格在模型列表页，接口统一走 https://api.aigcbreeze.cn。
常见问题
流式已经开了，为什么第一个字还是很慢？
首字延迟由排队时间、模型预填充时间和链路传输三段组成，流式只改善最后一段的体感。先用 curl 直连接口对比基线：直连快、走应用慢，问题就在中间层——重点排查反向代理有没有对响应做整体缓冲。
并发数到底调到多少合适？
没有通用答案，只有你自己的观测结果。从小并发起步，每档观察几分钟，以「429 不出现、首字时间不抬升」为边界，卡在临界点之下的最大档位就是合适值。
换快模型会不会牺牲质量？
看任务类型：摘要、分类、格式转换、短补全这类任务，快模型通常足够；复杂推理和多步分析保持强模型。拿不准就在同一批真实样本上各跑一遍，对比输出再决定，比凭感觉换靠谱。