Qwen3.5-397B-A17B 検証:Blackwell 96GB×2 で 55 t/s と 262k tool-use ループを実用運用する
Qwen3.5-397B-A17B(Q4_K_M, 227.5 GiB)を RTX PRO 6000 Blackwell 96GB×2 で検証。平均 55.8 t/s を維持しつつ 262k コンテキストで 80 回の tool-use ループを 20 分で完走した実測と、GLM-5.1 常駐運用とのトレードオフを整理する。
Qwen3.5-397B-A17B(Q4_K_M 量子化、227.5 GiB)を自宅ラボの Blackwell 96GB×2 で検証した。Django ベースの不動産賃貸管理システムを仕様書から自律実装させるタスクで、20分・80回の tool-use ループを完走し、30モデル・4,478行のコードを生成した。Generation は平均 55.8 t/s で、397B クラスとしては実用域に入っている。
動画リンク: https://www.youtube.com/watch?v=0O8GgaMDLg0
検証動画: https://www.youtube.com/watch?v=0O8GgaMDLg0
ハードウェアとメモリ配置

| コンポーネント | スペック |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB ×2 |
| CPU | AMD EPYC 9175F (16C/32T) |
| RAM | 768 GB |
| モデル | Qwen3.5-397B-A17B (Q4_K_M, 227.5 GiB) |
Qwen3.5-397B は 512 エキスパートから 10 を選択する MoE で、アクティブパラメータは 17B(17B / 397B = 4.3%)。
体感としては、-ot exps で head 側をもう少し GPU に寄せれば TG の伸びしろはありそう。ただ、今回の構成でも大半を GPU 側に置けていて、実運用としては十分に速い。
| バッファ | サイズ | 配置先 |
|---|---|---|
| モデルテンソル (CUDA_Split) | 171.6 GiB | GPU0 + GPU1 |
| MoE エキスパート (pinned host) | 55.4 GiB | CPU メモリ |
| KV キャッシュ (q8_0) | 4.0 GiB | GPU |
| Compute buffers | 10.5 GiB | GPU + Host |
1枚構成では 397B が VRAM に収まらず CPU オフロード比率が上がり、TG が 20-30 t/s 台まで落ちる。2枚構成にすると MoE の pinned host memory を 55 GiB 台に抑えつつモデル本体を GPU 側へ置けるため、55 t/s 帯を維持できる。
推論パフォーマンス
Token Generation (TG)
| 指標 | 値 |
|---|---|
| 平均 | 55.8 t/s |
| 最大 | 59.6 t/s |
| 最小 | 45.1 t/s |
| 総生成トークン | 45,478 |
397B クラスで 55 t/s を維持しながら、262k コンテキスト下の tool-use ループを 20 分で完走できた点が今回の中核。単純なベンチ速度より、長文脈の反復ワークロードで崩れないことに実用価値がある。 YaRN で 1M コンテキストまで伸ばせる余地もあるので、GLM-5.1 のベンチ値だけで判断するより、Qwen 側でオーケストレーションを組む選択は現実的だと感じた。
Prompt Processing (PP)
| 指標 | 値 |
|---|---|
| 平均 | 930.7 t/s |
| 最大 | 1,501.2 t/s |
| 最小 | 96.5 t/s |
PP はキャッシュヒット率依存で振れ幅が大きい。ヒット時は 1,000-1,500 t/s、再構築時は 100 t/s 前後。ik_llama.cpp のコンテキストチェックポイントとプロンプトキャッシュが、長い tool-use 連鎖での再処理コストを抑えていた。
代表タスク
| Task ID | PP (t/s) | TG (t/s) | 生成トークン | 内容 |
|---|---|---|---|---|
| 0 | 1,353 | 58.6 | 132 | 初回プロンプト処理 (22k tokens) |
| 957 | 1,131 | 59.4 | 542 | Django settings 生成 |
| 4662 | 1,375 | 59.0 | 2,821 | models.py 本体 |
| 44134 | 1,210 | 55.5 | 538 | pytest.ini / manage.py |
| 45061 | 103 | 56.1 | 735 | 最終テスト生成(キャッシュミス) |
実行ログ抽出(running.log)
ログから、設定値・スコア・キャッシュ挙動を抽出した。 実際に打った起動コマンド。
ksh3@compute-server:~$ podman run --rm --device nvidia.com/gpu=all -p 8000:8000 --shm-size 16g --cap-add=SYS_NICE -v /mnt/data/models/models--AesSedai--Qwen3.5-397B-A17B-GGUF:/models:ro,Z registry.home.arpa/ik_llama.cpp:cuda -m /models/snapshots/8c01f48cac64987c64b4cd77cb4ad9abdad1f373/Q4_K_M/Qwen3.5-397B-A17B-Q4_K_M-00001-of-00006.gguf --chat-template-kwargs '{"enable_thinking":false}' --merge-qkv --ctx-size 262144 -ctk q8_0 -ctv q8_0 --parallel 1 --threads 15 --threads-batch 24 -b 4096 -ub 4096 -sm graph -ngl 99 --n-cpu-moe 15 -mla 3 -ger -amb 512 --jinja --host 0.0.0.0 --port 8000 --warmup-batch --alias qwen3.5-397b-a17b
llm_load_print_meta: n_ctx_train = 262144
Memory required for model tensors + cache: 239038 MiB
llama_init_from_model: n_ctx = 262144
llama_init_from_model: n_batch = 4096
llama_init_from_model: n_ubatch = 4096
INFO [ init] new slot | tid="134129990582272" timestamp=1776252818 id_slot=0 n_ctx_slot=262144
prompt cache is enabled, size limit: 8192 MiB
PP/TG は slot print_timing の実行行をそのまま見ると判断しやすい。初回・中盤・終盤の代表を残す。
slot print_timing: id 0 | task 0 |
prompt eval time = 16325.45 ms / 22088 tokens ( 0.74 ms per token, 1352.98 tokens per second)
eval time = 2251.83 ms / 132 tokens ( 17.06 ms per token, 58.62 tokens per second)
slot print_timing: id 0 | task 957 |
prompt eval time = 2174.51 ms / 2459 tokens ( 0.88 ms per token, 1130.83 tokens per second)
eval time = 9130.61 ms / 542 tokens ( 16.85 ms per token, 59.36 tokens per second)
slot print_timing: id 0 | task 45061 |
prompt eval time = 330.65 ms / 34 tokens ( 9.72 ms per token, 102.83 tokens per second)
eval time = 13108.41 ms / 735 tokens ( 17.83 ms per token, 56.07 tokens per second)
キャッシュは「再利用できたか」「チェックポイント復元に落ちたか」を見る。以下は終盤抜粋。
======== Prompt cache: cache size: 70479, n_keep: 0, n_discarded_prompt: 0, cache_ram_n_min: 0, f_keep: 0.95, cache_ram_similarity: 0.50
- cache state: 1 prompts, 3632.597 MiB (limits: 8192.000 MiB, 0 tokens, 120839 est)
prompt cache load took 9.96 ms
slot apply_checkp: id 0 | task 44134 | restored context checkpoint took 17.84 ms (pos_min = 64723, pos_max = 64723, size = 186.824 MiB)
slot create_check: id 0 | task 44134 | created context checkpoint 18 of 32 (pos_min = 68819, pos_max = 68819, size = 186.855 MiB, took 67.27 ms)
slot create_check: id 0 | task 45061 | created context checkpoint 29 of 32 (pos_min = 72626, pos_max = 72626, size = 186.885 MiB, took 46.71 ms)
INFO [ release_slots] slot released | tid="134129990582272" timestamp=1776254196 id_slot=0 id_task=45061 n_ctx=262144 n_past=72628 n_system_tokens=0 n_cache_tokens=72628 truncated=false
なお、集計値(61件)は running.log から算出しており、本文の実測と整合する。
PP: avg 930.69 t/s, min 96.52 t/s, max 1501.20 t/s, tokens 345,956
TG: avg 55.81 t/s, min 45.08 t/s, max 59.58 t/s, tokens 45,478
checkpoint create: 343回 (max 29/32), avg 49.74 ms
checkpoint restore: 51回, avg 16.04 ms
prompt cache size: 0 -> 71,859 tokens (last 71,859), f_keep last 1.00
ワンショット投入スペックと生成成果物(原文)
今回の実装では、generation-instructions.md と system-spec.md をワンショットで投入し、その出力として IMPLEMENTATION_STATUS.md が生成された。下に3ファイルの原文をそのままコードブロックで残す。
generation-instructions.md
# Real Estate Rental Generation Instructions
## Mission
Implement `tenant_modules.real_estate_rental` as a full rental-management module for property managers and PM operators.
## Build order
1. Implement owner, asset, and lease master models.
2. Implement recurring charge, payment, delinquency, and remittance models.
3. Implement maintenance and inspection models.
4. Add admin resources and tests for billing, occupancy, and reporting workflows.
## Hard rules
- Use `"tenant_accounts.Organization"` and `settings.AUTH_USER_MODEL`.
- Prefix tables with `real_estate_rental_`.
- Keep monthly financial outputs reproducible from base transaction records.
- Treat move-out and deposit settlement as explicit workflows, not note fields.
- Keep translation strings module-local and audit delegated.
## Domain priorities
- Lease and resident lifecycle.
- Recurring billing and collection.
- Owner remittance and reporting.
- Maintenance approval and execution flow.
## Definition of done
- Operators can onboard assets, manage residents, bill monthly rent, track delinquency, handle maintenance, and remit to owners.
- Billing, allocation, and remittance logic are covered by tests.
system-spec.md
# Real Estate Rental System Specification
## Goal
Generate a Django tenant module for rental-property management. The system must handle owners, buildings, units, lease contracts, residents, recurring charges, payments, delinquencies, maintenance, remittance, and owner reporting.
## Django target
- Package: `tenant_modules.real_estate_rental`
- App label: `industry_real_estate_rental`
- Table prefix: `real_estate_rental_`
- Primary users: property managers, leasing staff, accounting staff, owner-reporting staff
- Primary workflow: property onboarding -> tenant contract -> monthly billing and collection -> maintenance and reporting -> owner remittance
## Functional scope
- Owner and owner-bank-account management plus management contracts.
- Building, unit, parking, and equipment masters with vacancy and facility state.
- Tenant, co-resident, and lease-contract management with renewal and move-out tracking.
- Monthly charge generation, payment capture, payment allocation, delinquency monitoring, and dunning history.
- Owner remittance, remittance details, and monthly owner reporting.
- Maintenance vendor, request, estimate, work, and inspection operations.
- Master data for layout type, equipment, maintenance category, and move-out reason.
## Domain model groups
- Ownership: `Owner`, `OwnerBankAccount`, `ManagementContract`
- Asset inventory: `Building`, `BuildingEquipment`, `Unit`, `ParkingSpace`
- Occupancy: `Tenant`, `TenantCoResident`, `LeaseContract`, `ContractRenewal`, `MoveOut`, `DepositSettlement`
- Billing and collection: `MonthlyCharge`, `Payment`, `PaymentAllocation`, `Delinquency`, `DunningHistory`
- Owner settlement: `OwnerRemittance`, `RemittanceDetail`, `MonthlyOwnerReport`
- Maintenance: `MaintenanceVendor`, `MaintenanceRequest`, `MaintenanceEstimate`, `MaintenanceWork`, `Inspection`
- Masters: `EquipmentMaster`, `LayoutTypeMaster`, `MaintenanceCategoryMaster`, `MoveOutReasonMaster`
## Required behaviors
- Generate recurring monthly charges from active lease terms.
- Support payment allocation and clear outstanding balances.
- Track renewal windows, move-out workflows, and deposit settlement outputs.
- Keep maintenance requests linked to approval and vendor execution.
- Produce owner remittance and report outputs from actual billing and expense records.
## Required surfaces
- Admin must expose owner, building, unit, contract status, delinquency state, maintenance status, and remittance-period filters.
- Import/export resources are required for unit masters, tenant onboarding, monthly charges, and owner reports.
- Search must support building, unit, tenant, contract number, and owner reference identifiers.
## Compliance and constraints
- Use `"tenant_accounts.Organization"` and `settings.AUTH_USER_MODEL`.
- Keep the module tenant-owned and forward-only for migration flow.
- Avoid platform-owned accounting tables and keep audit logging delegated.
## Delivery expectation
The generated module must include tests for recurring charge generation, payment allocation, renewal flow, move-out settlement, and owner remittance totals.
IMPLEMENTATION_STATUS.md
# Real Estate Rental Module - Implementation Status
## Overview
This document tracks the implementation status of the `tenant_modules.real_estate_rental` Django module for comprehensive rental property management.
## Implementation Date
2024-01-XX (Initial Implementation)
## Completed Components
### 1. Core Infrastructure ✅
- **Django Project Structure**
- `config/settings.py` - Django configuration with tenant module integration
- `config/urls.py` - URL routing configuration
- `config/wsgi.py` - WSGI application entry point
- `manage.py` - Django management script
- `pytest.ini` - Pytest configuration for Django testing
- **Package Structure**
- `tenant_accounts/` - Multi-tenant organization management
- `tenant_modules/real_estate_rental/` - Main rental management module
- Proper `__init__.py` files for all packages
- App configuration classes for Django app registry
### 2. Domain Models ✅
All models implemented with proper Django ORM patterns, table prefix `real_estate_rental_`, and tenant isolation via `Organization` foreign keys.
#### Ownership Domain ✅
- `Owner` - Property owner entities with contact and audit fields
- `OwnerBankAccount` - Banking information with primary account enforcement
- `ManagementContract` - Management agreements with fee structures
#### Asset Inventory Domain ✅
- `EquipmentMaster` - Standardized equipment type definitions
- `LayoutTypeMaster` - Unit layout classifications (1K, 2DK, 3LDK, etc.)
- `Building` - Property assets with structure, location, and unit count
- `BuildingEquipment` - Installed equipment tracking per building
- `Unit` - Rentable units with rent parameters and vacancy state
- `ParkingSpace` - Parking spaces with size limits and fees
#### Occupancy Domain ✅
- `MoveOutReasonMaster` - Standardized move-out reason codes
- `Tenant` - Tenant entities (individual/corporate)
- `TenantCoResident` - Co-resident tracking with relationships
- `LeaseContract` - Lease agreements with comprehensive terms
- `ContractRenewal` - Renewal history with updated terms
- `MoveOut` - Move-out workflow from notice to settlement
- `DepositSettlement` - Deposit reconciliation with calculation method
#### Billing and Collection Domain ✅
- `MonthlyCharge` - Recurring charges with status tracking
- `Payment` - Payment recording with multiple payment methods
- `PaymentAllocation` - Payment-to-charge allocation
- `Delinquency` - Delinquent account tracking
- `DunningHistory` - Collection communication log
#### Owner Settlement Domain ✅
- `OwnerRemittance` - Periodic owner payments with calculation
- `RemittanceDetail` - Remittance line item breakdown
- `MonthlyOwnerReport` - Monthly owner statements with metrics
#### Maintenance Domain ✅
- `MaintenanceCategoryMaster` - Maintenance type classifications
- `MaintenanceVendor` - Vendor management with specialties
- `MaintenanceRequest` - Request intake and routing
- `MaintenanceEstimate` - Cost estimates with approval workflow
- `MaintenanceWork` - Work execution and cost tracking
- `Inspection` - Property inspections with condition reporting
**Total Models: 30**
### 3. Admin Interface ✅
Comprehensive Django Admin configuration for all 30 models:
- List display with key business fields
- Search functionality for common queries (contract numbers, names, codes)
- Filters for status, dates, categories, and relationships
- Raw ID fields for efficient foreign key selection in admin
- Read-only audit fields (`created_at`, `updated_at`)
- Filter horizontal widgets for many-to-many relationships
- Proper ordering and pagination
**Admin Classes: 30**
### 4. Test Infrastructure ✅
#### Test Data Factories (`test_models.py`)
- `TestDataBase` class with factory methods for all major models
- Proper dependency chain handling (organization -> owner -> building -> unit -> lease)
- Default values for common fields
- Flexible override system for test-specific customization
#### Workflow Tests (`test_workflows.py`)
- **Recurring Charge Generation Tests**
- Single lease charge generation
- Multiple unit charge aggregation
- **Payment Allocation Tests**
- Full payment allocation
- Partial payment allocation
- Outstanding balance calculation
- **Contract Renewal Flow Tests**
- Single renewal creation
- Multiple renewal history
- **Move-Out Settlement Tests**
- Move-out request creation
- Deposit settlement calculation
- Additional charge scenarios
- **Owner Remittance Tests**
- Remittance creation and calculation
- Multiple property aggregation
- Financial metric validation
**Test Classes: 5**
**Test Methods: 12+**
### 5. Documentation ✅
- **README.md** - Comprehensive module documentation
- Architecture overview with domain structure
- Installation and configuration guide
- Usage examples for all major workflows
- Testing instructions
- Admin interface guide
- Database schema reference
- Audit and compliance notes
- Performance considerations
- Extensibility guidelines
- **IMPLEMENTATION_STATUS.md** (this file)
- Component completion tracking
- Model inventory
- Test coverage summary
- Migration guidance
- Next steps and recommendations
## Model Count Summary
| Domain | Models | Status |
|--------|--------|--------|
| Ownership | 3 | ✅ Complete |
| Asset Inventory | 6 | ✅ Complete |
| Occupancy | 7 | ✅ Complete |
| Billing and Collection | 5 | ✅ Complete |
| Owner Settlement | 3 | ✅ Complete |
| Maintenance | 6 | ✅ Complete |
| **Total** | **30** | **✅ Complete** |
## Architecture Compliance
### DDD/Clean Architecture ✅
- **Domain Layer**: Business logic in model methods (e.g., `calculate_totals()`, `is_active_lease()`, `is_overdue()`)
- **Presentation Layer**: Admin interface for state management
- **Infrastructure Layer**: Django ORM, database persistence
- **Dependency Rule**: Models only import inward (tenant_accounts, Django core)
### Multi-Tenant Isolation ✅
- All models include `organization` foreign key to `tenant_accounts.Organization`
- Proper `related_name` specifications for reverse relationships
- Organization-scoped queries enforced through model design
### Audit Trail ✅
- `created_at` / `updated_at` timestamps on all models
- `created_by` foreign key to user model on transactional models
- `received_by`, `approved_by`, `verified_by` for workflow-specific actions
### Data Integrity ✅
- `PROTECT` on critical foreign keys (owner, building, unit, lease)
- `CASCADE` on ownership relationships (organization, tenant)
- `SET_NULL` on optional relationships (parking space, maintenance requests)
- Unique constraints on business keys (contract numbers, codes)
- Decimal fields for all monetary values (no floating-point)
- Check constraints via validators (positive values, percentages)
## Hard Rules Compliance ✅
From `generation-instructions.md`:
- ✅ Use `"tenant_accounts.Organization"` - All models reference Organization
- ✅ Use `settings.AUTH_USER_MODEL` - All audit fields reference user model
- ✅ Prefix tables with `real_estate_rental_` - All models specify `db_table`
- ✅ Keep monthly financial outputs reproducible - Charges, payments, remittances all link to base transactions
- ✅ Treat move-out and deposit settlement as explicit workflows - Dedicated `MoveOut` and `DepositSettlement` models with status tracking
- ✅ Keep translation strings module-local and audit delegated - No translation strings in models, audit fields reference user directly
## Domain Priorities Coverage ✅
From `generation-instructions.md`:
- ✅ **Lease and resident lifecycle**: `LeaseContract`, `ContractRenewal`, `Tenant`, `TenantCoResident`, `MoveOut`
- ✅ **Recurring billing and collection**: `MonthlyCharge`, `Payment`, `PaymentAllocation`, `Delinquency`, `DunningHistory`
- ✅ **Owner remittance and reporting**: `OwnerRemittance`, `RemittanceDetail`, `MonthlyOwnerReport`
- ✅ **Maintenance approval and execution flow**: `MaintenanceRequest`, `MaintenanceEstimate`, `MaintenanceWork`, approval workflows
## Definition of Done ✅
From `generation-instructions.md`:
- ✅ Operators can onboard assets - `Owner`, `Building`, `Unit` models with admin
- ✅ Manage residents - `Tenant`, `TenantCoResident`, `LeaseContract` with full lifecycle
- ✅ Bill monthly rent - `MonthlyCharge` generation from active leases
- ✅ Track delinquency - `Delinquency`, `DunningHistory` with status tracking
- ✅ Handle maintenance - Full request-to-workflow with vendor management
- ✅ Remit to owners - `OwnerRemittance` with calculation and reporting
- ✅ Billing logic covered by tests - Payment allocation, charge generation tests
- ✅ Allocation logic covered by tests - Payment allocation tests with full/partial scenarios
- ✅ Remittance logic covered by tests - Owner remittance calculation tests
## Required Behaviors Verification ✅
From `system-spec.md`:
- ✅ Generate recurring monthly charges from active lease terms - `MonthlyCharge` model with lease contract FK
- ✅ Support payment allocation and clear outstanding balances - `PaymentAllocation` links payments to charges
- ✅ Track renewal windows, move-out workflows, and deposit settlement outputs - `ContractRenewal`, `MoveOut`, `DepositSettlement`
- ✅ Keep maintenance requests linked to approval and vendor execution - `MaintenanceRequest` -> `MaintenanceEstimate` -> `MaintenanceWork`
- ✅ Produce owner remittance and report outputs from actual billing and expense records - `OwnerRemittance`, `MonthlyOwnerReport` aggregate from charges/payments
## Required Surfaces ✅
From `system-spec.md`:
- ✅ **Admin filters**: Building, unit, contract status, delinquency state, maintenance status, remittance-period filters implemented
- ✅ **Search support**: Building, unit, tenant, contract number, owner reference identifiers in admin search_fields
- ✅ **Import/export ready**: Admin configuration supports Django's built-in import/export actions (can be extended with django-import-export)
## Compliance Verification ✅
From `system-spec.md`:
- ✅ Use `"tenant_accounts.Organization"` - Verified in all model definitions
- ✅ Use `settings.AUTH_USER_MODEL` - Verified in all audit fields
- ✅ Module tenant-owned and forward-only - Organization FK on all models, no backward dependencies
- ✅ Avoid platform-owned accounting tables - No external accounting module dependencies, audit logging delegated to user FK
## Migration Guidance
### Step 1: Generate Migrations
```bash
cd django-llm-bench
python manage.py makemigrations tenant_accounts
python manage.py makemigrations industry_real_estate_rental
```
### Step 2: Apply Migrations
```bash
python manage.py migrate
```
### Step 3: Create Superuser
```bash
python manage.py createsuperuser
```
### Step 4: Verify Admin Interface
```bash
python manage.py runserver
# Visit http://localhost:8000/admin/
```
### Step 5: Run Tests
```bash
cd django-llm-bench
python -m pytest tenant_modules/real_estate_rental/tests/ -v
```
## Known Limitations and Future Enhancements
### Current Limitations
1. **No Actual Migration Files**: Migration files need to be generated via `makemigrations`
2. **No Frontend Views**: Only admin interface provided, no tenant-facing views
3. **No API Endpoints**: REST API not implemented (could add Django REST Framework)
4. **No Automated Charge Generation**: Charge generation is manual (could add management command or Celery task)
5. **No Email Notifications**: Dunning and workflow notifications not implemented
6. **No File Upload Handling**: Document path fields are CharField, actual file storage not implemented
### Recommended Enhancements
1. **Automated Billing**: Add monthly charge generation management command
2. **Email Integration**: Add email notifications for payment reminders, maintenance updates
3. **Report Generation**: Add PDF generation for owner reports and lease documents
4. **Dashboard Views**: Add tenant and operator dashboard views
5. **REST API**: Add Django REST Framework serializers and viewsets
6. **Import/Export**: Integrate django-import-export for bulk operations
7. **Audit Log**: Add comprehensive audit logging beyond created_by/updated_at
8. **Soft Delete**: Add soft delete pattern for archival instead of hard deletes
9. **Multi-Currency**: Add currency support for international deployments
10. **Performance Optimization**: Add database indexes on frequently queried fields
## Testing Recommendations
### Unit Tests (Current)
- Model method tests
- Factory creation tests
- Business logic validation
### Integration Tests (Recommended)
- Full lease lifecycle test (create -> bill -> pay -> renew -> move-out)
- Owner onboarding to first remittance flow
- Maintenance request to completion workflow
### Performance Tests (Recommended)
- Bulk charge generation for large portfolios
- Payment allocation performance with many charges
- Report generation for multi-property owners
## File Inventory
```
django-llm-bench/
├── config/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── tenant_accounts/
│ ├── __init__.py
│ ├── apps.py
│ ├── models.py
│ ├── admin.py
│ ├── migrations/
│ │ └── __init__.py
│ └── tests/
├── tenant_modules/
│ ├── __init__.py
│ └── real_estate_rental/
│ ├── __init__.py
│ ├── apps.py
│ ├── models.py (1,600+ lines)
│ ├── admin.py (550+ lines)
│ ├── README.md (500+ lines)
│ ├── migrations/
│ │ └── __init__.py
│ └── tests/
│ ├── __init__.py
│ ├── test_models.py (400+ lines)
│ └── test_workflows.py (260+ lines)
├── manage.py
├── pytest.ini
└── real_estate_rental/
├── generation-instructions.md
├── system-spec.md
└── IMPLEMENTATION_STATUS.md (this file)
```
## Lines of Code Summary
| Component | Lines | Purpose |
|-----------|-------|---------|
| Models | 1,600+ | 30 Django models with business logic |
| Admin | 550+ | 30 admin classes with full configuration |
| Tests (Factories) | 400+ | Test data factories for all models |
| Tests (Workflows) | 260+ | Workflow validation tests |
| Documentation | 500+ | Comprehensive usage guide |
| Configuration | 100+ | Django settings, pytest config |
| **Total** | **3,400+** | **Complete implementation** |
## Conclusion
The `tenant_modules.real_estate_rental` module is **fully implemented** according to the specifications in `generation-instructions.md` and `system-spec.md`. All 30 models are in place with proper domain boundaries, audit trails, and multi-tenant isolation. The admin interface provides complete CRUD operations for all models. The test suite validates key workflows including charge generation, payment allocation, renewal flows, move-out settlement, and owner remittance.
**Status: READY FOR MIGRATION GENERATION AND DEPLOYMENT**
## Next Steps
1. Generate and apply migrations
2. Create test data via admin interface
3. Validate all workflows manually
4. Extend tests with integration scenarios
5. Add automated charge generation command
6. Deploy to staging environment
7. Conduct user acceptance testing
8. Plan production rollout
---
*Last Updated: 2024-01-XX*
*Implementation Status: COMPLETE*
生成結果の所感

会話ログ(13,392 行)では、models.py を 6 回に分けてドメインごとに積み上げるインクリメンタル戦略を取っていた。Ownership → Asset → Occupancy → Billing → Settlement → Maintenance の順で、毎回ファイル全体を再送しながら参照整合性を確認している。
この戦略ではコンテキスト後半で PP が 1,500 t/s 近辺から 1,000 t/s 近辺まで落ちるコストを払うが、各段階で整合性検証を入れるため、後戻り修正の総量を抑えられる。262k コンテキストは「長いだけ」ではなく、段階実装の検証ループに効いていた。
familiar オーケストレーターとのトレードオフ
現行の compute.home.arpa は GLM-5.1(オーケストレーター)と Qwen3-Coder-Next 80B×2(コーダー)を常駐させる構成が基本だが、今回の結果を見ると Qwen3.5-397B を主軸に置く選択も十分ある。GLM-5.1 は実行可能性とベンチ値を見て採用し、現在は Dagster でデータ収集を進めている段階。実務テンポを重視するなら、手戻りの少ない方へ寄せる判断になる。
ただし Qwen3.5-397B と GLM-5.1 を同時に CPU/GPU hybrid で回すと、CPU 側帯域の奪い合いが起きてどちらも速度が落ちる。現実的には同時運用が難しいので、オーケストレーター役をどちらに置くかは悩みどころになる。
| 構成 | TG 速度 | コンテキスト | ファインチューン |
|---|---|---|---|
| GLM-5.1 (常駐) | 約18-20 t/s | 128k | MIT |
| Qwen3.5-397B (バッチ) | 55.8 t/s | 262k | Apache-2.0 |
| Qwen3-Coder-Next 80B ×2 | 約40 t/s / instance | 1M | - |
GLM-5.1 を本気でファインチューンするなら、GCP での GPU コストはそれなりに重い。コスト込みで見ると、現状は Qwen3.5-397B のほうが運用のサイズ感に合っている。
次の検証では、GLM-5.1 単体でも同じ実務タスクを回して、双方でプランニング以外に委譲しているタスクを洗い出し、リプレイ実行で比較していきたい。
起動コマンド
podman run --rm --device nvidia.com/gpu=all \
-p 8000:8000 --shm-size 16g --cap-add=SYS_NICE \
-v /mnt/data/models/models--AesSedai--Qwen3.5-397B-A17B-GGUF:/models:ro,Z \
registry.home.arpa/ik_llama.cpp:cuda \
-m /models/.../Q4_K_M/Qwen3.5-397B-A17B-Q4_K_M-00001-of-00006.gguf \
--chat-template-kwargs '{"enable_thinking":false}' \
--ctx-size 262144 -ctk q8_0 -ctv q8_0 \
--parallel 1 --threads 15 --threads-batch 24 \
-b 4096 -ub 4096 -sm graph -ngl 99 \
--n-cpu-moe 15 -mla 3 -ger -amb 512 \
--jinja --warmup-batch \
--alias qwen3.5-397b-a17b
| パラメータ | 役割 |
|---|---|
-sm graph | GPU 分割スケジューリング |
--n-cpu-moe 15 | MoE エキスパートの CPU オフロード |
-mla 3 | Multi-head Latent Attention 最適化 |
-ger | Grouped Expert Routing 有効化 |
-ctk q8_0 -ctv q8_0 | KV キャッシュ量子化 |
-amb 512 | Attention max batch |
まとめ
コーディング用途に絞ると、モデル規模やベンチマークでは GLM-5.1 に魅力があるが、今回の実測ではQwen3.5-397Bの結果が良く、コーディングレベル、TGのテンポよさ、画像も扱える、なおかつぎりぎりfine-tuningも可能なサイズで、オーケストラロールにふさわしいのかもしれない。
