Chen Qian

In 2.11 the optimizer does lazy loading, if you want to explicitly restore the variable values, you need to call `optimizer.build(model.trainable_variables)`, which is automatically called at the first time of...

``` import tensorflow as tf print(tf.__version__) print(tf.keras.__version__) model = tf.keras.Sequential( [ tf.keras.Input(shape=(1,)), tf.keras.layers.Dense(1, activation="softmax"), ] ) model.compile(optimizer="adam", loss="categorical_crossentropy") model.fit([[1]], [0], verbose=0) model.save("model") new = tf.keras.models.load_model("model") new.load_weights("model") new.optimizer.build(model.trainable_variables) print([v.name for v...

@lgeiger Thanks for reporting the issue! Could you try moving the `model.compile()` under strategy scope and rerun the tests in your setup? Also is it only failing with SGD or...

This is strange, my recent change should not take any effect unless users are specifying the environment variable `MLFLOW_ASYNC_LOGGING_WAITING_TIME`, which is not yet publicly documented.

Yes technically when every job is finished then this threadpool will shut down. I don't know why there is a regression. Need to take a closer look at the user's...

this makes a lot of sense. @borchero Would like to see your PR!

@Nasreddine Mipro and SIMBA should be better than COPRO for almost every case, and we will remove COPRO in the near future.

@Nasreddine Thanks for reporting the issue! I am a bit confused about your LM response: ``` LM Response: {"type": "function", "name": "json_tool_call", "parameters": {"discussion": "The predict module is to blame...

I would rather just delete this weird warning and let it error out, which may sound risky but I am pretty sure that reduces users' confusion.

@davruet Thanks for reporting the issue! could you provide a reproducible code on gpt-4.1 that doesn't have the complete identifier? This is supposed to be internal adapter logic, and I...