今日已更新 329 条资讯 | 累计 40774 条内容
关于我们

标签:#home

找到 310 篇相关文章

AI 资讯

Running LLMs Locally on Consumer Hardware — Part 1: The Stack and First Benchmarks

This is the first in a series of build-log posts documenting a local LLM project, in which models are run on owned consumer hardware rather than through a cloud API. The present entry covers the hardware, the software stack, and the benchmarks by which a primary model was selected. The hardware Two machines are used, both consumer-grade. All benchmarks reported below were obtained on the primary desktop. Machine CPU RAM GPU Primary desktop Ryzen 5950X ~80 GB DDR4 AMD RX 6900XT (16 GB) Secondary box Ryzen 5600G 32 GB NVIDIA GTX 1060 (6 GB) The software stack Ollama serves as the model runner across two GPU vendors: ROCm 5.7 for the AMD card on the primary desktop, and CUDA for the NVIDIA card on the secondary box. The primary model is Gemma 4 26B, a mixture-of-experts model with roughly 3.8B active parameters, quantized to Q4_K_M and occupying approximately 18 GB on disk. On the RX 6900XT it is run with an automatic GPU/CPU layer split, as the Q4 weights together with the KV cache exceed the 16 GB of available VRAM. Several Ollama settings were enabled to recover headroom: flash attention, and an 8-bit ( q8_0 ) KV cache, the latter approximately halving the cache footprint. A free cloud tier is retained for occasional heavier tasks, though the objective is to run as much as possible locally. Selecting a model: benchmarks Before a primary model was chosen, the installed models were benchmarked. Two properties were of interest: throughput and output quality. Throughput was measured on the primary desktop with a 500-word essay prompt ( ollama run <model> --verbose ): Model Tokens/sec Duration Tokens out gemma4:26b 18.86 50.11s 945 gemma4-26b (64K ctx) 17.96 51.99s 934 mistral:7b-instruct 34.81 10.17s 354 llama3.2 57.11 3.99s 228 The smaller models are substantially faster; their token counts, however, are lower, and in practice their responses were correspondingly shallower. Quality was assessed with a five-task suite spanning logic, coding, summarization, creative writ

2026-07-31 原文 →
AI 资讯

5 macOS-on-Proxmox Bugs That No Guide Warns You About

Back in February I published a post about osx-proxmox-next , a tool that builds a macOS VM on Proxmox with one command instead of an afternoon of OpenCore plist editing. About 1,500 people read it. Some of them installed it. On hardware I don't own. That's when the interesting bugs showed up. 150 commits later, here are five failures that don't appear in any macOS-on-Proxmox guide I've found, with the actual root cause for each. 1. The installer stalls at 100% CPU and nothing moves Symptom: macOS installer reaches the copy phase. CPU pegged at 100%. Disk IO and network throughput both flat zero. It sits there forever. Only on Xeon E5/E7 v2-v4 hosts. My first fix was wrong. The stall looked like a network problem, so I assumed the vmxnet3 kext was failing to load during install and swapped those hosts to e1000-82545em . Shipped it. Then issue #103 came back from someone with the actual hardware: vmxnet3 got network fine, and e1000-82545em did not attach at all. I had made it worse. The real cause is two layers down. Those chips are genuine HEDT parts with dual-socket / multi-die topology, and -cpu host leaks that topology straight through to the guest. Pair it with a MacPro7,1 SMBIOS, which macOS treats as multi-socket capable, and XNU's scheduler livelocks under heavy multithreaded IO. The installer copy phase is exactly that workload. The fix is to stop passing the host topology through: _XEON_HEDT_PATTERN = re . compile ( r " Xeon.*E[57][ -]*\d+ *v([234]) " , re . IGNORECASE ) def _xeon_hedt_cpu_model ( model_name : str ) -> str : match = _XEON_HEDT_PATTERN . search ( model_name ) if not match : return "" if match . group ( 1 ) == " 2 " : return " Haswell-noTSX,model=158,stepping=3 " return " Broadwell-noTSX,model=158 " Lesson I keep relearning: the symptom showed up at the network layer, the cause lived in CPU topology. Guessing from the symptom cost me a release. 2. The VM boots into Recovery forever Symptom: Fresh install finishes. Every subsequent boot lands b

2026-07-31 原文 →
AI 资讯

SwitchBot makes a better fan

I was already a big fan of SwitchBot's big circulator fan I recently reviewed, and now we're getting the SwitchBot Battery Circulator Fan 2 Pro. Priced at $119.99, it ditches the height-adjustable stand but increases battery life, throw distance, and wind speed while adding native Matter-over-Wi-Fi, allowing it to join your smart home without needing […]

2026-07-30 原文 →
开发者

KNX Motion-Sensor Automations in Home Assistant

A note before the post: the mistake in the first section is genuinely mine. It cost me an evening of forking conditions in Home Assistant before I accepted the fix didn't belong in Home Assistant at all. I've left it in rather than writing around it, because it's the part I'd have wanted to read first. The first time motion-controlled lighting actually worked in my place, it didn't feel clever. It felt obvious — I walked into a dark hallway and the light was already on by the time I'd registered it was dark. That's the bar. Not smart , just attentive. Getting there with seven KNX motion sensors took me less code than I expected and one insight I wish I'd had on day one. This is Part 05 of the series. The earlier parts cover the boring-but-load-bearing groundwork: running Home Assistant in Docker and wiring up HACS . Here I'm assuming HA is up, talking KNX, and you just want the lights to behave. One sensor, two jobs, two addresses Here's the mistake I made, and it's the whole reason this post exists. KNX exposes each motion sensor to Home Assistant as a binary_sensor with device_class: motion , fed by a KNX group-address state object you configure in knx.yaml with a state_address per sensor. Simple enough. So I wired all seven sensors with one group address each and pointed both the lighting automation and the presence logic at the same signal. That works right up until you want the two to behave differently. A light should react to the smallest twitch, instantly, generously. Presence and security want the opposite: a debounce, a grace window, some scepticism before they commit. When both ride the same group address, every change you make to one quietly deforms the other. I spent an evening forking conditions in Home Assistant trying to make one signal mean two things. The fix isn't in Home Assistant at all. It's in ETS: give each physical PIR a second group address . One drives comfort lighting, the other feeds presence and the alarm path. I use a flat convention —

2026-07-29 原文 →
AI 资讯

Nanoleaf’s colorful pegboard and shelf kit is half off

Nanoleaf’s Blocks Combo XL Smarter Kit is a fun back-to-school buy that can add pops of customizable light and storage to your wall. It combines colorful smart lighting panels with a low-profile shelf and pegboard, and right now you can buy the kit for half off at $99.99 from Nanoleaf, which marks a new low […]

2026-07-28 原文 →