Replies: 10 comments 37 replies
-
|
I think we also need to look into minimizing (however possible without compromising test coverage) the amount of builds running. |
Beta Was this translation helpful? Give feedback.
-
|
How do we feel about disabling all automatic Github-hosted workflows for Pull Requests and delegate it to maintainers to manually decide which workflows to run and when for a given PR? The |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if our main issue is that we have many long running |
Beta Was this translation helpful? Give feedback.
-
|
Well I was the one who set up the We also have way too many jobs in general. Aside from removing jobs you can also try spreading out the load between ARM and x86 machines if possible, some stuff like those cross compiles or webgpu runs can probably be done on ARM. There's also the new ubuntu-slim machine which they hopefully have more of and which we can use for simple jobs that only need 1 core and 5 gigs of memory. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I can set up a dedicated Podman container with GPU access that starts automatically with my AI server (Ryzen 9 9950X3D 96GB DDR5). It won't interfere with my other workloads and can run CUDA and Vulkan workflows at full speed on a real GPU (RTX PRO 6000) ? It would be a clean pod with minimal Debian Containerfile / yaml, with the latest CUDA/Vulkan, that anyone in our group could download and instantiate to run the pipeline. |
Beta Was this translation helpful? Give feedback.
-
|
I have a dedicated server with AMD Ryzen 7 2700X (8C 16T), 32 GB DDR4, 4 TB storage and an NVIDIA RTX 2060 GPU doing nothing currently. I believe it can run both CUDA and Vulkan CI workloads. Let me know if my configuration is feasible and we can onboard my server as part of the self-hosted runners. |
Beta Was this translation helpful? Give feedback.
-
What needs to be updated is this: Not sure if this will break anything though, this is not yet done upstream, so no use syncing our fork yet either. |
Beta Was this translation helpful? Give feedback.
-
|
@ggerganov |
Beta Was this translation helpful? Give feedback.
-
|
I guess i am currently on my way of making this worse with #20430, i have quite a few more checks i would like to add to this workflow in the future. I would be happy to have this restricted to running when i press a button on prs that affect the hip backed. |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
With the current trend of the Github Actions runners becoming increasing slower and slower, we are close to not having a useable CI pipeline. Opening this discussion to discuss what we can do about this.
Queue time for last 6 months
TODOs
riscvworkflows only on themasterbranch and not in PRs.ymlfilesccache-action: ci : discuss optimization strategies #20446 (reply in thread)ggml-ci-*-cpu-*workflows to self-hosted runners to reduce some of the GH cacheUpcoming self-hosted runners
One of the best way to minimize the queue times is to move the workflows to self-hosted runners that are dedicated to running ggml workflows. This requires provisioning and hosting hardware.
Beta Was this translation helpful? Give feedback.
All reactions