Loading…
Topic
24 posts about Cost Optimization. Every summary links to the original.
See the idea
AWS Glue runs serverless Spark jobs that transform data in batches; engine-native pipelines transform during ingestion. This comparison shows how to pick between them by freshness, cost, and data fidelity.
A five-checkpoint workflow for keeping BigQuery in the right lane: land and shape data once, tune partitions and history windows, and federate instead of copying.
A benchmark can support two different verdicts: pass@1 on the first attempt, or pass@k with retries measured as cost per solved task. This comparison shows which reading matches your workload.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
PostgreSQL’s ACID guarantees cause substantial write amplification: each write flushes WAL for durability, copies rows via MVCC for isolation, and updates every affected index, amplifying 100 bytes of row change into tens of kilobytes of I/O. Costs scale linearly with data size, and even sharded Postgres offers only linear scaling with added coordination overhead, so growing datasets drive rising bills. The post proposes offloading settled, rarely-changing data to ClickHouse, whose columnar compression shrinks datasets 10-30x and whose cloud offering costs about 5x less than comparable Postgres infrastructure while also reducing Postgres compute load through fewer indexes. ClickHouse builds indexes in background batches and runs aggregations at roughly 100x lower cost than Postgres. ClickHouse Cloud provides WalShadow for millisecond-latency CDC and pg_clickhouse FDW, enabling an application pattern that cuts the cost of serving settled data by an order of magnitude.
The post describes design tradeoffs and workarounds encountered while building the open-source Bulk Executor tool for Amazon DynamoDB on AWS Glue. Core requirements included real-time local-script feel, scaling to hundreds of parallel workers without user infrastructure management, and easy command extensibility. AWS Glue was chosen for serverless parallelism and a built-in DynamoDB connector, but the connector simplified data types, losing distinctions like string set versus list of strings. Challenges included estimating costs for provisioned tables, handling job termination with ^C, and streaming output via CloudWatch Live Tail which samples events and delivers out-of-order. Solutions included a two-phase cost estimate for deletes, programmatic interrupt handling, writing large output to S3 with a preview, mandating point-in-time recovery for mutating commands, and using AI for testing and linting; the team also migrated from AWS Glue 4 to 5 and 6 for faster startup and 30 percent lower DPU costs.
Level 5 covers operability for LLM systems: daily running, cost control, provider outage survival, and fast shutdown on misbehavior. A single gateway funnels all model traffic, measuring cost, routing requests, enabling failover, and hosting an instantaneous kill switch; a shared decision_id threads metrics, logs, traces, and the audit ledger. Observability supplements RED metrics with a decision layer capturing auto vs. human splits, guardrail blocks, judge disagreements, token spend per tenant and capability, and shadow-eval pass ratios via tiered structured logs. Cost controls attribute spending at the gateway per tenant and capability, with hard budget ceilings; optimization follows order: skip model, batch, cache, right-size, trim—each step profiled against quality. The platform spine includes stateless agent services, the gateway, an audit datastore, cache, secrets store, and object storage—scoped with least-privilege IAM and encryption, avoiding queues or vector stores until warranted.
Salesforce Data 360 processes about eight million Apache Spark executions daily, where successful completion alone does not confirm efficient resource use. The team instrumented the shared Data Processing Controller (DPC) gateway with a DataFlint Spark listener plugin to capture per-executor CPU, memory, shuffle, and zero-task metrics without application code changes. Metrics stream through Kafka into an Iceberg lakehouse, and a curated Silver analytic layer ensures analysis uses only complete, comparable runs and correctly handles retries and missing data. Investigation revealed workloads that repeatedly allocated executors performing zero tasks, enabling targeted reductions like lowering initial executors from forty to four. After staged production rollout monitored for runtime, spill, retries, and platform pressure, weekly compute-cost run rate fell 31% while DPC job starts grew over 7%.
Reactive cost management for cloud data warehouses fails because usage is unattributed, budgets are absent, and alerts arrive too late. Databricks’ proactive framework addresses this through five pillars: cost attribution via warehouse and query tags, layered budgets with email alerts, real-time dashboards, and optimizations. SQL Serverless warehouses eliminate idle compute costs, as Lumen Technologies demonstrated with a 30-40% reduction. Query tags (Public Preview) enable per-query attribution, linking spend to specific dashboards or dbt models. The post provides step-by-step instructions for tagging, budget creation in the Account Console, and tuning auto-stop and statement timeouts to reduce waste.
Lakebase uses separated storage and compute to reduce costs: branches share storage, autoscaling matches compute to demand, and scale to zero suspends compute after inactivity. Read replicas and high availability add compute without duplicating storage. For synced tables from Lakehouse, sync only the active working set via materialized views and choose the appropriate sync mode—snapshot for volatile data, triggered for incremental, continuous for real-time—and binpack tables into one pipeline to share compute. Right-size initial compute by focusing on the working set, and set PITR retention and snapshot schedules based on actual recovery needs. Snapshot storage is priced at $0.090/GB-month and PITR storage at $0.200/GB-month, both cheaper than regular branch storage. Compute and storage usage can be tracked through system.billing.usage, with separate SKUs for compute, branch storage, PITR, and snapshots.
Cloudflare AI Gateway’s User Insights now provides context beyond model names and request counts, using a dedicated Worker to classify conversations by task type such as coding, research, summarization, or formatting. The “model overkill” view identifies conversations where a high-capability reasoning model is used for simple tasks, showing which users or agents are driving that usage and the associated cost. Teams can analyze conversation turns to see how many back-and-forth exchanges a task requires, helping uncover inefficiencies in prompts or workflows. The Potential Savings view and Auto Router (closed beta) use task and model-fit signals to automatically route requests to appropriate models without a separate rule for each workload. These features are free for AI Gateway users and require stable user_id and session_id for analysis, with optional Access integration.
Databricks provides 12,000 employees Day 1 access to new frontier models through a pipeline using Unity Gateway for governance, cost management, and observability. New models are immediately made available on an experimental basis with per-user budgets to control costs and mitigate risk from models that may not be on the efficiency frontier. Budgets include monthly maximum, daily runaway limit, quality frontier budget, and experimental budget, with configurations pushed via Unity Gateway CLI running on employee laptops. After three days, Databricks evaluates models using benchmark data, user-reported quality, and cost tracking via OpenTelemetry traces to decide whether to promote the model. Opus 5.5 was promoted as higher quality and lower cost than predecessors, while GPT-6 Sol was included in the smart router due to its cost advantage over GPT-5.6 Sol.
Databricks provides employees Day 1 access to new AI models using Unity Gateway for governance and cost management. The company uses a three-step pipeline: immediate experimental availability, per-user budget constraints, and data-driven promotion decisions. Unity Gateway CLI distributes model configurations to employee laptops, tagging new models as experimental. Per-user budgets include a monthly maximum, daily runaway limit, quality frontier budget, and experimental budget to control costs. Within three days of the Opus 5.5 and GPT-6 Sol launches, Databricks gathered benchmark, user feedback, and cost data to confirm they were on the efficiency frontier and promoted them, with Opus 5.5 showing a 29% cost reduction per session over Opus 4.8 and GPT-6 Sol showing a 48% reduction over GPT-5.6 Sol.
Organizations face a challenge as new frontier models appear roughly every five days, making it difficult to balance flexibility with governance. Databricks introduces the Unity Gateway CLI, which lets admins centrally configure approved coding agents, models, MCP servers, skills, and spending policies. Developers launch any approved agent with a single ug command, and the CLI handles authentication and applies the published settings. Features include Smart Routing that selects cost-appropriate models per task, budget-aware defaults that switch to lower-cost options as spending thresholds are reached, and tracing to capture tool calls and skill invocations for waste analysis. In internal use, the system processed over 61 billion input tokens across roughly 360,000 requests, and tracing helped identify bugs that saved an estimated 1.2 million per year.
Together GPU Clusters is introducing preemptible compute in public preview for Kubernetes clusters in all regions, offering interruptible GPU capacity at a flat 50% of the on-demand rate. Preemptible nodes use the same NVIDIA accelerated compute, can be reclaimed when unused capacity is needed, and receive a maximum five-minute drain window for checkpointing and graceful exit. Clusters retain the requested preemptible target and automatically refill as capacity returns, while usage is metered every one to two minutes and billed sub-hourly. The feature suits resumable, retryable, or requeueable work such as experiments, batch inference, and temporary bursts, but critical services, uncheckpointed multi-day runs, and strict-SLO serving should remain on standard nodes; users must schedule eligible pods with the together.ai/compute-class=preemptible label.
The GLM-5.3 Flash, a distilled variant of the full GLM-5.3, achieves a pass@1 of 63.4% on the DeepSWE benchmark at $0.24 per rollout, 17 times cheaper than the full model’s 69.0% at $3.99. The pass@4 gap narrows to 2.6 points (87.6% versus 85.0%). Distillation removed consistency rather than capability: the Flash solves 93 of the 99 tasks the full model solves, but its ability to convert extra effort into a win is lost (46% win rate on flaky tasks versus 61%). A cascade that runs Flash first and escalates to the full model only when the answer is rejected solves 80.9% of tasks at $1.70 each, 57% lower cost than using the full model alone.
GLM-5.3 and GPT-5.6 Sol were evaluated on 113 DeepSWE tasks with 904 rollouts, comparing accuracy, cost, and failure patterns. Sol edges ahead at pass@1 (72.7% vs 69.0%), but GLM-5.3 leads at pass@4 (87.6% vs 85.8%) at $3.99 per rollout, half Sol’s $8.37 cost and yielding 17 solves per $100 versus Sol’s 9. Their low per-task correlation of 0.43 makes a cascade effective: GLM-5.3 first, then Sol on test failure, achieving 85.9% solved at $6.61 per task. Sol runs faster (19 minutes, 61 steps vs 35 minutes, 124 steps) and achieves higher reliability (61 tasks solved all four tries vs 48), but it breaks passing tests in 20% of failures versus GLM-5.3’s 11%.
GLM-5.3 and Claude Fable 5 were compared on the DeepSWE benchmark across 113 tasks with four trials each, totaling 904 rollouts. On first-attempt accuracy, Fable 5 scored 69.7% and GLM-5.3 scored 69.0%, a statistical tie inside error bars. GLM-5.3 led on pass@2 (81.1% vs. 77.1%) and pass@4 (87.6% vs. 84.1%), and cost $3.99 per rollout versus Fable’s $21.63, a 5.4x price gap. Per $100, GLM-5.3 solved 17 tasks while Fable solved 3. Both models regress test suites in only 11% of failures, and GLM-5.3 averages 35 minutes per rollout with 80k output tokens versus Fable’s 34 minutes and 114k tokens. The models are near-substitutes with 0.65 per-task correlation; GLM-5.3 won five of eight domains including JavaScript and concurrency, while Fable excelled only in Rust and serialization, making GLM-5.3 the practical default.
DeepSeek V4 Pro 0813 costs $0.24 per rollout and achieves 62.8% pass@1 on DeepSWE, while GPT-5.6 Sol reaches 72.7% pass@1 at $8.37 per rollout—a 35x price gap. At four attempts, DeepSeek V4 Pro 0813 surpasses Sol, with 88.5% pass@4 versus 85.8%. Sol is faster and more reliable, completing a rollout in 17 minutes and 53 steps, and breaking tests in only 11% of its failures. A cascade strategy—running DeepSeek V4 Pro 0813 first and escalating to Sol on test failure—solves 83.0% of tasks at $3.35 each, outperforming either model alone. Per $100, DeepSeek V4 Pro 0813 solves 260 tasks versus Sol’s 9, making it the value leader for budget-constrained workloads.
The DeepSWE benchmark comparison between DeepSeek V4 Pro 0813 and Claude Fable 5 reveals a trade-off between cost and accuracy. Claude Fable 5 leads on the first attempt with 69.7% pass@1 versus DeepSeek V4 Pro’s 62.8%, but costs 90 times more per rollout ($21.63 vs $0.24). Under repeated attempts, DeepSeek V4 Pro surpasses Fable, achieving 88.5% pass@4 compared to Fable’s 84.1%. The two models show unusually low per-task correlation (0.39), meaning they fail on different tasks. A cascade strategy that runs DeepSeek V4 Pro first and escalates to Claude Fable 5 only on failures solves 82.7% of tasks at $8.28 per task, outperforming either model used alone.
Uber’s offline export workloads often retrieve a small set of records from large, date-partitioned Apache Hudi tables, but narrow historical predicates can still trigger full-table scans. Repeatedly touching files, metadata, or Parquet footers keeps Google Cloud Storage objects hot, undermining Auto-Class tiering and increasing storage, retrieval, metadata-operation, egress, and latency costs. The approach combines Hudi column stats with sorting on predicate columns: metadata-table statistics prune files without opening them, while clustered records tighten file-level min/max ranges and make pruning more selective. A Hudi secondary index was evaluated but did not reduce file scans enough because records for a subject were spread across most files. The conclusion is that a one-time rewrite and ongoing Hudi table services can turn broad historical scans into lower-touch lookups, while future work targets multi-column layouts and automated ROI-based optimization.
On the DeepSWE coding benchmark, GPT-5.6 Luna achieves 67.2% pass@1 versus DeepSeek-V4 Flash’s 53.3%, a 14-point gap. DeepSeek costs $0.10 per task, roughly six times less than Luna’s $0.61, delivering 532 solves per $100 versus Luna’s 110. A cascade that runs DeepSeek first and escalates only on failure solves 78.9% of tasks at $0.385 each, beating Luna’s solo accuracy and cutting cost by 37%. DeepSeek fails more gracefully (9% broken tests vs 15%) but is slower and dramatically weaker on JavaScript (35% vs 60%). Luna dominates seven of eight task domains, while DeepSeek leads only on query and config languages, illustrating how inexpensive models can combine with flagships for superior price-performance.
GPT-5.6 Sol and Kimi K3 were compared on the DeepSWE software engineering benchmark using 904 graded rollouts across 113 tasks. Sol wins single-shot pass@1 (72.7% vs 68.5%) and reliability (84.5% tasks solved four-for-four versus 76.6%), while Kimi K3 leads pass@4 (89.4% vs 85.8%) with wider coverage at a substantially lower cost—$4.65 per rollout versus Sol’s $8.37, delivering 14.7 solves per $100 against Sol’s 5.3. The two models have a low task correlation of 0.46 and disagree on 18 tasks, enabling a cascade routing strategy that runs Kimi first and escalates to Sol when the test suite rejects the result, achieving 85.6% accuracy, beating both models individually and a perfect one-shot oracle router. Kimi K3 is open-weight and available on Together AI.
On DeepSWE, Kimi K3 trails Claude Fable 5 by 1.4 points at pass@1 (68.5% vs 69.9%) but leads at pass@2 (82.0 vs 80.2) and pass@4 (89.4% vs 88.5%) across 452 rollouts. Kimi K3 costs $4.65 per rollout versus $13.41 for Fable, delivering 2.8x more solved tasks per dollar. It covers 89.4% of the benchmark, solving 101 of 113 tasks, while Fable solves 100, though Fable is more reliable with 58 tasks solved four-for-four versus Kimi’s 45. The models share the highest cross-vendor similarity (0.72) and fail on the same tasks, with Kimi leading in Go and Fable leading in Python, JavaScript, TypeScript, and Rust. As an open-weight model, Kimi K3 offers a cost-effective alternative for retry-tolerant workloads.
The best engineering reads, once a week.
