[opariffazman]

Problem

On a t3.large running Ubuntu 26.04, camne never answered. llama.log showed:

llama-server: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

• Cause: upstream's Ubuntu build links OpenMP. The 26.04 cloud image does not ship libgomp1.
• Effect: camne then polled /health for the full 2-minute WaitReady timeout.

Changes

• .github/workflows/llama.yml: a llama-b<build>-noomp tag rebuilds the pinned llama.cpp tag for Linux x64 and arm64.
  • Flags match upstream's ubuntu-cpu job, except GGML_OPENMP=OFF, LLAMA_OPENSSL=OFF, and LLAMA_BUILD_UI=OFF.
  • CI fails if llama-server or any .so still has a NEEDED entry for gomp, ssl, or crypto.
  • The result is published as a prerelease with --latest=false, so /releases/latest stays on v0.9.0.
• internal/provision: Linux pins the llama-b10333-noomp assets by sha256 and size.
  • The build unpacks to bin/llama-b10333-noomp/, so an existing install is replaced, never trusted.
  • RemoveOtherServers removes the old directory, but only after the new server is in place.
  • macOS and Windows keep upstream's builds.
• internal/engine: WaitReady returns as soon as a server camne started exits. The error includes the last line of llama.log, stripped to printable ASCII.
• internal/engine: threadsFor uses 2 threads on 2–5 logical CPUs. The old NumCPU/2 gave 1 thread on 2 vCPUs. 6+ CPUs are unchanged.

Numbers

Box: t3.large (2 vCPU, 1 physical core, Xeon 8259CL, AVX-512), Ubuntu 26.04.

• Model: camne-1.5b-Q4_K_M.gguf.
• Decoding: temperature 0, n_predict 64, grammar on.
• Prompt: camne nak cari file besar dalam folder ni (58 prompt tokens, no prompt cache).
• Runs: 3 per row. Output was find . -type f -size +100M on every run.

Build	Threads	Wall per query	Prompt tok/s	Output tok/s
upstream (OpenMP)	1	5.8 s	18	5.0
upstream (OpenMP)	2	3.5 s	28.5	8.8
no OpenMP (this PR)	2	3.5 s	28.5	8.8

• Upstream rows ran with libgomp unpacked into /tmp, because the box has none.
• The no-OpenMP build matches upstream within 0.03 s across 2 alternating rounds.
• The thread change comes from one box only. The 2/4/6/8 thread sweep on the 4-core target box was not re-run. Only 2 and 3 logical CPUs change; 4+ CPUs keep their old thread count.

End to end on the same box, no libgomp installed, with this branch's binary:

• First run: downloads 16 MB, loads the model, and answers in 9.0 s.
• Warm: camne nak buat file baru gives touch newfile.txt in 971 ms.
• Warm: tunjuk disk space gives df -h in 917 ms.

Tests

• go vet ./..., go test ./... pass. GOOS=windows go vet ./... and GOOS=darwin go build ./... pass.
• New tests: TestThreadsFor, TestWaitReadyServerExited, TestRemoveOtherServers, and dir/URL checks in TestLlamaAsset.

Not covered

• A t3.large has 1 physical core, so a cold-cache query stays about 3.5 s. It is above the 1.5 s warm target on this hardware.
• Burstable instances that run out of CPU credits drop to 30% of a core. Nothing in camne changes that.

🤖 Generated with Claude Code