Text Generation InferenceTGI流式生成完全指南从 SSE 原理到 Python / cURL / JavaScript 实战【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference导读本文以 Text Generation InferenceTGI官方文档中的 Streaming 章节为核心系统讲解边生成边返回的令牌流式输出Token Streaming机制它为什么能显著降低用户感知延迟如何在 Python、cURL、JavaScript 三种主流场景下开启流式调用以及 TGI 底层如何借助 Server-Sent EventsSSE实现单向持续推送并介绍并发超载时的overloaded错误处理与--max_concurrent_requests背压配置。读完本文你将掌握 TGI 流式接口的完整调用方式、底层事件流数据形态以及基于源码的调优与排错思路。什么是 Token StreamingToken streaming令牌流式生成是服务器在模型生成过程中逐 token 返回结果的工作模式。与等全部生成完毕再一次性返回的传统模式不同流式模式下用户无需等待完整响应即可看到逐字逐句出现的生成内容。在 TGI 中流式生成是提升终端用户体验的关键能力其核心价值在于降低感知延迟perceived latency——这是流畅体验中最重要的指标之一。流式生成带来的四个直接收益原文档明确列出了流式模式对用户体验的积极影响长查询场景下结果数量级提前可见对于极长的生成任务用户能在极短时间内看到第一批 token支持中途纠错看到生成过程后如果内容偏离预期方向用户可以提前终止生成避免浪费算力与等待时间感知延迟更低结果在早期阶段就开始展示用户主观上感觉响应更快对话式 UI 更自然逐字输出符合人类阅读与交流习惯聊天界面体验更接近真人对话。一个直观的时延对比示例原文档给出了如下量化示例假设系统每秒可生成 100 个 token若要生成 1000 个 token非流式non-streaming用户必须等待完整 10 秒才能看到任何结果流式streaming用户立刻收到第一批结果虽然端到端总耗时end-to-end latency相同但 5 秒时已经能看到一半的生成内容。这一示例说明流式并没有加速模型推理本身而是把等待时间转化为可见的、渐进的输出从而彻底改变用户的等待体验。如何在 TGI 中使用流式生成TGI 同时提供原生generate_stream接口与 OpenAI 兼容的v1/chat/completions消息接口二者均支持流式返回。下面按语言分别介绍。PythonInferenceClient一行开启流式使用huggingface_hub的InferenceClient只需传入streamTrue并迭代响应对象即可from huggingface_hub import InferenceClient client InferenceClient(base_urlhttp://127.0.0.1:8080) output client.chat.completions.create( messages[ {role: system, content: You are a helpful assistant.}, {role: user, content: Count to 10}, ], streamTrue, max_tokens1024, ) for chunk in output: print(chunk.choices[0].delta.content) # 1 # 2 # 3 # 4 # 5 # 6 # 7 # 8 # 9 # 10这里chunk.choices[0].delta.content是每个流式分片中的增量内容。值得注意的是max_tokens1024用于限制生成长度防止无限生成流式模式下每个 chunk 对应一个或一批新 token。Python 异步AsyncInferenceClient处理并发请求当需要并发处理大量流式请求例如多用户聊天服务时huggingface_hub提供了异步版本AsyncInferenceClientfrom huggingface_hub import AsyncInferenceClient client AsyncInferenceClient(base_urlhttp://127.0.0.1:8080) async def main(): stream await client.chat.completions.create( messages[{role: user, content: Say this is a test}], streamTrue, ) async for chunk in stream: print(chunk.choices[0].delta.content or , end) asyncio.run(main()) # This # is # a # test #.异步版本的用法与同步版本几乎一一对应create返回一个可异步迭代的流对象用async for逐块消费。注意chunk.choices[0].delta.content or 这一写法——流式响应中部分分片如携带角色信息或结束标记的分片的content可能为None需做空值兜底。补充TGI 原生 Python 客户端的流式实现除huggingface_hub外仓库自带的 clients/python/text_generation/client.py 同样内置流式支持generate_stream/chat的streamTrue。其底层实现直接使用requests的streamTrue发送 POST 到/v1/chat/completions然后逐行解析响应体只处理以data:前缀开头的行并反序列化为ChatCompletionChunk见 client.py 的_chat_stream_responsefor byte_payload in resp.iter_lines(): if byte_payload b\n: continue payload byte_payload.decode(utf-8) if payload.startswith(data:): json_payload json.loads(payload.lstrip(data:).rstrip(\n)) response ChatCompletionChunk(**json_payload) yield response这段代码清晰地展示了 SSE 数据帧的标准形态每个事件以data:开头、以换行结束。理解这一点有助于你在没有现成 SDK 的任意语言中自行解析 TGI 的流式响应。cURL-N标志禁用缓冲使用 OpenAI 兼容的 Messages APIv1/chat/completions端点时cURL 默认会缓冲整个响应体直到连接关闭才一次性打印。必须添加-N--no-buffer标志禁用 cURL 的默认缓冲让数据随到随显curl localhost:8080/v1/chat/completions \ -X POST \ -d { model: tgi, messages: [ { role: system, content: You are a helpful assistant. }, { role: user, content: What is deep learning? } ], stream: true, max_tokens: 20 } \ -H Content-Type: application/json请求体中stream: true是开启流式的关键开关-H Content-Type: application/json声明请求体为 JSON。运行后你会看到终端逐段输出 SSE 事件帧而非等待 20 个 token 全部生成完。JavaScripthuggingface/inference客户端在 Node.js 环境中首先安装官方库npm install huggingface/inference无论使用 Hugging Face Inference Providersserverless API还是 Inference Endpoints都可以用InferenceClient发起流式生成import { InferenceClient } from huggingface/inference; const client new InferenceClient(hf_YOUR_TOKEN, { endpointUrl: https://YOUR_ENDPOINT.endpoints.huggingface.cloud }); // prompt const prompt What can you do in Nuremberg, Germany? Give me 3 Tips; const stream client.textGenerationStream({ inputs: prompt }); for await (const r of stream) { // yield the generated token process.stdout.write(r.token.text); }textGenerationStream返回一个异步可迭代流每次迭代取到{ token: { text } }结构r.token.text即当前增量 token 的文本。process.stdout.write不带换行用于模拟逐字打字的输出效果。流式生成底层原理Server-Sent EventsSSESSE 的工作方式TGI 的流式输出基于Server-Sent EventsSSE实现。其流程为客户端发起一个携带请求数据的 HTTP 请求与服务端建立连接并订阅更新服务端此后持续向客户端推送数据全程客户端无需再发送任何额外请求连接保持单向数据流。SSE 的三大特性使其非常适合 LLM 流式输出单向unidirectional数据只从服务端流向客户端客户端在首个请求后不再向服务端发送其他请求基于 HTTP无需引入 WebSocket 等额外协议任何支持 HTTP 的环境都能直接使用接入成本极低长连接持续推送一次连接内可连续推送多个事件帧。SSE 与 Polling、Webhooks 的本质区别原文档将 SSE 与另外两种常见数据获取方式做了对比机制连接方向特点主要问题SSE单向服务端 → 客户端基于 HTTP、一次订阅持续推送单向客户端无法在同连接内回传数据Polling轮询单向客户端反复请求客户端不断轮询服务端获取数据服务端可能频繁返回空响应造成大量无效开销WebhooksWebhook双向首次请求后服务端与客户端可互相发送数据不只依赖 HTTP运维与实现更复杂TGI 选择 SSE 而非轮询正是因为轮询会在 token 尚未生成时反复返回空响应、白白消耗连接与带宽而 SSE 把何时推送的主动权交给服务端天然契合逐 token 生成的节奏。从源码看 TGI 的 SSE 实现在 TGI 的 Rust 路由层router/src/server.rs中流式端点generate_stream的响应类型即被标注为text/event-stream见 server.rs 端点定义这正是 SSE 的标准 Content-Type。关键实现细节包括保持连接活跃响应流通过Sse::new(response_stream).keep_alive(KeepAlive::default())包装server.rs在生成间隙自动发送心跳注释帧防止代理或客户端因超时断开连接禁用中间层缓冲响应头显式写入X-Accel-Buffering: noserver.rs告知 Nginx 等反向代理不要缓冲响应体保证 token 能实时穿透到客户端——这是生产部署中流式卡顿排查的常见关键点逐 token 事件化路由层将后端返回的InferStreamResponse::Intermediate逐条序列化为 SSE 事件帧server.rs每个新 token 对应一个事件并附带递增的indexPrefill阶段的填充结果则被显式忽略只推送真正新生成的 token结束帧携带统计信息最后一个 token 通过InferStreamResponse::End触发除返回generated_text、finish_reason、generated_tokens外还会记录并上报total_time、validation_time、queue_time、inference_time、time_per_token等时序指标server.rs这些正是监控流式服务质量的核心数据异常兜底如果流中途断开且未正常到达结束帧路由层会补发incomplete_generation错误事件server.rs避免客户端无限挂起等待。流式请求的完整生命周期贯穿 router/src/infer/mod.rsInfer::generate_stream会先获取并发信号量许可再调度后端Backend::schedule返回一个UnboundedReceiverStream路由层消费该流并逐 token 转成 SSE 帧——信号量许可在整个流存活期间持续持有确保并发计数准确。高并发下的背压overloaded错误与--max_concurrent_requests过载时的错误语义当同一时刻的并发请求过多时TGI 会返回 HTTP 错误其error_type为overloaded。huggingface_hub客户端会将此错误映射为OverloadedError异常见 clients/python/text_generation/errors.py。overloaded错误是设计给客户端做背压管理的客户端收到该错误后可以向用户展示服务繁忙的提示退避后发起新请求重试结合自身排队策略削峰填谷。在 router/src/server.rs 的端点定义中429 状态码对应{error: Model is overloaded, error_type: overloaded}其响应类型同样是text/event-stream即过载错误也会以 SSE 帧的形式出现在流中。并发上限的配置与底层机制TGI 启动参数--max_concurrent_requests用于设置最大并发请求数它通过 Rust 层的tokio::sync::Semaphore信号量实现router/src/infer/mod.rs// 初始化以 max_concurrent_requests 为容量创建信号量 let semaphore Arc::new(Semaphore::new(max_concurrent_requests)); // 每个流式请求进入时尝试获取许可失败即视为 overloaded let permit self .clone() .limit_concurrent_requests .try_acquire_owned() .map_err(|err| { metrics::counter!(tgi_request_failure, err overloaded).increment(1); tracing::error!({err}); err })?;从源码可见每个并发流式请求需要先成功获取一个信号量许可才能进入推理调度许可在整个流式生成期间被持有代码注释明确 Keep permit as long as generate_stream lives当许可耗尽时try_acquire_owned立即失败而非阻塞等待并同时递增tgi_request_failure计数器的overloaded标签——这意味着过载请求不会在队列中堆积而是快速失败并反馈给客户端由客户端决定重试策略该参数由启动器传递至路由层launcher/src/main.rs 及 launcher/src/main.rs生产部署时建议结合模型推理吞吐与后端队列容量合理设定避免客户端重试风暴。流式模式下的参数限制基于源码还可以确认一个流式模式的细节当请求同时开启stream与best_of采样多条候选时路由层会直接返回BestOfStream校验错误decoder_input_details返回解码器输入细节同样不支持流式server.rs。原因是流式协议按单条 token 序列推送无法承载多条候选序列的并行输出。调用时如需流式请关闭这两个参数。总结与最佳实践何时使用流式任何面向用户交互的场景聊天、Copilot 式补全、长文生成都应默认开启流式仅在纯批处理、结果需整体校验的离线场景中使用非流式。客户端三件套Python 用InferenceClient(streamTrue)或异步版AsyncInferenceClient命令行调试用curl -N前端/Node 用huggingface/inference的textGenerationStream。生产部署要点确认反向代理透传text/event-stream且不缓冲对应 TGI 响应头X-Accel-Buffering: no根据吞吐合理设置--max_concurrent_requests对OverloadedError实现退避重试。可观测性流式请求结束帧会记录time_per_token、queue_time、inference_time等时序指标可与 docs/source/reference/metrics.md 中的指标体系配合持续监控流式服务质量。进一步阅读完整的 API 端点与请求参数可参考 docs/source/reference/api_reference.md 与 docs/source/reference/launcher.md流式相关的端到端行为可结合仓库集成测试中的流式用例如 integration-tests/models/test_completion_prompts.py验证。【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Text Generation Inference（TGI）流式生成完全指南：从 SSE 原理到 Python / cURL / JavaScript 实战
Text Generation InferenceTGI流式生成完全指南从 SSE 原理到 Python / cURL / JavaScript 实战【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference导读本文以 Text Generation InferenceTGI官方文档中的 Streaming 章节为核心系统讲解边生成边返回的令牌流式输出Token Streaming机制它为什么能显著降低用户感知延迟如何在 Python、cURL、JavaScript 三种主流场景下开启流式调用以及 TGI 底层如何借助 Server-Sent EventsSSE实现单向持续推送并介绍并发超载时的overloaded错误处理与--max_concurrent_requests背压配置。读完本文你将掌握 TGI 流式接口的完整调用方式、底层事件流数据形态以及基于源码的调优与排错思路。什么是 Token StreamingToken streaming令牌流式生成是服务器在模型生成过程中逐 token 返回结果的工作模式。与等全部生成完毕再一次性返回的传统模式不同流式模式下用户无需等待完整响应即可看到逐字逐句出现的生成内容。在 TGI 中流式生成是提升终端用户体验的关键能力其核心价值在于降低感知延迟perceived latency——这是流畅体验中最重要的指标之一。流式生成带来的四个直接收益原文档明确列出了流式模式对用户体验的积极影响长查询场景下结果数量级提前可见对于极长的生成任务用户能在极短时间内看到第一批 token支持中途纠错看到生成过程后如果内容偏离预期方向用户可以提前终止生成避免浪费算力与等待时间感知延迟更低结果在早期阶段就开始展示用户主观上感觉响应更快对话式 UI 更自然逐字输出符合人类阅读与交流习惯聊天界面体验更接近真人对话。一个直观的时延对比示例原文档给出了如下量化示例假设系统每秒可生成 100 个 token若要生成 1000 个 token非流式non-streaming用户必须等待完整 10 秒才能看到任何结果流式streaming用户立刻收到第一批结果虽然端到端总耗时end-to-end latency相同但 5 秒时已经能看到一半的生成内容。这一示例说明流式并没有加速模型推理本身而是把等待时间转化为可见的、渐进的输出从而彻底改变用户的等待体验。如何在 TGI 中使用流式生成TGI 同时提供原生generate_stream接口与 OpenAI 兼容的v1/chat/completions消息接口二者均支持流式返回。下面按语言分别介绍。PythonInferenceClient一行开启流式使用huggingface_hub的InferenceClient只需传入streamTrue并迭代响应对象即可from huggingface_hub import InferenceClient client InferenceClient(base_urlhttp://127.0.0.1:8080) output client.chat.completions.create( messages[ {role: system, content: You are a helpful assistant.}, {role: user, content: Count to 10}, ], streamTrue, max_tokens1024, ) for chunk in output: print(chunk.choices[0].delta.content) # 1 # 2 # 3 # 4 # 5 # 6 # 7 # 8 # 9 # 10这里chunk.choices[0].delta.content是每个流式分片中的增量内容。值得注意的是max_tokens1024用于限制生成长度防止无限生成流式模式下每个 chunk 对应一个或一批新 token。Python 异步AsyncInferenceClient处理并发请求当需要并发处理大量流式请求例如多用户聊天服务时huggingface_hub提供了异步版本AsyncInferenceClientfrom huggingface_hub import AsyncInferenceClient client AsyncInferenceClient(base_urlhttp://127.0.0.1:8080) async def main(): stream await client.chat.completions.create( messages[{role: user, content: Say this is a test}], streamTrue, ) async for chunk in stream: print(chunk.choices[0].delta.content or , end) asyncio.run(main()) # This # is # a # test #.异步版本的用法与同步版本几乎一一对应create返回一个可异步迭代的流对象用async for逐块消费。注意chunk.choices[0].delta.content or 这一写法——流式响应中部分分片如携带角色信息或结束标记的分片的content可能为None需做空值兜底。补充TGI 原生 Python 客户端的流式实现除huggingface_hub外仓库自带的 clients/python/text_generation/client.py 同样内置流式支持generate_stream/chat的streamTrue。其底层实现直接使用requests的streamTrue发送 POST 到/v1/chat/completions然后逐行解析响应体只处理以data:前缀开头的行并反序列化为ChatCompletionChunk见 client.py 的_chat_stream_responsefor byte_payload in resp.iter_lines(): if byte_payload b\n: continue payload byte_payload.decode(utf-8) if payload.startswith(data:): json_payload json.loads(payload.lstrip(data:).rstrip(\n)) response ChatCompletionChunk(**json_payload) yield response这段代码清晰地展示了 SSE 数据帧的标准形态每个事件以data:开头、以换行结束。理解这一点有助于你在没有现成 SDK 的任意语言中自行解析 TGI 的流式响应。cURL-N标志禁用缓冲使用 OpenAI 兼容的 Messages APIv1/chat/completions端点时cURL 默认会缓冲整个响应体直到连接关闭才一次性打印。必须添加-N--no-buffer标志禁用 cURL 的默认缓冲让数据随到随显curl localhost:8080/v1/chat/completions \ -X POST \ -d { model: tgi, messages: [ { role: system, content: You are a helpful assistant. }, { role: user, content: What is deep learning? } ], stream: true, max_tokens: 20 } \ -H Content-Type: application/json请求体中stream: true是开启流式的关键开关-H Content-Type: application/json声明请求体为 JSON。运行后你会看到终端逐段输出 SSE 事件帧而非等待 20 个 token 全部生成完。JavaScripthuggingface/inference客户端在 Node.js 环境中首先安装官方库npm install huggingface/inference无论使用 Hugging Face Inference Providersserverless API还是 Inference Endpoints都可以用InferenceClient发起流式生成import { InferenceClient } from huggingface/inference; const client new InferenceClient(hf_YOUR_TOKEN, { endpointUrl: https://YOUR_ENDPOINT.endpoints.huggingface.cloud }); // prompt const prompt What can you do in Nuremberg, Germany? Give me 3 Tips; const stream client.textGenerationStream({ inputs: prompt }); for await (const r of stream) { // yield the generated token process.stdout.write(r.token.text); }textGenerationStream返回一个异步可迭代流每次迭代取到{ token: { text } }结构r.token.text即当前增量 token 的文本。process.stdout.write不带换行用于模拟逐字打字的输出效果。流式生成底层原理Server-Sent EventsSSESSE 的工作方式TGI 的流式输出基于Server-Sent EventsSSE实现。其流程为客户端发起一个携带请求数据的 HTTP 请求与服务端建立连接并订阅更新服务端此后持续向客户端推送数据全程客户端无需再发送任何额外请求连接保持单向数据流。SSE 的三大特性使其非常适合 LLM 流式输出单向unidirectional数据只从服务端流向客户端客户端在首个请求后不再向服务端发送其他请求基于 HTTP无需引入 WebSocket 等额外协议任何支持 HTTP 的环境都能直接使用接入成本极低长连接持续推送一次连接内可连续推送多个事件帧。SSE 与 Polling、Webhooks 的本质区别原文档将 SSE 与另外两种常见数据获取方式做了对比机制连接方向特点主要问题SSE单向服务端 → 客户端基于 HTTP、一次订阅持续推送单向客户端无法在同连接内回传数据Polling轮询单向客户端反复请求客户端不断轮询服务端获取数据服务端可能频繁返回空响应造成大量无效开销WebhooksWebhook双向首次请求后服务端与客户端可互相发送数据不只依赖 HTTP运维与实现更复杂TGI 选择 SSE 而非轮询正是因为轮询会在 token 尚未生成时反复返回空响应、白白消耗连接与带宽而 SSE 把何时推送的主动权交给服务端天然契合逐 token 生成的节奏。从源码看 TGI 的 SSE 实现在 TGI 的 Rust 路由层router/src/server.rs中流式端点generate_stream的响应类型即被标注为text/event-stream见 server.rs 端点定义这正是 SSE 的标准 Content-Type。关键实现细节包括保持连接活跃响应流通过Sse::new(response_stream).keep_alive(KeepAlive::default())包装server.rs在生成间隙自动发送心跳注释帧防止代理或客户端因超时断开连接禁用中间层缓冲响应头显式写入X-Accel-Buffering: noserver.rs告知 Nginx 等反向代理不要缓冲响应体保证 token 能实时穿透到客户端——这是生产部署中流式卡顿排查的常见关键点逐 token 事件化路由层将后端返回的InferStreamResponse::Intermediate逐条序列化为 SSE 事件帧server.rs每个新 token 对应一个事件并附带递增的indexPrefill阶段的填充结果则被显式忽略只推送真正新生成的 token结束帧携带统计信息最后一个 token 通过InferStreamResponse::End触发除返回generated_text、finish_reason、generated_tokens外还会记录并上报total_time、validation_time、queue_time、inference_time、time_per_token等时序指标server.rs这些正是监控流式服务质量的核心数据异常兜底如果流中途断开且未正常到达结束帧路由层会补发incomplete_generation错误事件server.rs避免客户端无限挂起等待。流式请求的完整生命周期贯穿 router/src/infer/mod.rsInfer::generate_stream会先获取并发信号量许可再调度后端Backend::schedule返回一个UnboundedReceiverStream路由层消费该流并逐 token 转成 SSE 帧——信号量许可在整个流存活期间持续持有确保并发计数准确。高并发下的背压overloaded错误与--max_concurrent_requests过载时的错误语义当同一时刻的并发请求过多时TGI 会返回 HTTP 错误其error_type为overloaded。huggingface_hub客户端会将此错误映射为OverloadedError异常见 clients/python/text_generation/errors.py。overloaded错误是设计给客户端做背压管理的客户端收到该错误后可以向用户展示服务繁忙的提示退避后发起新请求重试结合自身排队策略削峰填谷。在 router/src/server.rs 的端点定义中429 状态码对应{error: Model is overloaded, error_type: overloaded}其响应类型同样是text/event-stream即过载错误也会以 SSE 帧的形式出现在流中。并发上限的配置与底层机制TGI 启动参数--max_concurrent_requests用于设置最大并发请求数它通过 Rust 层的tokio::sync::Semaphore信号量实现router/src/infer/mod.rs// 初始化以 max_concurrent_requests 为容量创建信号量 let semaphore Arc::new(Semaphore::new(max_concurrent_requests)); // 每个流式请求进入时尝试获取许可失败即视为 overloaded let permit self .clone() .limit_concurrent_requests .try_acquire_owned() .map_err(|err| { metrics::counter!(tgi_request_failure, err overloaded).increment(1); tracing::error!({err}); err })?;从源码可见每个并发流式请求需要先成功获取一个信号量许可才能进入推理调度许可在整个流式生成期间被持有代码注释明确 Keep permit as long as generate_stream lives当许可耗尽时try_acquire_owned立即失败而非阻塞等待并同时递增tgi_request_failure计数器的overloaded标签——这意味着过载请求不会在队列中堆积而是快速失败并反馈给客户端由客户端决定重试策略该参数由启动器传递至路由层launcher/src/main.rs 及 launcher/src/main.rs生产部署时建议结合模型推理吞吐与后端队列容量合理设定避免客户端重试风暴。流式模式下的参数限制基于源码还可以确认一个流式模式的细节当请求同时开启stream与best_of采样多条候选时路由层会直接返回BestOfStream校验错误decoder_input_details返回解码器输入细节同样不支持流式server.rs。原因是流式协议按单条 token 序列推送无法承载多条候选序列的并行输出。调用时如需流式请关闭这两个参数。总结与最佳实践何时使用流式任何面向用户交互的场景聊天、Copilot 式补全、长文生成都应默认开启流式仅在纯批处理、结果需整体校验的离线场景中使用非流式。客户端三件套Python 用InferenceClient(streamTrue)或异步版AsyncInferenceClient命令行调试用curl -N前端/Node 用huggingface/inference的textGenerationStream。生产部署要点确认反向代理透传text/event-stream且不缓冲对应 TGI 响应头X-Accel-Buffering: no根据吞吐合理设置--max_concurrent_requests对OverloadedError实现退避重试。可观测性流式请求结束帧会记录time_per_token、queue_time、inference_time等时序指标可与 docs/source/reference/metrics.md 中的指标体系配合持续监控流式服务质量。进一步阅读完整的 API 端点与请求参数可参考 docs/source/reference/api_reference.md 与 docs/source/reference/launcher.md流式相关的端到端行为可结合仓库集成测试中的流式用例如 integration-tests/models/test_completion_prompts.py验证。【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考