Instructions to use ai-sage/GigaChat3.5-432B-A28B-GGUF with libraries, inference providers, notebooks, and local apps. Follow these links to get started.

Notebooks
Google Colab
Kaggle
Local Apps Settings

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with llama.cpp:

Install (macOS, Linux)

curl -LsSf https://llama.app/install.sh | sh
# Start a local OpenAI-compatible server with a web UI:
llama serve -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
# Run inference directly in the terminal:
llama cli -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Install from WinGet (Windows)

winget install llama.cpp
# Start a local OpenAI-compatible server with a web UI:
llama serve -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
# Run inference directly in the terminal:
llama cli -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Use pre-built binary

# Download pre-built binary from:
# https://github.com/ggerganov/llama.cpp/releases
# Start a local OpenAI-compatible server with a web UI:
./llama-server -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
# Run inference directly in the terminal:
./llama-cli -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Build from source code

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
cmake -B build
cmake --build build -j --target llama-server llama-cli
# Start a local OpenAI-compatible server with a web UI:
./build/bin/llama-server -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
# Run inference directly in the terminal:
./build/bin/llama-cli -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Use Docker

docker model run hf.co/ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

LM Studio
Jan

vLLM

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with vLLM:

Install from pip and serve model

# Install vLLM from pip:
pip install vllm
# Start the vLLM server:
vllm serve "ai-sage/GigaChat3.5-432B-A28B-GGUF"
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:8000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "ai-sage/GigaChat3.5-432B-A28B-GGUF",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Use Docker

docker model run hf.co/ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Ollama
How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Ollama:
```
ollama run hf.co/ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
```

Unsloth Studio

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Unsloth Studio:

Install Unsloth Studio (macOS, Linux, WSL)

curl -fsSL https://unsloth.ai/install.sh | sh
# Run unsloth studio
unsloth studio -H 0.0.0.0 -p 8888
# Then open http://localhost:8888 in your browser
# Search for ai-sage/GigaChat3.5-432B-A28B-GGUF to start chatting

Install Unsloth Studio (Windows)

irm https://unsloth.ai/install.ps1 | iex
# Run unsloth studio
unsloth studio -H 0.0.0.0 -p 8888
# Then open http://localhost:8888 in your browser
# Search for ai-sage/GigaChat3.5-432B-A28B-GGUF to start chatting

Using HuggingFace Spaces for Unsloth

# No setup required
# Open https://huggingface.co/spaces/unsloth/studio in your browser
# Search for ai-sage/GigaChat3.5-432B-A28B-GGUF to start chatting

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Pi:

Start the llama.cpp server

# Install llama.cpp:
brew install llama.cpp
# Start a local OpenAI-compatible server:
llama serve -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Configure the model in Pi

# Install Pi:
npm install -g @mariozechner/pi-coding-agent
# Add to ~/.pi/agent/models.json:
{
  "providers": {
    "llama-cpp": {
      "baseUrl": "http://localhost:8080/v1",
      "api": "openai-completions",
      "apiKey": "none",
      "models": [
        {
          "id": "ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M"
        }
      ]
    }
  }
}

Run Pi

# Start Pi in your project directory:
pi

OpenClaw new

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with OpenClaw:

Start the llama.cpp server

# Install llama.cpp:
brew install llama.cpp
# Start a local OpenAI-compatible server:
llama serve -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Configure OpenClaw

# Install OpenClaw:
npm install -g openclaw@latest
# Register the local server and set it as the default model:
openclaw onboard --non-interactive --mode local \
  --auth-choice custom-api-key \
  --custom-base-url http://127.0.0.1:8080/v1 \
  --custom-model-id "ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M" \
  --custom-provider-id llama-cpp \
  --custom-compatibility openai \
  --custom-text-input \
  --accept-risk \
  --skip-health

Run OpenClaw

openclaw agent --local --agent main --message "Hello from Hugging Face"

Docker Model Runner
How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Docker Model Runner:
```
docker model run hf.co/ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M
```

Lemonade

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Lemonade:

Pull the model

# Download Lemonade from https://lemonade-server.ai/
lemonade pull ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Run and chat with the model

lemonade run user.GigaChat3.5-432B-A28B-GGUF-Q4_K_M

List all available models

lemonade list

Hermes Agent

How to use ai-sage/GigaChat3.5-432B-A28B-GGUF with Hermes Agent:

Start the llama.cpp server

# Install llama.cpp:
brew install llama.cpp
# Start a local OpenAI-compatible server:
llama serve -hf ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Configure Hermes

# Install Hermes:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup
# Point Hermes at the local server:
hermes config set model.provider custom
hermes config set model.base_url http://127.0.0.1:8080/v1
hermes config set model.default ai-sage/GigaChat3.5-432B-A28B-GGUF:Q4_K_M

Run Hermes

hermes

Atomic Chat

Q8_0 produces garbage output with llama.cpp — Q4_K_M works fine

by SergeyLizin - opened Jul 14

Discussion

SergeyLizin

Jul 14

Q8_0 produces garbage output with llama.cpp (PR #25342, gigachat35 arch) — Q4_K_M works fine

Reporting a reproducible issue for anyone else trying to run GigaChat3.5-432B-A28B on llama.cpp.

Setup

llama.cpp built from PR #25342 (custom gigachat35 architecture; not yet in master)
CUDA build, multi-GPU (-sm layer -ts ...), -fa on --jinja, GGUF-embedded chat template
Same host, same binary, same launch flags for both quants

Symptom

Q4_K_M (~240 GB): works correctly — coherent generation, passes our eval suite.
Q8_0 (~460 GB): deterministic word-salad / incoherent token stream on every configuration we tried. Not a sampling issue — output is broken from the first token.

What we ruled out (Q8 still broke with each of these controlled):

Chat template — used the GGUF-embedded minja-compatible template via --jinja (the original repo chat_template.jinja is full Jinja2 and doesn't parse in minja, but that fails at startup, not silently; embedded template loads fine and Q4 uses the identical path).
KV-cache quantization — tested with f16 KV cache, same garbage.
tool_choice / structured-output path — garbage on plain completion too.
Multi-GPU tensor split / OOM — no OOM; layers split cleanly across GPUs, VRAM fits.
MTP speculative decoding — disabled it entirely (draft acceptance was 0% anyway); Q8 still produces garbage without MTP.

Because the only variable that changes the outcome is the quantization level (Q4 → coherent, Q8 → garbage) while binary, host, template, and flags are held constant, this points to either a bad Q8_0 quantization of these weights or the PR #25342 code path mishandling Q8_0 specifically for this MoE/MLA architecture.

Workaround: use Q4_K_M until the Q8_0 path is fixed. If anyone has run Q8_0 coherently on llama.cpp, we'd be glad to hear the exact build/flags.

SergeyLizin

Jul 14

Cause is a broken partial re-upload on main, not the quant or the PR.

The Jul-13 commit 4ab92df re-quantized Q8_0 but only replaced shards 00001-00006 and 00010 — shards 00007/00008/00009 are still the Jul-6 blobs (verified: identical oids, older shards untouched). So main mixes two different quantization runs - dequant reads the old shards wrong - deterministic word-salad. Q6_K shows the same pattern.

bsfg

ai-sage org Jul 14

@SergeyLizin Hi,
Please try to rebuild binary with latest changes (3edef37e8a9f0a9cb77232e283c2e9be0cb26d2d). There was change yesterday in norms, norms presented not in all gguf files

SergeyLizin

30 days ago

•

edited 30 days ago

3edef37 ("fix scale") targets the new format, so it breaks the old be1eac4 quant (salad) and still can't fix main (mixed).

The Jul-13 4ab92df re-quant only replaced Q8_0 shards 00001-00006 and 00010 — shards 00007/00008/00009 are still the Jul-6 blobs (their LFS oids are byte-identical to revision be1eac4…). So main mixes two quantization runs, norm/scale tensors inconsistent across shards, deterministic word-salad. No build can reconcile old- and new-format shards.

Only working combo: revision be1eac4fd62a08abdc2d0d14c3fa3bf3c6ff865a + a pre-3edef37 binary.

@ai-sage — please re-upload the full Q8_0 / Q6_K in one consistent pass; the upload-large-folder run left shards 00007-00009 stale.

bsfg

ai-sage org 30 days ago

@SergeyLizin
The upload isn't partial, shards 00007-00009 contain no norm tensors, so they legitimately weren't re-uploaded; there's nothing inconsistent about them. Every tensor the norm change touches lives in the shards that were replaced.
We ran the current main Q8_0 with a clean 3edef37 build on 8×H100 - it generates correctly (plain chat, math, tool calls). So main + 3edef37 is a valid, working pair. Problems comes from a weights/binary generation mismatch: the current weights fold the norm +1 into the tensors, so a pre-3edef37 (or stale incremental) build re-applies the old runtime +1 -> rms·(w+2) -> exactly this output. Please do a clean rebuild at 3edef37 (fresh build dir; confirm llama-server actually relinked) against the current revision and it'll be coherent. If it still isn't after a clean build, send your exact commit hash + build flags and we'll look

SergeyLizin

29 days ago

Thanks, that's a clear diagnosis and it matches the symptom exactly. You're right — I was wrong to read the untouched 00007–00009 shards as a partial upload; if they carry no norm tensors there's nothing to re-upload, and main is consistent.

My builds were incremental against an existing build dir, so the stale-binary / weights mismatch you describe (old runtime +1 re-applied on top of already-folded norms → rms·(w+2)) is almost certainly what produced the word-salad. That also explains why the only coherent combo I'd found was an older weights+binary pair.

I'll do a clean rebuild at 3edef37 — fresh build dir, --no-cache, and I'll confirm llama-server actually relinked — against the current revision, and report back. If it's still incoherent after that, I'll send the exact commit hash + full build flags.

Appreciate the help.

Upload images, audio, and videos by dragging in the text input, pasting, or clicking here.

Tap or paste here to upload images

· Sign up or log in to comment