github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #204] Consider Using Standard Config Format #62120

New Issue
Open
opened 2026-05-03 07:36:13 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-05-03 07:36:13 -05:00
Owner
Copy Link

Originally created by @nazimamin on GitHub (Jul 24, 2023).
Original GitHub issue: https://github.com/ollama/ollama/issues/204

Thank you for your work, this is great and will be very helpful for the OSS community. The custom configuration file named "Modelfile" works well in the context of this project.

I would like to discuss the possibility of using a standardized config format such as JSON5, TOML, YAML, or another similar standard. Those are battle-tested, easy to read and maintain, and have extensive tooling support. Using custom config language makes it harder for people to adapt quickly and makes it hard to build tooling support on top of it. Thoughts?

Originally created by @nazimamin on GitHub (Jul 24, 2023). Original GitHub issue: https://github.com/ollama/ollama/issues/204 Thank you for your work, this is great and will be very helpful for the OSS community. The custom configuration file named "Modelfile" works well in the context of this project. I would like to discuss the possibility of using a standardized config format such as JSON5, TOML, YAML, or another similar standard. Those are battle-tested, easy to read and maintain, and have extensive tooling support. Using custom config language makes it harder for people to adapt quickly and makes it hard to build tooling support on top of it. Thoughts?
GiteaMirror added the feedback wantedfeature request labels 2026-05-03 07:36:13 -05:00
GiteaMirror commented 2026-05-03 07:36:15 -05:00
Author
Owner
Copy Link

@mchiang0610 commented on GitHub (Jul 25, 2023):

Hey @nazimamin, thank you so much for submitting this, and bringing it to our attention.

Having worked with multiple config formats in the past, I think you and I know very well, no matter what we choose, there will be different trade offs. Some cater towards composability, and making it easy to generate via generator tools. Some are more human-readable than others, and the list can go on.

We probably won't get it right all the time, but we'll always pick the one that can address the biggest number of people. Always listening to more use-cases, and suggestions to determine what's the best.

We definitely should have good support to tools/formats that to enable use of Ollama's API.

<!-- gh-comment-id:1649058126 --> @mchiang0610 commented on GitHub (Jul 25, 2023): Hey @nazimamin, thank you so much for submitting this, and bringing it to our attention. Having worked with multiple config formats in the past, I think you and I know very well, no matter what we choose, there will be different trade offs. Some cater towards composability, and making it easy to generate via generator tools. Some are more human-readable than others, and the list can go on. We probably won't get it right all the time, but we'll always pick the one that can address the biggest number of people. Always listening to more use-cases, and suggestions to determine what's the best. We definitely should have good support to tools/formats that to enable use of Ollama's API.
GiteaMirror commented 2026-05-03 07:36:15 -05:00
Author
Owner
Copy Link

@nkoehring commented on GitHub (Jul 25, 2023):

I support the OPs suggestion. Maybe "getting it right" issues could be mitigated by supporting multiple formats that can be easily serialized. I for example find TOML very easy to read and write, but also simple to parse. Others might prefer YAML (which I don't like that much). Parsing those formats into the same memory structure should be rather easy, nowadays.

<!-- gh-comment-id:1649442366 --> @nkoehring commented on GitHub (Jul 25, 2023): I support the OPs suggestion. Maybe "getting it right" issues could be mitigated by supporting multiple formats that can be easily serialized. I for example find TOML very easy to read and write, but also simple to parse. Others might prefer YAML (which I don't like that much). Parsing those formats into the same memory structure should be rather easy, nowadays.
GiteaMirror commented 2026-05-03 07:36:16 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Jul 25, 2023):

I think there's potentially a misunderstanding of the purpose of the Modelfile. It's not a config file, but more akin to a Makefile or a Dockerfile. It's probably hard to see at this point because everything is still so rudimentary, but the vision is to have a format which can handle assembling all of the quantization levels, embeddings, and even peft/lora training all in the same file. Additionally, with the support of manifest lists in the model image we can support multiple weights formats beyond ggml v3. The point is that you can use the Modelfile to assemble your model, and use ollama push to push it to the registry where you can easily share it with other people.

So it's not so much as a config file as it is a script or a source file for assembling models. I appreciate the suggestion here, guys, but I'm going to go ahead and close the issue. There will be ollama config files at some point for tweaking parameters in the ollama runner/server, and those will definitely be normal config files.

<!-- gh-comment-id:1649855994 --> @pdevine commented on GitHub (Jul 25, 2023): I think there's potentially a misunderstanding of the purpose of the Modelfile. It's not a config file, but more akin to a Makefile or a Dockerfile. It's probably hard to see at this point because everything is still so rudimentary, but the vision is to have a format which can handle assembling all of the quantization levels, embeddings, and even peft/lora training all in the same file. Additionally, with the support of manifest lists in the model image we can support multiple weights formats beyond ggml v3. The point is that you can use the Modelfile to assemble your model, and use `ollama push` to push it to the registry where you can easily share it with other people. So it's not so much as a config file as it is a script or a source file for assembling models. I appreciate the suggestion here, guys, but I'm going to go ahead and close the issue. There will be ollama config files at some point for tweaking parameters in the ollama runner/server, and those will definitely be normal config files.
GiteaMirror commented 2026-05-03 07:36:17 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Jul 25, 2023):

One thing I should also mention; you can use JSON to set the hyper-parameters already when calling POST /api/generate. We could fairly easily expose this through ollama run so you could easily tweak the parameters. LMK if this would be useful.

<!-- gh-comment-id:1649982736 --> @pdevine commented on GitHub (Jul 25, 2023): One thing I should also mention; you *can* use JSON to set the hyper-parameters already when calling `POST /api/generate`. We could fairly easily expose this through `ollama run` so you could easily tweak the parameters. LMK if this would be useful.
GiteaMirror commented 2026-05-03 07:36:17 -05:00
Author
Owner
Copy Link

@nathanleclaire commented on GitHub (Jul 25, 2023):

Yea, there is never any good answer on this kind of thing. Dockerfile took off like crazy because it's so easy to understand and read/write. And Kubernetes had loads of YAML with infinite flexibility, but it made us all miserable, and generation layers on top like Helm made everything worse. It might be a good compromise if Ollama had a well-defined API (or JSON compatibility with Modelfile, that type of thing), that didn't push so much of the magic to the client like Docker does in a lot of instances.

<!-- gh-comment-id:1650713477 --> @nathanleclaire commented on GitHub (Jul 25, 2023): Yea, there is never any good answer on this kind of thing. `Dockerfile` took off like crazy because it's so easy to understand and read/write. And Kubernetes had loads of YAML with infinite flexibility, but it made us all miserable, and generation layers on top like Helm made everything worse. It might be a good compromise if Ollama had a well-defined API (or JSON compatibility with Modelfile, that type of thing), that didn't push so much of the magic to the client like Docker does in a lot of instances.
GiteaMirror commented 2026-05-03 07:36:18 -05:00
Author
Owner
Copy Link

@sammcj commented on GitHub (May 5, 2024):

I'd really like to see Ollama support using a standard config file for model server settings and default parameters.

Somewhat related #4120 #4154 #4123 #836

<!-- gh-comment-id:2094988225 --> @sammcj commented on GitHub (May 5, 2024): I'd really like to see Ollama support using a standard config file for model server settings and default parameters. Somewhat related #4120 #4154 #4123 #836
GiteaMirror commented 2026-05-03 07:36:19 -05:00
Author
Owner
Copy Link

@chigkim commented on GitHub (May 31, 2024):

This seems an old issue, so maybe neglected, but regardless it would be amazing to be able to set with config file like yaml/json format.

OLLAMA_HOST: "0.0.0.0"
OLLAMA_NOHISTORY: true
OLLAMA_FLASH_ATTENTION: true
OLLAMA_NUM_PARALLEL: 4
OLLAMA_MAX_LOADED: 2
<!-- gh-comment-id:2143024325 --> @chigkim commented on GitHub (May 31, 2024): This seems an old issue, so maybe neglected, but regardless it would be amazing to be able to set with config file like yaml/json format. ``` OLLAMA_HOST: "0.0.0.0" OLLAMA_NOHISTORY: true OLLAMA_FLASH_ATTENTION: true OLLAMA_NUM_PARALLEL: 4 OLLAMA_MAX_LOADED: 2 ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request feedback wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#62120
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?