diff --git a/docs.json b/docs.json index 6a4137a..6fb858d 100644 --- a/docs.json +++ b/docs.json @@ -80,6 +80,7 @@ "group": "Fine-tuning", "icon": "sliders", "pages": [ + "lfm/fine-tuning/overview", "lfm/fine-tuning/leap-finetune", "lfm/fine-tuning/datasets", "lfm/fine-tuning/trl", @@ -116,6 +117,15 @@ "deployment/gpu-inference/fal" ] }, + { + "group": "Guides", + "icon": "book-open", + "pages": [ + "guides/hardware-evaluation", + "guides/use-case-evaluation", + "guides/migration-guide" + ] + }, { "group": "Help", "icon": "book", @@ -508,7 +518,7 @@ }, { "source": "/lfm/fine-tuning", - "destination": "/lfm/fine-tuning/leap-finetune" + "destination": "/lfm/fine-tuning/overview" } ], "ai": { diff --git a/guides/hardware-evaluation.mdx b/guides/hardware-evaluation.mdx new file mode 100644 index 0000000..9c77fb1 --- /dev/null +++ b/guides/hardware-evaluation.mdx @@ -0,0 +1,78 @@ +--- +title: "Hardware Evaluation" +description: "Profile Liquid Foundation Models for latency, throughput, and memory on your target hardware." +--- + +Use this guide when you are evaluating LFMs on a specific board, accelerator, mobile device, or server. The goal is to measure latency, throughput, memory behavior, and quantization trade-offs on the hardware you plan to ship. + +## Recommended models + +Start with **LFM2.5-350M**. It is small enough to bring up quickly on almost any target and is the first model many silicon partners profile. + +Then scale through the family to map the performance curve: + +1. **LFM2.5-350M**: bring-up and baseline +2. **LFM2.5-1.2B-Instruct**: standard dense datapoint +3. **LFM2.5-8B-A1B**: MoE with 1.5B active parameters, useful for testing sparse-model behavior on your memory subsystem +4. **LFM2.5-VL-450M** and **LFM2.5-Audio-1.5B**: multimodal datapoints when your target supports vision or audio workloads + +The LFM2 and LFM2.5 architecture interleaves short convolutions with grouped-query attention. In practice, that means less KV-cache pressure and better long-context latency scaling than pure-attention models of the same size. Your profiling should make that behavior visible. + +## Setup by framework + +| Framework | Guide | Typical target | +| --- | --- | --- | +| Transformers | [Transformers](/deployment/gpu-inference/transformers) | GPU baseline, correctness check | +| vLLM | [vLLM](/deployment/gpu-inference/vllm) | GPU serving | +| SGLang | [SGLang](/deployment/gpu-inference/sglang) | GPU serving | +| llama.cpp | [llama.cpp](/deployment/on-device/llama-cpp) | CPU, embedded, custom silicon | +| Ollama | [Ollama](/deployment/on-device/ollama) | Local development | +| MLX | [MLX](/deployment/on-device/mlx) | Apple Silicon | +| ONNX | [ONNX](/deployment/on-device/onnx) | NPUs and accelerator toolchains | +| LEAP SDK | [Quick Start](/deployment/on-device/sdk/quick-start) | iOS and Android apps | + +For most silicon evaluations, **llama.cpp with GGUF** or **ONNX** is the fastest path to numbers on your target. + +## Quantization + +LFMs are routinely deployed quantized on device. Major models ship pre-quantized, so choose the quantization level that fits your memory budget. Lower precision reduces memory and usually improves throughput. + +- **GGUF ladder:** `Q4_0`, `Q4_K_M`, `Q5_K_M`, `Q6_K`, `Q8_0`, `F16` +- **MLX:** 4-bit, 5-bit, 6-bit, 8-bit, and bf16 repos per model +- **ONNX:** per-model `-ONNX` repos + +`Q4_K_M` is the default recommendation for CPU and edge deployments. Move up the ladder if your quality bar requires it. + +Profile at least two quantization levels, such as `Q4_K_M` and `Q8_0`, so you can see the memory, quality, and throughput trade-off on your hardware instead of measuring only one point. + +## Benchmarking methodology + +Report end-to-end latency with prefill and decode separated: + +- Time to first token +- Decode tokens per second +- P50 and P95 latency, after one warmup iteration + +Use these prompt and output lengths: + +| Input tokens | Output tokens | +| --- | --- | +| 256 | 100 | +| 512 | 100 | +| 1024 | 100 | + +Report peak memory at each context length: + +- 256 tokens +- 512 tokens +- 1024 tokens +- 2048 tokens +- 4096 tokens + +This gives you a clear view of scaling behavior, KV-cache efficiency, and deployment headroom. + +## Related docs + +- [Complete Model Library](/lfm/models/complete-library) +- [Use Case Evaluation](/guides/use-case-evaluation) +- [Migration Guide](/guides/migration-guide) diff --git a/guides/migration-guide.mdx b/guides/migration-guide.mdx new file mode 100644 index 0000000..32f9b6e --- /dev/null +++ b/guides/migration-guide.mdx @@ -0,0 +1,242 @@ +--- +title: "Migration Guide" +description: "Move from Qwen, Llama, or Gemma to LFMs while avoiding the common migration pitfalls." +--- + +This guide is for teams already running Qwen, Llama, or Gemma who want to evaluate Liquid Foundation Models as replacements. LFMs load and serve through the same frameworks you already use, so most migrations are a model ID and config change. The details that usually matter are sampling defaults, chat templates, tool-call parsing, and LoRA module names. + +Use this alongside [Use Case Evaluation](/guides/use-case-evaluation) for model selection and benchmarking methodology. + +## Model mapping + +Pick the LFM in the same deployment class as your current model. Compare within class; benchmarking a 1.2B LFM against a 32B Qwen does not tell you whether it fits your deployment. + +| If you run | Evaluate | Notes | +| --- | --- | --- | +| Qwen3-0.6B, Llama-3.2-1B, Gemma-3-270M/1B | [LFM2.5-350M](https://huggingface.co/LiquidAI/LFM2.5-350M) | Classification, extraction, routing. Also consider LFM2.5-230M. | +| Qwen3-1.7B, Llama-3.2-3B, Gemma-3-4B | [LFM2.5-1.2B-Instruct](https://huggingface.co/LiquidAI/LFM2.5-1.2B-Instruct) | The default dense workhorse. | +| Qwen3-4B/8B, Llama-3.1-8B, Gemma-3-12B | [LFM2.5-8B-A1B](https://huggingface.co/LiquidAI/LFM2.5-8B-A1B) | MoE with 8B total and 1.5B active parameters. | +| Qwen3-14B/32B and larger dense models | [LFM2-24B-A2B](https://huggingface.co/LiquidAI/LFM2-24B-A2B) | 24B total and roughly 2.3B active parameters. | +| Qwen3 thinking mode or DeepSeek distills | [LFM2.5-1.2B-Thinking](https://huggingface.co/LiquidAI/LFM2.5-1.2B-Thinking) | Reasoning traces at 1.2B. | +| Qwen2.5-VL-3B/7B, Llama-3.2-Vision, Gemma-3 vision | [LFM2.5-VL-450M](https://huggingface.co/LiquidAI/LFM2.5-VL-450M) or [LFM2.5-VL-1.6B](https://huggingface.co/LiquidAI/LFM2.5-VL-1.6B) | Use `-Extract` variants for image to strict JSON. | +| Whisper plus separate TTS | [LFM2.5-Audio-1.5B](https://huggingface.co/LiquidAI/LFM2.5-Audio-1.5B) | ASR, TTS, and speech-to-speech in one model. | + +See the [Complete Model Library](/lfm/models/complete-library) for the full catalog. + +LFM2.5 dense models support 32K context, and LFM2.5-8B-A1B supports 128K. If you rely on 128K context in a small dense Qwen or Llama model, check your production context distribution before assuming this is a blocker. Most sub-8B deployments do not exceed 8K tokens. + +## Runtime-by-runtime migration + +Minimum versions: + +- `transformers >= 5.2.0` +- vLLM `>= 0.23.0` + + + + Change the model ID and use the model's chat template: + + ```python + from transformers import AutoModelForCausalLM, AutoTokenizer + + model_id = "LiquidAI/LFM2.5-1.2B-Instruct" + model = AutoModelForCausalLM.from_pretrained( + model_id, + dtype="bfloat16", + device_map="auto", + ) + tokenizer = AutoTokenizer.from_pretrained(model_id) + + inputs = tokenizer.apply_chat_template( + [{"role": "user", "content": "What is C. elegans?"}], + add_generation_prompt=True, + return_tensors="pt", + return_dict=True, + ).to(model.device) + + out = model.generate( + **inputs, + max_new_tokens=512, + do_sample=True, + temperature=0.1, + top_k=50, + repetition_penalty=1.05, + ) + ``` + + Do not reuse literal Llama-style or Gemma-style prompt strings. They will usually run, but quality will degrade. + + See [Transformers](/deployment/gpu-inference/transformers). + + + + Serve the model behind an OpenAI-compatible endpoint: + + ```bash + vllm serve LiquidAI/LFM2.5-1.2B-Instruct + ``` + + Your OpenAI-client code stays mostly unchanged: + + ```python + client.chat.completions.create( + model="LiquidAI/LFM2.5-1.2B-Instruct", + messages=messages, + temperature=0.1, + extra_body={"top_k": 50, "repetition_penalty": 1.05}, + ) + ``` + + If you use OpenAI-style `tools=[...]`, configure the LFM tool-call parser before switching traffic. See [Tool calling](#tool-calling) below and the [vLLM guide](/deployment/gpu-inference/vllm). + + + + Serve the model through SGLang's OpenAI-compatible API and keep your client integration mostly unchanged: + + ```bash + sglang serve --model-path LiquidAI/LFM2.5-1.2B-Instruct --tool-call-parser lfm2 + ``` + + Use LFM sampling defaults and configure the LFM tool-call parser if your evaluation includes tools. + + See [SGLang](/deployment/gpu-inference/sglang). + + + + Pull the official GGUF and choose the quantization level you plan to deploy: + + ```bash + llama-server -hf LiquidAI/LFM2.5-1.2B-Instruct-GGUF:Q4_K_M + ``` + + The GGUF embeds the correct chat template. Do not override it with an old Qwen or Llama template. + + See [llama.cpp](/deployment/on-device/llama-cpp). + + + + Use the official GGUF artifact and keep the embedded chat template: + + ```bash + ollama run hf.co/LiquidAI/LFM2.5-1.2B-Instruct-GGUF:Q4_K_M + ``` + + If you are using LM Studio, select the matching GGUF quantization and avoid overriding the prompt template with a previous Qwen, Llama, or Gemma template. + + See [Ollama](/deployment/on-device/ollama) and [LM Studio](/deployment/on-device/lm-studio). + + + + Per-precision repos exist for each model, including `-MLX-4bit` through `-MLX-8bit` and `-ONNX`. Swap the repo ID in `mlx-lm` or your ONNX Runtime pipeline. + + See [MLX](/deployment/on-device/mlx) and [ONNX](/deployment/on-device/onnx). + + + + The [LEAP SDK](/deployment/on-device/sdk/quick-start) gives iOS and Android apps a supported runtime with function calling and constrained generation included. + + + +## Chat template and sampling + +LFMs use a ChatML-style format: + +```text +<|startoftext|><|im_start|>system +You are a helpful assistant trained by Liquid AI.<|im_end|> +<|im_start|>user +What is C. elegans?<|im_end|> +<|im_start|>assistant +``` + +Roles are `system`, `user`, `assistant`, and `tool`. Vision-language models use an `` sentinel. See [Chat template](/lfm/key-concepts/chat-template). + +Migration notes: + +- **From Qwen:** ChatML is familiar, but token details differ. Use `apply_chat_template`; do not reuse literal Qwen strings. +- **From Llama:** replace `<|begin_of_text|>` and `<|start_header_id|>` prompt builders. +- **From Gemma:** replace `` builders. LFMs support a real `system` role. + +Recommended starting sampling values: + +| Param | LFM2.5 recommendation | Common carry-over mistake | +| --- | --- | --- | +| `temperature` | `0.1` | `0.6` to `0.7`, which can cause drift | +| `top_k` | `50` | disabled | +| `repetition_penalty` | `1.05` | `1.0` | + +For deterministic classification, extraction, and structured output, use greedy decoding. See [Text generation and prompting](/lfm/key-concepts/text-generation-and-prompting). + +## Tool calling + +LFMs natively emit a Pythonic tool-call list, not OpenAI-style JSON: + +```text +<|tool_call_start|>[get_candidate_status(candidate_id="12345")]<|tool_call_end|> +``` + +If you swap an agent to an LFM and let a generic JSON parser run, tool calls can appear broken. The format is different. + +What to do: + +1. Pass tools through `tokenizer.apply_chat_template(messages, tools=[...])` or the serving runtime's supported tool mechanism. +2. Parse the Pythonic call list between `<|tool_call_start|>` and `<|tool_call_end|>`. +3. On vLLM or SGLang, configure the LFM tool-call parser instead of a generic JSON parser. +4. Return results as `tool` role messages, with JSON content if useful. +5. For strict schemas, use constrained decoding. See [Constrained Generation](/deployment/on-device/sdk/constrained-generation). +6. If you fine-tune for tool calling, train on the native Pythonic format and convert to any internal DSL after parsing. + +## Migrating your fine-tuning pipeline + +LFMs are standard Hugging Face causal LMs, so TRL and Unsloth-style pipelines carry over with two LFM-specific corrections. + +First, update LoRA `target_modules`. LFM2 and LFM2.5 use a conv-attention hybrid with different module names than Llama-family models: + +```python +# LFM2 / LFM2.5 +target_modules = ["w1", "w2", "w3", "q_proj", "k_proj", "v_proj", "out_proj", "in_proj"] + +# Llama/Qwen/Gemma configs are wrong for LFMs: +# o_proj/gate_proj/up_proj/down_proj do not exist. +``` + +Before a long run, call `model.print_trainable_parameters()`. You should see millions of trainable parameters, and the LoRA module count should be in the expected range for your model size. If it is near zero, the module names are wrong. + +Second, format training examples with the LFM chat template. Training data formatted with your previous model's template creates a silent distribution mismatch. + +Everything else transfers directly: + +- [LEAP Finetune](https://github.com/Liquid4All/leap-finetune) for SFT, LoRA, DPO, GRPO, text, VLM, MoE, local, SLURM, Kubernetes, Modal, and GGUF export workflows +- Existing [TRL](/lfm/fine-tuning/trl) or [Unsloth](/lfm/fine-tuning/unsloth) setups +- Starting LoRA recipe: `r=16`, `alpha=32`, learning rate around `2e-4` to `3e-4`, 3 to 5 epochs, bf16 + +## Migration checklist + +### Serving swap + +- Runtime meets minimum version requirements +- Model ID swapped +- Chat template comes from the model +- Sampling updated for LFM defaults +- Tool parser configured if tool calling is in scope +- Context length validated against production p95 + +### Evaluation + +- Comparison stays within the same deployment class +- Latency and throughput measured at production prompt lengths and concurrency +- Quantized artifact evaluated if you plan to ship quantized + +### Fine-tuning + +- LoRA `target_modules` updated to LFM names +- Trainable-parameter count sanity-checked +- Training data reformatted with the LFM chat template +- Tool-call training data uses the native Pythonic format +- Held-out eval set frozen before training + +## Related docs + +- [Hardware Evaluation](/guides/hardware-evaluation) +- [Use Case Evaluation](/guides/use-case-evaluation) +- [Fine-tuning Overview](/lfm/fine-tuning/overview) diff --git a/guides/use-case-evaluation.mdx b/guides/use-case-evaluation.mdx new file mode 100644 index 0000000..ec73c4b --- /dev/null +++ b/guides/use-case-evaluation.mdx @@ -0,0 +1,49 @@ +--- +title: "Use Case Evaluation" +description: "Evaluate LFMs as drop-in replacements for an existing application or workflow." +--- + +Use this guide when you want to validate LFMs on an actual product task. The goal is to compare quality, latency, cost, and integration fit against the model you would otherwise deploy. + +## Recommended starter models + +- **Default:** [LFM2.5-1.2B-Instruct](https://huggingface.co/LiquidAI/LFM2.5-1.2B-Instruct) +- **Best quality:** [LFM2.5-8B-A1B](https://huggingface.co/LiquidAI/LFM2.5-8B-A1B) or [LFM2-24B-A2B](https://huggingface.co/LiquidAI/LFM2-24B-A2B) +- **Reasoning:** [LFM2.5-1.2B-Thinking](https://huggingface.co/LiquidAI/LFM2.5-1.2B-Thinking) +- **Tightest footprint:** [LFM2.5-350M](https://huggingface.co/LiquidAI/LFM2.5-350M) +- **Vision and audio:** [LFM2.5-VL-1.6B](https://huggingface.co/LiquidAI/LFM2.5-VL-1.6B) or [LFM2.5-Audio-1.5B](https://huggingface.co/LiquidAI/LFM2.5-Audio-1.5B) + +## Integration + +LFMs serve through OpenAI-compatible endpoints on [vLLM](/deployment/gpu-inference/vllm) and [SGLang](/deployment/gpu-inference/sglang), load in [Transformers](/deployment/gpu-inference/transformers), and run locally through [llama.cpp](/deployment/on-device/llama-cpp), [Ollama](/deployment/on-device/ollama), [MLX](/deployment/on-device/mlx), and [LM Studio](/deployment/on-device/lm-studio). + +Read these three pages before judging quality: + +- [Chat template](/lfm/key-concepts/chat-template): LFMs use a ChatML-style format. Always use `apply_chat_template` or the server's chat endpoint instead of hand-writing prompts. +- [Text generation and prompting](/lfm/key-concepts/text-generation-and-prompting): start from LFM sampling defaults instead of carrying over another model's generation parameters. +- [Tool use](/lfm/key-concepts/tool-use): LFMs emit a Pythonic tool-call format. If your harness assumes OpenAI-style JSON tool calls, read the [migration guide](/guides/migration-guide) first. + +## What to evaluate + +- **Task quality vs. your current model.** Compare against the model you would actually deploy, including its cost and latency class. +- **Latency and throughput under realistic workloads.** Measure your prompt lengths, output lengths, and concurrency. +- **Cost-performance.** Compare tokens per second per dollar at your traffic profile. +- **Structured output and tool calling.** Evaluate with the native format and constrained decoding where possible. + +A fair evaluation of a small model often includes a light fine-tune. Out of the box, a 1.2B model will trail a larger generalist on broad tasks. After task-specific fine-tuning, it can match or beat that larger model on your task at lower cost and latency. + +## Evaluation checklist + +- Production-like prompts and inputs selected +- Current production model or planned baseline selected +- Sampling parameters reset for LFM defaults +- Chat template generated by the tokenizer or serving runtime +- Tool parser updated if tool calling is in scope +- Latency measured at production p50 and p95 prompt lengths +- Held-out examples frozen before any fine-tuning + +## Related docs + +- [Complete Model Library](/lfm/models/complete-library) +- [Fine-tuning Overview](/lfm/fine-tuning/overview) +- [Migration Guide](/guides/migration-guide) diff --git a/lfm/fine-tuning/overview.mdx b/lfm/fine-tuning/overview.mdx new file mode 100644 index 0000000..a56460a --- /dev/null +++ b/lfm/fine-tuning/overview.mdx @@ -0,0 +1,51 @@ +--- +title: "Overview" +description: "Decide when to fine-tune an LFM and choose the right training workflow." +--- + +Fine-tuning is the next step when prompt changes, template fixes, constrained decoding, and better tool descriptions are not enough. Use it when the base model misses your task's semantic boundary or needs to learn a production-specific output style. + +## Before you fine-tune + +Exhaust the cheaper levers first: + +- Verify that prompts use the model's [chat template](/lfm/key-concepts/chat-template) +- Reset generation parameters using the [prompting guide](/lfm/key-concepts/text-generation-and-prompting) +- Use constrained decoding for strict JSON or grammar-bound outputs +- Improve tool descriptions and validate the native [tool-use format](/lfm/key-concepts/tool-use) +- Evaluate the right model size and deployment class with the [use case evaluation guide](/guides/use-case-evaluation) + +If the model still misses the task, fine-tune. + +## Recommended stack + +[LEAP Finetune](https://github.com/Liquid4All/leap-finetune) is Liquid's open-source training stack for the full customization loop: + +- SFT, LoRA, DPO, and GRPO +- Text, vision, and MoE model support +- Distributed training on local GPUs, SLURM, Kubernetes, or Modal +- Dataset formatting and validation +- GGUF export and quantization for deployment + +You can also use [TRL](/lfm/fine-tuning/trl) or [Unsloth](/lfm/fine-tuning/unsloth) directly if those already fit your workflow. + +## Typical workflow + +1. Load a base model from Hugging Face. Start from the current LFM2.5 checkpoint for your target size. +2. Prepare 500 to 5,000 task examples. Quality and distribution matter more than volume; match production inputs. +3. Train with LoRA for the first pass. A 1.2B LoRA run can take minutes to tens of minutes on a single modern GPU. +4. Evaluate on a held-out set that you froze before training. +5. Iterate on data, prompts, and hyperparameters before scaling to larger runs. + +## Two rules that save the most pain + +Train with the model's own chat template. Use `apply_chat_template` and keep training formatting character-for-character identical to production. + +For tool calling, train on the native Pythonic tool-call format. The [migration guide](/guides/migration-guide) explains how LFMs differ from OpenAI-style JSON tool calls and how to adapt parsers safely. + +## Fine-tuning docs + +- [LEAP Finetune](/lfm/fine-tuning/leap-finetune) +- [Datasets](/lfm/fine-tuning/datasets) +- [TRL](/lfm/fine-tuning/trl) +- [Unsloth](/lfm/fine-tuning/unsloth) diff --git a/link-snapshot.yaml b/link-snapshot.yaml index f10ad5b..5885348 100644 --- a/link-snapshot.yaml +++ b/link-snapshot.yaml @@ -110,10 +110,14 @@ active: - /examples/web/audio-webgpu-demo - /examples/web/hand-voice-racer - /examples/web/vl-webgpu-demo + - /guides/hardware-evaluation + - /guides/migration-guide + - /guides/use-case-evaluation - /leap/edge-sdk/overview - /lfm/fine-tuning - /lfm/fine-tuning/datasets - /lfm/fine-tuning/leap-finetune + - /lfm/fine-tuning/overview - /lfm/fine-tuning/trl - /lfm/fine-tuning/unsloth - /lfm/getting-started/connect-ai-tools diff --git a/scripts/generateLinkSnapshot.ts b/scripts/generateLinkSnapshot.ts index cb93fa4..f9a701e 100644 --- a/scripts/generateLinkSnapshot.ts +++ b/scripts/generateLinkSnapshot.ts @@ -32,7 +32,7 @@ const DELETED_EXAMPLE = ` deleted: // Directories whose .mdx/.md files map to docs URLs. snippets/ is excluded // because it holds reusable fragments, not pages. -const PAGE_DIRS = ['lfm', 'leap', 'examples', 'deployment']; +const PAGE_DIRS = ['lfm', 'guides', 'leap', 'examples', 'deployment']; interface DocsJson { navigation?: { tabs?: NavNode[] }; diff --git a/style.css b/style.css index 4aa63cf..95cd70d 100644 --- a/style.css +++ b/style.css @@ -597,6 +597,55 @@ table:has(thead th:nth-child(7):not(:nth-child(8))) td:first-child a:hover { color: #86efac !important; } +/* Normal table links - match model-name link treatment, not green checkmarks. */ +:root:not(.dark) table:not(:has(thead th:nth-child(6))) a { + display: inline-block !important; + color: inherit !important; + font-weight: 500 !important; + line-height: 1.25 !important; + padding: 0.2rem 0.35rem !important; + margin: 0.05rem 0.1rem 0.05rem -0.35rem !important; + border-radius: 4px !important; + background-image: none !important; + background-color: transparent !important; + border-bottom: 0 !important; + box-shadow: 0 1px 0 #864bc4 !important; + text-decoration: none !important; + text-decoration-line: none !important; + transition: background-color 0.15s ease, color 0.15s ease, box-shadow 0.15s ease !important; +} + +:root:not(.dark) table:not(:has(thead th:nth-child(6))) a:hover { + color: #864bc4 !important; + background-color: rgba(134, 75, 196, 0.1) !important; + background-image: none !important; + box-shadow: 0 1.5px 0 #864bc4 !important; +} + +.dark table:not(:has(thead th:nth-child(6))) a { + display: inline-block !important; + color: inherit !important; + font-weight: 500 !important; + line-height: 1.25 !important; + padding: 0.2rem 0.35rem !important; + margin: 0.05rem 0.1rem 0.05rem -0.35rem !important; + border-radius: 4px !important; + background-image: none !important; + background-color: transparent !important; + border-bottom: 0 !important; + box-shadow: 0 1px 0 #a78bfa !important; + text-decoration: none !important; + text-decoration-line: none !important; + transition: background-color 0.15s ease, color 0.15s ease, box-shadow 0.15s ease !important; +} + +.dark table:not(:has(thead th:nth-child(6))) a:hover { + color: #a78bfa !important; + background-color: rgba(167, 139, 250, 0.15) !important; + background-image: none !important; + box-shadow: 0 1.5px 0 #a78bfa !important; +} + /* Code block styling - ensure visible background contrast */ /* Inline code */ :root:not(.dark) code:not(pre code) {