curl_multi_*仅负责高效并发发送http请求，不参与ai推理；真正推理由调用的ai服务（如ollama、openai api）完成，需通过curlopt_timeout_ms设超时、curlmopt_maxconnects控连接数、分批提交防限流，并用curlopt_private绑定请求id以精准匹配结果。
curl_multi_* 本身不支持 AI 推理，它只管发 HTTP 请求
很多人看到 curl_multi_exec 能并发发请求，就以为能直接“并发跑模型”，其实不是。它只是把多个 curl_init() 的句柄扔进一个批处理队列里，由 libcurl 底层调度发出去——和模型推理逻辑完全无关。真正做推理的是你调用的 AI 服务（比如本地 Ollama、OpenAI API、vLLM 端点），curl_multi_* 只负责高效地批量打这些 API。
怎么组织并发请求才能避免超时或被限流？
AI 推理接口普遍响应慢（几百 ms 到几秒），且多数服务对并发数、QPS 或 token 总量有限制。盲目堆 curl_multi_add_handle 容易触发 429 或连接超时。关键控制点有三个：
-
CURLOPT_TIMEOUT_MS必须设（比如 30000），否则默认是 0（无限等待），整个 multi 队列会卡死 - 用
curl_multi_setopt($mh, CURLMOPT_MAXCONNECTS, 20)控制最大空闲连接数，避免瞬时建连爆炸 - 分批提交：把 100 个请求拆成每批 10–20 个，等这批全返回再投下一批，比一股脑塞 100 个更稳
如何正确回收每个请求的结果并区分对应输入？
很多人用 curl_multi_getcontent() 拿不到数据，是因为没在每个 curl_init() 里提前设置 CURLOPT_RETURNTRANSFER。更隐蔽的问题是：multi 模式下 handle 顺序和添加顺序不一致，必须靠 curl_getinfo($ch, CURLINFO_EFFECTIVE_URL) 或你自己绑定的上下文 ID 来匹配原始输入。
推荐做法是在初始化每个 cURL 句柄时，用 curl_setopt($ch, CURLOPT_PRIVATE, $request_id) 存一个唯一标识（比如数组下标或 UUID），之后在 curl_multi_info_read() 循环里用 $info['handle'] 取出这个 CURLOPT_PRIVATE 值，就能精准关联结果与原始 prompt。
为什么不用 Guzzle 或 ReactPHP？
如果你已经用着 Laravel 或 Symfony，Guzzle 的 Pool 确实更易读；但纯 PHP CLI 批量任务中，curl_multi_* 零依赖、内存占用低、可控性强。ReactPHP 虽然异步能力强，但要引入 event-loop，对简单批量推理反而增加复杂度。真正卡住性能的从来不是并发机制，而是模型服务本身的吞吐瓶颈——与其换库，不如先确认你的 vLLM 是否开了 --tensor-parallel-size，或 OpenAI 是否用了 batch endpoint。
实际写的时候，别忘了检查 CURLOPT_HTTPHEADER 里 Content-Type: application/json 和鉴权 header 是否每个 handle 都设全了，漏一个就会静默返回 400，还不好 debug。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
