Troubleshooting¶
Every ads-bib run performs a stage-aware preflight before the pipeline
starts and stops early when required keys, optional dependencies, or runtime
files are missing. The symptom → fix pairs below cover the errors that
survive that preflight.
Before You Debug¶
Walk through this short checklist before investigating a symptom:
-
Run the preflight report on the exact command you want to execute:
-
Confirm you are in the Python 3.12 env you intend to use for this run.
- Confirm
.envexists in your project folder and holds the keys your road requires (see Install & First Run). -
Check the versions of the package and its heavy dependencies:
A managed runtime download is not a failure
If the preflight reports that a managed runtime (the llama-server binary
or a default model file) will be downloaded on run, that is a warning,
not a blocker. The actual download happens when you start the run.
Missing ADS token¶
Symptom: ADS API auth or request errors.
Fix:
- Ensure
.envcontainsADS_TOKEN. - Re-run
ads-bib run ...after editing.env. - Reload the environment in the notebook session or restart the kernel.
Missing runtime dependency¶
Symptom: import or provider errors for topic models, translation, or visualization.
Fix:
- Reinstall the base package into the active env:
- If you intentionally switched to
topic_model.reduction_method=umap, adduv pip install "ads-bib[umap]". - If you intentionally switched to
topic_model.clustering_method=hdbscan, adduv pip install "ads-bib[hdbscan]". - Use
ads-bib doctor ...if you want the full stage-aware report without starting a run.
First run is slower than expected¶
Symptom: a fresh env or a fresh machine feels much slower than later runs.
Fix:
- This is expected one-time warmup work. The canonical list of what may download is in Runtime Roads — First-Run Behavior; use that section and this one together (same content, different shape).
- Re-run the same command once the caches are populated before treating the slowdown as a regression.
Missing lid.176.bin¶
Symptom: translation fails before API or local model calls start.
Fix:
- Download
lid.176.bininto the configured path, usuallydata/models/lid.176.bin. - For the packaged starter presets,
ads-bib rundownloads that default file automatically if it is missing. - Or point
translate.fasttext_modelat an existinglid.176.binlocation.
Missing llama-server¶
Symptom: local GGUF labeling fails before generation starts.
Fix:
- With the default
llama_server.command: "llama-server",ads-bib runfirst checksPATH, then the managed cache, then downloads the pinned package-managed runtime automatically. - If
ads-bib doctor ...says the managed runtime will be auto-downloaded on run, that is only a warning, not a blocker. local_cpuuses this path by default for labeling.local_gpuonly needs it when you explicitly switch topic labeling from local Transformers to GGUF.- If you set
llama_server.commandto an explicit path or custom command name, that override must resolve successfully; otherwise the run stops early. - If
Qwen3.5fails withunknown model architecture: 'qwen35', your active binary is too old or incompatible. - If an outdated
PATHbinary shadows the managed runtime you intended to use, remove the old binary fromPATHor pointllama_server.commandat the exact executable you want. - Restart the notebook session or CLI run after changing the executable path.
local_gpu reports no CUDA support¶
Symptom: ads-bib doctor --preset local_gpu ... reports Torch correctly but
still says the official GPU road is unsupported.
Fix:
- Confirm
torch.cuda.is_available()isTruein the active env. - If not, install the validated CUDA Torch wheel into the same env:
- Re-run
ads-bib doctor --preset local_gpu .... - If CUDA is still unavailable, the local HF/Torch paths will fall back to CPU,
but you are no longer on the official GPU-accelerated
local_gpupath.
local_gpu on Linux uses a different llama.cpp binary¶
Symptom: you read CUDA everywhere in the docs, then notice the managed
llama-server on Linux is a Vulkan build and wonder whether something is
misconfigured.
Fix:
- Nothing to fix — the split is intentional. On Linux,
ads-bibdownloads the official llama.cpp Vulkan build for thellama-serverlabeling runtime, while embeddings andtransformers-based translation still run on CUDA 12.4 via PyTorch. On Windows, both sides use CUDA 12.4. - Vulkan is the supported prebuilt GPU distribution of llama.cpp on Linux and runs on the same NVIDIA driver stack as CUDA PyTorch.
- See Runtime Roads → GPU runtime differs between Windows and Linux for the full table.
Unsupported local HF architecture¶
Symptom: errors such as Transformers does not recognize this architecture
for models like gemma3, qwen3, or gemma3_text.
Fix:
Then restart the kernel or session.
Windows OpenMP runtime conflict¶
Symptom: OMP: Error #15.
Fix:
OpenRouter provider errors¶
Symptom: provider validation, authentication, or cost resolution failures.
Fix:
- Ensure
OPENROUTER_API_KEYis set. - Ensure the
openaiPython package is installed. For package-managed installs,uv pip install ads-bibalready covers this; otherwise installopenaidirectly. - Use supported provider names and model identifiers.
Toponymy first-layer error¶
Symptom: Not enough clusters found in the first layer.
Fix:
- Lower
base_min_cluster_sizefirst. - If needed, lower
min_clustersas well. - Leave
toponymy_layer_index="auto"unless you need a fixed layer.
Toponymy layer index out of range¶
Symptom: layer_index ... is out of range.
Fix:
- Use a smaller explicit layer index, or switch back to
toponymy_layer_index="auto"for the coarsest available overview layer. - Recheck that the fit actually produced more than one layer.
- If the fit returned no layers, lower the Toponymy clustering thresholds.
Toponymy / Fast-HDBSCAN compatibility¶
Symptom: TypeError: missing argument 'n_threads' during topic_fit.
Fix:
- Use the package-managed dependency set.
ads-bibpinsfast-hdbscan>=0.2.2,<0.3becausetoponymy==0.4.0calls Fast-HDBSCAN's Boruvka helper with the 0.2.x signature. - Run
uv sync --python 3.12 --group dev --extra test --extra umap --extra hdbscanin a repo checkout, or reinstall the package in user environments. - Do not try to solve this with
toponymy_max_workers; that setting only controls concurrent Toponymy labeling/embedding requests.
Hugging Face API provider errors¶
Symptom: huggingface_api validation, authentication, or runtime failures.
Fix:
- Ensure
HF_TOKENis set.HF_API_KEYandHUGGINGFACE_API_KEYare also accepted. - Ensure the
huggingface-hubPython package is installed.uv pip install ads-bibalready includes it for the official roads. - Use HF-native model ids such as
Qwen/Qwen3-Embedding-8Borunsloth/Qwen2.5-72B-Instruct:featherless-ai. hf_apinow supports both BERTopic and Toponymy; backend-specific errors are therefore more likely to be a wrong model id, a token problem, or a rate/network issue than a pipeline wiring issue.
Author Disambiguation¶
Symptom: author_disambiguation fails before running.
Fix:
- Update to a current install:
uv pip install -U ads-bib. - Check the effective config with
ads-bib doctor --to author_disambiguation. - Leave
author_disambiguation.backend=localunless you want Modal. - For Modal, set both
MODAL_TOKEN_IDandMODAL_TOKEN_SECRETin your environment or project.env. - For small validation runs, set
author_disambiguation.runtime=cpuandauthor_disambiguation.infer_stage=smoke.
spaCy model unavailable¶
Symptom: tokenization model load errors.
Fix:
Or configure a fallback model explicitly. If tokenize.auto_download=true, the
run will also try to install the preferred model automatically.
Quality Checks (Contributors)¶
If you are working on ads-bib itself rather than just running it, these
checks mirror CI:
Equivalent explicit commands:
Read next¶
- Runtime Roads — one-time downloads and cache behavior
- Configuration — full key reference
- Install & First Run — env and first command recap