- 参数的作用
- 参数接受的类型
- 常见范围或可接受值
- 是否会影响质量、成本、延迟或路由行为
快速查找
端点说明
service_tier 支持以下主要文本请求接口：
仅在所选模型和提供商组合支持时使用 ultrafast、fast（支持时也可使用 priority）和 flex。Ultrafast 选择受支持的最高速层级；fast 和 priority 使用相同的 Fast 路由和定价。省略 service_tier 时，默认值为 standard。
Batch 不是 service_tier 的取值。批处理请求使用独立的 Batch API。
对于兼容 Anthropic 的 Messages 请求，Anthropic 原生上游取值为 auto 和 standard_only。Phaseo 可能会在不同提供商之间规范化或映射这些值，同时保留 /v1/messages 上与 Anthropic 兼容的行为。
如果使用自定义基础 URL 指向 Phaseo 的 Anthropic 官方 SDK，请优先在 /v1/messages 上使用 Anthropic 原生值。对于 ultrafast, priority、flex 等跨提供商规范化的级别控制，或 OpenAI 的别名 fast，请优先使用原始 HTTP 请求或网关原生/OpenAI 风格的文本 API。
参数参考
model
选择请求使用的网关模型 ID。
除非你有意使用受支持的别名，否则请使用各模型页面快速入门中显示的规范模型 ID。规范 ID 是示例、自动化和长期集成中最稳妥的选择。
stream
通过 Server-Sent Events 逐步返回输出，而不是等待完整响应正文。
若用于聊天界面、逐 token 渲染，或提前输出能改善体验的长响应，请开启此选项。若需要完整 JSON 响应、更简单的重试或更容易进行结构化解析，请关闭。
注意事项：
流式传输支持情况因端点而异。
流式传输通常是传输方式的选择，而非质量控制。
工具调用或结构化输出流程的流式传输方式也可能因提供商而异。
temperature
控制 token 选择的随机程度。
较低的值会让输出更保守、可重复。较高的值会增加多样性，有助于头脑风暴或创意写作，但也可能降低一致性和对 schema 的遵循度。
适用场景：
- 信息提取
- 分类
- JSON 或 schema 输出
- 创意生成
temperature 或 top_p，不要同时调整两者。
较高的 temperature 与激进量化结合可能会放大不稳定性。
top_p
应用核采样，将候选项限制为累计概率达到 top_p 的最小 token 集。
较低的值会缩小模型选择的概率范围，通常让输出更安全、更聚焦。较高的值允许模型考虑更多 token。
注意事项：
如果想在不直接更改 temperature 的情况下缩小或扩大搜索空间，请调整
top_p。
对大多数应用而言，适中的 temperature 和接近 1.0 的 top_p 是合理的基准。
top_k
在支持此项的提供商上，将每一步的采样限制为排名前 k 的候选 token。
较低的
top_k 会收窄模型的选择范围，使输出更可预测；较高的值会扩大候选集。
注意事项：
并非所有提供商都支持 top_k。
相比 top_p，它能更明确地限制候选 token 集。
max_tokens
在仍使用 max_tokens 字段名的端点和提供商上限制输出长度。
用于控制成本、延迟和输出截断风险。值过小时，即使模型运行正常，输出也可能看起来不完整。
max_output_tokens
在使用 max_output_tokens 而非 max_tokens 的路由上限制输出长度。
语义上与
max_tokens 相同，但应使用所选端点或 SDK 接口要求的字段名。
max_completion_tokens
在使用 max_completion_tokens 的新版 OpenAI 风格文本 API 上限制输出长度。
这是另一个输出 token 预算字段。请使用端点要求的字段名，不要在同一请求结构中混用输出长度别名。
frequency_penalty
根据 token 已出现的频率降低重复使用的倾向。
如果模型陷入循环、重复短语或过度使用相同措辞，请调高此值。
presence_penalty
token 一旦出现过，就会降低其再次使用的倾向，从而帮助模型探索新主题或措辞。
相比
frequency_penalty，它通常更广泛地控制新颖性，而非重复次数。
repetition_penalty
应用提供商专用的重复抑制行为，不属于经典 OpenAI 风格的 penalty 字段。
其用途与
frequency_penalty 和 presence_penalty 类似，但语义因提供商而异。应将其视为提供商原生行为，而非完全通用的控制项。
seed
在上游提供商支持 seed 生成时请求确定性采样。
用于调试、回归测试，并在上游平台允许的范围内尽可能复现行为。Seed 生成有助于提高可复现性，但无法保证所有提供商或基础设施变更下都完全确定。
stop
定义一个或多个用于提前终止生成的序列。
当需要严格控制输出边界时很有用，例如在页脚、工具分隔符或下一个生成区块之前停止。
logprobs
在可用时请求 token 级概率元数据。
主要用于分析、评估、排序、调试和置信度类工作流。标准产品响应通常不需要此项。
top_logprobs
请求每个输出位置的主要备选候选 token 及其对数概率。
当需要检查备选 token 分支，而不只是最终选中的输出 token 时使用。
tools
为使用工具的模型工作流声明可调用的工具或函数。
除非端点文档另有说明，否则请使用 OpenAI 风格的工具 schema。工具声明说明模型可以调用什么，并不表示必须调用。
tool_choice
控制模型是否可以自动调用工具、禁止调用工具或必须使用特定工具。
只需内容时使用
none，由模型决定时使用 auto；若下游编排要求调用工具，则使用更严格的取值。
parallel_tool_calls
在兼容的工具调用 API 上允许或禁止并发工具调用。
若下游系统要求严格按顺序执行、按序产生副作用或使用更简单的 agent 跟踪，请关闭此项。
response_format
请求特定的输出格式，例如纯文本、JSON 或受 schema 约束的响应。
确切支持的结构取决于端点和提供商适配器。需要自由文本以外的格式时使用，尤其适合 JSON 响应和结构化提取流程。
structured_outputs
表示所选路由和提供商组合是否支持可靠的结构化或 schema 约束响应。
在快速入门表中，此项可帮助判断所选端点和活跃提供商能否可靠支持结构化输出工作流。最好将其视为支持情况元数据。
json_schema
提供用于在兼容模型和端点上强制结构化输出的 JSON schema。
当应用需要保证字段、类型化提取或严格响应契约时使用。schema 应尽量精简并针对具体任务，以提高遵循度。
reasoning
包含面向支持推理的 API 的提供商专用推理配置。
根据路由不同，这可能包括是否启用、推理强度、token 预算、详细程度或是否返回推理内容。
reasoning_effort
当端点和模型提供此控制项时，请求较低或较高的推理预算。
更高的推理强度可能改善复杂推理任务，但会增加延迟和 token 用量。较低强度通常更适合追求速度和成本的请求。
reasoning_tokens
在支持时表示推理专用的 token 字段。
根据路由不同，它可能是请求控制项、限制值或响应用量统计字段，而非普遍支持的请求参数。
include_reasoning
在支持时请求在响应中返回推理内容或摘要。
请谨慎使用。推理负载可能更大，并非所有模型都支持；对于不需要额外诊断信息的生产响应也可能不合适。
service_tier
在兼容的文本 API 上选择受支持的路由或价格级别。
仅在所选模型和提供商组合支持时使用
ultrafast、fast（支持时也可使用 priority）和 flex。Ultrafast 选择受支持的最高速层级；fast 和 priority 使用相同的 Fast 路由和定价。省略该字段以保持默认标准层级。
Phaseo 会在内部将网关规范化的级别值映射为提供商原生控制项，因此调用方可在受支持的文本接口上使用相同的 service_tier 值。
注意事项：
Batch 是独立的 API 流程，并非服务级别的取值。
支持情况因端点和提供商而异。
prompt_cache_key
为具备 prompt 缓存感知能力的路由提供稳定的缓存亲和性键。
当一系列请求共享稳定的 prompt 前缀，并希望尽可能使用相同的上游提供商或区域时使用。Phaseo 也可以根据请求上下文推导缓存亲和性，但显式键更适合长对话、agent 会话和重复工作流。
prompt_cache_options
通过受支持的 OpenAI 路由传递 OpenAI 提示缓存控制。
对于 GPT-6 Astra，需要显式提示缓存时使用
{"mode":"explicit","ttl":"30m"}。Phaseo 在请求规范化过程中保留此对象，并原样发送给 OpenAI。
cache_control
在受支持的文本请求接口上应用与提供商无关的 prompt 缓存策略。
若要让相同的缓存提示通过网关通用 schema 传递，请在 Chat Completions、Responses 和 Anthropic Messages 请求的顶层使用
cache_control。需要显式缓存断点时，也可将其放在受支持的内容块上。
常见 TTL 值为 5m 和 1h，具体取决于提供商和模型的支持情况。原生集成仍接受 provider_options.anthropic.cache_control 和 provider_options.google.cache_control 等提供商专用别名。
prompt_cache_retention
在受支持的 OpenAI 路由请求上设置兼容 OpenAI 的 prompt 缓存保留策略。
若要传递 OpenAI 缓存保留选项而不将其嵌套在提供商专用选项中，请使用此项。仍接受提供商专用别名
provider_options.openai.prompt_cache_retention。若两者同时提供，则顶层 prompt_cache_retention 优先。
provider
包含路由约束和提供商偏好。
用于指定哪些上游提供商可以执行请求、如何排序，以及必须满足哪些合规要求。
常见字段包括：
quantizations 遵循兼容 OpenRouter 的提供商路由词汇，可放在 provider 或 routing 下。匹配不区分大小写，并忽略空格、连字符和下划线；float8/FP8、bfloat16/BF16 等无歧义名称可互为别名。启用此筛选器后，没有量化元数据的报价会被排除。如果没有符合条件的报价，Gateway 会返回错误并列出请求值和当前可用的量化方式，而不会静默路由到其他变体。
provider_options
包含提供商专用的直通设置，不应将其规范化到网关通用请求结构中。
例如：
openai.context_managementopenai.prompt_cache_retentionanthropic.cache_controlgoogle.cache_controlgoogle.cached_content
cache_control；兼容 OpenAI 的保留设置优先使用顶层 prompt_cache_retention。
有关 Chat Completions、Responses 和 Anthropic Messages 的提供商 prompt 缓存示例，请参阅Prompt 缓存。
meta
在支持时请求额外的响应元数据。
若要在响应中添加用于调试、分析或下游检查的非核心元数据，请使用此项。
usage
在支持时请求用量统计详情。
如果希望在响应正文中明确包含 token 或用量统计，而不只是依赖标头或仪表板，此项会很有用。
debug
启用受控的请求和路由诊断信息。
支持的调试字段包括：
调试负载可能包含敏感请求上下文。仅在开发或严格受控的环境中使用。