Create a new chat completion.
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Developer-provided instructions that the model should follow, regardless of
messages sent by the user. With o1 models and newer, developer messages
replace the previous system messages.
-9223372036854776000 <= x <= 9223372036854776000"none"low, medium, high -1 <= x <= 9223372036854776000If true, the new message will be prepended with the last message if they belong to the same role.
If true, the generation prompt will be added to the chat template. This is a parameter used by chat template in tokenizer config of the model.
If this is set, the chat will be formatted so that the final message in the chat is open-ended, without any EOS tokens. The model will continue this message rather than starting a new one. This allows you to "prefill" part of the model's response for it. Cannot be used at the same time as add_generation_prompt.
If true, special tokens (e.g. BOS) will be added to the prompt on top of what is added by the chat template. For most models, the chat template takes care of adding the special tokens so this should be set to false (as is the default).
A list of dicts representing documents that will be accessible to the model if it is performing RAG (retrieval-augmented generation). If the template does not support RAG, this argument will have no effect. We recommend that each document should be a dict containing "title" and "text" keys.
A Jinja template to use for this conversion. As of transformers v4.44, default chat template is no longer allowed, so you must provide a chat template if the tokenizer does not define one.
Additional keyword args to pass to the template renderer. Will be accessible by the chat template.
Additional kwargs to pass to the HF processor.
Additional kwargs for structured outputs
The priority of the request (lower means earlier handling; default: 0). Any priority other than 0 will raise an error if the served model does not use priority scheduling.
The request_id related to this request. If the caller does not set it, a random_uuid will be generated. This id is used through out the inference process and return in response.
If specified with 'logprobs', tokens are represented as strings of the form 'token_id:{token_id}' so that tokens that are not JSON-encodable can be identified.
If specified, the result will include token IDs alongside the generated text. In streaming mode, prompt_token_ids is included only in the first chunk, and token_ids contains the delta tokens for each chunk. This is useful for debugging or when you need to map generated text back to input tokens.
If specified, the prefix cache will be salted with the provided string to prevent an attacker to guess prompts in multi-user environments. The salt should be random, protected from access by 3rd parties, and long enough to be unpredictable (e.g., 43 characters base64-encoded, corresponding to 256 bit).
KVTransfer parameters used for disaggregated serving.
Additional request parameters with (list of) string or numeric values, used by custom extensions.
Parameters for detecting repetitive N-gram patterns in output tokens. If such repetition is detected, generation will be ended early. LLMs can sometimes generate repetitive, unhelpful token patterns, stopping only when they hit the maximum output length (e.g. 'abcdabcdabcd...' or '\emoji \emoji \emoji ...'). This feature can detect such behavior and terminate early, saving time and tokens.
Successful Response
"chat.completion"auto, default, flex, scale, priority KVTransfer parameters.