AI Interview Questions

A small language model (SLM) is a language model with significantly fewer parameters than large models, typically ranging from 100 million to 7 billion parameters, compared to LLMs with 70 billion to 1 trillion+ parameters. There's no strict threshold, but SLMs are designed for efficiency, speed, and deployment on resource-constrained devices.

SLMs achieve smaller size through: 1) Fewer layers and smaller hidden dimensions. 2) More aggressive parameter sharing (e.g., ALBERT). 3) Distillation - training small model to mimic larger one. 4) Pruning - removing less important weights. 5) Quantization - using lower precision. Despite smaller size, SLMs can perform well on specific tasks through focused training and fine-tuning. They're often used for on-device applications, real-time inference, and cost-sensitive deployments.

SLMs democratize AI by making it accessible on edge devices (phones, laptops), reducing cloud dependency, and lowering costs. They offer: 1) Privacy - data stays on device. 2) Latency - no network calls. 3) Cost - no API fees. 4) Energy efficiency - lower compute. 5) Offline capability. For many tasks, SLMs are sufficient, making them a practical alternative to massive LLMs.

Microsoft's Phi-3 (3.8B) runs on a smartphone, providing coding assistance offline. Compare to GPT-4 (est. 1.8T) which requires cloud servers. For code completion on a plane, Phi-3 works; GPT-4 doesn't. SLM makes AI ubiquitous, not just cloud-based.

Several notable SLMs have emerged, each with different strengths: Microsoft Phi-3 (3.8B) excels at reasoning despite small size; Mistral 7B balances performance and efficiency; Google Gemma (2B, 7B) is optimized for accessibility; Meta Llama 3.2 (1B, 3B) targets edge devices.

Phi-3: Trained on high-quality synthetic data, achieves GPT-3.5-level performance at 3.8B parameters. Mistral 7B: Uses grouped-query attention and sliding window attention for efficiency, outperforming larger models on many benchmarks. Gemma: Built from same research as Gemini, optimized for responsible deployment, available in 2B and 7B sizes. Llama 3.2: Smallest Llama models, designed for on-device use with 1B and 3B parameters, supporting edge applications.

The proliferation of capable SLMs gives developers choices based on their constraints: need smallest possible (Llama 3.2 1B), best performance within 7B (Mistral), or surprising reasoning (Phi-3). This diversity enables optimization for specific use cases, hardware, and cost requirements.

Mobile app developer needs on-device summarization. Llama 3.2 1B fits in 500MB RAM, runs at 20 tokens/s on phone. For server-side cost-sensitive app, Mistral 7B on CPU provides good performance at fraction of GPT-4 cost. Researcher needing reasoning on limited hardware chooses Phi-3. Each SLM serves different needs.

For enterprise deployment, SLMs offer compelling advantages over large models: lower cost, faster inference, easier compliance, and simpler infrastructure. These often outweigh the slight quality trade-off for many business applications.

Advantages: 1) Cost - self-hosted SLMs have no per-token fees; cloud costs are 10-100x lower than API-based LLMs. 2) Latency - SLMs can run on CPU, reducing network latency to zero. 3) Privacy - data never leaves enterprise control, crucial for regulated industries. 4) Compliance - easier to audit and certify. 5) Customization - can be fine-tuned on proprietary data without API restrictions. 6) Predictability - fixed infrastructure cost, no usage surprises. 7) Offline capability - works without internet.

Enterprises often have thousands of daily queries. At scale, API costs become significant. A single GPT-4 query might cost $0.05; 1M queries/month = $50,000. Self-hosted SLM might cost $1,000 in compute. For many tasks (classification, extraction, summarization), SLM performance is sufficient, making the cost difference compelling.

Insurance company processes 10,000 claims daily with AI. Using GPT-4: 10,000 × $0.10 = $1,000/day = $365,000/year. Using fine-tuned Mistral 7B on 2 GPUs: $2,000/month = $24,000/year. 94% cost savings. Quality difference: 92% vs 95% accuracy - acceptable trade-off. SLM wins.

On-device inference means running AI models directly on user devices (phones, laptops, tablets) rather than in the cloud. SLMs enable this because their smaller size allows them to fit in device memory and run within device compute constraints.

On-device inference requires: 1) Small model size - typically under 7B parameters, often 1-3B. 2) Quantization - 4-bit or 8-bit to reduce memory. 3) Optimized runtimes - ExecuTorch, MLX, TFLite, Core ML. 4) Hardware acceleration - use NPU, GPU when available. Benefits: zero latency (no network), privacy (data never leaves device), offline capability, and no cloud costs. Challenges: battery consumption, thermal limits, and device fragmentation.

On-device AI transforms user experience. Imagine a personal assistant that works on airplane mode, with instant responses, and complete privacy. It also reduces cloud dependency and costs. SLMs make this possible - a 1B model quantized to 4-bit is ~500MB, fitting on modern phones.

Google's Pixel phone with on-device Gemini Nano: user dictates a message, transcription happens instantly on device, no internet needed. Private, fast, free. Without SLM, would need cloud connection, adding latency and privacy concerns. On-device inference powered by SLMs enables this.

Edge deployment refers to running AI models on edge devices close to where data is generated (IoT devices, cameras, gateways) rather than in the cloud. SLMs enable this by fitting within the strict compute, memory, and power constraints of edge hardware.

Edge devices (Raspberry Pi, NVIDIA Jetson, smartphones, cameras) have limited resources: 1-8GB RAM, limited CPU/GPU, battery power. SLMs (1-7B) quantized to 4-bit can run on these devices. Use cases: 1) Smart cameras - real-time object detection and description. 2) Industrial IoT - predictive maintenance with on-device analysis. 3) Healthcare - portable diagnostic devices. 4) Automotive - in-car voice assistants. 5) Retail - in-store inventory management. Benefits: low latency, privacy, offline operation, reduced bandwidth.

Many applications can't rely on cloud: factories may have poor connectivity, medical devices require privacy, autonomous vehicles need instant response. Edge deployment with SLMs brings AI to these scenarios, expanding AI's reach beyond internet-connected devices.

Agricultural drone monitors crops, uses on-device SLM to analyze images and detect diseases in real-time, even without cellular connection. Results stored locally, uploaded when connectivity available. Without edge SLM, would need cloud connection (often unavailable in fields) or store all images for later analysis (delayed response). Edge deployment enables immediate action.

Mistral 7B and GPT-4 represent different points on the size-performance curve. Mistral is a 7B parameter open-source model; GPT-4 is a proprietary model estimated at 1.8T parameters. The trade-offs span quality, cost, speed, and control.

Quality: GPT-4 generally outperforms Mistral on complex reasoning, multilingual tasks, and nuanced understanding. Mistral performs surprisingly well, often matching GPT-3.5 on many tasks, and can be fine-tuned for specific domains. Cost: Mistral self-hosted has zero per-query cost after infrastructure; GPT-4 costs $0.01-0.10 per query. Speed: Mistral on GPU can generate 50+ tokens/s; GPT-4 API typically 10-30 tokens/s. Control: Mistral can be fine-tuned, modified; GPT-4 is a fixed black box.

Choice depends on application. For high-stakes, complex reasoning where quality paramount and budget sufficient, GPT-4 wins. For high-volume, cost-sensitive applications where Mistral's quality is sufficient, SLM wins. Many applications (classification, extraction, basic QA) fall into the latter.

Legal contract analysis: need deep understanding, nuance, rare clauses - GPT-4's quality justifies its cost. Customer support FAQ: Mistral 7B fine-tuned on company data achieves 95% accuracy vs GPT-4's 97% - 2% difference not worth 20x cost. Trade-off analysis guides choice.

Model distillation is a technique where a smaller 'student' model is trained to mimic the behavior of a larger 'teacher' model. The student learns from the teacher's outputs (soft labels) rather than just ground truth, capturing the teacher's knowledge and reasoning patterns.

Process: 1) Teacher model (e.g., GPT-4) generates outputs on a large dataset. For each input, teacher produces probability distributions over vocabulary (soft targets) containing rich information about relationships between classes. 2) Student model (e.g., 7B) is trained to match these soft targets via KL divergence loss, often combined with standard cross-entropy on ground truth. Temperature scaling smooths distributions to emphasize relationships. The student learns not just correct answers but the teacher's reasoning patterns and uncertainty estimates. Multiple teacher models can be ensembled. Distillation can reduce model size by 10-100x while retaining much of the teacher's capability.

Distillation is the primary method for creating high-performance SLMs. It transfers capabilities from massive, expensive models to small, efficient ones. Models like Phi-3, DistilBERT, and MiniLM are created via distillation. This democratizes access to near-SOTA performance in small packages.

Microsoft used GPT-4 to generate millions of high-quality reasoning examples, then trained Phi-3 (3.8B) on this data. Result: Phi-3 achieves GPT-3.5-level performance at 1/50th the size. Without distillation, training such a capable small model from scratch would require enormous compute and data. Distillation makes SLMs possible.

Fine-tuning an SLM on a specific task can dramatically improve its performance, sometimes matching or exceeding larger general-purpose models on that task. This is because the SLM becomes highly specialized, while larger models remain generalists.

Process: 1) Collect task-specific data - e.g., 10k customer support Q&A pairs. 2) Choose base SLM (Mistral 7B, Llama 3.2 3B). 3) Fine-tune using techniques like QLoRA for efficiency. 4) Evaluate on held-out test set, compare to larger model (GPT-4). 5) Iterate with more data or different hyperparameters. The fine-tuned SLM learns domain-specific patterns, terminology, and output formats that the general model may not prioritize. It can also learn to avoid common errors in that domain.

A fine-tuned SLM can outperform GPT-4 on a specific task at a fraction of the cost. This is the killer app for SLMs: they become specialized experts. For many enterprise applications, this is the optimal approach - best of both worlds: high performance, low cost.

Medical coding: fine-tune Mistral 7B on 50k clinical notes with ICD-10 codes. Result: 92% accuracy on test set. GPT-4 zero-shot: 88% accuracy. Fine-tuned SLM beats GPT-4 on this specific task, at 1/100th the cost per query. This is why enterprises are adopting SLMs for domain-specific tasks.

Quantization reduces model precision (e.g., from 16-bit to 4-bit) to shrink model size and speed up inference, enabling deployment on resource-constrained devices. For SLMs, quantization is often essential to fit within memory limits.

Common quantization formats: 1) FP16/BF16 - half precision, 2x reduction, minimal quality loss. 2) INT8 - 8-bit integer, 4x reduction, small quality loss. 3) INT4 - 4-bit, 8x reduction, moderate quality loss. 4) GGUF - format with multiple quantization options (Q2, Q3, Q4, Q5, Q6, Q8) allowing trade-off between size and quality. 5) GPTQ - post-training quantization for GPU inference. 6) AWQ - activation-aware quantization, better quality at same bit. Choice depends on hardware: CPU inference often uses GGUF; GPU uses GPTQ/AWQ. Quantization can reduce 7B model from 14GB (FP16) to 3.5GB (INT4), fitting on many edge devices.

Without quantization, SLMs may not fit on target hardware. A 7B model at FP16 requires 14GB RAM - too much for phone or edge device. At INT4, 3.5GB fits. Quantization makes SLMs deployable. The quality trade-off is often acceptable (1-3% accuracy drop) for the deployment gains.

Deploying Llama 3.2 3B on Raspberry Pi 5 (8GB RAM). FP16: 6GB model + overhead = too large. Q4_K_M GGUF: 2.5GB, fits, runs at 5 tokens/s. Quality: perplexity increases from 6.5 to 7.0 - barely noticeable. Quantization enabled deployment that would otherwise be impossible.

The Phi series (Phi-1, Phi-1.5, Phi-2, Phi-3) are small language models from Microsoft Research that achieve remarkable performance through training on high-quality synthetic data rather than scale. Their philosophy: data quality > data quantity.

Phi models are trained on carefully curated, textbook-quality data, often generated by larger models. For example, Phi-1 was trained on 50B tokens of Python code filtered for quality. Phi-3 used 3.3T tokens of synthetic data designed to teach reasoning, common sense, and knowledge. The key insight: most web data is noisy and repetitive. By using high-quality synthetic data, small models can learn efficiently without needing massive scale. This challenges the scaling laws paradigm that more data always helps.

Phi shows that with clever data curation, small models can achieve surprising capabilities. Phi-3-mini (3.8B) rivals GPT-3.5 on many benchmarks. This has profound implications: maybe we don't need trillion-parameter models for many tasks. It also opens new research directions: how to generate optimal training data.

Phi-3 trained on synthetic textbook-like data: lessons on reasoning, step-by-step explanations, high-quality Q&A. Result: outperforms much larger models on reasoning tasks. A user asks a logic puzzle, Phi-3 solves it correctly where 7B models trained on web data fail. Data quality, not just size, matters.

GGUF (GPT-Generated Unified Format) is a file format designed for efficient storage and execution of quantized LLMs, particularly optimized for CPU inference on consumer hardware. It enables running SLMs on laptops without GPUs.

GGUF stores models with advanced quantization (2-8 bits) using techniques like k-quants that adapt precision based on parameter importance. The format is designed for memory mapping - instead of loading entire model into RAM, the operating system can load pages on-demand as needed. It includes metadata about architecture, tokenizer, and quantization parameters. Inference engines like llama.cpp read GGUF files and execute optimized CPU kernels (AVX, NEON, CUDA) for matrix multiplication. This enables running models on laptops, phones, and servers without dedicated GPUs.

GGUF democratizes SLM deployment. A 7B model quantized to 4-bit is ~4GB - fits in RAM of any modern laptop. CPU inference runs at 5-20 tokens/s - usable for many applications. This eliminates GPU dependency, reducing cost and enabling edge deployment. GGUF's memory-mapping allows running models larger than RAM (slow but possible).

Developer runs Mistral 7B on 2020 MacBook Air. Downloads GGUF 4-bit file (3.8GB). Launches llama.cpp, gets 8 tokens/s generation - sufficient for chat, summarization, coding help. No GPU, no cloud costs. This accessibility enables private, offline AI applications. GGUF is why local SLMs are viable.

Ollama is a user-friendly tool for running large language models locally on macOS, Linux, and Windows. It packages models (mostly SLMs) in an easy-to-use interface, handling download, quantization, and inference.

Ollama provides: 1) Model library - one-command download of popular SLMs (Llama 3.2, Mistral, Phi, Gemma). 2) Quantization - automatically uses efficient formats (GGUF). 3) API server - local REST API compatible with OpenAI. 4) CLI - simple commands like ollama run llama3.2. 5) Integration - works with LangChain, Continue.dev, and other tools. It handles the complexity of model loading, context management, and hardware acceleration, making local SLMs accessible to non-experts.

Before Ollama, running local models required technical expertise: finding models, converting formats, setting up inference engines. Ollama democratizes local AI, making it as easy as using cloud APIs. This accelerates adoption of SLMs for development, prototyping, and production.

Developer wants to prototype an app with local LLM. Instead of spending days setting up, they run ollama pull mistral and ollama run mistral. In minutes, they have a local API. App connects to localhost:11434 and uses Mistral. Rapid prototyping enabled. Without Ollama, would likely just use cloud API out of convenience.

Synthetic data is artificially generated data, often created by larger models, used to train SLMs. It plays a crucial role in creating capable small models by providing high-quality, diverse, and targeted training examples that may not exist in natural corpora.

Process: 1) Use a powerful teacher model (GPT-4, Claude) to generate examples for desired tasks: Q&A pairs, reasoning chains, code explanations, instruction following. 2) Filter and curate generated data for quality, diversity, and correctness. 3) Train SLM on this synthetic dataset, often combined with some real data. Benefits: can generate unlimited examples, control distribution, focus on specific capabilities, and avoid noise of web data. Phi series heavily uses synthetic data. Risks: model collapse if overused without real data, potential bias propagation.

Synthetic data enables SLMs to punch above their weight. A 3B model trained on high-quality synthetic data can outperform a 7B model trained on web data. It allows creating specialized datasets for tasks where real data is scarce. As models improve, synthetic data quality improves, creating a flywheel.

Phi-3 trained on 3.3T tokens of synthetic data generated by GPT-4: textbooks, exercises, dialogues, reasoning examples. Result: outperforms models trained on much larger web corpora. Synthetic data provided focused, high-quality learning material that web data lacks. This is why Phi-3 is so capable for its size.

Running SLMs locally keeps all data on the user's device, never transmitted to external servers. This provides complete privacy, as sensitive information (personal messages, documents, medical records) never leaves user control.

With cloud LLMs, every query is sent to provider servers, where it may be logged, used for training, or potentially accessed by third parties. Even with privacy policies, data leaves user control. Local SLM: 1) No data transmission - everything stays on device. 2) No logging by third parties. 3) Can work offline. 4) Compliant with strict data regulations (HIPAA, GDPR) without complex agreements. 5) Users have full control over deletion. The trade-off is potentially lower quality, but for many applications, privacy outweighs quality differences.

Privacy is paramount for many applications: healthcare (patient records), legal (confidential documents), enterprise (proprietary information), and personal (private conversations). Cloud LLMs pose risks of data leakage, subpoenas, or breaches. Local SLMs eliminate these risks, making AI viable for sensitive domains.

Law firm cannot send client documents to OpenAI due to confidentiality. They deploy local Mistral 7B on their own servers. All processing stays within their network, fully compliant with legal ethics rules. They get AI assistance without privacy risk. This would be impossible with cloud LLMs. Local SLMs enable AI in regulated industries.

Recommend an SLM when the use case prioritizes cost, privacy, latency, or offline capability over absolute peak performance, and when the task is narrow enough that an SLM can be fine-tuned to meet requirements.

Decision criteria for SLM: 1) Cost sensitivity - high-volume applications where API costs would be prohibitive. 2) Privacy requirements - data cannot leave premises. 3) Latency requirements - need real-time response without network. 4) Offline operation - must work without internet. 5) Task specificity - narrow, well-defined task where fine-tuning can achieve high performance. 6) Control - need ability to modify model behavior. 7) Predictable costs - fixed infrastructure vs variable API fees. 8) Regulatory compliance - data sovereignty requirements.

Many organizations default to large proprietary models without considering alternatives. This leads to unnecessary costs, privacy risks, and vendor lock-in. SLMs offer a compelling alternative for a wide range of applications. Understanding when to choose SLM enables cost-effective, privacy-preserving AI.

Healthcare chatbot for patient intake: high privacy requirements, moderate complexity, high volume. Cloud LLM: privacy concerns, $0.10 per conversation × 10,000/day = $1,000/day. SLM: fine-tuned Mistral 7B on-premise, $500/month fixed cost, privacy guaranteed, 95% of cloud quality. SLM clearly wins. For creative writing assistant where quality paramount and volume low, cloud LLM may be better. Context matters.

Benchmarking SLMs requires creating task-specific evaluation sets that reflect real-world usage, rather than relying solely on general benchmarks (MMLU, HellaSwag). This ensures the chosen SLM actually meets your application's needs.

Process: 1) Define task requirements - what does the model need to do? (classification, extraction, generation, reasoning). 2) Create evaluation dataset - collect 500-1000 representative examples from your domain with ground truth. 3) Select candidate SLMs (Phi-3, Mistral, Llama 3.2, Gemma) in various sizes. 4) Run each model on evaluation set (possibly with quantization options). 5) Measure metrics: accuracy, F1, ROUGE, etc., as appropriate. 6) Also measure latency, memory usage, and cost. 7) Compare results to decide which model meets requirements at acceptable resource usage. 8) Consider fine-tuning potential - base performance may improve with fine-tuning.

General benchmarks don't predict domain performance. A model that scores high on MMLU may fail on your specific task. Task-specific benchmarking reveals true capabilities and guides model selection. It also sets realistic expectations for performance.

Legal contract classification task. Test Phi-3, Mistral, Llama 3.2 on 500 legal documents. Results: Phi-3 92% accuracy, Mistral 94%, Llama 3.2 89%. Mistral wins but uses 2x memory. If memory constrained, Phi-3 good enough. Without benchmarking, might pick Llama based on general benchmarks and get 89% instead of 94%. Benchmarking drives optimal choice.

Speculative decoding uses a fast SLM (draft model) to generate candidate tokens, which are then verified in parallel by a larger target model. This technique speeds up inference of large models by leveraging the SLM's speed and the target model's ability to verify multiple tokens at once.

Process: 1) Draft model (e.g., 100M parameters) autoregressively generates K candidate tokens (typically 3-5). 2) Target model (e.g., 70B) computes a single forward pass over all K candidates in parallel, obtaining its own probability distributions. 3) System determines longest prefix where target model agrees with draft model's predictions, accepting those tokens. If disagreement at position i, resamples using target model's distribution and discards remaining candidates. This verifies multiple tokens per target forward pass. Speedup depends on draft model speed and acceptance rate (how often draft is correct).

Speculative decoding can achieve 2-3× speedup in generation latency without quality loss. It's particularly effective when draft model is much faster than target (10-20×) and acceptance rate high (60-80%). This technique makes large models more practical for latency-sensitive applications.

Serving 70B model with 100M draft model. Without speculation: 100 tokens × 50ms = 5000ms latency. With speculation (K=5, acceptance rate 70%): target forward passes ≈ 100/(5×0.7) ≈ 29 passes × 50ms = 1450ms. Draft runs 29×5×2ms = 290ms. Total 1740ms - 2.9× speedup. User perceives faster responses. Quality identical because target verifies all accepted tokens.

SLMs offer dramatic cost savings compared to large proprietary models, especially at scale. The savings come from zero per-query fees, efficient hardware usage, and the ability to run on cheaper infrastructure (CPU vs GPU).

Cost comparison: Cloud LLM (GPT-4): $10-30 per 1M tokens. Self-hosted SLM on GPU: ~$0.50 per 1M tokens (amortized hardware + electricity). Self-hosted SLM on CPU: ~$0.10 per 1M tokens. For 1M queries/day at 1000 tokens each: GPT-4 = $10,000-30,000/day. SLM on GPU = $500/day. SLM on CPU = $100/day. Annual savings: $3.6M to $10M. Additional savings: no data transfer costs, predictable budgeting, ability to scale horizontally with cheap instances.

For high-volume applications, cost is a primary driver. SLMs make AI economically viable at scale. A startup couldn't afford GPT-4 for 1M daily users; they could afford SLMs. This democratizes AI for high-traffic applications.

Social media platform with 10M daily active users, each making 10 AI requests (sentiment analysis, content moderation). Cloud LLM: 100M requests × 200 tokens × $0.02/1K = $400,000/day = $146M/year. SLM on dedicated GPU cluster: $50,000/month = $600,000/year. 99.6% cost reduction. SLM makes this use case viable; cloud LLM would be prohibitively expensive.

SLMs have inherent limitations compared to larger models due to their smaller capacity. They may struggle with complex multi-step reasoning, nuanced instruction following, handling ambiguity, and tasks requiring broad world knowledge.

Limitations manifest in: 1) Reasoning depth - may miss steps in complex chains, especially with multiple constraints. 2) Knowledge breadth - less memorized facts, especially rare or recent information. 3) Instruction following - may misinterpret nuanced instructions, especially with multiple parts. 4) Context utilization - smaller attention capacity may miss information in long contexts. 5) Creativity - may produce less varied or original outputs. 6) Multilingual performance - weaker in low-resource languages. 7) Safety alignment - may be more vulnerable to jailbreaks. These stem from fewer parameters, less training data, and simpler architectures.

Understanding limitations prevents over-reliance on SLMs for tasks beyond their capability. For complex reasoning (scientific research, advanced coding), larger models still needed. For many business tasks (classification, extraction, simple QA), SLMs sufficient. Knowing the boundary guides appropriate use.

Legal analysis requiring interpretation of multiple precedents and statutes: SLM may miss connections, oversimplify. GPT-4 more reliable. For summarizing a straightforward document, SLM fine-tuned on legal texts works well. Task complexity determines model choice. SLMs excel in their zone, fail outside it.

Building a product strategy around SLMs for privacy-sensitive applications involves leveraging their on-device or on-premise deployment capabilities to offer features that cloud-based competitors cannot, creating competitive advantage through privacy.

Strategy elements: 1) Privacy as feature - market 'your data never leaves your device' as key differentiator. 2) Offline capability - product works without internet, appealing for travel, remote areas. 3) No subscription fees - one-time purchase or device-bound license, not ongoing API costs. 4) Customization - allow users to fine-tune on their own data without privacy concerns. 5) Vertical integration - build for specific industries (healthcare, legal) with compliance certifications. 6) Hybrid approach - use SLM for most tasks, offer cloud LLM for complex tasks with explicit user consent and clear privacy disclosures.

Privacy is becoming a competitive advantage. Many users are uncomfortable with cloud AI. SLMs enable privacy-preserving products that can't be replicated by cloud-only competitors. This opens new markets and builds trust.

Health journal app with AI insights. Competitors use cloud LLMs, sending sensitive health data to servers. Our app uses on-device SLM (Phi-3). Marketing: 'Your health data never leaves your phone.' Works offline. One-time purchase $20. Appeals to privacy-conscious users. No recurring cloud costs. This strategy leverages SLM's unique advantages to create differentiated product.