LGAI-EXAONE

/

K-EXAONE-236B-A23B

like 558

Follow

LG AI Research 1.66k

Dear LG AI Research team,

Thank you sincerely for releasing K-EXAONE-236B-A23B. We are a small student research project (KOSMOS, Apache-2.0) building a conversational orchestrator over Korean public-data APIs, and K-EXAONE is at the heart of it. We are deeply grateful for the model, the open license, and for the earlier guidance from @nuxlear in discussion #9 — that clarification unblocked our initial integration.

We have encountered a separate issue that we would like to respectfully report, in case it is useful to the team. We are not certain whether the root cause lies in the model, the chat template, or the inference provider's decoder, so we are reporting it here and also to FriendliAI.

What we observe

When the model is called through an OpenAI-compatible endpoint with tools and tool_choice properly supplied (exactly as recommended in discussion #9), and the intended tool-argument value is a CJK (Korean) string, the returned tool_calls[0].function.arguments contains only whitespace and newline characters in place of the value. The model's reasoning stream clearly contains the correct Korean string just before emitting the tool call.

Minimal reproduction

• Model: LGAI-EXAONE/K-EXAONE-236B-A23B
• Inference: FriendliAI Serverless OpenAI-compatible API, /v1/chat/completions
• Streaming and non-streaming return byte-identical broken output.

Outbound tool schema (OpenAI function-calling form):

{
  "type": "function",
  "function": {
    "name": "address_to_region",
    "parameters": {
      "type": "object",
      "properties": {
        "address": {
          "type": "string",
          "description": "Full Korean administrative address; do not infer or leave blank.",
          "examples": ["강남역", "서울시 강남구 역삼동"],
          "minLength": 1
        }
      },
      "required": ["address"]
    }
  }
}

User message (Korean): "강남역이 어느 시/도에 속하는지 알려주세요."

Reasoning stream (CJK present, correct):

… 사용자가 "강남역"에 대해 물었으므로 address 필드에 "강남역"을 넣어 호출한다 …

Tool-call arguments delta sequence:

"" → "{\"" → "address" → "\":" → "  " → "\n" → "}"

Assembled arguments:

{"address":  \n}

(two spaces and a newline — the CJK value is absent.)

Expected behaviour

{"address": "강남역"}

What works vs. what fails

• ASCII argument values (e.g. {"city": "Seoul"}) are returned correctly.
• CJK argument values are consistently replaced by whitespace/newline, across streaming and non-streaming.
• The same prompt through the same model on a different provider (if any of you can test locally with vllm --tool-call-parser hermes or the native <|tool_call|> template) would help confirm whether this is upstream in the model/template or downstream in the provider decoder. We do not currently have GPUs capable of running 236B-A23B locally to verify.

Respectful ask

If the team has any insight into:

1. Whether the <|tool_call|> / <|tool_declare|> chat template escapes or handles CJK inside argument values differently from English, or
2. Whether this matches a known provider-side issue you have seen,

any guidance would be invaluable. We are very happy to run any additional repros you suggest.

We are also filing this with FriendliAI in parallel (since we cannot tell whether it is their decoder or the model); we will link back here if they respond.

Thank you again for your time and for the wonderful model. 진심으로 감사드립니다.

— KOSMOS project team (학생 연구 프로젝트)